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>