From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNmON-0001F4-MU for qemu-devel@nongnu.org; Mon, 15 Oct 2012 11:15:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TNmOH-0004ky-VP for qemu-devel@nongnu.org; Mon, 15 Oct 2012 11:15:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNmOH-0004kD-Mt for qemu-devel@nongnu.org; Mon, 15 Oct 2012 11:15:37 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9FFFaVI006570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Oct 2012 11:15:37 -0400 Message-ID: <507C2892.9050909@redhat.com> Date: Mon, 15 Oct 2012 11:15:30 -0400 From: Laine Stump MIME-Version: 1.0 References: <5079D352.5000701@redhat.com> <20121015083007.GC24883@stefanha-thinkpad.redhat.com> <20121015092558.GB3462@redhat.com> In-Reply-To: <20121015092558.GB3462@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Problems using netdev_del+netdev_add w/o corresponding device_del+device_add List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Libvirt Cc: qemu list On 10/15/2012 05:25 AM, Daniel P. Berrange wrote: > On Mon, Oct 15, 2012 at 10:30:07AM +0200, Stefan Hajnoczi wrote: >> On Sat, Oct 13, 2012 at 04:47:14PM -0400, Laine Stump wrote: >>> Here is the sequence sent to disconnect only the host side, then >>> reconnect it with a new tap device. (although the fd is the same, this >>> is because the old tap device had already been closed, so the number is >>> just being used - the same thing happens when doing sequential full >>> detach/attach cycles, and they all work with no problems): >>> >>> >>> 168.750 > 0x7f8e20000c90 >>> {"execute":"netdev_del","arguments":{"id":"hostnet0"},"id":"libvirt-30"} >>> 168.762 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-30"} >>> 168.800 > 0x7f8e20000c90 >>> {"execute":"getfd","arguments":{"fdname":"fd-net0"},"id":"libvirt-31"} >>> (fd=27) >>> 168.801 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-31"} >>> 168.801 > 0x7f8e20000c90 >>> {"execute":"netdev_add","arguments":{"type":"tap","fd":"fd-net0","id":"hostnet0"},"id":"libvirt-32"} >>> 168.802 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-32"} >>> 168.802 > 0x7f8e20000c90 >>> {"execute":"set_link","arguments":{"name":"net0","up":true},"id":"libvirt-33"} >>> 168.803 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-33"} >>> >>> After this sequence is done, everything about the network device >>> *appears* normal on both the guest and host (at least the things I know >>> to look at), but no traffic from the host shows up in a tcpdump of the >>> interface on the guest, and no traffic from the guest shows up in a >>> tcpdump of the tap device on the host. >> What you are trying to do isn't possible today. Well, at least it's good to know that I should stop trying to make it work :-) Actually, it's a bit disconcerting that 1) the act of creating a guest device is split into two commands, implying that they don't necessarily have a hardwired a-->b relationship although that is the case, and that 2) netdev_add even returns success when you use it in this way. Although hindsight is 20/20 and all that, if both a and b are required, and must always be in the same order, wouldn't it have made more sense for the two steps to be a single command? I suppose this is a byproduct of the monitor commands being a direct reflection ot the commandline options. (At the very least, though, I think netdev_add should report an error if the device name alias it uses is already in use by a device.) >> >> The device associates with the netdev during initialization only - there >> is no command to associate at a later point in time. That is why your >> example works only when the device is deleted together with the netdev. >> >> It is certainly possible to implement a command to switch netdevs At this point yes, it would be better to have a new command rather than to make netdev_add work in the way I've attempted - this way there would be a new command whose presence libvirt could use to decide whether or not to support this functionality. >> but >> I'm curious what the use case is. Is this necessary just because QEMU >> doesn't provide a way to modify the existing netdev or because you >> really want to switch to a completely different netdev? > We have end users who want to be able to dynamically change the guest' > networking attachment, without restarting/hotplugging devices in the > guest[1]. If it is just a case of changing from one bridge, to another > bridge we can do that just by moving the TAP Device from one to another. > This doesn't work if we want to support more general changes in config. > eg from a macvtap setup to a TAP setup, or vica-verca. Beyond that, I haven't determined it conclusively yet, but it so far looks to me like a macvtap device can only be linked to a physdev when it is created - there is no netlink message to re-link it to a different physdev (this is based on my naive examination of the relevant kernel source). So if you want to change the attach point for a macvtap-type connection, you again need to discard the old macvtap device and create a new one, implying that you need to do a new netdev_add.