[libvirt] RFC: Supporting IPv6 on libvirt virtual networks

[Laine Stump]

On 11/03/2010 06:36 AM, Daniel P. Berrange wrote:
> On Tue, Nov 02, 2010 at 02:22:08PM -0400, Laine Stump wrote:
>>     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, so if we're going to have an<radvd>
>>     subelement, it's going to need a *lot* of attributes/subelements of
>>     its own:
>>
>>       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.
> The list of radvd.conf options is long, because it is a tool that has
> to serve a million&  one different deployment scenarios. The libvirt
> virtual networking is just 1/2 scenarios and thus we don't need to
> deal with the entire of radvd configuration.

Okay, I'll take your word for that, and use your example in the other 
email as the model config.

Can I assume it's okay to do this:

1) run a separate radvd instance for each interface
2) store the pid in /var/run/libvirt/network/${netname}-radvd.pid
3) create the conf file to be used by radvd in 
/var/run/libvirt/network/${netname}-radvd.conf

??

Also, similar to dnsmasq, I will leave it running if libvirtd exits, and 
check for it the next time libvirtd starts up.


>>     However, we can't merely ignore radvd, since our bridges don't
>>     exist at the time radvd is started by the system, and even if
>>     you've put the proper config in the static radvd.conf file, it
>>     can't be recognized until the interface exists, and the method of
>>     informing radvd that it needs to re-scan the conf file to find new
>>     interfaces is to send it a SIGHUP.
> That isn't going to work. radvd is something that you only ever run
> on machines that are network gateways. Virtalization hosts are thus
> very unlikely to be running radvd at all. We are taking a non-gateway
> host, and making it serve as a gateway solely for the virutal network
> interface. As such, we need to be able to run radvd ourselves, solely
> for the virbr0 device (and any other configured networks we have).
> Running libvirt on a host that is already a network router, and thus
> does have radvd running, is something that is really out of scope
> for this.


But once I get this all running, that's exactly what I will be doing 
(using the same machine as a virt host and an IPv6 router). :-P

Sure, it's not what I'd do if I had lots of equipment and space, but in 
my limited hardware setup at home, I only have a single machine that I 
can depend on to be always on, and always connected to the network.


Anyway, as long as radvd can have multiple instances running (as long as 
none of them are attempting to use the same interface), this shouldn't 
be a problem.


>   Therefore we should entirely manage radvd as we do for
> dnsmasq.
>
>>     So, I'm thinking we can add an<radvd/>  subelement to IP that, for
>>     now, will have no attributes and no subelements. If the ip/radvd
>>     subelement exists, libvirt will send radvd a SIGHUP when the
>>     network is brought up, and again if it is brought down.
> I don't think we need a radvd element really. If the forwarding
> method is 'routed', then we always need radvd to make that
> functionality work. If it is 'isolated', then we don't want it.
> To configure radvd, all we need to know is the interface name,
> and bridge IPv6 address and the bridge prefix. We have all that
> info already in the XML.

So I guess the idea is that in isolated mode, the machines could talk 
amongst themselves using the link-local IPv6 address (fe80:...), right?

As far as in routed mode, I have two questions:


1) Can we be 100% sure that users will always want want (or at least be 
able to tolerate) route discovery on a routed IPv6 network? (I don't 
have enough experience using IPv6 in the real world to know the answer)

2) What about the people who do want to adjust the radvd config in some 
manner, should we require them to setup their own bridge from scratch?

3) (kind of related to (2)) If no IPv6 addresses are given in the XML, 
should we continue to disable IPv6 capabilities on the bridge (thus 
preventing someone from rolling their own radvd/whatever without needing 
to create their own bridge).


>
>> Configuring the IP addresses of the bridge
>> ------------------------------------------
>>
>> Unfortunately, libnl isn't available on all Linux platforms (libvirt's
>> virtual networks are only available on Linux), for example RHEL5 has
>> libnl, but it's an older version that is API-incompatible with the
>> version used by libvirt.
> How badly API incompatible ?  Stupid little differences that can be
> trivially #ifdef'd, or major differences that make it look like an
> entirely different API ?


A good question. I'm not sure. My statement here is based totally on an 
email where the NetworkManager maintainer (Dan Williams) told me that 
when they started using libnl-1.1 in the version of NetworkManager 
that's in RHEL-5, they had to build their own private copy of libnl, 
since the -1.0 in RHEL5 was ABI incompatible.

A quick look through the header files of 1.0 vs 1.1 shows that the name 
of at least one header file has changed, and there are some new 
functions, and some others eliminated. Much of it is the same, though. 
My worry would be about functions whose signature remains the same, but 
have different semantics.