On Fri, Jun 19, 2009 at 05:39:57PM +0100, Daniel P. Berrange wrote: > On Thu, Jun 18, 2009 at 05:53:59PM +0000, David Lutterkort wrote: > > On Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote: > > > > > 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. ? > > Yes that was a mistake. > > > > 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> > > Here is a proposal that is a compromise between the single hierarchy, and > completely flat. The break point is only introduced where VLANs appear, > which is acceptable because when defining VLAns, you don't need to define > the underlying inteface at the same time - it can exist in its own right > ahead of time. Only nic+bond or nics+bridge or nic+bond+bridge need to > be atomically defined at once. > > > There are 4 possible arrangements of physical NIC, bond and vlan, > each of which can use a bridge. This gives 8 total configs > > 1. Physical NIC > > 2. Physical NIC + bridge > > 3. Physical NIC + bond > > 4. Physical NIC + bond + bridge > > 5. Physical NIC + vlan > > 6. Physical NIC + vlan + bridge > > 7. Physical NIC + bond + vlan > > 8. Physical NIC + bond + vlan + bridge > > > Of those, the last 4 are the 'hard' ones since there are 'n' > source points and 'm' end points. The end points are the core > object the public API wants to deal in. > > The first 4 configs can all be expressed in terms of a single > interface object, since there is a single end point. The last > 4 configs suggest one base interface followed by 'n' additional > interfaces, with the break being where the 1 -> 'n' relation > appears. The idea of having the intermediate 'end point' appear > as an interface object in the public API makes sense, because > these can exist in their own right, before VLANs are added. > Only bonds/bridges need to be defined as a single entity. > > So the possible configs would appear as XML like > > 1. Physical NIC > > <interface type='ethernet'> > <name>eth0</name> > </interface> > > 2. Physical NIC + bridge > > <interface type="bridge"> > <name>br0</name> > <bridge> > <interface type='ethernet'> > <name>eth0</name> > </interface> > </bridge> > </interface> > > 3. Physical NIC + bond > > <interface type="bond"> > <name>bond0</name> > <bond> > <interface type='ethernet'> > <name>eth0</name> > </interface> > <interface type='ethernet'> > <name>eth1</name> > </interface> > </bond> > </interface> > > 4. Physical NIC + bond + bridge > > <interface type="bridge"> > <name>br0</name> > <bridge> > <interface type="bond"> > <name>bond0</name> > <bond> > <interface type='ethernet'> > <name>eth0</name> > </interface> > <interface type='ethernet'> > <name>eth1</name> > </interface> > </bond> > </interface> > </bridge> > </interface> > > 5. Physical NIC + 2 * vlan > > <interface type="ethernet"> > <name>eth0</name> > </interface> > > <interface type="vlan"> > <name>vlan42</name> > <vlan tag='42'> > <interface type='ethernet'> > <name>eth0</name> > </inteface> > </vlan> > </inteface> > > <interface type="vlan"> > <name>vlan48</name> > <vlan tag='48'> > <interface type='ethernet'> > <name>eth0</name> > </inteface> > </vlan> > </inteface> > > > 6. Physical NIC + 2 * vlan + bridge > > <interface type="ethernet"> > <name>eth0</name> > </interface> > > <interface type='bridge'> > <name>br42</name> > <bridge> > <interface type="vlan"> > <name>vlan42</name> > <vlan tag='42'> > <interface type='ethernet'> > <name>eth0</name> > </inteface> > </vlan> > </inteface> > </bridge> > </interface> > > <interface type='bridge'> > <name>br42</name> > <bridge> > <interface type="vlan"> > <name>vlan42</name> > <vlan tag='42'> > <interface type='ethernet'> > <name>eth0</name> > </inteface> > </vlan> > </inteface> > </bridge> > </interface> > > > 7. Physical NIC + bond + 2 * vlan > > <interface type="bond"> > <name>bond0</name> > <bond> > <interface type='ethernet'> > <name>eth0</name> > </interface> > <interface type='ethernet'> > <name>eth1</name> > </interface> > </bond> > </interface> > > <interface type="vlan"> > <name>vlan42</name> > <vlan tag='42'> > <interface type='bond'> > <name>bond0</name> > </inteface> > </vlan> > </inteface> > > <interface type="vlan"> > <name>vlan48</name> > <vlan tag='48'> > <interface type='bond'> > <name>bond0</name> > </inteface> > </vlan> > </inteface> > > 8. Physical NIC + bond + 2 * vlan + bridge > > > <interface type="bond"> > <name>bond0</name> > <bond> > <interface type='ethernet'> > <name>eth0</name> > </interface> > <interface type='ethernet'> > <name>eth1</name> > </interface> > </bond> > </interface> > > <interface type='bridge'> > <name>br42</name> > <bridge> > <interface type="vlan"> > <name>vlan42</name> > <vlan tag='42'> > <interface type='bond'> > <name>bond0</name> > </inteface> > </vlan> > </inteface> > </bridge> > </interface> > > <interface type='bridge'> > <name>br42</name> > <bridge> > <interface type="vlan"> > <name>vlan42</name> > <vlan tag='42'> > <interface type='bond'> > <name>bond0</name> > </inteface> > </vlan> > </inteface> > </bridge> > </interface> > > > > Of course, you could actually have a hybrid of 7/8, where some vlans > where bridged, and others direct endpoints. That's trivally handled > there of course. Hum, since an XML can only have one single root, I suggest to put a wrapper around multiple definitions and if you call it <interfaces> that looks a bit like my own proposal but more recursive. I still suggest to change having name as an attribute on the <interface> tags because it allows to easilly do the ID/IDREF matching. for references. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list