[libvirt] SR-IOV VLANs

Dax Kelson dkelson at gurulabs.com
Thu Apr 26 17:54:15 UTC 2012


How should libvirt deal with different SR-IOV VLAN scenarios?

Hardware with full SR-IOV and ACS support is increasingly available
and in production. I just took delivery of such a server this week. It
would be nice if the software can fully take advantage of the
hardware.

== Scenario A - Transparent VLAN ==

In the first scenario a /single/ VLAN can be tied to a a VF and the
tagging and stripping of the VLAN tag happens outside of the view of
the VM. Since the VLAN management happens outside the VM there isn't
any security concerns from a malicious VM.

Today this can configured with the ip command: ip link set <pf> vf
<vfN> vlan <vlanID>

But, unless I'm reading it wrong, libvirtd will blow away any
pre-configured transparent VLAN in qemuDomainHostdevNetConfigReplace

== Scenario B - VM VLAN tagging ==

In the second scenario, tagged frames are delivered to the VM and the
VM uses them like normal.

There are security considerations here. You don't want a malicious VM
to access arbitrary VLANs.

There should be a way to have a whitelist of allowed VLAN tags that
can be enforced per VF at lower layer than the VM. Unfortunately it
doesn't seem like hardware today supports this granularity. The Intel
x540 datasheet indicates that a VLAN filter can be programmed with up
to 8 VLANs, but I'm not sure if that is per VF or a global limit.

With Emulex hardware, running: "ip link set <pf> vf <vfN> vlan 4095"
allows the VM with the given VF to configure any VLAN.

Likewise, the Intel ixgbe driver has ixgbe_set_vlan_anti_spoofing (and
ixgbe_set_mac_anti_spoofing) on a per VF basis. It isn't clear to me
if IFLA_VF_SPOOFCHK toggles both or just the mac anti spoofing.




More information about the libvir-list mailing list