[libvirt] RFC: adding configuration for standard dhcp options to <network>
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).