Re: tap device name for emulated NIC too long

[Wei Liu <wei.liu2@citrix.com>]

Sorry, this fell through the crack.

On Wed, Nov 30, 2016 at 06:38:45PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> During the last Wg-openstack meetup we briefly discussed a long-standing bug
> when using Xen+libvirt+OpenStack with Neutron networking
> 
> https://bugs.launchpad.net/nova/+bug/1450465
> 
> The bug was also discussed on this list with no resolution
> 
> https://lists.xenproject.org/archives/html/xen-devel/2015-06/msg04116.html
> 
> To summarize: the tap device name for an emulated NIC is too long after
> libxl appends '-emu' to the name provided by Neutron. Some proposed fixes
> include
> 
> 1. Shorten '-emu' to just '-e', avoiding IFNAMSIZ limit. But users are free
> to provide a name that already occupies the full IFNAMSIZ. Also, the
> user-provided name may be used in rules, filters, etc. elsewhere in the
> network, so modifying it at all seems questionable.
> 

This is just a workaround, not a solution. As you said, there is no way
to prevent users from setting a long name.

> 2. Change OpenStack to not exceed IFNAMSIZ-4 when specifying Xen vif name.
> This could be proposed to the Neutron devs, but IMO adding such Xen-specific
> hacks in OpenStack is undesirable.
> 

Is there a knob to tune the name length in Neutron? Then we can set such
knob in Xen driver (not sure if it is the right term in Neutron)?

I think such knob would not be Xen specific. I would go further to say
tying Neutron to Linux specific thing is a bug. What if Linux changes
IFNAMSIZ some day?  What if other OSes need to be supported?

Long term I think having such knob in Neutron and let specific driver
tune it would be the best option for Neutron. And the angle is no more
Xen specific, so it might be easier to sell to Neutron devs?

> 3. Change the Xen default vif type from 'ioemu' to 'vif' (see
> docs/misc/xl-network-configuration.markdown), which avoids creating an
> emulated device. (Note: such a change could be made in Xen or libvirt.) But
> I think this is a no-go. I'd suspect it would result in a lot of broken
> configurations. E.g. a guest may not have PV drivers and is relying on the
> emulated device. Or the guest may be configured to network boot, in which
> case the emulated device would be needed for PXE [0].
> 

Correct, this is a no-go option.

Wei.

> We (the Wg-openstack folks) would like to hear your opinions on these
> proposals, or alternatives for fixing this bug.
> 
> Regards,
> Jim
> 
> [0] iPXE claims support for Xen netfront devices, but I've not yet got it to
> work: http://lists.ipxe.org/pipermail/ipxe-devel/2014-July/003674.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel