From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO2LS-00056l-3g for qemu-devel@nongnu.org; Tue, 16 Oct 2012 04:17:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TO2LH-0005od-MP for qemu-devel@nongnu.org; Tue, 16 Oct 2012 04:17:45 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:38142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO2LH-0005oD-CR for qemu-devel@nongnu.org; Tue, 16 Oct 2012 04:17:35 -0400 Received: by mail-bk0-f45.google.com with SMTP id jf3so2406736bkc.4 for ; Tue, 16 Oct 2012 01:17:34 -0700 (PDT) Date: Tue, 16 Oct 2012 10:17:31 +0200 From: Stefan Hajnoczi Message-ID: <20121016081731.GC23066@stefanha-thinkpad.redhat.com> References: <5079D352.5000701@redhat.com> <20121015083007.GC24883@stefanha-thinkpad.redhat.com> <20121015092558.GB3462@redhat.com> <507C2892.9050909@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507C2892.9050909@redhat.com> 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: Laine Stump Cc: Libvirt , qemu list On Mon, Oct 15, 2012 at 11:15:30AM -0400, Laine Stump wrote: > 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 commands are historic (at least to me) and we have to make the best of them. > >> 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. Yep, I just checked too. macvlan_dev->lowerdev is only set in macvlan_common_newlink(). There is no way to change it once the link has been created. Stefan