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 :|