There have been multiple requests over the last couple years to make the DHCP server of libvirt's virutal networks more configurable (for example, see the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=824573 ). You can see a full list of the options supported by dnsmasq with this command: dnsmasq --help dhcp The biggest question here is in exactly how to represent the options in the network XML. I can see a few different options, among them: 1) make each option its own element within <dhcp>, e.g.: <dnsServer family='ipv4' address='x.x.x.x'/> <dnsServer family='ipv6' address='xxxx:xxxx::1'/> <ntpServer address='y.y.y.y'/> <smtpServer address='z.z.z.z'/> 2) A variation of (1) where each option could appear only once, but with two attributes, one for ipv6 address and one for ipv4: <dnsServer address4='x.x.x.x'address6='xxxx:xxxx::1'/> <ntpServer address4='y.y.y.y'/> 3) have a repeatable "option" element (again, a subelement of <dhcp> that can contain any number of the options as attributes: <option family='ipv4' dnsServer='x.x.x.x' ntpServer='y.y.y.y' smtpServer='z.z.z.z'/> <option family='ipv6' dnsServer='xxxx:xxxx:1'/> (in this case, we may or may not support repeating <option> to add more options for the same family). 4) yet another variation, where each option is a subelement of <option family='xxxx'>: <option family='ipv4'> <dnsServer>x.x.x.x</dnsServer> <ntpServer>y.y.y.y</ntpServer> <smtpServer>z.z.z.z</smtpServer> </option> <option family='ipv6'> <dnsServer>xxxx:xxxx::1</dnsServer> </option> I'm not sure which of these would be more straightforward for a user. One thought I've had is that dnsmasq at least allows specifying different groups of guest addresses (with a "tag") and applying different options to addresses with different tags. I don't know if we'll ever use that capability, but if we do it *seems* like any of these methods could be adapted to specifying multiple groups. Does anyone have a preference? (I have a narrow preference for (1), simply because it was the first to come to my mind, but could easily be swayed to one of the others, or something else, given a logical reason). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list