From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFdrV-0000sK-Ug for qemu-devel@nongnu.org; Fri, 08 Aug 2014 02:41:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFdrP-0003fN-Rs for qemu-devel@nongnu.org; Fri, 08 Aug 2014 02:41:13 -0400 Received: from indium.canonical.com ([91.189.90.7]:45139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFdrP-0003ej-MV for qemu-devel@nongnu.org; Fri, 08 Aug 2014 02:41:07 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.76 #1 (Debian)) id 1XFdrP-0002Ge-4b for ; Fri, 08 Aug 2014 06:41:07 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 15C822E80BB for ; Fri, 8 Aug 2014 06:41:07 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 08 Aug 2014 06:31:28 -0000 From: swestlake <1352555@bugs.launchpad.net> Sender: bounces@canonical.com References: <20140804210526.23780.8062.malonedeb@wampee.canonical.com> <20140805094442.7691.64872.malone@chaenomeles.canonical.com> Message-Id: <53E46EC0.7030702@videotron.ca> Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 1352555] Re: iproute2 incompatibility Reply-To: Bug 1352555 <1352555@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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:. 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=3Dvirtio 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=3Dvirtio 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