[libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

[Gerhard Stenzel]

On Fri, 2012-03-02 at 10:52 -0500, Laine Stump wrote:
> Again, my knowledge is insufficient to understand - why was a vlanid
> not
> necessary before when we were dealing with a hostside macvtap tied to
> a
> guest-side emulated netdev, and why is it necessary now that we want
> to
> just passthrough the PCI device to the guest?
> 
> >  Note the additional vlanid attribute. The semantic
> > would be that the host establishes a Qbg association for 
> > (managerid, typeid, typeidversion, instanceid, vlanid)
> > and that the VM would need to add the correct VLAN tag in order to
> be
> > able to communicate.
> 
> So adding the VLAN tag has in the past been done by the macvtap
> interface? Where did it learn the vlanid from?

(Many questions for which I will need some time ..)

Let me answer the simple ones first:

If you look here http://libvirt.org/formatdomain.html:

<devices>
    <interface type='direct'/>
    ...
    <interface type='direct'>
      <source dev='eth0.2' mode='vepa'/>
      <virtualport type="802.1Qbg">
        <parameters managerid="11" typeid="1193047" typeidversion="2"
instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/>
      </virtualport>
    </interface>
  </devices>
  ...

In this example, the macvtap interface will be created on top of the
VLAN interface 2 on top of eth0.

The Qbg switch needs this information:
(managerid, typeid, typeidversion, instanceid, vlanid)

macvtap/VEPA does not need the the VLAN to work, but Qbg does.

So for PCI passthrough, if the host does the association, it has to know
which VLANID to associate, but the guest has to add the VLAN tags.

> 
> Definitely if the packets need to leave the host with a VLAN tag, in
> PCI
> passthrough mode that will need to be done by the guest OS, since the
> host will be unable to get its hands on the packets. Once that's the
> case, does it maybe make more sense to just leave *everything* up to
> the
> guest OS - do a PCI passthrough of the device (maybe setting the MAC
> address) and let the guest do the port associate etc. too? (Another
> way
> of saying this - at this point, shouldn't we just admit that
> transparent
> hostside support of VEPA (or any other protocol that requires data
> packets to be modified) using PCI passthrough by definition is not
> possible, and therefore isn't supported?) 

Letting the guest do the association is an option, which should work
already (even if noone probably tested it yet), but the question is
really how much control should the host have vs the guest. There are
definitely scenarios thinkable where the host should do the association.


Best regards, 

Gerhard Stenzel, Hybrid Technologies, LTC
-----------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung:
Dirk Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294