tap device name for emulated NIC too long

tap device name for emulated NIC too long

[Jim Fehlig]

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.

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.

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].

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

Re: tap device name for emulated NIC too long

[Konrad Rzeszutek Wilk]

On Wed, Nov 30, 2016 at 06:38:45PM -0700, Jim Fehlig wrote:
> Hi All,

.. crickets..
> 
> 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.

+1
> 
> 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.
> 
> 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].
> 
> 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

Re: tap device name for emulated NIC too long

[Wei Liu]

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