[libvirt] libvirt plans: dns support for IPv6?
I would like to know what the plans are for supporting dns for virtual guests with only IPv6. My objective is to be able to reference a virtual guest for the host ... doing ssh, scp, etc. such functions work just fine if you specify the ip-address but, after a while, those ip-addresses are difficult to remember ... afterall, that is why dns exists. For IPv4, with a some patches to libvert implementing "--local=/virt/ --domain-needed" if "--domain virt" is specified, I am now able to ssh to guests by name. The additions needed are to run the NetworkManager supporting "--conf-dir=/etc/NetworkManager/dnsmasq.d/" (or patch it like I did), and add a file specifying the dnsmasq on the virtual NIC. For example, server=/virt/,192.168.122.1 will forward queries. Alternatively, you can run yet another dnsmasq on the host which just passes queries to the dnsmasq and modify your upstream dns server to forward any queries for the virtual domains to the dnsmasq on the host. IPv6 is another situation entirely. And it may be even more important to have dns support because if IPv4 address are difficult to remember, IPv6 are practically impossible. So, are there any plans for providing dns on the IPv6 virtual networks? I can see a couple of solutions and each has pluses and minuses. 1. Do it the same way the it is done for IPv4. The current version of dnsmasq (2.63) supports dhcp for IPv6 and, IIRC, has since 2.61. I realize that you need to continue support of libvirt on RHEL 6 and possibly others that are running an old version of dnsmasq, but isn't it time to move along? While you can manually configure IPv6 interfaces so that you can add the definitions to a /etc/host file, this is not a good approach from my perspective. The use of dnsmasq also allows specification of different domains for each virtual IPv6 network. 2. There is another approach and it would be useful for both dnsmasq and this approach be available. That is, continue to use radvd and have the virtual guests autoconf the ip addresses. Then use mDNS (avahi and nss-mdns) to support access by name. This does not require doing anything about dnsmasq. In fact, it is possible thatyou do not need it at all. In addition, the plans for Fedora 18 are to make mDNS the default for Desktop installs [I am not sure what that means]. A big problem is that there is only a single domain which is ".local" by default. An even bigger problem is that ssh (openssh) has an error if a mDNS name is specified. I noticed that Daniel Berrange has put in a bugzilla request that dnsmasq be updated. If someone is already coding up patches to add dhcp for IPv6 or will "real soon now", I will be happy to test it. Otherwise, I could take a shot at coming up with the patches. Gene
On 09/13/2012 02:00 PM, Gene Czarcinski wrote:
I would like to know what the plans are for supporting dns for virtual guests with only IPv6.
My objective is to be able to reference a virtual guest for the host ... doing ssh, scp, etc. such functions work just fine if you specify the ip-address but, after a while, those ip-addresses are difficult to remember ... afterall, that is why dns exists.
For IPv4, with a some patches to libvert implementing "--local=/virt/ --domain-needed" if "--domain virt" is specified, I am now able to ssh to guests by name.
The additions needed are to run the NetworkManager supporting "--conf-dir=/etc/NetworkManager/dnsmasq.d/" (or patch it like I did), and add a file specifying the dnsmasq on the virtual NIC. For example, server=/virt/,192.168.122.1 will forward queries.
Alternatively, you can run yet another dnsmasq on the host which just passes queries to the dnsmasq and modify your upstream dns server to forward any queries for the virtual domains to the dnsmasq on the host.
IPv6 is another situation entirely. And it may be even more important to have dns support because if IPv4 address are difficult to remember, IPv6 are practically impossible.
So, are there any plans for providing dns on the IPv6 virtual networks?
I can see a couple of solutions and each has pluses and minuses.
1. Do it the same way the it is done for IPv4. The current version of dnsmasq (2.63) supports dhcp for IPv6 and, IIRC, has since 2.61. I realize that you need to continue support of libvirt on RHEL 6 and possibly others that are running an old version of dnsmasq, but isn't it time to move along? While you can manually configure IPv6 interfaces so that you can add the definitions to a /etc/host file, this is not a good approach from my perspective. The use of dnsmasq also allows specification of different domains for each virtual IPv6 network.
2. There is another approach and it would be useful for both dnsmasq and this approach be available. That is, continue to use radvd and have the virtual guests autoconf the ip addresses. Then use mDNS (avahi and nss-mdns) to support access by name. This does not require doing anything about dnsmasq. In fact, it is possible thatyou do not need it at all. In addition, the plans for Fedora 18 are to make mDNS the default for Desktop installs [I am not sure what that means]. A big problem is that there is only a single domain which is ".local" by default. An even bigger problem is that ssh (openssh) has an error if a mDNS name is specified.
I noticed that Daniel Berrange has put in a bugzilla request that dnsmasq be updated.
If someone is already coding up patches to add dhcp for IPv6 or will "real soon now", I will be happy to test it. Otherwise, I could take a shot at coming up with the patches.
AFAIK nobody else is working on that right now, so I'd say go for it :-)
On 09/13/2012 04:05 PM, Laine Stump wrote:
On 09/13/2012 02:00 PM, Gene Czarcinski wrote:
I would like to know what the plans are for supporting dns for virtual guests with only IPv6.
My objective is to be able to reference a virtual guest for the host ... doing ssh, scp, etc. such functions work just fine if you specify the ip-address but, after a while, those ip-addresses are difficult to remember ... afterall, that is why dns exists.
For IPv4, with a some patches to libvert implementing "--local=/virt/ --domain-needed" if "--domain virt" is specified, I am now able to ssh to guests by name.
The additions needed are to run the NetworkManager supporting "--conf-dir=/etc/NetworkManager/dnsmasq.d/" (or patch it like I did), and add a file specifying the dnsmasq on the virtual NIC. For example, server=/virt/,192.168.122.1 will forward queries.
Alternatively, you can run yet another dnsmasq on the host which just passes queries to the dnsmasq and modify your upstream dns server to forward any queries for the virtual domains to the dnsmasq on the host.
IPv6 is another situation entirely. And it may be even more important to have dns support because if IPv4 address are difficult to remember, IPv6 are practically impossible.
So, are there any plans for providing dns on the IPv6 virtual networks?
I can see a couple of solutions and each has pluses and minuses.
1. Do it the same way the it is done for IPv4. The current version of dnsmasq (2.63) supports dhcp for IPv6 and, IIRC, has since 2.61. I realize that you need to continue support of libvirt on RHEL 6 and possibly others that are running an old version of dnsmasq, but isn't it time to move along? While you can manually configure IPv6 interfaces so that you can add the definitions to a /etc/host file, this is not a good approach from my perspective. The use of dnsmasq also allows specification of different domains for each virtual IPv6 network.
2. There is another approach and it would be useful for both dnsmasq and this approach be available. That is, continue to use radvd and have the virtual guests autoconf the ip addresses. Then use mDNS (avahi and nss-mdns) to support access by name. This does not require doing anything about dnsmasq. In fact, it is possible thatyou do not need it at all. In addition, the plans for Fedora 18 are to make mDNS the default for Desktop installs [I am not sure what that means]. A big problem is that there is only a single domain which is ".local" by default. An even bigger problem is that ssh (openssh) has an error if a mDNS name is specified.
I noticed that Daniel Berrange has put in a bugzilla request that dnsmasq be updated.
If someone is already coding up patches to add dhcp for IPv6 or will "real soon now", I will be happy to test it. Otherwise, I could take a shot at coming up with the patches. AFAIK nobody else is working on that right now, so I'd say go for it :-)
OK ... I guess :-) I started looking at the code and I believe that I am going to learn a lot more about libvirt that I thought I would have to. Well, this is something I believe needs doing. Gene
On 09/13/2012 04:05 PM, Laine Stump wrote:
On 09/13/2012 02:00 PM, Gene Czarcinski wrote:
I would like to know what the plans are for supporting dns for virtual guests with only IPv6.
My objective is to be able to reference a virtual guest for the host ... doing ssh, scp, etc. such functions work just fine if you specify the ip-address but, after a while, those ip-addresses are difficult to remember ... afterall, that is why dns exists.
For IPv4, with a some patches to libvert implementing "--local=/virt/ --domain-needed" if "--domain virt" is specified, I am now able to ssh to guests by name.
The additions needed are to run the NetworkManager supporting "--conf-dir=/etc/NetworkManager/dnsmasq.d/" (or patch it like I did), and add a file specifying the dnsmasq on the virtual NIC. For example, server=/virt/,192.168.122.1 will forward queries.
Alternatively, you can run yet another dnsmasq on the host which just passes queries to the dnsmasq and modify your upstream dns server to forward any queries for the virtual domains to the dnsmasq on the host.
IPv6 is another situation entirely. And it may be even more important to have dns support because if IPv4 address are difficult to remember, IPv6 are practically impossible.
So, are there any plans for providing dns on the IPv6 virtual networks?
I can see a couple of solutions and each has pluses and minuses.
1. Do it the same way the it is done for IPv4. The current version of dnsmasq (2.63) supports dhcp for IPv6 and, IIRC, has since 2.61. I realize that you need to continue support of libvirt on RHEL 6 and possibly others that are running an old version of dnsmasq, but isn't it time to move along? While you can manually configure IPv6 interfaces so that you can add the definitions to a /etc/host file, this is not a good approach from my perspective. The use of dnsmasq also allows specification of different domains for each virtual IPv6 network.
2. There is another approach and it would be useful for both dnsmasq and this approach be available. That is, continue to use radvd and have the virtual guests autoconf the ip addresses. Then use mDNS (avahi and nss-mdns) to support access by name. This does not require doing anything about dnsmasq. In fact, it is possible thatyou do not need it at all. In addition, the plans for Fedora 18 are to make mDNS the default for Desktop installs [I am not sure what that means]. A big problem is that there is only a single domain which is ".local" by default. An even bigger problem is that ssh (openssh) has an error if a mDNS name is specified.
I noticed that Daniel Berrange has put in a bugzilla request that dnsmasq be updated.
If someone is already coding up patches to add dhcp for IPv6 or will "real soon now", I will be happy to test it. Otherwise, I could take a shot at coming up with the patches. AFAIK nobody else is working on that right now, so I'd say go for it :-)
This is going to be more involved than I thought. While dnsmasq is suppose to support IPv6, I can get the IP-addresses but not the dns update. Right now, I believe the reason for that is that NetworkManager does not send the fqdn. Gene
On Thu, Sep 13, 2012 at 02:00:48PM -0400, Gene Czarcinski wrote:
I would like to know what the plans are for supporting dns for virtual guests with only IPv6.
My objective is to be able to reference a virtual guest for the host ... doing ssh, scp, etc. such functions work just fine if you specify the ip-address but, after a while, those ip-addresses are difficult to remember ... afterall, that is why dns exists.
For IPv4, with a some patches to libvert implementing "--local=/virt/ --domain-needed" if "--domain virt" is specified, I am now able to ssh to guests by name.
The additions needed are to run the NetworkManager supporting "--conf-dir=/etc/NetworkManager/dnsmasq.d/" (or patch it like I did), and add a file specifying the dnsmasq on the virtual NIC. For example, server=/virt/,192.168.122.1 will forward queries.
Alternatively, you can run yet another dnsmasq on the host which just passes queries to the dnsmasq and modify your upstream dns server to forward any queries for the virtual domains to the dnsmasq on the host.
IPv6 is another situation entirely. And it may be even more important to have dns support because if IPv4 address are difficult to remember, IPv6 are practically impossible.
So, are there any plans for providing dns on the IPv6 virtual networks?
I can see a couple of solutions and each has pluses and minuses.
1. Do it the same way the it is done for IPv4. The current version of dnsmasq (2.63) supports dhcp for IPv6 and, IIRC, has since 2.61. I realize that you need to continue support of libvirt on RHEL 6 and possibly others that are running an old version of dnsmasq, but isn't it time to move along? While you can manually configure IPv6 interfaces so that you can add the definitions to a /etc/host file, this is not a good approach from my perspective. The use of dnsmasq also allows specification of different domains for each virtual IPv6 network.
FYI, already libvirt aims to work with old dnsmasq, in general there is no problem with using features from new dnsmasq. If the host has an old dnsmasq, they simply won't be able to take advantage of new features libvirt might support. The key is simply that if the host has the old dnsmasq, we should be careful not to invoke it in the wrong way for existing features. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 09/14/2012 06:08 AM, Daniel P. Berrange wrote:
FYI, already libvirt aims to work with old dnsmasq, in general there is no problem with using features from new dnsmasq. If the host has an old dnsmasq, they simply won't be able to take advantage of new features libvirt might support. The key is simply that if the host has the old dnsmasq, we should be careful not to invoke it in the wrong way for existing features. I am not sure I understand the reasoning for continuing support of old versions of dnsmasq ... but so be it. How is the version of dnsmasq being determined ... at [ugly] runtime or during configuration/compilation?
Adding IPv6 dns capability to libvirt is turning out to be a little more involve that I thought it would be. Right now you can define a IPv6 network manually, define static IPv6 addresses in the guests, and add the definitions to the host's /etc/hosts file. That works. The current dnsmasq 2.63 has a number of options for IPv6 and (to me) appears to duplicate some/all of the functionality of radvd. It is not clear to me that all of these need to be supported. However, there is one mode which uses "slaac" IPv6 addresses on a network running both IPv4 and IPv6 stacks. It then does a "little dance" and will add the IPv6 address to cache under the guest system's FQDN. But this is not dhcp support. I am doing some testing but I believe that NetworkManager is not doing "the right thing" for stateful IPv6 addressing ... it is not sending the FQDN (not the host name like in IPv4 but the FQDN). I am trying not to dig into the NetworkManager code and am doing some testing to prove that this is the problem. Assuming that both of these approaches to IPv6 addressing and a dns service are desirable, this means adding some kind of network definition parameters so that libvirt knows what dnsmasq parameters to use. Any comments appreciated. Gene
On 09/15/2012 04:07 PM, Gene Czarcinski wrote:
On 09/14/2012 06:08 AM, Daniel P. Berrange wrote:
FYI, already libvirt aims to work with old dnsmasq, in general there is no problem with using features from new dnsmasq. If the host has an old dnsmasq, they simply won't be able to take advantage of new features libvirt might support. The key is simply that if the host has the old dnsmasq, we should be careful not to invoke it in the wrong way for existing features. I am not sure I understand the reasoning for continuing support of old versions of dnsmasq ... but so be it.
Upstream libvirt is targetted at many platforms, past and present, and must continue to build and function properly on a lot of different systems that aren't "the latest". For example, because there is a very large installed base of RHEL5 systems, we still check to make sure that upstream libvirt builds and runs properly on RHEL5.
How is the version of dnsmasq being determined ... at [ugly] runtime or during configuration/compilation?
You can't rely on any information gathered at compile time, since the binary may be built on one system and run on another. Instead, I believe what Dan was talking about is that the default usage of dnsmasq uses only features that are available on the oldest dnsmasq we support (which is likely whatever version is currently shipping with RHEL5 / CentOS5), and any dnsmasq feature used by libvirt that requires a newer version of dnsmasq will only be attempted when some extra knob is turned on in the config (for example, if someone wants IPv6 DNS :-), and will generate an error and fail if dnsmasq on the system isn't new enough to support whatever feature is required.
Adding IPv6 dns capability to libvirt is turning out to be a little more involve that I thought it would be.
Right now you can define a IPv6 network manually, define static IPv6 addresses in the guests, and add the definitions to the host's /etc/hosts file. That works.
The current dnsmasq 2.63 has a number of options for IPv6 and (to me) appears to duplicate some/all of the functionality of radvd. It is not clear to me that all of these need to be supported. However, there is one mode which uses "slaac" IPv6 addresses on a network running both IPv4 and IPv6 stacks. It then does a "little dance" and will add the IPv6 address to cache under the guest system's FQDN. But this is not dhcp support.
I am doing some testing but I believe that NetworkManager is not doing "the right thing" for stateful IPv6 addressing ... it is not sending the FQDN (not the host name like in IPv4 but the FQDN). I am trying not to dig into the NetworkManager code and am doing some testing to prove that this is the problem.
Assuming that both of these approaches to IPv6 addressing and a dns service are desirable, this means adding some kind of network definition parameters so that libvirt knows what dnsmasq parameters to use.
Any comments appreciated.
A general suggestion when adding things like this: try to make any required config options related to dhcp/dns terminology rather than the way they are presented in dnsmasq. Keep in mind that someone may some day want to provide a backend based on something other than dnsmasq.
On 09/15/2012 05:10 PM, Laine Stump wrote:
On 09/15/2012 04:07 PM, Gene Czarcinski wrote:
How is the version of dnsmasq being determined ... at [ugly] runtime or during configuration/compilation? You can't rely on any information gathered at compile time, since the binary may be built on one system and run on another.
Instead, I believe what Dan was talking about is that the default usage of dnsmasq uses only features that are available on the oldest dnsmasq we support (which is likely whatever version is currently shipping with RHEL5 / CentOS5), and any dnsmasq feature used by libvirt that requires a newer version of dnsmasq will only be attempted when some extra knob is turned on in the config (for example, if someone wants IPv6 DNS :-), and will generate an error and fail if dnsmasq on the system isn't new enough to support whatever feature is required.
Adding IPv6 dns capability to libvirt is turning out to be a little more involve that I thought it would be.
Right now you can define a IPv6 network manually, define static IPv6 addresses in the guests, and add the definitions to the host's /etc/hosts file. That works.
The current dnsmasq 2.63 has a number of options for IPv6 and (to me) appears to duplicate some/all of the functionality of radvd. It is not clear to me that all of these need to be supported. However, there is one mode which uses "slaac" IPv6 addresses on a network running both IPv4 and IPv6 stacks. It then does a "little dance" and will add the IPv6 address to cache under the guest system's FQDN. But this is not dhcp support.
I am doing some testing but I believe that NetworkManager is not doing "the right thing" for stateful IPv6 addressing ... it is not sending the FQDN (not the host name like in IPv4 but the FQDN). I am trying not to dig into the NetworkManager code and am doing some testing to prove that this is the problem.
Assuming that both of these approaches to IPv6 addressing and a dns service are desirable, this means adding some kind of network definition parameters so that libvirt knows what dnsmasq parameters to use.
Any comments appreciated. A general suggestion when adding things like this: try to make any required config options related to dhcp/dns terminology rather than the way they are presented in dnsmasq. Keep in mind that someone may some day want to provide a backend based on something other than dnsmasq. OK, how about this approach...
Let's assume we only want the "real dhcp6" provided by dnsmasq. If you do not specify a dhcp range for a family='ipv6' virtual network definition, then everything is as it is today. If you do specify a dhcp-range for an 'ipv6" network, then the extra command line parameter is added and (assuming you are running something like dnsmasq-2.63), it works: you get stateful dhcp6 with updates to the dns. The only other dnsmasq mode that might be of interest is "ra-names" and yes this is a dnsmasq thing. I need to do more testing to see if I want to bother with it. Again, if it is implemented, the default would be nothing and the command line compatible with old dnsmasq versions. Some special "parameter" would be needed for this to be invoked. The only interest I have in the 'ra-names" is that I need NetworkManager to work correctly and send fqdn.fqdn information for IPv6 networks and until it does, ra-names works. I have not looked at the code or done testing but, from looking at various documents, I believe that dhcpd-v6 will also need the fqdn.fqdn sent for it to do dynamic dns updating for IPv6 addresses. As I said earlier, static IPv6 addresses and /etc/hosts entries on the qemu/kvm/libvirt host work today with no changes. I hope this is a "good enough" solution and I believe it is do-able. Gene
participants (3)
-
Daniel P. Berrange -
Gene Czarcinski -
Laine Stump