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