On Fri, Jan 16, 2009 at 03:06:16PM +0000, Daniel P. Berrange wrote:
<interface type='physical'> <name>eth0</name> <mac address='00:19:d2:9f:88:96'/> <dhcp peerdns="yes"/> </interface>
<interface type='physical' <name>eth1</name> <mac address='00:19:d2:9f:88:97'/> <ip address="192.168.0.5" gateway="192.168.0.1" netmask="255.255.255.0"/> </interface>
<interface type='physical' <name>eth2</name> <mac address='00:19:d2:9f:88:98'/> </interface>
<interface type='bond'> <name>bond0</name> <bond mode='active-backup'> <interface name="eth0" primary="yes"/> <interface name="eth1"/> </bond> </bond>
<interface type='bridge'> <name>br0</name> <bridge stp='off'> <interface name="eth2"/> </bridge> <dhcp peerdns="yes"/> </bridge>
<interface type='vlan'> <name>vlan0</name> <vlan tag="42" reorder_hdr="yes"> <interface name='eth0'> </vlan> </inteface>
* Are there crucial config options that are not covered by the sketches above (e.g., setting an explicit MTU) ? Are there things in the XML sketches above that will be impossible to implement on some OS ?
There are almost certainly things we won't be able to implement for certain backends. XenAPI's API does not allow for VLANs for example. The important thing would be to provide a way to query what capabilities are curently available. So akin to the host virt capabilities, we'd need network API capabilities data.
Actually I tell a lie - XenAPI does allow for bonding + vlans, using a generic 'interface' class and a master/slave relation to associate bonds with their interfaces, and interfaces with vlans. So the XML format and functionality should map onto that quite well. 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 :|