iproute2 incompatibility

[swestlake]

installed iproute2 which replaced ifupdown, kvm no longer connects to tap devices and is unable to create spice sockets

[Michael Tokarev (mjt+launchpad-tls)]

This is a Very Useful BugReport (NOT!).

Qemu does not use neither ifupdown nor iproute. Instead, it runs a script, /etc/qemu-ifup by default, which should use whatever commands needed on the given operating system to do whatever configuration of the tap devices which is necessary. But qemu itself does not provide such a script.

So you can't file such a bug against qemu because qemu just does not HAVE this functionality to start with.

The script is expected to be provided by the user, and it can be as large as a one line which adds a given (as an argument) tap device to a user-specifid bridge. But this script greatly depends on the particular network details, -- eg, some prefer to have multiple bridges for different purposes, some prefer not to have any bridges at all (tap device will work without a bridge just fine), some may use these tap devices to assign them to lxc containers and so on and so forth. That's why you have to provide this script by your own - a script which suits _your_ needs.

Debian and ubuntu provides such scripts which covers "simple" case where all guest tap devices are assigned to a bridge wich has a default route on it, provided such a bridge exists. Both debian and ubuntu scripts will work with either ifconfig/route/bridge or with iproute2 package just fine, will use whatever is avilable/installed on the system. So it should not be debian/ubuntu problem either.

And one more thing: ifupdown, at least in ubuntu/debian, is _not_ being replaced by iproute2. This is just gross (again, at least on debian/ubuntu). Ifupdown package provides network configuration in /etc/network/, and it uses either iproute2 OR net-tools (which is the old ifconfig/route/... network toolset). So it is old ifconfig which is being "replaced" by iproute2, not ifupdown. But since you haven't specified any details at all, it is difficult to say whenever this comment applies to your distribution (as it isn't even know which distribution it is).

Closing this bugreport as invalid.

[swestlake (westlake2012)]

i discovered with iproute2 i have to manually bring the "lo" interface
link up which to me is pretty new.. after which the spice port can
immediately work with 127.0.0.1:<port>.

what I originally meant when installing iproute2 on debian was that it
uninstalls ifupdown as well as iproute.

I don't know the full plans of the debian team if they will ever release
a startup script for iproute2 or if its meant to be the "default"
package that will be replacing iproute&ifupdown.. but the ifconfig
command is still left intact, ifup & ifdown are taken out.

also if you don't mind to tell me whether if I can address something
which I'm really after which lead me to trying iproute2 since I'm having
a real problem with kvm

  --> I'm having issues with "two" model=virtio defined nics that are
bridged to two hypervisor tap interfaces. Having two virtio network
adapters is unstable with the current kvm build I'm using.i suppose I
can provide details on this but I'm trying to demonstrate to you guys
I'm not trolling in anyways and sorry I started out lacking a lot of
details on my first bug report which should of come off much better than
this..

Anyways I've been able to resolve the 'ip link set lo up' and the
solution seemed stupid but I don't suppose many people are even using
iproute2.

there's also an additional advantage with iproute2 which is why I'm
trying it because the "bridge" command utility that comes with it offers
more options per "bridge port" ...and this "bridge" command works with
currently created devices with brctl and complements it(brctl is still
available after iproute2 is installed). With iproute&ifupdown I don't
have access to this new 'bridge' command feature

So far my kvm machine works perfectly well with just 1 bridged tap
device but can't work with "two". I'm using virtio acceleration with a
virtio-capable kernel, by which the kernel image is passed to the
-kernel parameter option to the kvm command. (All tap devices are
pre-created with the root account)

The reason why and what I'm really after is if somebody knows if the
latest kvm build can handle two "virtio" nics that is stable(not using
"passthrough", .. just two virtio-accelerated nic devices that are
associated each separately on the hypervisor). I can't seem to find this
information anywhere. (dmesg indicates to me everything is virtio.. My
VM os is on /dev/vda1... I'm able to use two virtio raw image drives
without issue. ) I've been upgrading the VM's kernel from 3.2 to 3.14
i386 and have it to the kvm command line.

fwiw,
nic 1-> public IP address in the VM, works perfect well through the
hypervisor's bridged tap device.

nic 2-> another model=virtio device. When this second nic device is
added it doesn't matter whether or not this interface in the VM (eth1)
is "up" or "down", as long as a "second" nic interface is passed to the
kvm instance, nic 1 miserably stalls.. though it is capable of very
small network traffic and chokes miserably on the data-link layer (nic 1
exponentially increases in ARP requesting it's gateway mac-address and
barely passes a simple nslookup. I get to scrutinize traffic with
tcpdump against t...