On Wed, May 12, 2010 at 12:13:14PM -0400, Stefan Berger wrote:
Below is David Alan's original patch with lots of changes.
In particular, it now parses the following two XML descriptions, one
for 802.1Qbg and 802.1Qbh and stored the data internally. The actual
triggering of the switch setup protocol has not been implemented
here but the relevant code to do that should go into the functions
associatePortProfileId() and disassociatePortProfileId().
<interface type='direct'>
<source dev='static' mode='vepa'/>
<model type='virtio'/>
<vsi type='802.1Qbg'>
<parameters managerid='12' typeid='0x123456'
typeidversion='1'
instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f'/>
</vsi>
<filterref filter='clean-traffic'/>
</interface>
<interface type='direct'>
<source dev='static' mode='vepa'/>
<model type='virtio'/>
<vsi type='802.1Qbh'>
<parameters profileid='my_profile'/>
</vsi>
</interface>
I'd suggest to use this patch as a base for triggering the setup
protocol with the 802.1Qb{g|h} switch.
Ok, I think the XML suggestion is pretty reasonable wrt what I
can read about current state of the 802.* standards. My main
question is how this applies to the Cisco VNLink capability
that (IIUC) already exists in hardware today.
It sounds like at an XML level it is pretty much wanting the
same data as the 802.1Qbh case, so we could simply add a
3rd option that follows the scheme:
<interface type='direct'>
<source dev='static' mode='vepa'/>
<model type='virtio'/>
<vsi type='vnlink'>
<parameters profileid='my_profile'/>
</vsi>
</interface>
Internally this type='vnlink' would be something we key off
to decide whether we need to also pass down a host UUID and
other bits of info the Cisco stuff wants (guest UUID/name).
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|