When using libvirt, you define virtual networks to facilitate interactions between different virtual machines and/or the outside world. Regardless whether you use virsh or virt-manager, the result will always be a piece of XML code defining the network.Here’s an example:
<network> <name>Win7</name> <uuid>7965a350-859e-0269-944f-a4cd4b5f1778</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' delay='0' /> <mac address='52:54:00:74:28:39'/> <ip address='192.168.100.1' netmask='255.255.255.0'> <tftp root='/daten/Support/PXE' /> <dhcp> <range start='192.168.100.10' end='192.168.100.29' /> <host mac='52:54:00:96:81:97' name='host1' ip='192.168.100.30' /> <host mac='52:54:00:bd:65:d7' name='host2' ip='192.168.100.40' /> <bootp file='ipxe.pxe' /> </dhcp> </ip> </network>
The <dhcp> block causes libvirt to emit appropriate configuration statements to the dnsmasq DNS/DHCP server used in the background.
Now certain setups require more fine-grained control over the DHCP server. For instance, windows clients may like to be told the IP of a WINS server via DHCP option 44. Or you may want to stop Windows 7 from flooding your DHCP messages. That’s currently not possible with libvirtd (see eg. RedHat BZ #824573).
Laine Stump discussed various ways to implement such behavior in terms of XML statements. Since he didn’t get around to this issue himself yet, I went ahead and implemented support for a new <option> tag: Add support for <option> tag in network config. With this patch, you can now define DHCP options like this:
<dhcp> <option number="44" value="192.168.100.4" /> </dhcp>
Let’s see where this goes.