11:25 a.m.
On Thu, Nov 04, 2010 at 11:49:32AM -0400, Laine Stump wrote:
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.
Yes, treat it in the same way we treat dnsmasq, unless we find
something that requires a different approach.
> 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?
No, in isolated mode we still configure the IPv6 network as normal.
They simply won't be able to route to the LAN, because the firewall
rules will block traffic.
As a general rule you can't directly use link-local addresses from
applications, unless they've been explicitly designed to allow it,
and most haven't. The link local addresses are used in the router
advertisment protocol, to get a real address, at which point normal
apps can talk.
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)
As long as the radvd we're running is only sending traffic on the
the bridge interface we've created, it is no problem. We'd only
cause trouble if say we accidentally let it use a real physical
NIC on the LAN.
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?
They're out of scope of this functionality. The fact that we're using
radvd is just a private implementation detail. We're not providing a
general purpose IPv6 management API here.
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).
We should continue to set /net/ipv6/conf/%s/disable_ipv6=1 when
no IPv6 address is in XML. If someone really wants to roll their own
config, using libvirt's bridge, then they can toggle the setting
back to 0 at the same time as they manually configure the addresses
The other settings
/net/ipv6/conf/%s/accept_ra
/net/ipv6/conf/%s/autoconf
need to be set to 0 at all times. An interface which is used as a
gateway must always have autoconf=0, and accept_ra=0 is required
to prevent the guest hijacking the host network by sending out
its own router advertisments.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|