RHEL Under VMware SRM

Latest response

In our environment, we use RedHat primarily as VMs under VMware. These VMs are statically IPed. We're beginning to implement Site Recovery Manager for DR purposes. We have some RHEL-base systems that leverage LikeWise for AD integration (our AD is too big and too complex for Winbind to function effectively/correctly). Unfortunately, one of the customers we're looking to place under SRM has security requirements that prevent the use of LikeWise and therefore precludes the use of LikeWise's DDNS update tool. Since these VMs are statically IPed, it seems like we wouldn't be able to leverage dhclient's DDNS update capabilities. Is there any recommended ways to make an RHEL 5.8 system issue a DDNS update request without dhclient being used?


Hey Thomas, looks like you might have stumped the Groups with this one! I'm going to follow up on this and see if I can find someone to resolve this question for you.

Hi Thomas,


My name is Robb and I'm a networking support engineer, and I'd like to try and help out.


Just to reiterate exactly what is happening (please correct me if I make a mistake or misunderstand something, as I am not terribly too familiar with VMware's recovery manager) you're attempting to, while using static IP's, make the FQDN or hostname resolvable in the event an IP should be changed or the network alter, without any manual input?  I understand the need for this, as to edit each system's hosts file on potentially hundreds of virtual machines is not exactly an easy task.


If this is the case, then I unfortunately don't know of a good tool to accomplish this.  LikeWise potentially could, but I completely understand a security need outweighs this.  To my knowledge, dhclient won't allow just the use of the DDNS capabilities it provides without actually being the assigner of the IP's, and in a static network environment I highly doubt this will function.


I'm checking with a few other engineers besides myself and I'll let you know if I can find something more concrete you can use or investigate.

What we ended up having to do was leverage a DDNS updater tool on failover. At boot, the Likewise-less VMs use an RC script to issue a DDNS update (using the BIND `nsupdate` tool). It's a hack but it appeared to work in initial testing.


Granted, the tradeoff in making the VM more secure means that we have to either weaken our DNS security (the DNS servers are only internally-reachable, so not too much additional exposure). We can probably go down the trusted-DNS path, but that will take longer to engineer and get approved.


The joys of custom security requirements for specific guests in a shared VI environment.

Hey Thomas,


Actually, that's quite clever - having the clients check in at boot.  I tried to duplicate a setup in a virtual environment (private network, one system serving as DNS, two others updating using nsupdate, just like you're doing) and did a few tests to see if there were any errors or cases where it wouldn't function or error out, like high network traffic or pausing the VM, and moving it between hypervisors.  Since it's just a DNS update, and should resolve to the same location regardless of where it's located, nothing seemed to interfere with anything else.  If something needs to change on-the-fly you might even stick the script in a cron job so you can just forget about it during operations without the need for reboot to run the script again; I've had to do something similar to that before in various environments.


You're right though, a trusted DNS system would be easier to manage and a less work-aroundish method, but I completely understand fitting within the customer's limitations on exactly how the environment needs to be.


--Robb Manes