* vif-bridge: ip link set failed, "name" too long
@ 2015-06-25 11:36 Anthony PERARD
2015-06-25 11:53 ` Ian Campbell
0 siblings, 1 reply; 4+ messages in thread
From: Anthony PERARD @ 2015-06-25 11:36 UTC (permalink / raw)
To: Xen Devel; +Cc: Jim Fehlig
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vif-bridge: ip link set failed, "name" too long
2015-06-25 11:36 vif-bridge: ip link set failed, "name" too long Anthony PERARD
@ 2015-06-25 11:53 ` Ian Campbell
2015-06-26 6:28 ` Jim Fehlig
0 siblings, 1 reply; 4+ messages in thread
From: Ian Campbell @ 2015-06-25 11:53 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Jim Fehlig, Xen Devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vif-bridge: ip link set failed, "name" too long
2015-06-25 11:53 ` Ian Campbell
@ 2015-06-26 6:28 ` Jim Fehlig
2015-06-26 7:10 ` Ian Campbell
0 siblings, 1 reply; 4+ messages in thread
From: Jim Fehlig @ 2015-06-26 6:28 UTC (permalink / raw)
To: Ian Campbell, Anthony PERARD; +Cc: Xen Devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vif-bridge: ip link set failed, "name" too long
2015-06-26 6:28 ` Jim Fehlig
@ 2015-06-26 7:10 ` Ian Campbell
0 siblings, 0 replies; 4+ messages in thread
From: Ian Campbell @ 2015-06-26 7:10 UTC (permalink / raw)
To: Jim Fehlig; +Cc: Anthony PERARD, Xen Devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-06-26 7:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-25 11:36 vif-bridge: ip link set failed, "name" too long Anthony PERARD
2015-06-25 11:53 ` Ian Campbell
2015-06-26 6:28 ` Jim Fehlig
2015-06-26 7:10 ` Ian Campbell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.