[libvirt] RFC: Supporting IPv6 on libvirt virtual networks
Paolo Bonzini
pbonzini at redhat.com
Wed Nov 3 10:05:11 UTC 2010
On 11/02/2010 07:22 PM, Laine Stump wrote:
> 1) The <ip> element of the network xml will be expanded in the following
> ways:
>
> a) <ip> can now appear multiple times (although I think only one of
> these can/should be allowed to have a <dhcp> element). The bridge
> interface (eg virbr0) will be configured with all given ips.
While this can make sense as an initial implementation limit, I think in
general it makes sense to have multiple <dhcp> elements, with one
dnsmasq instance per <dhcp> (the need to invoke multiple dnsmasq
instances is a limitation of dnsmasq's command-line syntax, for example
dhcpd wouldn't need it).
So, it seems okay but it should be documented as a limit of libvirt
rather than a limit of the specification.
> family="ipv4|ipv6".
>
> Optional. It will default to ipv4 if not specified.
I do prefer ipv4/ipv6, but I'll just point out inet/inet6 as a possible
alternative.
> 2) New subelements of <ip>
>
> If we want to avoid requiring the admin to login to the hosts to
> configure radvd for advertising addresses, the ipv6 version of <ip>
> is going to need radvd config information. The list of options is
> rather long, and I don't see how we could assume a hardcoded
> default for any of them
If I had to pick four, those would be AdvSendAdvert, AdvOnLink,
AdvAutonomous, AdvRouterAddr. However...
> http://linux.die.net/man/5/radvd.conf
>
> For this reason, I think we can at least initially *not* include all
> this config, and not attempt to run radvd ourselves.
... as an initial plan I agree.
However, if you were to keep the <radvd/> element I would move it under
<interface> instead. This is for two reasons:
1) The idea, is that elements within <ip> represent services listening
on those interfaces (<dhcp> and <tftp> currently). You cannot SIGHUP
radvd only on some prefixes.
2) If, in the future, you add the ability to run radvd autonomously, an
empty <radvd/> tag would have a different meaning than "send a SIGHUP to
radvd". In particular, currently if there is no entry for an interface
in radvd.conf adding the <radvd/> tag makes no difference. If libvirtd
were to manage radvd, the empty tag would likely mean "start radvd with
some default arguments".
In other words, the schema should reflect the fact that radvd is not
handled the same way as dnsmasq. As an alternative idea I wonder: does
it make sense to do do the radvd SIGHUP unconditionally or based on a
/etc/libvirtd.conf flag?
(As an aside: when libvirtd starts managing radvd autonomously, if ever,
I would use a name like <ndp> for neighbor discovery protocol, rather
than radvd).
> libvirt's virtual networks have three modes: isolated, routed, and
> nat. If mode=isolated or mode=routed, IPv6 and IPv4 will be handled
> the same. However, since there is no NAT for IPv6, if you specify
> mode='nat' on a network, and give it an IPv6 address, the IPv6 traffic
> will be routed, while IPv4 traffic will be NATed. (Since there is a
> single mode attribute for the entire network, it will not be possible
> to specify isolated IPv6 and routed/nat IPv4, or isolated IPv4 and
> routed IPv6).
It could be possible to represent this in the schema by splitting out
the dev attribute into a new element, like this:
<physdev dev="eth1">
<forward mode="nat" family="ipv4">
<forward mode="isolated" family="ipv6">
My iptables-fu is too small to understand if it would make sense to have
multiple physdev elements.
Paolo
More information about the libvir-list
mailing list