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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list