getIPaddrVM() call is too slow / may fail
Opened this issue · 2 comments
So there's an implicit limitation in how we obtain the IP address of a newly cloned VM. Currently, when a new VM is cloned, we scan the primary syslog file on the host system, in order to where the DHCP lease occurs and try to obtain the IP address of the clone by looking at DHCPACK and DHCPOFFER lines.
The problem is two-fold:
-
If the log file is rather huge (> 50MB), then this scan could take a non-trivial amount of time to complete (> 10s). One interim fix to this, would be to only 'tail' the log file, rather than scan it completely.
-
In the slight chance that the log file undergoes log-rotation while we are scanning for these DHCP messages, then we could miss them entirely (very unlikely, but possible). If this happens, then the StartManager.pl call will hang until the clone VM obtains a new DHCP lease (~10mins).
A better method of fixing this would probably be one that doesn't rely on syslog messages. Instead, we'd probably want to manually parse the dhcpd.leases file, located at /etc/vmware/vmnet1/dhcpd/dhcpd.leases. We could use the following perl library to perform this operation:
Author: kindlund
Okay, I've committed r1649, which should fix this problem. I'll leave this ticket open until #174 and #175 are completed. The only annoying thing is that the unit test for getIPaddrVM() no longer works properly with an empty VM -- it seems that doing a network boot inside the VM doesn't actually cause the VM to successfully obtain a DHCP lease. As such, I had to check a 60MB! iso into trunk/ in order to get a test VM to boot into a livecd environment so that the VM could get a proper DHCP lease (and thus pass the getIPaddrVM() unit test).
This is far from ideal.
If anyone has any smaller floppy/iso images that could accomplish the same thing, I'd be happy to use those instead. The only requirement is that the bootable image successfully obtain a DHCP lease.
Author: kindlund
Oh, still have to update the UserGuide, to remove references to dhcp_log. I think we can reduce our requirements, now that we no longer need to examine the /var/log/messages file, but I'll have to double check.