Re: [libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs
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