During the last months, I’ve been experimenting with Xen virtualization. An old computer, equipped with a Pentium III running at 700Mhz, 512MB of RAM and an 160GB IDE HDD runs four installations of my favorite Linux distribution, CentOS, one as a Dom0 and the other three as DomUs with 64MB of memory each.
I remember that one of the first things I needed to test was whether all those virtual machines could properly use my DHCP service, located on a separate machine within my LAN, and get a dynamic IP. Furthermore, each time dhclient ran on the Dom0 or any of the DomUs in order to obtain a dynamic IP address, it also sent a name (non FQDN) to the DHCP service. This name represented the name the machine wished to use as a hostname. The DHCP server should generate an FQDN out of that name and update the forward and reverse zones on the DNS server, so that each virtual machine’s FQDN name could properly resolve to the relevant IP address, which had been allocated to the VM by the DHCP service. All this had already been set up in my home LAN since a long time ago, but had never actually tested it with multiple computers or other devices and virtualization definitely provided me with this option.
While I was performing the operating system installations, everything seemed to work as expected. Each virtual machine obtained a dynamic IP address and the DNS records were updated correctly. Glad that things work, I turned off Dom0 after the tests.
At a later time, when I switched Dom0 on again, I noticed that I could not reach any of the virtual machines. Their fully qualified domain names that had been allocated to them by the DHCP service would not resolve to the proper IP. To make it worse, it seemed that the virtual machines had no active leases at all!
Soon I discovered that xendomains, the service responsible for starting and stopping the unprivileged Xen domains (DomU), whenever Domain Zero was shut down, it just saved the domain U’s state for later restoration instead of initiating the DomU’s shutdown procedure. When Dom0 was brought up again, xendomains restored the saved DomU states instead of forcing the domains to boot up normally.
I assume this is like suspending a laptop, which has obtained its IP automatically from a DHCP service within LAN A, moving it to a LAN B, and then bringing it up again within that LAN. It is almost certain that for an arbitrary amount of time you would experience connectivity problems.
In both cases above, at the time the machine resumes operations, the dhclient script (or any other similar script) is not run in order to renew the machine’s IP address.
Fortunately, this behaviour of the
xendomains service is configurable. In order to force all DomUs to shutdown, instead of suspending, during Domain 0′s shutdown, all you have to do is make following changes in
Leave empty the XENDOMAINS_SAVE variable. By default, it uses /var/lib/xen/save as the directory where the states of the DomUs are saved. By leaving it empty, the states of the virtual machines are not saved, but they are shut down as usual.
The second modification involves setting the XENDOMAINS_RESTORE variable to false. This determines whether saved domains will be restored from the directory set in the XENDOMAINS_SAVE variable during the Dom0 startup:
From now on, whenever Dom0 starts up, it will force all U domains to boot up normally. Contrariwise, whenever Dom0 shuts down, it will force all DomU to shut down as well. No domain state saving or restoration happens any more.
This means that the network service on each DomU, hence the dhclient script, will run every time the domain U starts up or shuts down, ensuring proper allocation of dynamic IP addresses and hostnames by the DHCP service. Of course, this adds much overhead to both the boot and power off process of Domain Zero (Dom0), but it seems that there is no other way to overcome this problem. If you know of a better way, please let me know.
The Xen DomU using dynamic IP and hostname by George Notaras, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.