[libvirt] dhcp6, radvd, ip6tables, etc.
OK, I have the basic implementation for libvirt support of dhcp6. Let me say again that 98% of the work was already done. There is still a bunch of work today which includes writing some tests, understanding how things such as bootp, dhcp-host, etc. should be supported with dhcp6, as well as the items I discuss below. 1. Right now, the only way that dhcp6 is in effect is if there is no dhcp4 range definition. This will be fixed/expanded so that, at a minimum, you can have both a dhcp4 and dhcp6 on the same interface. However, it appears to be easier to just pass to dnsmasq ANY/EVERY dhcp4 range or dhcp6 range defined in the xml. Comments? Any input on which approach to use or avoid? 2. I have modified radvd so both stateful (dhcp6) and stateless (SLAAC) addressing is supported with radvd for the default route. This is done on an interface basis (that is the way it works). So if any dhcp6 range is specified, then stateful is used. The way this is implemented will make it easy to add some tests verifying that the configuration parameters are working. I intend this to be an expansion to networkxml2argvtest since it has the xml specification files which determine both dnsmasq and radvd configuration parameters. 3. After completing what I thought was code that should result in a guest getting dhcp6 addresses, it was not working. Once more it took me a little time to realize that ip6tables rules were blocking it. [I have been down this path before, you would think I would realize the problem sooner.] 3a. In looking over the ip6tables rules, I saw a whole bunch of additions at the top of the INPUT chain which were accepts for udp/tcp port 53. In looking at the code in bridge_driver.c, I found that, every time a network device was started, 3 FORWARD rules and 2 INPUT rules were added, but, when the network device was destroyed, only the 3 FORWARD rules were removed. I believe this is a bug (but not high priority) and I will be submitting a separate patch to fix this. 3b. There are two different approaches for the rule which allows the dhcp6 server to work. I could add (actually insert) one rule to the INPUT chain which accepted the packet if it is "-d ff02::1:2 "--dport 547". Or, I could add (insert) a rule specifying "-i virbr__" for every IPv6 device which would be removed when the device was destroyed. 4. After getting all of this working to my satisfaction, my next mountain to climb is VM ... it really does not like network xml definitions which include a dhcp-range for an ipv6 definition. Comments? NOTE: I am implementing all of this assuming that my previous patches have been accepted ... the ones for creating a dnsmasq conf-file for parameters rather than using the dnsmasq command-line. I am sure that someone could spend the time refitting the dhcp6 patches to the old code but why get aggravated? If you folks do not want to do things that way, fine, please say so. But if it is going to be accepted, then I would like some indication of this. Gene
On 10/27/2012 03:18 PM, Gene Czarcinski wrote:
OK, I have the basic implementation for libvirt support of dhcp6. Let me say again that 98% of the work was already done. There is still a bunch of work today which includes writing some tests, understanding how things such as bootp, dhcp-host, etc. should be supported with dhcp6, as well as the items I discuss below.
1. Right now, the only way that dhcp6 is in effect is if there is no dhcp4 range definition. This will be fixed/expanded so that, at a minimum, you can have both a dhcp4 and dhcp6 on the same interface. However, it appears to be easier to just pass to dnsmasq ANY/EVERY dhcp4 range or dhcp6 range defined in the xml.
Comments? Any input on which approach to use or avoid? For the current situation, the implementation is for one (the first) IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough little gotchas that need to be worked out.
2. I have modified radvd so both stateful (dhcp6) and stateless (SLAAC) addressing is supported with radvd for the default route. This is done on an interface basis (that is the way it works). So if any dhcp6 range is specified, then stateful is used. The way this is implemented will make it easy to add some tests verifying that the configuration parameters are working. I intend this to be an expansion to networkxml2argvtest since it has the xml specification files which determine both dnsmasq and radvd configuration parameters.
3. After completing what I thought was code that should result in a guest getting dhcp6 addresses, it was not working. Once more it took me a little time to realize that ip6tables rules were blocking it. [I have been down this path before, you would think I would realize the problem sooner.]
3a. In looking over the ip6tables rules, I saw a whole bunch of additions at the top of the INPUT chain which were accepts for udp/tcp port 53. In looking at the code in bridge_driver.c, I found that, every time a network device was started, 3 FORWARD rules and 2 INPUT rules were added, but, when the network device was destroyed, only the 3 FORWARD rules were removed. I believe this is a bug (but not high priority) and I will be submitting a separate patch to fix this.
3b. There are two different approaches for the rule which allows the dhcp6 server to work. I could add (actually insert) one rule to the INPUT chain which accepted the packet if it is "-d ff02::1:2 "--dport 547". Or, I could add (insert) a rule specifying "-i virbr__" for every IPv6 device which would be removed when the device was destroyed. OBE - I chose the approach of adding (and removing) a rule per interface. The rule adds "--dport 547" but does NOT specify "-d ff02::1:2". This works With the radvd configuration and a dhcp-range specified for a ipv6 subnet, a guest will get a dhcp6 address and RA default route.
4. After getting all of this working to my satisfaction, my next mountain to climb is VM ... it really does not like network xml definitions which include a dhcp-range for an ipv6 definition.
Comments?
NOTE: I am implementing all of this assuming that my previous patches have been accepted ... the ones for creating a dnsmasq conf-file for parameters rather than using the dnsmasq command-line.
I am sure that someone could spend the time refitting the dhcp6 patches to the old code but why get aggravated? If you folks do not want to do things that way, fine, please say so. But if it is going to be accepted, then I would like some indication of this.
NC ... working fine. 5. As far as I can tell (or at least this is for dnsmasq), "dhcp-no-override", "enable-tftp", "tftp-root=", and "dhcp-boot=" are all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not looked to see what network_conf.c does. 6. Handling of the info for addn-hosts file and the dhcp-hostsfile. This currently works because things are forced so that one and only one IPv4 dhcp definition will be handled. With the addition of IPv6 dhcp, things fall apart. 6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file in both form and function. The <dns>-<host> specification is done on an interface bases and, thus, the processing of the data and creation of the file should only be done once. 6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for every ip definition that is processed for dhcp. Initially, this will be for dhcp4 only until I can figure out how to do it for dhcp6. 6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two functions [one for addn-hosts and one for dhcp-hosts]. Additionally, all the functions which call dnsmasqSave() need to be reworked appropriately. 7. So far, the only things I have done involving the xml specification is to enable <dhcp> for IPv6. However, the xml to specify a dns addn-hosts appears, IMHO, to be overly verbose and complicated. So, while allowing the current xml to be valid, I suggest adding an alternate form for which is similar to that used for dhcp-host. An example is "<host ip='1.2.3.4' name='one' />" Comments, suggestions, etc. still appreciated. Gene
On 10/29/2012 08:26 AM, Gene Czarcinski wrote:
OK, I have the basic implementation for libvirt support of dhcp6. Let me say again that 98% of the work was already done. There is still a bunch of work today which includes writing some tests, understanding how things such as bootp, dhcp-host, etc. should be supported with dhcp6, as well as the items I discuss below.
1. Right now, the only way that dhcp6 is in effect is if there is no dhcp4 range definition. This will be fixed/expanded so that, at a minimum, you can have both a dhcp4 and dhcp6 on the same interface. However, it appears to be easier to just pass to dnsmasq ANY/EVERY dhcp4 range or dhcp6 range defined in the xml.
Comments? Any input on which approach to use or avoid? For the current situation, the implementation is for one (the first) IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough
On 10/27/2012 03:18 PM, Gene Czarcinski wrote: little gotchas that need to be worked out.
I think that is the proper thing to do for now. As discussed earlier, before supporting dhcp on multiple subnets of the same protocol (ipv6 vs ipv4) we would need to decide why and how we want to do that - IPs assigned from different subnets need to be matched with the IP address of that subnet, and it will take a more complicated dnsmasq commandline to do that, iirc.
2. I have modified radvd so both stateful (dhcp6) and stateless (SLAAC) addressing is supported with radvd for the default route. This is done on an interface basis (that is the way it works). So if any dhcp6 range is specified, then stateful is used. The way this is implemented will make it easy to add some tests verifying that the configuration parameters are working. I intend this to be an expansion to networkxml2argvtest since it has the xml specification files which determine both dnsmasq and radvd configuration parameters.
NC ... working fine.
3. After completing what I thought was code that should result in a guest getting dhcp6 addresses, it was not working. Once more it took me a little time to realize that ip6tables rules were blocking it. [I have been down this path before, you would think I would realize the problem sooner.]
3a. In looking over the ip6tables rules, I saw a whole bunch of additions at the top of the INPUT chain which were accepts for udp/tcp port 53. In looking at the code in bridge_driver.c, I found that, every time a network device was started, 3 FORWARD rules and 2 INPUT rules were added, but, when the network device was destroyed, only the 3 FORWARD rules were removed. I believe this is a bug (but not high priority) and I will be submitting a separate patch to fix this.
3b. There are two different approaches for the rule which allows the dhcp6 server to work. I could add (actually insert) one rule to the INPUT chain which accepted the packet if it is "-d ff02::1:2 "--dport 547". Or, I could add (insert) a rule specifying "-i virbr__" for every IPv6 device which would be removed when the device was destroyed. OBE - I chose the approach of adding (and removing) a rule per interface. The rule adds "--dport 547" but does NOT specify "-d ff02::1:2".
I haven't looked at how dhcp6 works, but if its anything like dhcp4, the IP address is irrelevant and shouldn't be included in the rule. As long as your rule specifies both the interface and port, that should be fine (take a look at the rules already being added for dhcp4) (and no, I have absolutely no idea why we add a rule to allow *tcp* on the dhcp port. It's just been that way since the first day I set eyes on the code).
This works With the radvd configuration and a dhcp-range specified for a ipv6 subnet, a guest will get a dhcp6 address and RA default route.
Interesting - so both radvd and dnsmasq are involved, correct?
4. After getting all of this working to my satisfaction, my next mountain to climb is VM ... it really does not like network xml definitions which include a dhcp-range for an ipv6 definition.
Comments?
NOTE: I am implementing all of this assuming that my previous patches have been accepted ... the ones for creating a dnsmasq conf-file for parameters rather than using the dnsmasq command-line.
I have no problem with the "convert from long commandline to conf file" patch except for the bit that points to a "conf directory" where user supplied conf files can be added. Aside from that part needing to be in a spearate patch, if we're going to add that kind of configurability, we need to do it in a way that will allow us to easily see that the user is playing outside the fence (otherwise we spend a lot of time chasing "bugs" that end up being caused by user-supplied options). Because we're in freeze right now I haven't spent a lot of time discussing that, but planned to send a message about it when I get a minute.
I am sure that someone could spend the time refitting the dhcp6 patches to the old code but why get aggravated? If you folks do not want to do things that way, fine, please say so. But if it is going to be accepted, then I would like some indication of this.
5. As far as I can tell (or at least this is for dnsmasq), "dhcp-no-override", "enable-tftp", "tftp-root=", and "dhcp-boot=" are all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not looked to see what network_conf.c does.
"what network_conf.c does"? Well, it of course doesn't deal directly with those options, but the config that feeds into some of those options is parsed in virNetworkIPParseXML(), and is only done if the <ip> element is ipv4. But then you've already seen that code if you have dhcp working for ipv6 - the <dhcp> element is also only parsed for ipv6. The format-side code doesn't have that extra check; I guess I figured that if there was no way to configure ipv6 with dhcp or tftp, it was safe to assume any ip element with dhcp or tftp info was ipv4 anyway.
6. Handling of the info for addn-hosts file and the dhcp-hostsfile. This currently works because things are forced so that one and only one IPv4 dhcp definition will be handled. With the addition of IPv6 dhcp, things fall apart.
6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file in both form and function. The <dns>-<host> specification is done on an interface bases and, thus, the processing of the data and creation of the file should only be done once.
6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for every ip definition that is processed for dhcp. Initially, this will be for dhcp4 only until I can figure out how to do it for dhcp6.
6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two functions [one for addn-hosts and one for dhcp-hosts]. Additionally, all the functions which call dnsmasqSave() need to be reworked appropriately.
I've actually never liked the "dnsmasqContext" concept, as it seems like overkill and has conceptual problems such as what you've described. I would be just as happy with replacements that were simpler and easier to deal with. I think part of what complicates dnsmasq.[hc] is that it's in the util directory, so it isn't allowed to understand the contents of virNetworkDef, and must instead be sent the list of hosts in a simpler format. If, instead, there was a file src/network/bridge_dnsmasq.[hc], that could have functions that took virNetworkDef as an arg, and just immediately return a string (or, in a separate function, write to a file). That should simplify calling, and writing tests. And existing dnsmasq-related functions in bridge_driver.c could be moved there as well, reducing clutter in bridge_driver.c. (Of course I'm saying all this without ever seriously considering it, just talking off the cuff, so I may be completely wrong :-)
7. So far, the only things I have done involving the xml specification is to enable <dhcp> for IPv6. However, the xml to specify a dns addn-hosts appears, IMHO, to be overly verbose and complicated.
It is made that way because a single IP address may have multiple hostnames associated with it, and we want to avoid having multiple methods of describing the same thing. What you propose in the next couple sentences was already proposed, tried, and rejected when dns host support was originally added.
So, while allowing the current xml to be valid, I suggest adding an alternate form for which is similar to that used for dhcp-host. An example is "<host ip='1.2.3.4' name='one' />"
There are a few places in libvirt's XML where the same thing can be expressed in two different ways, but that is only done when necessary because the existing XML is unable to completely describe the new functionality but backward compatibility is required. It creates all sorts of problems when formatting the config back into XML though (which of the two do you choose? Or do you do both? Either of these is a bad answer), therefore we definitely don't want to do that except in cases where it is absolutely necessary; this isn't one of those cases.
On 10/29/2012 04:08 PM, Laine Stump wrote: > On 10/29/2012 08:26 AM, Gene Czarcinski wrote: >> On 10/27/2012 03:18 PM, Gene Czarcinski wrote: >>> OK, I have the basic implementation for libvirt support of dhcp6. Let >>> me say again that 98% of the work was already done. There is still a >>> bunch of work today which includes writing some tests, understanding >>> how things such as bootp, dhcp-host, etc. should be supported with >>> dhcp6, as well as the items I discuss below. >>> >>> 1. Right now, the only way that dhcp6 is in effect is if there is no >>> dhcp4 range definition. This will be fixed/expanded so that, at a >>> minimum, you can have both a dhcp4 and dhcp6 on the same interface. >>> However, it appears to be easier to just pass to dnsmasq ANY/EVERY >>> dhcp4 range or dhcp6 range defined in the xml. >>> >>> Comments? Any input on which approach to use or avoid? >> For the current situation, the implementation is for one (the first) >> IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough >> little gotchas that need to be worked out. > I think that is the proper thing to do for now. As discussed earlier, > before supporting dhcp on multiple subnets of the same protocol (ipv6 vs > ipv4) we would need to decide why and how we want to do that - IPs > assigned from different subnets need to be matched with the IP address > of that subnet, and it will take a more complicated dnsmasq commandline > to do that, iirc. I cannot think of a good reason to have multiple IPv4 or IPv6 dhcp-range specification. Some day, someone will come up with a good reason but, for right now, I believe that one IPv4 and one IPv6 dhcp-range specifications is one of those "good enough" answers. > >>> 2. I have modified radvd so both stateful (dhcp6) and stateless >>> (SLAAC) addressing is supported with radvd for the default route. >>> This is done on an interface basis (that is the way it works). So if >>> any dhcp6 range is specified, then stateful is used. The way this is >>> implemented will make it easy to add some tests verifying that the >>> configuration parameters are working. I intend this to be an >>> expansion to networkxml2argvtest since it has the xml specification >>> files which determine both dnsmasq and radvd configuration parameters. >>> >> NC ... working fine. >>> 3. After completing what I thought was code that should result in a >>> guest getting dhcp6 addresses, it was not working. Once more it took >>> me a little time to realize that ip6tables rules were blocking it. [I >>> have been down this path before, you would think I would realize the >>> problem sooner.] >>> >>> 3a. In looking over the ip6tables rules, I saw a whole bunch of >>> additions at the top of the INPUT chain which were accepts for >>> udp/tcp port 53. In looking at the code in bridge_driver.c, I found >>> that, every time a network device was started, 3 FORWARD rules and 2 >>> INPUT rules were added, but, when the network device was destroyed, >>> only the 3 FORWARD rules were removed. I believe this is a bug (but >>> not high priority) and I will be submitting a separate patch to fix >>> this. >>> >>> 3b. There are two different approaches for the rule which allows the >>> dhcp6 server to work. I could add (actually insert) one rule to the >>> INPUT chain which accepted the packet if it is "-d ff02::1:2 "--dport >>> 547". Or, I could add (insert) a rule specifying "-i virbr__" for >>> every IPv6 device which would be removed when the device was destroyed. >> OBE - I chose the approach of adding (and removing) a rule per >> interface. The rule adds "--dport 547" but does NOT specify "-d >> ff02::1:2". > I haven't looked at how dhcp6 works, but if its anything like dhcp4, the > IP address is irrelevant and shouldn't be included in the rule. As long > as your rule specifies both the interface and port, that should be fine > (take a look at the rules already being added for dhcp4) (and no, I have > absolutely no idea why we add a rule to allow *tcp* on the dhcp port. > It's just been that way since the first day I set eyes on the code). Well, ff02::1:2 does have some meaning in dhcp6. From what I have seen by "well behaved" clients is that the client always uses port 546 and the server always uses port 547. But, dnsmasq have some comments/code which indicates that not all clients are "well behaved." In dhcp6, a little four dhcpv6 dance is performed to establish the clients address: 1. dhcpv6 solicit: from=fe80::client:546 to=ff02::1:2:547 2. dhcpv6 advertise: from=fe80::server:547 to=fe80::client:546 3. dhcpv6 request: from=fe80::client:546 to=ff02::1:2:547 4. dhcpv6 reply: from=fe80::server:547 to=fe80::client:546 Or, in other words: (1) need dhcpv6, (2) I serve it, (3) OK, give me one, and (4) here it is. Since dnsmasq does its own packet filtering and with bind-interfaces having a real meaning, it all works (assuming that radvd has the right configuration). > > >> This works With the radvd configuration and a dhcp-range specified for >> a ipv6 subnet, a guest will get a dhcp6 address and RA default route. > Interesting - so both radvd and dnsmasq are involved, correct? Yes, why not? Sometime in the future this should be reconsidered and either everything is done by dnsmasq or it is at least an option. I must say that having dnsmasq do everything does have appeal ... one less dependency. > >>> 4. After getting all of this working to my satisfaction, my next >>> mountain to climb is VM ... it really does not like network xml >>> definitions which include a dhcp-range for an ipv6 definition. >>> >>> Comments? >>> >>> NOTE: I am implementing all of this assuming that my previous >>> patches have been accepted ... the ones for creating a dnsmasq >>> conf-file for parameters rather than using the dnsmasq command-line. > I have no problem with the "convert from long commandline to conf file" > patch except for the bit that points to a "conf directory" where user > supplied conf files can be added. Aside from that part needing to be in > a spearate patch, if we're going to add that kind of configurability, we > need to do it in a way that will allow us to easily see that the user is > playing outside the fence (otherwise we spend a lot of time chasing > "bugs" that end up being caused by user-supplied options). Originally, I wanted the conf-dir so that I could pop in/out some configuration changes that would happen when dnsmasq re-read the configuration. Well, it does not work that way and dnsmasq has to be restarted for some of the more interesting changes. Given this, I believe that conf-dir serves no useful purpose and should be removed and I will remove it and resubmit the patch. > > Because we're in freeze right now I haven't spent a lot of time > discussing that, but planned to send a message about it when I get a minute. Right now I am working on getting dhcpv6 functional and, while what I have works, there is still more to do. > >>> I am sure that someone could spend the time refitting the dhcp6 >>> patches to the old code but why get aggravated? If you folks do not >>> want to do things that way, fine, please say so. But if it is going >>> to be accepted, then I would like some indication of this. >> 5. As far as I can tell (or at least this is for dnsmasq), >> "dhcp-no-override", "enable-tftp", "tftp-root=", and "dhcp-boot=" are >> all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not >> looked to see what network_conf.c does. > "what network_conf.c does"? Well, it of course doesn't deal directly > with those options, but the config that feeds into some of those options > is parsed in virNetworkIPParseXML(), and is only done if the <ip> > element is ipv4. But then you've already seen that code if you have dhcp > working for ipv6 - the <dhcp> element is also only parsed for ipv6. The > format-side code doesn't have that extra check; I guess I figured that > if there was no way to configure ipv6 with dhcp or tftp, it was safe to > assume any ip element with dhcp or tftp info was ipv4 anyway. I have now dived into network_conf.c and a little into dnsmasq.c. Yet again I was surprised because most of what was needed for dhcpv6 was a little tweaking here and there. To support dhcp-host for IPv6, I did assumed that for IPv6 no MAC address would be specified since it does not have a defined meaning in DHCPv6. Therefore, in dnsmasq.c/hostsfileAdd(), if the mac==NULL, I use the IPv6 format of <hostname>,[<ipv6-addr>] whereas for IPv4 it is either MAC,<ipv4-addr>,<hostname. or MAC,<ipv4-addr>. This way most of the code works as is. Dnsmasq has lots of options and different ways that dhcp-host= can be specified, but this is simple and I know it works. > >> 6. Handling of the info for addn-hosts file and the dhcp-hostsfile. >> This currently works because things are forced so that one and only >> one IPv4 dhcp definition will be handled. With the addition of IPv6 >> dhcp, things fall apart. >> >> 6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file >> in both form and function. The <dns>-<host> specification is done on >> an interface bases and, thus, the processing of the data and creation >> of the file should only be done once. >> >> 6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for >> every ip definition that is processed for dhcp. Initially, this will >> be for dhcp4 only until I can figure out how to do it for dhcp6. >> >> 6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two >> functions [one for addn-hosts and one for dhcp-hosts]. Additionally, >> all the functions which call dnsmasqSave() need to be reworked >> appropriately. > > I've actually never liked the "dnsmasqContext" concept, as it seems like > overkill and has conceptual problems such as what you've described. I > would be just as happy with replacements that were simpler and easier to > deal with. I think part of what complicates dnsmasq.[hc] is that it's in > the util directory, so it isn't allowed to understand the contents of > virNetworkDef, and must instead be sent the list of hosts in a simpler > format. If, instead, there was a file src/network/bridge_dnsmasq.[hc], > that could have functions that took virNetworkDef as an arg, and just > immediately return a string (or, in a separate function, write to a > file). That should simplify calling, and writing tests. And existing > dnsmasq-related functions in bridge_driver.c could be moved there as > well, reducing clutter in bridge_driver.c. (Of course I'm saying all > this without ever seriously considering it, just talking off the cuff, > so I may be completely wrong :-) Right now I have fixed things up so they work. I would like to leave this as an exercise for someone else [or at least a later time]. Besides, isn't bridge_driver.c pretty much for dnsmasq only? > > >> 7. So far, the only things I have done involving the xml specification >> is to enable <dhcp> for IPv6. However, the xml to specify a dns >> addn-hosts appears, IMHO, to be overly verbose and complicated. > It is made that way because a single IP address may have multiple > hostnames associated with it, and we want to avoid having multiple > methods of describing the same thing. What you propose in the next > couple sentences was already proposed, tried, and rejected when dns host > support was originally added. OK. > >> So, while allowing the current xml to be valid, I suggest adding an >> alternate form for which is similar to that used for dhcp-host. An >> example is "<host ip='1.2.3.4' name='one' />" >> > There are a few places in libvirt's XML where the same thing can be > expressed in two different ways, but that is only done when necessary > because the existing XML is unable to completely describe the new > functionality but backward compatibility is required. It creates all > sorts of problems when formatting the config back into XML though (which > of the two do you choose? Or do you do both? Either of these is a bad > answer), therefore we definitely don't want to do that except in cases > where it is absolutely necessary; this isn't one of those cases. This is why I have tried to tweak and bend things so it works (and because it mostly worked before). And now, as the saying goes, one more thing. I now realize that I am going to need to get into virsh net-update since I am adding things to the xml specification and net-update will need to differentiate between dhcp4 and dhcp6 changes. Another thought that occurs to me is whether there has any consideration been given having a "virsh net-restart" which would just restart dnsmasq and radvd. Typing stuff in for the command line of net-update is a little prone to typos. Wouldn't having net-edit and net-restart do what is intended for net-update. Maybe there is a way to have net-update do the equivalent of net-edit/net-restart. For example, if you only did "virsh net-update <network>" it would do it. BTW, as I mentioned in another message, net-update for <dns> <host> does not work. Gene
On 10/30/2012 11:58 AM, Gene Czarcinski wrote: > On 10/29/2012 04:08 PM, Laine Stump wrote: >> On 10/29/2012 08:26 AM, Gene Czarcinski wrote: >>> On 10/27/2012 03:18 PM, Gene Czarcinski wrote: >>>> OK, I have the basic implementation for libvirt support of dhcp6. Let >>>> me say again that 98% of the work was already done. There is still a >>>> bunch of work today which includes writing some tests, understanding >>>> how things such as bootp, dhcp-host, etc. should be supported with >>>> dhcp6, as well as the items I discuss below. >>>> >>>> 1. Right now, the only way that dhcp6 is in effect is if there is no >>>> dhcp4 range definition. This will be fixed/expanded so that, at a >>>> minimum, you can have both a dhcp4 and dhcp6 on the same interface. >>>> However, it appears to be easier to just pass to dnsmasq ANY/EVERY >>>> dhcp4 range or dhcp6 range defined in the xml. >>>> >>>> Comments? Any input on which approach to use or avoid? >>> For the current situation, the implementation is for one (the first) >>> IPv4 dhcp and one (the first) IPv6 dhcp. This introduces enough >>> little gotchas that need to be worked out. >> I think that is the proper thing to do for now. As discussed earlier, >> before supporting dhcp on multiple subnets of the same protocol (ipv6 vs >> ipv4) we would need to decide why and how we want to do that - IPs >> assigned from different subnets need to be matched with the IP address >> of that subnet, and it will take a more complicated dnsmasq commandline >> to do that, iirc. > I cannot think of a good reason to have multiple IPv4 or IPv6 > dhcp-range specification. Some day, someone will come up with a good > reason but, for right now, I believe that one IPv4 and one IPv6 > dhcp-range specifications is one of those "good enough" answers. >> >>>> 2. I have modified radvd so both stateful (dhcp6) and stateless >>>> (SLAAC) addressing is supported with radvd for the default route. >>>> This is done on an interface basis (that is the way it works). So if >>>> any dhcp6 range is specified, then stateful is used. The way this is >>>> implemented will make it easy to add some tests verifying that the >>>> configuration parameters are working. I intend this to be an >>>> expansion to networkxml2argvtest since it has the xml specification >>>> files which determine both dnsmasq and radvd configuration parameters. >>>> >>> NC ... working fine. >>>> 3. After completing what I thought was code that should result in a >>>> guest getting dhcp6 addresses, it was not working. Once more it took >>>> me a little time to realize that ip6tables rules were blocking it. [I >>>> have been down this path before, you would think I would realize the >>>> problem sooner.] >>>> >>>> 3a. In looking over the ip6tables rules, I saw a whole bunch of >>>> additions at the top of the INPUT chain which were accepts for >>>> udp/tcp port 53. In looking at the code in bridge_driver.c, I found >>>> that, every time a network device was started, 3 FORWARD rules and 2 >>>> INPUT rules were added, but, when the network device was destroyed, >>>> only the 3 FORWARD rules were removed. I believe this is a bug (but >>>> not high priority) and I will be submitting a separate patch to fix >>>> this. >>>> >>>> 3b. There are two different approaches for the rule which allows the >>>> dhcp6 server to work. I could add (actually insert) one rule to the >>>> INPUT chain which accepted the packet if it is "-d ff02::1:2 "--dport >>>> 547". Or, I could add (insert) a rule specifying "-i virbr__" for >>>> every IPv6 device which would be removed when the device was >>>> destroyed. >>> OBE - I chose the approach of adding (and removing) a rule per >>> interface. The rule adds "--dport 547" but does NOT specify "-d >>> ff02::1:2". >> I haven't looked at how dhcp6 works, but if its anything like dhcp4, the >> IP address is irrelevant and shouldn't be included in the rule. As long >> as your rule specifies both the interface and port, that should be fine >> (take a look at the rules already being added for dhcp4) (and no, I have >> absolutely no idea why we add a rule to allow *tcp* on the dhcp port. >> It's just been that way since the first day I set eyes on the code). > Well, ff02::1:2 does have some meaning in dhcp6. > > From what I have seen by "well behaved" clients is that the client > always uses port 546 and the server always uses port 547. But, > dnsmasq have some comments/code which indicates that not all clients > are "well behaved." > > In dhcp6, a little four dhcpv6 dance is performed to establish the > clients address: > > 1. dhcpv6 solicit: from=fe80::client:546 to=ff02::1:2:547 > 2. dhcpv6 advertise: from=fe80::server:547 to=fe80::client:546 > 3. dhcpv6 request: from=fe80::client:546 to=ff02::1:2:547 > 4. dhcpv6 reply: from=fe80::server:547 to=fe80::client:546 > > Or, in other words: (1) need dhcpv6, (2) I serve it, (3) OK, give me > one, and (4) here it is. Ah, so that address has a special meaning/function. > > Since dnsmasq does its own packet filtering and with bind-interfaces > having a real meaning, it all works (assuming that radvd has the right > configuration). >> >> >>> This works With the radvd configuration and a dhcp-range specified for >>> a ipv6 subnet, a guest will get a dhcp6 address and RA default route. >> Interesting - so both radvd and dnsmasq are involved, correct? > Yes, why not? No reason. Just curious. > Sometime in the future this should be reconsidered and either > everything is done by dnsmasq or it is at least an option. Yeah, it couldn't be mandatory, at least not now, since there are still lots of people using dnsmasq versions that don't have all the required capabilities. > I must say that having dnsmasq do everything does have appeal ... > one less dependency. >> >>>> 4. After getting all of this working to my satisfaction, my next >>>> mountain to climb is VM ... it really does not like network xml >>>> definitions which include a dhcp-range for an ipv6 definition. >>>> >>>> Comments? >>>> >>>> NOTE: I am implementing all of this assuming that my previous >>>> patches have been accepted ... the ones for creating a dnsmasq >>>> conf-file for parameters rather than using the dnsmasq command-line. >> I have no problem with the "convert from long commandline to conf file" >> patch except for the bit that points to a "conf directory" where user >> supplied conf files can be added. Aside from that part needing to be in >> a spearate patch, if we're going to add that kind of configurability, we >> need to do it in a way that will allow us to easily see that the user is >> playing outside the fence (otherwise we spend a lot of time chasing >> "bugs" that end up being caused by user-supplied options). > Originally, I wanted the conf-dir so that I could pop in/out some > configuration changes that would happen when dnsmasq re-read the > configuration. Well, it does not work that way and dnsmasq has to be > restarted for some of the more interesting changes. Given this, I > believe that conf-dir serves no useful purpose and should be removed > and I will remove it and resubmit the patch. >> >> Because we're in freeze right now I haven't spent a lot of time >> discussing that, but planned to send a message about it when I get a >> minute. > Right now I am working on getting dhcpv6 functional and, while what I > have works, there is still more to do. >> >>>> I am sure that someone could spend the time refitting the dhcp6 >>>> patches to the old code but why get aggravated? If you folks do not >>>> want to do things that way, fine, please say so. But if it is going >>>> to be accepted, then I would like some indication of this. >>> 5. As far as I can tell (or at least this is for dnsmasq), >>> "dhcp-no-override", "enable-tftp", "tftp-root=", and "dhcp-boot=" are >>> all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not >>> looked to see what network_conf.c does. >> "what network_conf.c does"? Well, it of course doesn't deal directly >> with those options, but the config that feeds into some of those options >> is parsed in virNetworkIPParseXML(), and is only done if the <ip> >> element is ipv4. But then you've already seen that code if you have dhcp >> working for ipv6 - the <dhcp> element is also only parsed for ipv6. The >> format-side code doesn't have that extra check; I guess I figured that >> if there was no way to configure ipv6 with dhcp or tftp, it was safe to >> assume any ip element with dhcp or tftp info was ipv4 anyway. > I have now dived into network_conf.c and a little into dnsmasq.c. Yet > again I was surprised because most of what was needed for dhcpv6 was a > little tweaking here and there. I'd like to think that's because we've tried to do things in a manner that anticipates future expansions, but some of it may be pure luck :-) > > To support dhcp-host for IPv6, I did assumed that for IPv6 no MAC > address would be specified since it does not have a defined meaning in > DHCPv6. Therefore, in dnsmasq.c/hostsfileAdd(), if the mac==NULL, I > use the IPv6 format of <hostname>,[<ipv6-addr>] whereas for IPv4 it > is either MAC,<ipv4-addr>,<hostname. or MAC,<ipv4-addr>. > > This way most of the code works as is. Dnsmasq has lots of options > and different ways that dhcp-host= can be specified, but this is > simple and I know it works. >> >>> 6. Handling of the info for addn-hosts file and the dhcp-hostsfile. >>> This currently works because things are forced so that one and only >>> one IPv4 dhcp definition will be handled. With the addition of IPv6 >>> dhcp, things fall apart. >>> >>> 6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file >>> in both form and function. The <dns>-<host> specification is done on >>> an interface bases and, thus, the processing of the data and creation >>> of the file should only be done once. >>> >>> 6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for >>> every ip definition that is processed for dhcp. Initially, this will >>> be for dhcp4 only until I can figure out how to do it for dhcp6. >>> >>> 6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two >>> functions [one for addn-hosts and one for dhcp-hosts]. Additionally, >>> all the functions which call dnsmasqSave() need to be reworked >>> appropriately. >> >> I've actually never liked the "dnsmasqContext" concept, as it seems like >> overkill and has conceptual problems such as what you've described. I >> would be just as happy with replacements that were simpler and easier to >> deal with. I think part of what complicates dnsmasq.[hc] is that it's in >> the util directory, so it isn't allowed to understand the contents of >> virNetworkDef, and must instead be sent the list of hosts in a simpler >> format. If, instead, there was a file src/network/bridge_dnsmasq.[hc], >> that could have functions that took virNetworkDef as an arg, and just >> immediately return a string (or, in a separate function, write to a >> file). That should simplify calling, and writing tests. And existing >> dnsmasq-related functions in bridge_driver.c could be moved there as >> well, reducing clutter in bridge_driver.c. (Of course I'm saying all >> this without ever seriously considering it, just talking off the cuff, >> so I may be completely wrong :-) > Right now I have fixed things up so they work. I would like to leave > this as an exercise for someone else [or at least a later time]. > > Besides, isn't bridge_driver.c pretty much for dnsmasq only? Right now, yes. It's always possible that an alternative could come along, of course... >>> 7. So far, the only things I have done involving the xml specification >>> is to enable <dhcp> for IPv6. However, the xml to specify a dns >>> addn-hosts appears, IMHO, to be overly verbose and complicated. >> It is made that way because a single IP address may have multiple >> hostnames associated with it, and we want to avoid having multiple >> methods of describing the same thing. What you propose in the next >> couple sentences was already proposed, tried, and rejected when dns host >> support was originally added. > OK. >> >>> So, while allowing the current xml to be valid, I suggest adding an >>> alternate form for which is similar to that used for dhcp-host. An >>> example is "<host ip='1.2.3.4' name='one' />" >>> >> There are a few places in libvirt's XML where the same thing can be >> expressed in two different ways, but that is only done when necessary >> because the existing XML is unable to completely describe the new >> functionality but backward compatibility is required. It creates all >> sorts of problems when formatting the config back into XML though (which >> of the two do you choose? Or do you do both? Either of these is a bad >> answer), therefore we definitely don't want to do that except in cases >> where it is absolutely necessary; this isn't one of those cases. > This is why I have tried to tweak and bend things so it works (and > because it mostly worked before). > > And now, as the saying goes, one more thing. > > I now realize that I am going to need to get into virsh net-update > since I am adding things to the xml specification and net-update will > need to differentiate between dhcp4 and dhcp6 changes. > > Another thought that occurs to me is whether there has any > consideration been given having a "virsh net-restart" which would just > restart dnsmasq and radvd. Typing stuff in for the command line of > net-update is a little prone to typos. You can always put them in (temporary) files :-) > Wouldn't having net-edit and net-restart do what is intended for > net-update. Maybe there is a way to have net-update do the equivalent > of net-edit/net-restart. For example, if you only did "virsh > net-update <network>" it would do it. My first proposal for doing a live update of network config was to simply enhance virNetworkDefine with a flag that meant "take effect immediately", but this was voted down as being too open-ended and difficult to keep track of what had and hadn't changed. I also proposed an API that would use xpath expressions to specify which part of the network was being updated, thus allowing arbitrary change of any piece of the network config; also voted down for some of the same reasons (and some others, e.g. we would have an API that *looked* like it could specify any change, but it could actually encounter problems - if you're interested you should look up the mail threads, just search for virNetworkDefine and virNetworkUpdate. What I would like to do, however, is to get the network code and the domain interface code interconnected well enough that when a network is destroyed, all the interfaces connected to it have their link set down, and anytime a network is started, a search would be done through all interfaces on all active domains to reconnect them to the network. This would have the same effect. > > BTW, as I mentioned in another message, net-update for <dns> <host> > does not work. Yeah, that's because it wasn't on the "required" list for the initial pass and got left out, and then I forgot that fact when I was telling you about it. I have some other patches pending that will make it simpler to implement, so I'll probably post a patch for it sometime shortly after 1.0.0 is released.
On 10/30/2012 02:28 PM, Laine Stump wrote: > On 10/30/2012 11:58 AM, Gene Czarcinski wrote: >> >> Well, ff02::1:2 does have some meaning in dhcp6. >> >> From what I have seen by "well behaved" clients is that the client >> always uses port 546 and the server always uses port 547. But, >> dnsmasq have some comments/code which indicates that not all clients >> are "well behaved." >> >> In dhcp6, a little four dhcpv6 dance is performed to establish the >> clients address: >> >> 1. dhcpv6 solicit: from=fe80::client:546 to=ff02::1:2:547 >> 2. dhcpv6 advertise: from=fe80::server:547 to=fe80::client:546 >> 3. dhcpv6 request: from=fe80::client:546 to=ff02::1:2:547 >> 4. dhcpv6 reply: from=fe80::server:547 to=fe80::client:546 >> >> Or, in other words: (1) need dhcpv6, (2) I serve it, (3) OK, give me >> one, and (4) here it is. > Ah, so that address has a special meaning/function. OK, I took the easy approach. I will go back and "do it right" so that both "-d ff02::1:2" and "--dport 547" are specified. > > >> Since dnsmasq does its own packet filtering and with bind-interfaces >> having a real meaning, it all works (assuming that radvd has the right >> configuration). >>> >>>> This works With the radvd configuration and a dhcp-range specified for >>>> a ipv6 subnet, a guest will get a dhcp6 address and RA default route. >>> Interesting - so both radvd and dnsmasq are involved, correct? >> Yes, why not? > No reason. Just curious. > >> Sometime in the future this should be reconsidered and either >> everything is done by dnsmasq or it is at least an option. > Yeah, it couldn't be mandatory, at least not now, since there are still > lots of people using dnsmasq versions that don't have all the required > capabilities. I am having second thoughts and think it might be a good idea to just have dnsmasq do everything since it can do both dhcp6 and RA. This sure does simplify things: if you have dhcp6, add the dnsmasq parameter "enable-ra". If not, don't add it. About being compatible with old code. I see the dhcp6 patches and this potential patch as being based on v1.0.0 and not being back-ported. So I am not sure I see a potential conflict. > > >> I must say that having dnsmasq do everything does have appeal ... >> one less dependency. >>>>> 4. After getting all of this working to my satisfaction, my next >>>>> mountain to climb is VM ... it really does not like network xml >>>>> definitions which include a dhcp-range for an ipv6 definition. >>>>> >>>>> Comments? >>>>> >>>>> NOTE: I am implementing all of this assuming that my previous >>>>> patches have been accepted ... the ones for creating a dnsmasq >>>>> conf-file for parameters rather than using the dnsmasq command-line. >>> I have no problem with the "convert from long commandline to conf file" >>> patch except for the bit that points to a "conf directory" where user >>> supplied conf files can be added. Aside from that part needing to be in >>> a spearate patch, if we're going to add that kind of configurability, we >>> need to do it in a way that will allow us to easily see that the user is >>> playing outside the fence (otherwise we spend a lot of time chasing >>> "bugs" that end up being caused by user-supplied options). >> Originally, I wanted the conf-dir so that I could pop in/out some >> configuration changes that would happen when dnsmasq re-read the >> configuration. Well, it does not work that way and dnsmasq has to be >> restarted for some of the more interesting changes. Given this, I >> believe that conf-dir serves no useful purpose and should be removed >> and I will remove it and resubmit the patch. >>> Because we're in freeze right now I haven't spent a lot of time >>> discussing that, but planned to send a message about it when I get a >>> minute. >> Right now I am working on getting dhcpv6 functional and, while what I >> have works, there is still more to do. >>>>> I am sure that someone could spend the time refitting the dhcp6 >>>>> patches to the old code but why get aggravated? If you folks do not >>>>> want to do things that way, fine, please say so. But if it is going >>>>> to be accepted, then I would like some indication of this. >>>> 5. As far as I can tell (or at least this is for dnsmasq), >>>> "dhcp-no-override", "enable-tftp", "tftp-root=", and "dhcp-boot=" are >>>> all IPv4 only and thus ignored for IPv6 in bridge_driver. I have not >>>> looked to see what network_conf.c does. >>> "what network_conf.c does"? Well, it of course doesn't deal directly >>> with those options, but the config that feeds into some of those options >>> is parsed in virNetworkIPParseXML(), and is only done if the <ip> >>> element is ipv4. But then you've already seen that code if you have dhcp >>> working for ipv6 - the <dhcp> element is also only parsed for ipv6. The >>> format-side code doesn't have that extra check; I guess I figured that >>> if there was no way to configure ipv6 with dhcp or tftp, it was safe to >>> assume any ip element with dhcp or tftp info was ipv4 anyway. >> I have now dived into network_conf.c and a little into dnsmasq.c. Yet >> again I was surprised because most of what was needed for dhcpv6 was a >> little tweaking here and there. > I'd like to think that's because we've tried to do things in a manner > that anticipates future expansions, but some of it may be pure luck :-) A little luck can go a long way because no matter how good you are, it is impractical to predict the future. > >> To support dhcp-host for IPv6, I did assumed that for IPv6 no MAC >> address would be specified since it does not have a defined meaning in >> DHCPv6. Therefore, in dnsmasq.c/hostsfileAdd(), if the mac==NULL, I >> use the IPv6 format of <hostname>,[<ipv6-addr>] whereas for IPv4 it >> is either MAC,<ipv4-addr>,<hostname. or MAC,<ipv4-addr>. >> >> This way most of the code works as is. Dnsmasq has lots of options >> and different ways that dhcp-host= can be specified, but this is >> simple and I know it works. >>>> 6. Handling of the info for addn-hosts file and the dhcp-hostsfile. >>>> This currently works because things are forced so that one and only >>>> one IPv4 dhcp definition will be handled. With the addition of IPv6 >>>> dhcp, things fall apart. >>>> >>>> 6a. addn-hosts: The addn-hosts file is similar to the /etc/hosts file >>>> in both form and function. The <dns>-<host> specification is done on >>>> an interface bases and, thus, the processing of the data and creation >>>> of the file should only be done once. >>>> >>>> 6b. dhcp-hostsfile (dhcp-host=): This needs to be done at least for >>>> every ip definition that is processed for dhcp. Initially, this will >>>> be for dhcp4 only until I can figure out how to do it for dhcp6. >>>> >>>> 6c. Thus, networkBuildDnsmasqHostsfile() needs to be split into two >>>> functions [one for addn-hosts and one for dhcp-hosts]. Additionally, >>>> all the functions which call dnsmasqSave() need to be reworked >>>> appropriately. >>> I've actually never liked the "dnsmasqContext" concept, as it seems like >>> overkill and has conceptual problems such as what you've described. I >>> would be just as happy with replacements that were simpler and easier to >>> deal with. I think part of what complicates dnsmasq.[hc] is that it's in >>> the util directory, so it isn't allowed to understand the contents of >>> virNetworkDef, and must instead be sent the list of hosts in a simpler >>> format. If, instead, there was a file src/network/bridge_dnsmasq.[hc], >>> that could have functions that took virNetworkDef as an arg, and just >>> immediately return a string (or, in a separate function, write to a >>> file). That should simplify calling, and writing tests. And existing >>> dnsmasq-related functions in bridge_driver.c could be moved there as >>> well, reducing clutter in bridge_driver.c. (Of course I'm saying all >>> this without ever seriously considering it, just talking off the cuff, >>> so I may be completely wrong :-) >> Right now I have fixed things up so they work. I would like to leave >> this as an exercise for someone else [or at least a later time]. >> >> Besides, isn't bridge_driver.c pretty much for dnsmasq only? > Right now, yes. It's always possible that an alternative could come > along, of course... The alternative would have to be really good to replace all the functionality of dnsmasq and would likely have it's own driver. > > >>>> 7. So far, the only things I have done involving the xml specification >>>> is to enable <dhcp> for IPv6. However, the xml to specify a dns >>>> addn-hosts appears, IMHO, to be overly verbose and complicated. >>> It is made that way because a single IP address may have multiple >>> hostnames associated with it, and we want to avoid having multiple >>> methods of describing the same thing. What you propose in the next >>> couple sentences was already proposed, tried, and rejected when dns host >>> support was originally added. >> OK. >>>> So, while allowing the current xml to be valid, I suggest adding an >>>> alternate form for which is similar to that used for dhcp-host. An >>>> example is "<host ip='1.2.3.4' name='one' />" >>>> >>> There are a few places in libvirt's XML where the same thing can be >>> expressed in two different ways, but that is only done when necessary >>> because the existing XML is unable to completely describe the new >>> functionality but backward compatibility is required. It creates all >>> sorts of problems when formatting the config back into XML though (which >>> of the two do you choose? Or do you do both? Either of these is a bad >>> answer), therefore we definitely don't want to do that except in cases >>> where it is absolutely necessary; this isn't one of those cases. >> This is why I have tried to tweak and bend things so it works (and >> because it mostly worked before). >> >> And now, as the saying goes, one more thing. >> >> I now realize that I am going to need to get into virsh net-update >> since I am adding things to the xml specification and net-update will >> need to differentiate between dhcp4 and dhcp6 changes. >> >> Another thought that occurs to me is whether there has any >> consideration been given having a "virsh net-restart" which would just >> restart dnsmasq and radvd. Typing stuff in for the command line of >> net-update is a little prone to typos. > You can always put them in (temporary) files :-) I am still thinking about this and I still have to fix net-update for dhcp6. Gene
On Tue, 30 Oct 2012, Gene Czarcinski wrote:
1. dhcpv6 solicit: from=fe80::client:546 to=ff02::1:2:547 2. dhcpv6 advertise: from=fe80::server:547 to=fe80::client:546 3. dhcpv6 request: from=fe80::client:546 to=ff02::1:2:547 4. dhcpv6 reply: from=fe80::server:547 to=fe80::client:546
I think the rules you want are these (we use the symbolic names for the packet sub-type as it makes things clearer) # /etc/sysconfig/ip6tables # ... -A INPUT -p ipv6-icmp --icmpv6-type router-advertisement -s $IP6SERVER -j ACCEPT -A INPUT -p ipv6-icmp --icmpv6-type router-advertisement -j DROP -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -j REJECT --reject-with icmp6-adm-prohibited # ... I do not know that you need to filter or attempt to direct 'router-solicitation' as your comments mentioned. We have not had a 'real world' need to do so. We run a variation of these rules at pmman from: man 8 ip6tables icmp6 This extension can be used if ‘--protocol ipv6-icmp’ or ‘--protocol icmpv6’ is specified. It provides the following option: [!] --icmpv6-type type[/code]|typename This allows specification of the ICMPv6 type, which can be a numeric ICMPv6 type, type and code, or one of the ICMPv6 type names shown by the command ip6tables -p ipv6-icmp -h -- Russ herrold
On 10/30/2012 06:45 PM, R P Herrold wrote:
I think the rules you want are these (we use the symbolic names for the packet sub-type as it makes things clearer)
# /etc/sysconfig/ip6tables # ... -A INPUT -p ipv6-icmp --icmpv6-type router-advertisement -s $IP6SERVER -j ACCEPT -A INPUT -p ipv6-icmp --icmpv6-type router-advertisement -j DROP -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -j REJECT --reject-with icmp6-adm-prohibited # ...
I do not know that you need to filter or attempt to direct 'router-solicitation' as your comments mentioned. We have not had a 'real world' need to do so. We run a variation of these rules at pmman
from: man 8 ip6tables
icmp6 This extension can be used if ‘--protocol ipv6-icmp’ or ‘--protocol icmpv6’ is specified. It provides the following option:
[!] --icmpv6-type type[/code]|typename This allows specification of the ICMPv6 type, which can be a numeric ICMPv6 type, type and code, or one of the ICMPv6 type names shown by the command ip6tables -p ipv6-icmp -h It is not icmp6 but dhcpv6 packets.
As I explained earlier in the thread, there is a little 4 packet dance which implements dhcpv6 addresses. Routing is handled by RA. The difference is that you much have the AdvManagedFlag on for dhcpv6 and off otherwise. There does not seem to be a problem with the RA packets getting through. But, for dhcpv6, you need port 547 packets (and specifically with a destination address of ff02::01:2) to get through to the dnsmasq process running on the virtualization host. To happen, this needs an additional ip6tables rule. While just specifying "--dport 547" seems to work, the "correct" appraach should also specify "--destination ff02::1:2" for "--in-interface <our interface>". This is what I have currently implemented and it seems to work well. Gene Gene
On 10/30/2012 05:35 PM, Gene Czarcinski wrote:
About being compatible with old code. I see the dhcp6 patches and this potential patch as being based on v1.0.0 and not being back-ported. So I am not sure I see a potential conflict.
Being able to backport patches to older libvirt releases is not the issue we are concerned about - that is actually usually not an important consideration. What *is* important is the ability to build and run the new libvirt releases on older platforms. For example, if the upstream release containing your patches were built on CentOS6.3 or RHEL6.3, the dhcp6 functionality wouldn't be available, because those distros are stuck at dnsmasq-2.48. That's okay as long as all the pre-existing functionality still works properly on those distros. Eliminating radvd in favor of using dnsmasq for ipv6 ra and autoconf would *not* be acceptable, though, because if the release containing that patch were built on RHEL6/CentOS6, it would mean a regression in behavior, since IPv6 autoconf/ra would cease to work.
On 10/31/2012 09:42 PM, Laine Stump wrote:
On 10/30/2012 05:35 PM, Gene Czarcinski wrote:
About being compatible with old code. I see the dhcp6 patches and this potential patch as being based on v1.0.0 and not being back-ported. So I am not sure I see a potential conflict. Being able to backport patches to older libvirt releases is not the issue we are concerned about - that is actually usually not an important consideration. What *is* important is the ability to build and run the new libvirt releases on older platforms. For example, if the upstream release containing your patches were built on CentOS6.3 or RHEL6.3, the dhcp6 functionality wouldn't be available, because those distros are stuck at dnsmasq-2.48. That's okay as long as all the pre-existing functionality still works properly on those distros. Eliminating radvd in favor of using dnsmasq for ipv6 ra and autoconf would *not* be acceptable, though, because if the release containing that patch were built on RHEL6/CentOS6, it would mean a regression in behavior, since IPv6 autoconf/ra would cease to work.
Lets see if I understand what you are saying correctly. You want to be able to a specific adaptation/configuration of libvirt-1.0.0 on RHEL6/CentOS6 but not insist that their dnsmasq be updated. Doing some looking, it appears that RHEL6.3 uses libvirt-0.8.7 and CentOS6.3 uses libvirt-0.9.10. I can see some group wanting to remain on there particular vintage of RHEL or CentOS and to want the latest libvirt at the same time. OK, but why not require some other packages (such as dnsmasq) be updated also. Are these same folks contemplating putting a newer kernel such as kernel-3.6.3-1.fc17.x86_64 also? I thought the whole idea with RHEL and CentOS was stability and "guaranteed" long term (5 years) support. If you want to run the latest and greatest, then RHEL and CentOS are not the answer for you. Gene
On 11/01/2012 05:25 AM, Gene Czarcinski wrote:
You want to be able to a specific adaptation/configuration of libvirt-1.0.0 on RHEL6/CentOS6 but not insist that their dnsmasq be updated.
Yes, there are people that do that. In other words, we like for libvirt to work out of the box on systems as old as RHEL 5.
Doing some looking, it appears that RHEL6.3 uses libvirt-0.8.7 and CentOS6.3 uses libvirt-0.9.10. I can see some group wanting to remain on there particular vintage of RHEL or CentOS and to want the latest libvirt at the same time. OK, but why not require some other packages (such as dnsmasq) be updated also.
Because people that compile upstream libvirt out of the box don't necessarily want to have to maintain all packages in their system, just libvirt.
Are these same folks contemplating putting a newer kernel such as kernel-3.6.3-1.fc17.x86_64 also?
Probably not - they want to update just libvirt (since it has a promise of back-compat), and as little else as possible.
I thought the whole idea with RHEL and CentOS was stability and "guaranteed" long term (5 years) support. If you want to run the latest and greatest, then RHEL and CentOS are not the answer for you.
If you self-build libvirt on RHEL, then yes, you are no longer supported by Red Hat. But people do it. CentOS is already in unsupported territory, so there, it is already more common to mix and match CentOS for its packaging plus a few of your own packages for the features you want. And yes, if you want support, and you use RHEL, then wait for the next RHEL release (6.4 should be coming along soon now...), and take advantage of your support contract to ask Red Hat for the features you need. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Nov 01, 2012 at 07:25:45AM -0400, Gene Czarcinski wrote:
Doing some looking, it appears that RHEL6.3 uses libvirt-0.8.7 and CentOS6.3 uses libvirt-0.9.10. I can see some group wanting to
Just for the record, RHEL6.3 uses libvirt-0.9.10. Dave
On 11/01/2012 10:08 AM, Dave Allan wrote:
On Thu, Nov 01, 2012 at 07:25:45AM -0400, Gene Czarcinski wrote:
Doing some looking, it appears that RHEL6.3 uses libvirt-0.8.7 and CentOS6.3 uses libvirt-0.9.10. I can see some group wanting to Just for the record, RHEL6.3 uses libvirt-0.9.10.
OK, as far as I am concerned, the critical thing is what parameters will work with dnsmasq-2.48 so that if libvirt-1.0.0 was rebuilt and installed on (for example) CentOS 6.3, that dnsmasq-2.48 will work. First of all, at a minimum, to support DHCPv6, you must be running dnsmasq-2.64 or dnsmasq-2.63+patches [those patches may fit on earlier versions of dnsmasq, I have no idea]. But, if you do not specify any DHCPv6 but just the regular IPv4 stuff plus listen-address=<IPv6-address>, will dnsmasq work with the changes I have made to libvirt that puts the dnsmasq parameters into a conf-file. I am in the process of creating a CentOS 6.3 virtual system. I will then feed the dnsmasq on that system slightly modified versions of various conf-files created under libvirt to see which are going to give dnsmasq indigestion. I still believe that for someone to go to the effort of getting (lets say) libvirt-1.0.0 built, installed and running on CentOS 6.3, then requiring that dnsmasq-2.64 also be installed is not that big a deal ... but that is just my opinion. Gene
On 10/30/2012 02:28 PM, Laine Stump wrote:
I now realize that I am going to need to get into virsh net-update
since I am adding things to the xml specification and net-update will need to differentiate between dhcp4 and dhcp6 changes.
Another thought that occurs to me is whether there has any consideration been given having a "virsh net-restart" which would just restart dnsmasq and radvd. Typing stuff in for the command line of net-update is a little prone to typos. You can always put them in (temporary) files:-)
Wouldn't having net-edit and net-restart do what is intended for net-update. Maybe there is a way to have net-update do the equivalent of net-edit/net-restart. For example, if you only did "virsh net-update <network>" it would do it. Oh so close and yet so far.
I have given the man-page for net-update a closer reading and now realize that I can use a terporary file and that scratch one of my itches. As I read through that documentation I saw the --parent-index which allows you to select which <ip> definition you are changing. Oh boy, this looks good. I can use that to select if I am updating the ipv4 or ipv6 specification. Sounds good! Too bad it does not work that way. You check the family and if it is not ipv4, you quit. Going with a minimum change, I propose changing that test to allow ipv4 or ipv6. BTW, there seem to be a number of things that do not work in net-update. Aside from dns-host, is there anything else that is not there yet? Also, I am updating and re-basing my patches against v1.0.0-rc2. Is that a good choice for now? Gene Gene
On 10/31/2012 10:24 AM, Gene Czarcinski wrote:
On 10/30/2012 02:28 PM, Laine Stump wrote:
I now realize that I am going to need to get into virsh net-update
since I am adding things to the xml specification and net-update will need to differentiate between dhcp4 and dhcp6 changes.
Another thought that occurs to me is whether there has any consideration been given having a "virsh net-restart" which would just restart dnsmasq and radvd. Typing stuff in for the command line of net-update is a little prone to typos. You can always put them in (temporary) files:-)
Wouldn't having net-edit and net-restart do what is intended for net-update. Maybe there is a way to have net-update do the equivalent of net-edit/net-restart. For example, if you only did "virsh net-update <network>" it would do it. Oh so close and yet so far.
I have given the man-page for net-update a closer reading and now realize that I can use a terporary file and that scratch one of my itches. As I read through that documentation I saw the --parent-index which allows you to select which <ip> definition you are changing.
That was the most troublesome part of that entire API, and I'm still not really happy with the way it works, but every other possibility we could think of had more problems.
Oh boy, this looks good. I can use that to select if I am updating the ipv4 or ipv6 specification. Sounds good! Too bad it does not work that way. You check the family and if it is not ipv4, you quit.
That's just a safeguard to enforce the ipv4-only status of dhcp in the current libvirt. Just remove that restriction from the function virNetworkDefUpdateIP() as a part of your patch adding ipv6 dhcp support.
Going with a minimum change, I propose changing that test to allow ipv4 or ipv6.
Since those are the only two supported, and it has to be one or the other, just remove that part of the check.
BTW, there seem to be a number of things that do not work in net-update. Aside from dns-host, is there anything else that is not there yet?
Look at the functions whose names start with virNetworkDefUpdate in network_conf.c. Those for not-yet-implemented sections will be a shell with just a call to virNetworkDefUpdateNoSupport(). As of today, these are implemented: ip-dhcp-host, ip-dhcp-range, forward-interface, and portgroup. The patchset that initially added the virNetworkUpdate API added the toplevel API itself, the backend infrastructure, and the specific function for as many of the defined sections as I could get implemented prior to the 0.10.2 release. The reason for this is that 1) the next release of Fedora 18 will be based on 0.10.2, 2) there will never be a full rebase to a newer libvirt, 3) new public APIs cannot be backported as individual patches, but 4) code that simply adds functionality in the backend *can* be backported to older releases as individual patches. So, by pushing the API plus backend for 4 essential sections (according to a couple people requesting the functionality), we were able to guarantee that the API would be available in Fedora 18. (If there had been more time before the 0.10.2 release, I would have implemented backends for more of the sections)
Also, I am updating and re-basing my patches against v1.0.0-rc2. Is that a good choice for now?
You really should follow upstream git master rather than sticking to a particular snapshot. Any patches that you send to the list should be rebased to the head of git master anyway. Without exception, any patch that is applied to libvirt is first applied to the head of git master, and then later cherry-picked to one of the -maint branches for exporting to a distro build (at least this is the case for Fedora). Since you'll have to rebase to that eventually anyway, it's usually much easier to periodically rebase against git master as you go, and deal with small merge conflicts as they arise, rather than waiting until the end and suddenly having a large number of "conflicting conflicts" (or at least more confusing).
On 10/31/2012 11:53 AM, Laine Stump wrote:
That's just a safeguard to enforce the ipv4-only status of dhcp in the current libvirt. Just remove that restriction from the function virNetworkDefUpdateIP() as a part of your patch adding ipv6 dhcp support.
OK, removing the ipv4 test has net-update ipv6 working as well as ipv4 does. Observation: this is definitely a work-in-progress. I only tried ip-dhcp-range and ip-dhcp-host. The ip-dhcp-range produced the expected in the the xml was updated and dnsmasq was restarted. With ip-dhcp-host, it only did the right thing if the network was down. If it was started, nothing much happened. A suggestion, before F18 goes with 0.10.2, I suggest that the virsh man-page be updated. Currently, you would think that all of the stuff worked. Clearly, it does not. At best, users will be confused. I suggest listing the functions that are planned but not currently implemented. Speaking of documentation. This should be updated for DHCPv6: http://libvirt.org/http://libvirt.org/formatnetwork.html and there is docs/http://libvirt.org/formatnetwork.html.in in the git. However, it is not clear what the process is for changing/updating the documentation. Doing a grep on the log does not show a lot of commits being performed on it. While a lot of using IPv6/DHCP6 is straight-forward, there are a couple of twists such as not specifying a MAC address for a v6 dhcp-host specification. One other thing. I am thinking about a separate patch which will replace radvd with dnsmasq doing the work. I first need to look into dsnamsq a bit more to understand if and how it could do the job. Given it could, a small change for dnsmasq would eliminate the need for radvd. I know there is some touchiness about this so I am thinking of adding a "special xml keyword" which would switch between radvd and dnsmasq. BTW, I am assuming this is all post v1.0.0. I have currently completed the dhcp6 patch (net-update was the last piece) but I need to let things work for a while to see if I missed anything. If anyone wants to look at these patches, I can post them to this list or send them direct. However, I want to wait until v1.0.0 gets released before submitting them for review, etc. Gene
On 10/31/2012 03:11 PM, Gene Czarcinski wrote:
On 10/31/2012 11:53 AM, Laine Stump wrote:
That's just a safeguard to enforce the ipv4-only status of dhcp in the current libvirt. Just remove that restriction from the function virNetworkDefUpdateIP() as a part of your patch adding ipv6 dhcp support.
OK, removing the ipv4 test has net-update ipv6 working as well as ipv4 does.
Observation: this is definitely a work-in-progress. I only tried ip-dhcp-range and ip-dhcp-host. The ip-dhcp-range produced the expected in the the xml was updated and dnsmasq was restarted. With ip-dhcp-host, it only did the right thing if the network was down. If it was started, nothing much happened.
Most likely because, according to what you recently wrote, the dhcp hosts file isn't reread when a SIGHUP is sent to dnsmasq.
A suggestion, before F18 goes with 0.10.2, I suggest that the virsh man-page be updated. Currently, you would think that all of the stuff worked. Clearly, it does not. At best, users will be confused. I suggest listing the functions that are planned but not currently implemented.
A valid point. Note that it's not vanilla 0.10.2 that's currently in F18, it's the 0.20.2-maint branch, which is 0.10.2 plus some bugfixes deemed worthy of backporting. Patches can be added to that branch at any time during the lifetime of F18 (and even beyond if some other distro is using that release for their builds), but they are only bugfixes (adding the backend for missing sections could be seen as fixing a bug, if we *really* wanted to :-).
Speaking of documentation. This should be updated for DHCPv6: http://libvirt.org/http://libvirt.org/formatnetwork.html and there is docs/http://libvirt.org/formatnetwork.html.in in the git. However, it is not clear what the process is for changing/updating the documentation.
Just edit formatnetwork.html.in and make that edit a part of the same patch that makes the new functionality available. Your patch would be NACKed without that anyway.
Doing a grep on the log does not show a lot of commits being performed on it.
Any change to the network XML is not accepted for a push unless a change to formatnetwork.html.in accompanies it. Any low patch volume on the file is due to there being infrequent changes in the XML.
While a lot of using IPv6/DHCP6 is straight-forward, there are a couple of twists such as not specifying a MAC address for a v6 dhcp-host specification.
I know there is some touchiness about this so I am thinking of adding a "special xml keyword" which would switch between radvd and dnsmasq.
I'm not sure whether that would be appropriate, or to instead have an autoconf option that would enact the change at compile time.
BTW, I am assuming this is all post v1.0.0.
We've been in freeze for the last week, and at this point only simple fixes to very serious bugs are being pushed. New functionality is definnitely post-1.0.0
I have currently completed the dhcp6 patch (net-update was the last piece) but I need to let things work for a while to see if I missed anything. If anyone wants to look at these patches, I can post them to this list or send them direct. However, I want to wait until v1.0.0 gets released before submitting them for review, etc.
You can submit things for review now, they just won't be pushed until after the release is cut.
On 10/31/2012 09:50 PM, Laine Stump wrote:
On 10/31/2012 03:11 PM, Gene Czarcinski wrote:
On 10/31/2012 11:53 AM, Laine Stump wrote:
That's just a safeguard to enforce the ipv4-only status of dhcp in the current libvirt. Just remove that restriction from the function virNetworkDefUpdateIP() as a part of your patch adding ipv6 dhcp support.
OK, removing the ipv4 test has net-update ipv6 working as well as ipv4 does.
Observation: this is definitely a work-in-progress. I only tried ip-dhcp-range and ip-dhcp-host. The ip-dhcp-range produced the expected in the the xml was updated and dnsmasq was restarted. With ip-dhcp-host, it only did the right thing if the network was down. If it was started, nothing much happened. Most likely because, according to what you recently wrote, the dhcp hosts file isn't reread when a SIGHUP is sent to dnsmasq. With the network started, I tried editing its definition and adding dns host definitions, when I saved I got a message in syslog that the network was defined [networkCreate() had executed]. There is code in networkCreate() to go through and crate/update the addnhosts and hostsfile which was done. However, no SIGHUP was issued. I then did a SIGHUP manually and the files were re-read.
A suggestion, before F18 goes with 0.10.2, I suggest that the virsh man-page be updated. Currently, you would think that all of the stuff worked. Clearly, it does not. At best, users will be confused. I suggest listing the functions that are planned but not currently implemented. A valid point.
Note that it's not vanilla 0.10.2 that's currently in F18, it's the 0.20.2-maint branch, which is 0.10.2 plus some bugfixes deemed worthy of backporting. Patches can be added to that branch at any time during the lifetime of F18 (and even beyond if some other distro is using that release for their builds), but they are only bugfixes (adding the backend for missing sections could be seen as fixing a bug, if we *really* wanted to :-). I guess I like being a little more straight-forward with the user/customer.
Speaking of documentation. This should be updated for DHCPv6: http://libvirt.org/http://libvirt.org/formatnetwork.html and there is docs/http://libvirt.org/formatnetwork.html.in in the git. However, it is not clear what the process is for changing/updating the documentation. Just edit formatnetwork.html.in and make that edit a part of the same patch that makes the new functionality available. Your patch would be NACKed without that anyway.
Doing a grep on the log does not show a lot of commits being performed on it. Any change to the network XML is not accepted for a push unless a change to formatnetwork.html.in accompanies it. Any low patch volume on the file is due to there being infrequent changes in the XML. OK, one more thing on the todo list. I plan to use seamonkey or maybe Libreoffice to do the editing. Any comments/suggestions?
Any other files I should look at for appropriate change documentation?
While a lot of using IPv6/DHCP6 is straight-forward, there are a couple of twists such as not specifying a MAC address for a v6 dhcp-host specification.
I know there is some touchiness about this so I am thinking of adding a "special xml keyword" which would switch between radvd and dnsmasq. I'm not sure whether that would be appropriate, or to instead have an autoconf option that would enact the change at compile time.
If use/non-use of radvd is an issue on different systems, then an autoconf options is the way to go. For testing purpose (not really for submission) is the ablity to have one interface use dnsmasq only which another interface uses radvd & dnsmasq ... this was intended for testing only to make sure that things worked properly.
BTW, I am assuming this is all post v1.0.0.
We've been in freeze for the last week, and at this point only simple fixes to very serious bugs are being pushed. New functionality is definnitely post-1.0.0
I have currently completed the dhcp6 patch (net-update was the last piece) but I need to let things work for a while to see if I missed anything. If anyone wants to look at these patches, I can post them to this list or send them direct. However, I want to wait until v1.0.0 gets released before submitting them for review, etc. You can submit things for review now, they just won't be pushed until after the release is cut.
I think I want to do a bit more polishing (and updating documentation) before actually submitting. As things now stand, there are three patches with a forth planned for documentation: 1. put dnsmasq parameters into a file. 2. add interface= to dnsmasq parameters 3. add support for dhcp6 Anything involving radvd vs dnsmasq would be a separate issue, separate patch, although it would depend on the above patches.
On 11/01/2012 06:53 AM, Gene Czarcinski wrote:
On 10/31/2012 09:50 PM, Laine Stump wrote:
On 10/31/2012 03:11 PM, Gene Czarcinski wrote:
On 10/31/2012 11:53 AM, Laine Stump wrote:
That's just a safeguard to enforce the ipv4-only status of dhcp in the current libvirt. Just remove that restriction from the function virNetworkDefUpdateIP() as a part of your patch adding ipv6 dhcp support.
OK, removing the ipv4 test has net-update ipv6 working as well as ipv4 does.
Observation: this is definitely a work-in-progress. I only tried ip-dhcp-range and ip-dhcp-host. The ip-dhcp-range produced the expected in the the xml was updated and dnsmasq was restarted. With ip-dhcp-host, it only did the right thing if the network was down. If it was started, nothing much happened. Most likely because, according to what you recently wrote, the dhcp hosts file isn't reread when a SIGHUP is sent to dnsmasq. With the network started, I tried editing its definition and adding dns host definitions, when I saved I got a message in syslog that the network was defined [networkCreate() had executed].
No. If you edit a running network, the definition is updated on disk, but nothing else is (should be) done - it waits until the next start of the network. What you are seeing is the effect of executing networkDefine(), not networkCreate(). (I had assumed you were trying to do net-update to add a dhcp static host, not using net-edit. The changes in net-edit are *only* in the persistent config on disk, and should never take effect until the network is restarted. This is identical behavior to editing a guest's config, and is that way be design.)
There is code in networkCreate() to go through and crate/update the addnhosts and hostsfile which was done.
There is code in networkDefine() to do that as well. It shouldn't be there though - it should only be done when the network is started. Peter Krempa recently sent a patch to fix this: https://www.redhat.com/archives/libvir-list/2012-October/msg01495.html but it hasn't yet been pushed due to the freeze.
However, no SIGHUP was issued. I then did a SIGHUP manually and the files were re-read.
Okay, then net-update should work properly. The rule to remember - if you want a change to take effect immediately (and potentially be persistent across network restarts), use net-update. If you can wait / want to wait until the next time the network is restarted for the change to take effect, you can use net-edit (but can also use net-update with that effect).
A suggestion, before F18 goes with 0.10.2, I suggest that the virsh man-page be updated. Currently, you would think that all of the stuff worked. Clearly, it does not. At best, users will be confused. I suggest listing the functions that are planned but not currently implemented. A valid point.
Note that it's not vanilla 0.10.2 that's currently in F18, it's the 0.20.2-maint branch, which is 0.10.2 plus some bugfixes deemed worthy of backporting. Patches can be added to that branch at any time during the lifetime of F18 (and even beyond if some other distro is using that release for their builds), but they are only bugfixes (adding the backend for missing sections could be seen as fixing a bug, if we *really* wanted to :-).
I guess I like being a little more straight-forward with the user/customer.
I didn't say it wouldn't be useful to document which sections aren't yet implemented, just gave an explanation of how/why the code has eneded up where it is, and what might happen to it in the future; if there is enough demand from (for example) F18 users for the other sections to be complete, we have the ability to update it. If we hadn't done it this way and instead waited until all the sections were implemented and tested before pushing any of them, net-update wouldn't exist at all in F18, and there would be 0 possibility of adding it (because F18 won't rebase to a newer libvirt, and you can't backport API changes to an older libvirt version - not because we just don't want to, but because the library versioning stuff can't handle that.)
Speaking of documentation. This should be updated for DHCPv6: http://libvirt.org/http://libvirt.org/formatnetwork.html and there is docs/http://libvirt.org/formatnetwork.html.in in the git. However, it is not clear what the process is for changing/updating the documentation. Just edit formatnetwork.html.in and make that edit a part of the same patch that makes the new functionality available. Your patch would be NACKed without that anyway.
Doing a grep on the log does not show a lot of commits being performed on it. Any change to the network XML is not accepted for a push unless a change to formatnetwork.html.in accompanies it. Any low patch volume on the file is due to there being infrequent changes in the XML.
OK, one more thing on the todo list. I plan to use seamonkey or maybe Libreoffice to do the editing. Any comments/suggestions?
I think everybody just edits the text directly with emacs or whatever. I would be concerned about a higher level tool reformatting everything and creating huge diffs for tiny changes.
Any other files I should look at for appropriate change documentation?
If you want to look for an appropriate place on the libvirt wiki to add a section (or update an existing section) that might be nicem but not necessary.
While a lot of using IPv6/DHCP6 is straight-forward, there are a couple of twists such as not specifying a MAC address for a v6 dhcp-host specification.
I know there is some touchiness about this so I am thinking of adding a "special xml keyword" which would switch between radvd and dnsmasq. I'm not sure whether that would be appropriate, or to instead have an autoconf option that would enact the change at compile time.
If use/non-use of radvd is an issue on different systems, then an autoconf options is the way to go. For testing purpose (not really for submission) is the ablity to have one interface use dnsmasq only which another interface uses radvd & dnsmasq ... this was intended for testing only to make sure that things worked properly.
BTW, I am assuming this is all post v1.0.0.
We've been in freeze for the last week, and at this point only simple fixes to very serious bugs are being pushed. New functionality is definnitely post-1.0.0
I have currently completed the dhcp6 patch (net-update was the last piece) but I need to let things work for a while to see if I missed anything. If anyone wants to look at these patches, I can post them to this list or send them direct. However, I want to wait until v1.0.0 gets released before submitting them for review, etc. You can submit things for review now, they just won't be pushed until after the release is cut.
I think I want to do a bit more polishing (and updating documentation) before actually submitting.
As things now stand, there are three patches with a forth planned for documentation: 1. put dnsmasq parameters into a file. 2. add interface= to dnsmasq parameters
I thought Simon had determined that to be a non-issue for libvirt's use case. Is there still some advantage to it? (Although I tried it all the way back to REHL5 with no problems encountered, several of us have a vague memory that it had caused some kind of problem, so we'd rather avoid applying it unless there is a tangible benefit)
3. add support for dhcp6
Anything involving radvd vs dnsmasq would be a separate issue, separate patch, although it would depend on the above patches.
participants (5)
-
Dave Allan -
Eric Blake -
Gene Czarcinski -
Laine Stump -
R P Herrold