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
