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: > > 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> I think this is a really unpleasant format to deal with. IMHO there should not be nesting for <bridge>/<bond> tags. They should just refer to their slave device by name. So that last example would be better shown as a set of independant intefaces <interface type='bond'> <name>bond0</name> <bond mode="active-backup"> <interface name='eth0'/> <interface name='eth1'/> </bond> </interface> <interface type='vlan'> <name>bond0.42</name> <vlan tag='42'> <interface name='bond0'> </bridge> </interface> <interface type="bridge" startmode="onboot"> <name>br0</name> ... <bridge stp="off"> <interface name="bond0.42"/> </bridge> <interface> If you added more vlans, then they just appear as more interfaces at the top level <interface type='vlan'> <name>bond0.47</name> <vlan tag='47'> <interface name='bond0'> </bridge> </interface> <interface type='vlan'> <name>bond0.48</name> <vlan tag='48'> <interface name='bond0'> </bridge> </interface> Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list