On 03/02/2012 12:05 PM, Gerhard Stenzel wrote:
On Fri, 2012-03-02 at 10:52 -0500, Laine Stump wrote:
> 1) Currently it requires a PCI address (although I plan to add the
> ability to accept a netdev name and automatically convert it to a PCI
> address):
>
> <source>
> <address type='pci' domain='0' bus='0'
slot='6' function='0'/>
> </source>
This means the XML fragment look more like this for Qbh:
<interface type='hostdev'>
<source>
<address type='pci' domain='0' bus='0'
slot='6' function='0'/>
</source>
<mac address='52:54:00:8b:c9:51'>
<virtualport type='802.1Qbh'>
<parameters profileid='finance'/>
</virtualport>
</interface>
and for Qbg:
<interface type='hostdev'>
<source>
<address type='pci' domain='0' bus='0'
slot='6' function='0'/>
</source>
<mac address='52:54:00:8b:c9:51'>
<virtualport type="802.1Qbg">
<parameters managerid="11" typeid="1193047"
typeidversion="2"
instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f" vlanid="2"/>
</virtualport>
</interface>
So vlanid is the new part? In the case we have no macvtap device we
would have to find the vlanid in the XML and could convey that to lldpad
directly (rather than determining it by walking the stack of interfaces
as we do now) along with an ifindex of '0' or '-1' (?). If lldpad never
really looked at the ifindex or ifname we sent it via the netlink
message then this shouldn't be a problem to support, apart from having
to configure the guest to create a vlan interface of course. So I guess
the other set of parameters were not applied to the VM's traffic to
allow VM A using vlanid 2 to be distinguishable from VM B using vlanid 2
as well on the same host? If this is all true, then at least the code
path creating the association should be easy to adapt...
Stefan