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.