Emulated network driver is not working when using xen over libvirt

[Tomasz Paszkowski]

When using XEN over libvirt, emulated network drivers (rtl8139,e1000) will not work as the interface name is too long.

By default XEN when running VMs in HVM creates two interfaces on host system:

vifX.X (for PV drivers)
vifX.X-emu (for emulated drives)

-emu suffix combined with 14 characters long tap interface name is too long for a linux system and it results that vifX.X-emu can't be renamed to openstack standard.

Additionally openstack expects tap interface to be without -emu suffix and all security groups settings will not also cover this interface (even if we will shortcut its name).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/37477

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/37547

[Adam Spiers (adam.spiers)]

I got some valuable info on this from our resident Xen / libvirt
expert Jim Fehlig:

For better or worse, Xen defers preferred network device selection to
the guest OS in the case of HVM domains. The Xen toolstack will
create both emulated and PV devices, and let the guest OS decide which
to use. If the guest OS contains an appropriate PV driver, it will
claim the device and tell qemu to unplug the emulated one. If the
guest OS has no appropriate PV driver, the PV device will be ignored
as unkown/unconfigured hardware, but the guest will still have a
network device via the emulated one. This is all fine except when it
comes to device naming. Only one device name can be specified in the
domain configuration, from which two devices are created internally -
hence the *-emu device.

Some would argue this a user-friendly approach accommodating guest
OSes that have no PV driver. Others would argue that this approach
wreaks havoc higher toolstacks that should determine such policy.
Most OSes have PV device drivers these days, but it may not be
possible to change this default behavior since there are many older
HVM configs in the wild with a model-less vif, e.g.

    vif=[ 'mac=aa:bb:cc:dd:ee:ff,bridge=br0', ]

where the guest OS does not have PV drivers. Providing only the PV
device, avoiding the *-emu one, would break networking in such guests.

BTW, sounds as though nova generates a maximum length vif name, which
Xen exceeds by appending '-emu'. Is that correct? Hmm, not to mention
breaking any filtering rules based on the nova generated name...

Jim is open to any suggestions on ways to fix this in the Xen
toolstack without introducing regressions. This issue should
disappear with the move to Xen's new libxl toolstack, where these
types of policy decisions have been removed.

Jim also pointed out that the only good reason *not* to prefer using
the PV network device is if the guest OS has no driver for it.

[Adam Spiers (adam.spiers)]

It seems that the maximum size allowed in Linux is 16:

  #define IFNAMSIZ 16

  -- http://lxr.linux.no/linux+v3.11.6/include/uapi/linux/if.h#L26

so I think the question becomes, why do we need tap interface names which are 14 bytes long in the first place?

[Joe Gordon (jogo)]

Related patch https://review.openstack.org/#/c/37477/4

[Sean Dague (sdague)]

I think this is an upstream xen issue and it's not clear we should be working around it based on the patch commentary