[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] vif-bridge: ip link set failed, "name" too long



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.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.