3:47 p.m.
I am attempting to enhance libvirt's virDomainUpdateDeviceFlags() API to
support changing "just about anything" about the host side of a PCI
network device without actually detaching the PCI device from the guest.
Here is a patch I sent to the libvirt mailing list that I had thought
would accomplish this task:
https://www.redhat.com/archives/libvir-list/2012-October/msg00546.html
I am using qemu-kvm-1.2-0.1.20120806git3e430569.fc17.x86_64 on Fedora 17
for my testing.
Since the host side and guest side are created (and deleted) with
separate monitor commands ("netdev_(add|del)" vs. "device_(add|del)",
we
had thought that it would be possible to use netdev_del to disconnect
everything from the host side, [*not disconnect the guest side*], then
create a new tap device and connect it with netdev_add(). And, actually,
the netdev_del+netdev_add sequence does complete without error;
unfortunately, no traffic is visible on the tap device (looking from the
host with tcpdump).
When I modify the patch above to also include the device_del and
device_add monitor calls (with a 3 second delay in between to allow for
the guest's PCI detach to complete), then the device does work properly.
Of course in this case (1) the guest sees the device completely
disappear for a period, then reappear, which is more disruption than I
want, and (2) because qemu has no asynchronous event to notify libvirt
when the guest's PCI detach has actually completed, I have to stick in
an arbitrary call to sleep() which is generally *way* too long, but may
be too short in some cases of extremely high load.
The only comment I got from IRC on Friday afternoon (I know - not a good
time to be looking for people) was that they would be "surprised if it
did work". So, I have the following questions:
1) Should this work?
If it's supposed to work now:
2) can you give hints (aside from watching the qemu monitor commands and
responses with stap) on what I might need to change, or how to further
debug my problem within qemu? (I'm pretty well convinced that the
libvirt code is doing the tap device creation/etc correctly).
3) alternately can you verify that this is a known bug? Is fixing it on
anyone's todo list?
If it's not supposed to work now:
4) Does it sound like a reasonable thing for qemu to support?
5) Is there some other formal way to request addition of this
functionality (aside from figuring it out myself and posting a patch)?
********************************************
For reference, here is the sequence of qemu monitor commands sent by
libvirt to fully detach, then fully reattach a network device. Note that
fd is a newly opened TAP device. Also note the 3 second interval between
the netdev_del and the next command:
96.671 > 0x7f8e20000c90
{"execute":"device_del","arguments":{"id":"net0"},"id":"libvirt-25"}
96.673 < 0x7f8e20000c90 {"return": {}, "id":
"libvirt-25"}
96.674 > 0x7f8e20000c90
{"execute":"netdev_del","arguments":{"id":"hostnet0"},"id":"libvirt-26"}
96.695 < 0x7f8e20000c90 {"return": {}, "id":
"libvirt-26"}
99.777 > 0x7f8e20000c90
{"execute":"getfd","arguments":{"fdname":"fd-net0"},"id":"libvirt-27"}
(fd=27)
99.777 < 0x7f8e20000c90 {"return": {}, "id":
"libvirt-27"}
99.778 > 0x7f8e20000c90
{"execute":"netdev_add","arguments":{"type":"tap","fd":"fd-net0","id":"hostnet0"},"id":"libvirt-28"}
99.778 < 0x7f8e20000c90 {"return": {}, "id":
"libvirt-28"}
99.779 > 0x7f8e20000c90
{"execute":"device_add","arguments":{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:bd:b9","bus":"pci.0","addr":"0x4"},"id":"libvirt-29"}
99.780 < 0x7f8e20000c90 {"return": {}, "id":
"libvirt-29"}
After this sequence is done, the guest network device is fully functioning.
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.
Oh - the extra "set_link" command at the end is because I noticed that
the flags shown in ifconfig in the guest switched from:
UP BROADCAST RUNNING MULTICAST
to
UP BROADCAST MULTICAST
when reconnecting in this way, so I was hoping that forcing the
interface up would solve my problems. It didn't :-/ (Another note: I
also tried adding a delay after the netdev_del, and that also did nothing.)