Re: [libvirt] [Dnsmasq-discuss] Chaining instances?
This discussion should really be taking place on libvir-list - I'm Cc'ing it there. On 02/24/2013 04:11 PM, TJ wrote:
On 24/02/13 19:19, Laine Stump wrote:
I wondered if maybe configuring the libvirtd dnsmasq instances to be dhcp proxies for the LAN dnsmasq, and use multiple dhcp-range's with tags might do it?
My brain is a bit fried right now having had to fix several bugs in vmbuilder and libvirt, plus add new functionality to libvirtd to allow its dnsmasq instance to read a conf-file and use a separate log-facility, What you're talking about doing sounds *very* useful to have supported
On 02/24/2013 05:09 AM, TJ wrote: directly in libvirt, but you may want to contact libvirt's upstream developers (at libvir-list@redhat.com, or on irc.oftc.net in #virt) prior to expending a lot of effort on libvirt code - in general a problem may already be solved in a different manner, or somebody else may already be working on it. Failing that, there may have already been considerable debate on a particular subject, and a path to a solution generally agreed on, but with nobody yet working on the code. It turns out that what I need(ed) to do was completely *disable* libvirt's use of dnsmasq and instead use Simon's related "dhcp-helper" program which acts as a full dhcp-relay using, f.e:
/usr/sbin/dhcp-helper -u libvirt-dnsmasq -i virbr1 -b eth0
This forwards all requests to the primary dnsmasq DHCP server on the LAN which matches against the appropriate dhcp-range:
# physical network leases dhcp-range=set:phys,10.254.251.50,10.254.251.199,255.255.255.0,1440m # subnet for VMs on server1 dhcp-range=set:vmlan1,10.254.1.100,10.254.1.199,255.255.255.0,1440m # default route (gateway) dhcp-option=tag:phys,option:router,10.254.251.1 dhcp-option=tag:vmlan1,option:router,10.254.1.1 # DNS server dhcp-option=6,10.254.251.1
To that end this evening I added two additional options to libvirt:
<dnsmasq enabled='true'/> <dhcphelper enabled='false'/>
libvirt's XML should remain implementation-agnostic. We don't want to have an option to disable the specific implementation of dns+dhcp called "dnsmasq"; rather we want to be able to enable/disable a network's dhcp server and/or dns server. (The reason for this is that we want to leave the door open for someone to implement a different backend using a different dhcp server and/or dns server and be able to use the same configuration.) We have actually previously discussed disabling dns and/or dhcp (see http://www.redhat.com/archives/libvir-list/2012-November/msg00861.html). It is already possible to completely disable dhcp - simply don't include a <dhcp> element in the network definition. As for dns, from the very beginning dns has been *always* enabled on all networks, so even though there is a <dns> element, simply having not having one is not a valid way to say "no dns server" (as it would cause backward compatibility problems with existing installations). Instead, the conclusion of the above-mentioned thread was that the proper way to handle this would be to add an "enable" element to the existing <dns> element, which would default to "yes". To disable libvirt-supplied dns services for a subnet, you would just put: <dns enable='no'/> in the network definition. In the case that dns had enable='no' AND there was no <dhcp> element, dnsmasq simply wouldn't be started at all. That hasn't been implemented yet, but shouldn't be too complex to do. As for dhcp-helper, aside from the fact that again you've created an option that is specific to a particular implementation of what is needed, that command isn't universally available anyway (it's not in any package for Fedora/RHEL, for example), and I'm not sure that it's really necessary to have it started up by libvirt anyway - can it detect newly created/upped interfaces as dnsmasq can? If so, it could be started up by regular host system config even before libvirt was started.
These are the default values when the options are *not* defined. They allow the admin to disable dnsmasq entirely:
<dnsmasq enabled='false'/>
and to enable dhcp-helper:
<dhcphelper enabled='true'/>
Using two new functions:
int networkBuildDhcphelperArgv(...) int networkBuildDhcpHelperCommandLine(...)
the existing function:
int networkStartDhcpDaemon(...)
is able to launch either or both of dnsmasq and dhcp-helper with the correct options.
dhcp-helper's "-i" option is filled from network->def->bridge and its "-b" option is taken from the first forward device declared in a <forward dev='?'/> or <interface dev='?'/>. If no forward device is declared it throws a VIR_ERR_INVALID_INTERFACE error with appropriate explanatory text.
On 02/25/2013 02:05 AM, Laine Stump wrote:
This discussion should really be taking place on libvir-list - I'm Cc'ing it there.
Bah. I'm not sure what happened, but I ended up not actually Cc'ing...
On 24/02/13 19:19, Laine Stump wrote:
I wondered if maybe configuring the libvirtd dnsmasq instances to be dhcp proxies for the LAN dnsmasq, and use multiple dhcp-range's with tags might do it?
My brain is a bit fried right now having had to fix several bugs in vmbuilder and libvirt, plus add new functionality to libvirtd to allow its dnsmasq instance to read a conf-file and use a separate log-facility, What you're talking about doing sounds *very* useful to have supported
On 02/24/2013 05:09 AM, TJ wrote: directly in libvirt, but you may want to contact libvirt's upstream developers (at libvir-list@redhat.com, or on irc.oftc.net in #virt) prior to expending a lot of effort on libvirt code - in general a problem may already be solved in a different manner, or somebody else may already be working on it. Failing that, there may have already been considerable debate on a particular subject, and a path to a solution generally agreed on, but with nobody yet working on the code. It turns out that what I need(ed) to do was completely *disable* libvirt's use of dnsmasq and instead use Simon's related "dhcp-helper" program which acts as a full dhcp-relay using, f.e:
/usr/sbin/dhcp-helper -u libvirt-dnsmasq -i virbr1 -b eth0
This forwards all requests to the primary dnsmasq DHCP server on the LAN which matches against the appropriate dhcp-range:
# physical network leases dhcp-range=set:phys,10.254.251.50,10.254.251.199,255.255.255.0,1440m # subnet for VMs on server1 dhcp-range=set:vmlan1,10.254.1.100,10.254.1.199,255.255.255.0,1440m # default route (gateway) dhcp-option=tag:phys,option:router,10.254.251.1 dhcp-option=tag:vmlan1,option:router,10.254.1.1 # DNS server dhcp-option=6,10.254.251.1
To that end this evening I added two additional options to libvirt:
<dnsmasq enabled='true'/> <dhcphelper enabled='false'/>
On 02/24/2013 04:11 PM, TJ wrote: libvirt's XML should remain implementation-agnostic. We don't want to have an option to disable the specific implementation of dns+dhcp called "dnsmasq"; rather we want to be able to enable/disable a network's dhcp server and/or dns server. (The reason for this is that we want to leave the door open for someone to implement a different backend using a different dhcp server and/or dns server and be able to use the same configuration.)
We have actually previously discussed disabling dns and/or dhcp (see http://www.redhat.com/archives/libvir-list/2012-November/msg00861.html). It is already possible to completely disable dhcp - simply don't include a <dhcp> element in the network definition. As for dns, from the very beginning dns has been *always* enabled on all networks, so even though there is a <dns> element, simply having not having one is not a valid way to say "no dns server" (as it would cause backward compatibility problems with existing installations).
Instead, the conclusion of the above-mentioned thread was that the proper way to handle this would be to add an "enable" element to the existing <dns> element, which would default to "yes". To disable libvirt-supplied dns services for a subnet, you would just put:
<dns enable='no'/>
in the network definition. In the case that dns had enable='no' AND there was no <dhcp> element, dnsmasq simply wouldn't be started at all. That hasn't been implemented yet, but shouldn't be too complex to do.
As for dhcp-helper, aside from the fact that again you've created an option that is specific to a particular implementation of what is needed, that command isn't universally available anyway (it's not in any package for Fedora/RHEL, for example), and I'm not sure that it's really necessary to have it started up by libvirt anyway - can it detect newly created/upped interfaces as dnsmasq can? If so, it could be started up by regular host system config even before libvirt was started.
These are the default values when the options are *not* defined. They allow the admin to disable dnsmasq entirely:
<dnsmasq enabled='false'/>
and to enable dhcp-helper:
<dhcphelper enabled='true'/>
Using two new functions:
int networkBuildDhcphelperArgv(...) int networkBuildDhcpHelperCommandLine(...)
the existing function:
int networkStartDhcpDaemon(...)
is able to launch either or both of dnsmasq and dhcp-helper with the correct options.
dhcp-helper's "-i" option is filled from network->def->bridge and its "-b" option is taken from the first forward device declared in a <forward dev='?'/> or <interface dev='?'/>. If no forward device is declared it throws a VIR_ERR_INVALID_INTERFACE error with appropriate explanatory text.
2013/2/25 Laine Stump <laine@laine.org>
On 02/25/2013 02:05 AM, Laine Stump wrote:
This discussion should really be taking place on libvir-list - I'm Cc'ing it there.
Bah. I'm not sure what happened, but I ended up not actually Cc'ing...
On 02/24/2013 04:11 PM, TJ wrote:
On 24/02/13 19:19, Laine Stump wrote:
On 02/24/2013 05:09 AM, TJ wrote:
I wondered if maybe configuring the libvirtd dnsmasq instances to be
My brain is a bit fried right now having had to fix several bugs in
vmbuilder and libvirt, plus add new functionality to libvirtd to allow its dnsmasq instance to read a conf-file and use a separate log-facility, What you're talking about doing sounds *very* useful to have supported directly in libvirt, but you may want to contact libvirt's upstream developers (at libvir-list@redhat.com, or on irc.oftc.net in #virt) prior to expending a lot of effort on libvirt code - in general a problem may already be solved in a different manner, or somebody else may already be working on it. Failing that, there may have already been considerable debate on a particular subject, and a path to a solution generally agreed on, but with nobody yet working on the code. It turns out that what I need(ed) to do was completely *disable*
dhcp proxies for the LAN dnsmasq, and use multiple dhcp-range's with tags might do it? libvirt's use of dnsmasq
and instead use Simon's related "dhcp-helper" program which acts as a full dhcp-relay using, f.e:
/usr/sbin/dhcp-helper -u libvirt-dnsmasq -i virbr1 -b eth0
This forwards all requests to the primary dnsmasq DHCP server on the LAN which matches against the appropriate dhcp-range:
# physical network leases dhcp-range=set:phys,10.254.251.50,10.254.251.199,255.255.255.0,1440m # subnet for VMs on server1 dhcp-range=set:vmlan1,10.254.1.100,10.254.1.199,255.255.255.0,1440m # default route (gateway) dhcp-option=tag:phys,option:router,10.254.251.1 dhcp-option=tag:vmlan1,option:router,10.254.1.1 # DNS server dhcp-option=6,10.254.251.1
To that end this evening I added two additional options to libvirt:
<dnsmasq enabled='true'/> <dhcphelper enabled='false'/> libvirt's XML should remain implementation-agnostic. We don't want to have an option to disable the specific implementation of dns+dhcp called "dnsmasq"; rather we want to be able to enable/disable a network's dhcp server and/or dns server. (The reason for this is that we want to leave the door open for someone to implement a different backend using a different dhcp server and/or dns server and be able to use the same configuration.)
We have actually previously discussed disabling dns and/or dhcp (see http://www.redhat.com/archives/libvir-list/2012-November/msg00861.html). It is already possible to completely disable dhcp - simply don't include a <dhcp> element in the network definition. As for dns, from the very beginning dns has been *always* enabled on all networks, so even though there is a <dns> element, simply having not having one is not a valid way to say "no dns server" (as it would cause backward compatibility problems with existing installations).
Instead, the conclusion of the above-mentioned thread was that the proper way to handle this would be to add an "enable" element to the existing <dns> element, which would default to "yes". To disable libvirt-supplied dns services for a subnet, you would just put:
<dns enable='no'/>
in the network definition. In the case that dns had enable='no' AND there was no <dhcp> element, dnsmasq simply wouldn't be started at all. That hasn't been implemented yet, but shouldn't be too complex to do.
As for dhcp-helper, aside from the fact that again you've created an option that is specific to a particular implementation of what is needed, that command isn't universally available anyway (it's not in any package for Fedora/RHEL, for example), and I'm not sure that it's really necessary to have it started up by libvirt anyway - can it detect newly created/upped interfaces as dnsmasq can? If so, it could be started up by regular host system config even before libvirt was started.
These are the default values when the options are *not* defined. They allow the admin to disable dnsmasq entirely:
<dnsmasq enabled='false'/>
and to enable dhcp-helper:
<dhcphelper enabled='true'/>
Using two new functions:
int networkBuildDhcphelperArgv(...) int networkBuildDhcpHelperCommandLine(...)
the existing function:
int networkStartDhcpDaemon(...)
is able to launch either or both of dnsmasq and dhcp-helper with the correct options.
dhcp-helper's "-i" option is filled from network->def->bridge and its "-b" option is taken from the first forward device declared in a <forward dev='?'/> or <interface dev='?'/>. If no forward device is declared it throws a VIR_ERR_INVALID_INTERFACE error with appropriate explanatory text.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
I thinks it's better that if we can put dnsmasq args or options in a conf file, so we can do some custom through this conf file. I've added a Bug 913446 in redhat bugzilla,but seems no one take care of this bug?
On 02/25/2013 09:08 PM, Gao Yongwei wrote:
I thinks it's better that if we can put dnsmasq args or options in a conf file, so we can do some custom through this conf file. I've added a Bug 913446 in redhat bugzilla,but seems no one take care of this bug?
This has been discussed extensively on the list before, and we specifically *don't* want to do it. Gene Czarcinski even submitted a patch that would do it, and that patch was rejected (and I *think* he agreed with our reasoning :-) The problem is that when you allow a user to silently subvert the config that is shown in libvirt's XML, and the system stops working, the user will send a plea for help to irc/mailing list (or open a ticket with their Linux support vendor), and the people they ask for support will say "show us the output of 'virsh net-dumpxml mynetwork'", which they will send, and then a comedy of errors will ensue until someone finally realizes that there is some "extra" configuration that the user isn't telling us about. There are two solutions to that: 1) add an element for the specific option you want to control in libvirt's network XML. Some knobs are already there, and others are being added. 2) add a private "dnsmasq" namespace to libvirt's network xml, with provisions for directly passing through dnsmasq commandline options from the xml to the conf file. This would be similar to what has already been done for qemu: http://libvirt.org/drvqemu.html#qemucommand The difference between these and the idea of simply allowing a user-written conf file is that everything about the network's config would then be available in "virsh net-dumpxml $netname". As far as the bug you've filed, it takes awhile for bugs to be triaged. (At a first glance, it seems reasonable to add such an option, since it is a standard part of the dhcp protocol. We might need to do something about specifying different units for the lease time.)
2013/2/28 Laine Stump <laine@laine.org>
On 02/25/2013 09:08 PM, Gao Yongwei wrote:
I thinks it's better that if we can put dnsmasq args or options in a conf file, so we can do some custom through this conf file. I've added a Bug 913446 in redhat bugzilla,but seems no one take care of this bug?
This has been discussed extensively on the list before, and we specifically *don't* want to do it. Gene Czarcinski even submitted a patch that would do it, and that patch was rejected (and I *think* he agreed with our reasoning :-)
The problem is that when you allow a user to silently subvert the config that is shown in libvirt's XML, and the system stops working, the user will send a plea for help to irc/mailing list (or open a ticket with their Linux support vendor), and the people they ask for support will say "show us the output of 'virsh net-dumpxml mynetwork'", which they will send, and then a comedy of errors will ensue until someone finally realizes that there is some "extra" configuration that the user isn't telling us about.
There are two solutions to that:
1) add an element for the specific option you want to control in libvirt's network XML. Some knobs are already there, and others are being added.
2) add a private "dnsmasq" namespace to libvirt's network xml, with provisions for directly passing through dnsmasq commandline options from the xml to the conf file. This would be similar to what has already been done for qemu: http://libvirt.org/drvqemu.html#qemucommand
The difference between these and the idea of simply allowing a user-written conf file is that everything about the network's config would then be available in "virsh net-dumpxml $netname".
As far as the bug you've filed, it takes awhile for bugs to be triaged. (At a first glance, it seems reasonable to add such an option, since it is a standard part of the dhcp protocol. We might need to do something about specifying different units for the lease time.)
I 'd better like 2nd solution,because as time goes by,people may need to use tons of different options of dnsmasq to meet new requirments.
participants (2)
-
Gao Yongwei -
Laine Stump