[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).
On 11/24/2012 04:41 PM, Laine Stump wrote:
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>
5) With so many options, it may save lots of repetitive code in the parser/formatter to make a generic <option> element: <option name='dns-server' value='x.x.x.x'/> <option name='ntp-server' value='y.y.y.y'/> <option name='smtp-server' value='z.z.z.z'/> <option family='ipv6' name='dns-server' value='xxxx::1'/> <option number='201' value='/netboot/boot-dir/' force='yes'/> The final is an example of something I just noticed in the BZ I mentioned above - it is both using an option number and forcing the option to be sent back to the client even if the client doesn't request it. This is apparently needed for some clients. There is a precedent for the "name/value" type of object in nwfilter parameters. The advantages in this case are a) the code for the parser couple possibly be much smaller, with just a single enum + VIR_ENUM_(DECL|IMPL) b) it would be easier to support the options by number (which are all defined somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq) On the other hand, if we allowed any possible option by specifying a number (and even if not, depending on how the parser was implemented), it would be easier to create a situation where "bad stuff" could be injected into the dnsmasq commandline (we should have some type of intelligent parsing of the values - known options should have a type associated with them, and unknown should at least be checked for dangerous characters). Any opinions from those with more XML experience?
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 26.11.2012 21:12, Laine Stump wrote:
On 11/24/2012 04:41 PM, Laine Stump wrote:
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>
5) With so many options, it may save lots of repetitive code in the parser/formatter to make a generic <option> element:
<option name='dns-server' value='x.x.x.x'/> <option name='ntp-server' value='y.y.y.y'/> <option name='smtp-server' value='z.z.z.z'/> <option family='ipv6' name='dns-server' value='xxxx::1'/> <option number='201' value='/netboot/boot-dir/' force='yes'/>
The final is an example of something I just noticed in the BZ I mentioned above - it is both using an option number and forcing the option to be sent back to the client even if the client doesn't request it. This is apparently needed for some clients.
There is a precedent for the "name/value" type of object in nwfilter parameters. The advantages in this case are
a) the code for the parser couple possibly be much smaller, with just a single enum + VIR_ENUM_(DECL|IMPL)
b) it would be easier to support the options by number (which are all defined somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq)
On the other hand, if we allowed any possible option by specifying a number (and even if not, depending on how the parser was implemented), it would be easier to create a situation where "bad stuff" could be injected into the dnsmasq commandline (we should have some type of intelligent parsing of the values - known options should have a type associated with them, and unknown should at least be checked for dangerous characters).
Any opinions from those with more XML experience?
I lean towards 5) because I think it's the most general description. Sometimes I find myself in situation where I'm working on a new feature and the most time I spend thinking how to suit it into XML because this element is too narrow for it and I don't want to invent a new one, or something. Michal
On 11/27/2012 03:28 AM, Michal Privoznik wrote:
On 26.11.2012 21:12, Laine Stump wrote:
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>
On 11/24/2012 04:41 PM, Laine Stump wrote: 5) With so many options, it may save lots of repetitive code in the parser/formatter to make a generic <option> element:
<option name='dns-server' value='x.x.x.x'/> <option name='ntp-server' value='y.y.y.y'/> <option name='smtp-server' value='z.z.z.z'/> <option family='ipv6' name='dns-server' value='xxxx::1'/> <option number='201' value='/netboot/boot-dir/' force='yes'/>
The final is an example of something I just noticed in the BZ I mentioned above - it is both using an option number and forcing the option to be sent back to the client even if the client doesn't request it. This is apparently needed for some clients.
There is a precedent for the "name/value" type of object in nwfilter parameters. The advantages in this case are
a) the code for the parser couple possibly be much smaller, with just a single enum + VIR_ENUM_(DECL|IMPL)
b) it would be easier to support the options by number (which are all defined somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq)
On the other hand, if we allowed any possible option by specifying a number (and even if not, depending on how the parser was implemented), it would be easier to create a situation where "bad stuff" could be injected into the dnsmasq commandline (we should have some type of intelligent parsing of the values - known options should have a type associated with them, and unknown should at least be checked for dangerous characters).
Any opinions from those with more XML experience? I lean towards 5) because I think it's the most general description. Sometimes I find myself in situation where I'm working on a new feature and the most time I spend thinking how to suit it into XML because this element is too narrow for it and I don't want to invent a new one, or something.
Only sometimes? That's my biggest problem nearly 100% of the time :-) Thanks for voicing an opinion. I'll try an implementation that way and see how it turns out.
On 11/26/2012 03:12 PM, Laine Stump wrote:
5) With so many options, it may save lots of repetitive code in the parser/formatter to make a generic <option> element:
<option name='dns-server' value='x.x.x.x'/> <option name='ntp-server' value='y.y.y.y'/> <option name='smtp-server' value='z.z.z.z'/> <option family='ipv6' name='dns-server' value='xxxx::1'/> <option number='201' value='/netboot/boot-dir/' force='yes'/>
The final is an example of something I just noticed in the BZ I mentioned above - it is both using an option number and forcing the option to be sent back to the client even if the client doesn't request it. This is apparently needed for some clients.
There is a precedent for the "name/value" type of object in nwfilter parameters. The advantages in this case are
a) the code for the parser couple possibly be much smaller, with just a single enum + VIR_ENUM_(DECL|IMPL)
b) it would be easier to support the options by number (which are all defined somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq)
On the other hand, if we allowed any possible option by specifying a number (and even if not, depending on how the parser was implemented), it would be easier to create a situation where "bad stuff" could be injected into the dnsmasq commandline (we should have some type of intelligent parsing of the values - known options should have a type associated with them, and unknown should at least be checked for dangerous characters).
Any opinions from those with more XML experience?
I also prefer the new/separate option element. Some related observations: 1. Many of the dhcp options available with dnsmasq are IPv4 only and I am not sure that there is much support for additional IPv6 options in dhcp-sever or dhclient. 2. RA also has provisions for supplying the address of a nameserver and dnsmasq does provide this information for both state-full (DHCPv6) and state-less (SLAAC) operation. This is done automatically when dnsmasq has with enable-ra or ra-only specified. The address supplied by dnsmasq is the IPv6 link-local address on the machine it is running on. 3. As far as IPv6 options, I believe that this change is redundant to the support dnsmasq is providing. Of course, if you are using radvd for RA support, then, for IPv6, you could also specify the RDNSS and DNSSL (currently, this is not done by libvirt). 4. Doesn't this tie libvirt more strongly to dnsmasq? Don't get me wrong, I strongly believe in dnsmasq and its use by libvirt. I also believe that there would have to be an extremely good set of reasons to adopt something else. Gene
participants (3)
-
Gene Czarcinski -
Laine Stump -
Michal Privoznik