[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[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).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]