[libvirt] [libivrt][RFC]Send "netdev_del" command after receive the DEVICE_DELETED event

x00221466 xiexiangyou at huawei.com
Wed Mar 26 05:18:17 UTC 2014


Hi all:

There maybe a bug about detaching virtual net device(such as virtio nic、
RTL8138、E1000)。

When live detaching the net device, there are some problems:
(1)If the Guest OS don't support the hot plugging pci device, detach
the virtual network device by Libvirt, the "net device" in Qemu will
still exist, but "hostnet"(tap) in Qemu will be removed. so the net device
in Guest OS will be of no effect.

(2)If reject the nic in Guest OS, Qemu will remove the "net device",
then Qemu send DEVICE_DELETED to Libvirt, Libvirt receive the event
in event-loop thread and release info of the net device in
qemuDomainRemoveNetDevice func. but "hostnet" in Qemu still exist.
So next live attaching virtual net device will be failed because of
"Duplicate ID".

#virsh attach-device win2008_st_r2_64 net.xml --live
error: Failed to attach device from net.xml
error: internal error: unable to execute QEMU command 'netdev_add':
Duplicate ID 'hostnet0' for netdev

(3)In addition, in qemuDomainDetachNetDevice, detach net device func,
"netdev_del" command will be sent after sending "device_del" command
at once. So it is violent to remove the tap device before the net device
is completely removed.

So I think it's more logical that doing the work of sending Qemu command
"netdev_del" after receive the DEVICE_DELETED event. It can avoid the conflict
of device info between Libvirt side and Qemu side. I create a thread in
qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU
command "netdev_del". But I find there is another problem when sending monitor
msg in multiply threads. in "qemuMonitorSend", monitor lock maybe unlocked
and locked, so another thread has the opportunity to get the monitor lock,
and use the same monitor. It will occur error.

I wonder if it is workable that sending "netdev_del" command after receive the
DEVICE_DELETED event.

Thanks.

-xie




More information about the libvir-list mailing list