vif-bridge: ip link set failed, "name" too long

vif-bridge: ip link set failed, "name" too long

[Anthony PERARD]

Hi,

When one tries to start an HVM guest via OpenStack, which is setup with
Neutron for network, the guest creation always fail.

Here are a few relevent logs:

/var/log/libvirt/libxl/libxl-driver.log:
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge add [-1] exited with error status 1
libxl: error: libxl_device.c:1085:device_hotplug_child_death_cb: script: ip link set vif188.0-emu name tap695cf459-b0-emu failed
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0x7f5a9c05ddd0: deregister unregistered
libxl: error: libxl_create.c:1226:domcreate_attach_vtpms: unable to add nic devices

/var/log/xen/xen-hotplug.log:
Error: argument "tap695cf459-b0-emu" is wrong: "name" too long

The libvirt config, from Nova:
<interface type='bridge'>
  <mac address='fa:16:3e:b0:cd:2a'/>
  <source bridge='qbr695cf459-b0'/>
  <target dev='tap695cf459-b0'/>
</interface>

Thanks,

-- 
Anthony PERARD

Re: vif-bridge: ip link set failed, "name" too long

[Ian Campbell]

On Thu, 2015-06-25 at 12:36 +0100, Anthony PERARD wrote:
> Error: argument "tap695cf459-b0-emu" is wrong: "name" too long

Under Linux IFNAMSIZ is 16, whereas this is 18 characters.

Since our suffix is "-emu" we are adding 4 to the original 14, so we
could/should pick a 2 character suffix to distinguish PV from emulated
interfaces. "-e" perhaps?

It looks like the suffix is in both 
tools/hotplug/Linux/vif-common.sh and
tools/libxl/libxl_internal.h:TAP_DEVICE_SUFFIX. We could perhaps arrange
somehow that only the hotplug scripts needed to know this, allowing this
to be a more localised decision but it would no doubt involve a bunch of
faff. I'm inclined to suggest we just change the suffix globally.

Ian.

Re: vif-bridge: ip link set failed, "name" too long

[Jim Fehlig]

On 06/25/2015 05:53 AM, Ian Campbell wrote:
> On Thu, 2015-06-25 at 12:36 +0100, Anthony PERARD wrote:
>> Error: argument "tap695cf459-b0-emu" is wrong: "name" too long
> Under Linux IFNAMSIZ is 16, whereas this is 18 characters.
>
> Since our suffix is "-emu" we are adding 4 to the original 14, so we
> could/should pick a 2 character suffix to distinguish PV from emulated
> interfaces. "-e" perhaps?

I'm not familiar with Neutron, but might this break some rules or filters it 
creates based on the name? Appending stuff to a user-provided name doesn't seem 
right.

One way to avoid the emulated interface is to set libxl_device_nic->nictype = 
LIBXL_NIC_TYPE_VIF, so only the pv interface is created. In xl.cfg, I suppose 
that would be

   vif = [ '...,model=netfront' ]

In libvirt domXML

   <interface>
     ...
     <model type='netfront'/>
   </interface>

I realize that doesn't help much if the guest has no pv network driver. I wonder 
how this is handled in KVM? In the libvirt qemu driver, the default interface 
model is rtl8139 if <model type=''/> is not specified.  Does nova add <model 
type='virtio'/> to interfaces for KVM instances? Is it expected that the guest 
OS has a virtio network driver?

Regards,
Jim

Re: vif-bridge: ip link set failed, "name" too long

[Ian Campbell]

On Fri, 2015-06-26 at 00:28 -0600, Jim Fehlig wrote:
> On 06/25/2015 05:53 AM, Ian Campbell wrote:
> > On Thu, 2015-06-25 at 12:36 +0100, Anthony PERARD wrote:
> >> Error: argument "tap695cf459-b0-emu" is wrong: "name" too long
> > Under Linux IFNAMSIZ is 16, whereas this is 18 characters.
> >
> > Since our suffix is "-emu" we are adding 4 to the original 14, so we
> > could/should pick a 2 character suffix to distinguish PV from emulated
> > interfaces. "-e" perhaps?
> 
> I'm not familiar with Neutron, but might this break some rules or filters it 
> creates based on the name? Appending stuff to a user-provided name doesn't seem 
> right.

The issue is that we have two devices (the PV vif and the emulated one)
and they cannot have the same name, so we have to do something to one of
them. It could well be the case that this means we need to change
Neutron too.

[...]
> I realize that doesn't help much if the guest has no pv network driver. I wonder 
> how this is handled in KVM? In the libvirt qemu driver, the default interface 
> model is rtl8139 if <model type=''/> is not specified.  Does nova add <model 
> type='virtio'/> to interfaces for KVM instances? Is it expected that the guest 
> OS has a virtio network driver?

I don't know, but my suspicion is that QEMU/KVM is able to route both
virtio and emulated device traffic over the same tap interface, since
both originate in the same process. We sadly don't have that liberty.

If openstack is already assuming virtio only then that would of course
be wonderful for us and we should do the same...

Ian.