Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote:
On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote:
> We should allow standalone IPv4 and IPv6, or both. Each could either
> use DHCP or allow one or more IP address and routes.
You need to have allow for IP adddresses & routes to be present even
when doing DHCP, because you need to discover what was auto-configured.
That only makes sense when reading an existing config, with the meaning
'the interface uses DHCP when it is brought up, and has the following
address currently assigned to it'; it makes no sense when using the XML
to configure a device.
I would prefer for that case a separate API call to ask for currently
assigned addresses.
This is overly strict, because it does not allow for an interface
without any addresses - something you want todo if configuring a
bridge device just for guest traffic and do not want any IP on it
for the host. So just need to make both optional
You can achieve the same by making interface-addressing optional where
it is used.
Check out this preso for an overview if you dare.
http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf
Need to read that first.
The 'ip-addr' match rule will need separate rules for IPv4 vs
IP6
addresses, since the former use '.' as a seprator, while the latter
use ':'. The 'prefix-pattern' can be same, since its just a number
The valid range for prefix-pattern differs, and we should therefore
between the two.
VLANs are tricky, because you can define VLANs on a physical
inteface or a bond interface, and you then may want to also
add a bridge on top of a VLAN, eg take 2 physical NICs, eth0
and eth1, here are some possible combes
- One NIC for storage, another for host mgmt, and put
the guests all on VLANs
eth0 -> br0 IP addr used for storage
eth1 -> br1 IP addr used for host mgmt
eth1.42 -> br1.42 IP addr, used to talk to guests
eth1.43 -> br1.43 No IP, guest traffic only
eth1.44 -> br1.44 No IP, guest traffic only
I don't think that's the right notation, don't you mean 'eth1.42 ->
br2'
etc. ?
I think the currently approach of modelling bond, bridges and NICs
makes this a little hard, particularly if the netcf API only exposes
'connections' and not interfaces, because some of these setups are
not really connections, only building blocks for 'n' other connections
For that, you'd nest them where they are used, e.g. one connection to
establish the base ethernet interface (that might not exist at all):
<interface type="ethernet" startmode="none">
<name>eth0</name>
<mtu size="1492"/>
<mac address="aa:bb:cc:dd:ee:ff"/>
<dhcp peerdns="no"/>
</interface>
and one for the bridge with a vlan enslaved:
<interface type="bridge" startmode="onboot">
<name>br0</name>
...
<bridge stp="off">
<interface type="vlan" device="eth0"
tag="42"/>
</bridge>
</interface>
Similarly, a bond enslaved to a bridge, together with a vlan on that
bond also enslaved to the bridge would look like
<interface type="bridge" startmode="onboot">
<name>br0</name>
...
<bridge stp="off">
<interface type="bond">
<name>bond0</name>
<bond mode="active-backup">
<interface type="ethernet">
<name>eth1</name>
</interface>
<interface type="ethernet">
<name>eth0</name>
</interface>
</bond>
</interface>
<interface type="vlan" device="bond0"
tag="42"/>
</bridge>
</interface>
David