[Qemu-devel] [Bug 1352555] [NEW] iproute2 incompatibility

[Qemu-devel] [Bug 1352555] [NEW] iproute2 incompatibility

[swestlake]

Public bug reported:

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

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1352555

Title:
  iproute2 incompatibility

Status in QEMU:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1352555/+subscriptions

[Qemu-devel] [Bug 1352555] Re: iproute2 incompatibility

[Michael Tokarev]

** Changed in: qemu
       Status: New => Incomplete

** Changed in: qemu
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1352555

Title:
  iproute2 incompatibility

Status in QEMU:
  Invalid

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1352555/+subscriptions

[Qemu-devel] [Bug 1352555] Re: iproute2 incompatibility

[Michael Tokarev]

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.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1352555

Title:
  iproute2 incompatibility

Status in QEMU:
  Invalid

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1352555/+subscriptions

Re: [Qemu-devel] [Bug 1352555] Re: iproute2 incompatibility

[swestlake]

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 the bridge interface)

where can i ask this for more current-build information about the 
stability of multiple virtio nic interfaces? (I'm not using passthrough 
at all which is something much more advanced)

thanks, sorry for the lack of details..

-Scott

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1352555

Title:
  iproute2 incompatibility

Status in QEMU:
  Invalid

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1352555/+subscriptions