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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list