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