Re: [libvirt] [Qemu-devel] Problems using netdev_del+netdev_add w/o corresponding device_del+device_add

On Mon, Oct 15, 2012 at 10:25:58AM +0100, 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. > > > > 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 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. > > Another requirement is to be able to start a guest with a "null" backend > (akin to not plugging in the ethernet cable on a physical host), and > then attach it to a bridge/macvtap device on the fly later on (akin > to then plugging in the ethernet cable once running). virtio-net presents a challenge because checksum offload and other advanced features are announced in the virtio feature bits. Virtio feature bits don't change during the lifetime of the device and there's no way to notify existing guests to re-negotiate them besides taking down the device. The offload feature bits are tied to the netdev in QEMU, especially the tap driver's vnet_hdr feature which allows the guest to pass through offload flags to the host network stack. QEMU does not emulate these today and only enables them when the netdev supports vnet_hdr. In other words, virtio-net is tied to its netdev. Changing from -netdev tap,vhost=on setup to a -netdev user is difficult.

Two possibilities: 1. Add offload emulation code to QEMU. 2. Place sufficient checks in QEMU and libvirt so that only "safe" netdev changes can be made. #1 is unattractive because this code path will rarely be used but is complex (a bunch of buffer munging and memory management).

Are you trying to change netdev without involving the guest? In that case the link must stay up and libvirt needs to ensure that the new netdev will have a compatible network configuration (subnet, gateway, IP address details).