[libvirt] [PATCH]execute netdev_del after receive DEVICE_DELETED event
Hi, When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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". Regards, -xie Signed-off-by: xiexiangyou <xiexiangyou@huawei.com> --- src/qemu/qemu_hotplug.c | 154 +++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 137 insertions(+), 17 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index bf4f160..81f6a56 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -2699,6 +2699,124 @@ qemuDomainRemoveChrDevice(virQEMUDriverPtr driver, virDomainChrDefFree(chr); } +typedef struct privVmDevDriver { + virQEMUDriverPtr driver; + virDomainObjPtr vm; + virDomainDeviceDefPtr dev; +}privVmDevDriver, *privVmDevDriverPtr; + +static void +qemuProcessRemoveNetDevice(void *opaque) +{ + privVmDevDriverPtr privData = opaque; + virQEMUDriverPtr driver = privData->driver; + virDomainObjPtr vm = privData->vm; + virDomainDeviceDefPtr dev = privData->dev; + + qemuDomainObjPrivatePtr priv = vm->privateData; + char mac[VIR_MAC_STRING_BUFLEN]; + int detachidx; + virDomainNetDefPtr detach = NULL; + char *hostnet_name = NULL; + int vlan; + + virObjectLock(vm); + + if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0) + goto cleanup; + + detachidx = virDomainNetFindIdx(vm->def, dev->data.net); + if (detachidx == -2) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("multiple devices matching mac address %s found"), + virMacAddrFormat(&dev->data.net->mac, mac)); + goto endjob; + } + else if (detachidx < 0) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("network device %s not found"), + virMacAddrFormat(&dev->data.net->mac, mac)); + goto endjob; + } + detach = vm->def->nets[detachidx]; + if (virAsprintf(&hostnet_name, "host%s", detach->info.alias) < 0) { + virReportOOMError(); + goto endjob; + } + if ((vlan = qemuDomainNetVLAN(detach)) < 0) { + virReportError(VIR_ERR_OPERATION_FAILED, + "%s", _("unable to determine original VLAN")); + goto endjob; + } + + qemuDomainObjEnterMonitor(driver, vm); + if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_NETDEV) && + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) { + if (qemuMonitorRemoveNetdev(priv->mon, hostnet_name) < 0) { + qemuDomainObjExitMonitor(driver, vm); + virDomainAuditNet(vm, detach, NULL, "detach", false); + goto endjob; + } + } else { + if (qemuMonitorRemoveHostNetwork(priv->mon, vlan, hostnet_name) < 0) { + qemuDomainObjExitMonitor(driver, vm); + virDomainAuditNet(vm, detach, NULL, "detach", false); + goto endjob; + } + } + qemuDomainObjExitMonitor(driver, vm); + + qemuDomainRemoveNetDevice(driver, vm, dev->data.net); + +endjob: + if (!qemuDomainObjEndJob(driver, vm)) + vm = NULL; + +cleanup: + VIR_FREE(hostnet_name); + VIR_FREE(privData->dev); + VIR_FREE(privData); + + if (vm && virObjectUnref(vm)) + virObjectUnlock(vm); +} + +static void +qemuRemoveNetDeviceJob(virQEMUDriverPtr driver, + virDomainObjPtr vm, + virDomainDeviceDefPtr dev) +{ + virThread th; + privVmDevDriverPtr data = NULL; + virDomainDeviceDefPtr device = NULL; + + if (VIR_ALLOC(data) < 0) { + VIR_ERROR(_("Failed to alloc VmDevDriver")); + return; + } + + if (VIR_ALLOC(device) < 0) { + VIR_ERROR(_("Failed to alloc virDomainDeviceDefPtr")); + VIR_FREE(data); + return; + } + memcpy(device, dev, sizeof(*device)); + + data->dev = device; + data->driver = driver; + data->vm = vm; + virObjectRef(vm); + if (virThreadCreate(&th, + false, + qemuProcessRemoveNetDevice, + data) < 0) { + VIR_ERROR(_("Failed to create remove net device thread")); + VIR_FREE(device); + VIR_FREE(data); + virObjectUnref(vm); + } + +} void qemuDomainRemoveDevice(virQEMUDriverPtr driver, @@ -2713,7 +2831,7 @@ qemuDomainRemoveDevice(virQEMUDriverPtr driver, qemuDomainRemoveControllerDevice(driver, vm, dev->data.controller); break; case VIR_DOMAIN_DEVICE_NET: - qemuDomainRemoveNetDevice(driver, vm, dev->data.net); + qemuRemoveNetDeviceJob(driver, vm, dev); break; case VIR_DOMAIN_DEVICE_HOSTDEV: qemuDomainRemoveHostDevice(driver, vm, dev->data.hostdev); @@ -3419,26 +3537,28 @@ qemuDomainDetachNetDevice(virQEMUDriverPtr driver, goto cleanup; } } + qemuDomainObjExitMonitor(driver, vm); - if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_NETDEV) && - virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) { - if (qemuMonitorRemoveNetdev(priv->mon, hostnet_name) < 0) { - qemuDomainObjExitMonitor(driver, vm); - virDomainAuditNet(vm, detach, NULL, "detach", false); - goto cleanup; - } - } else { - if (qemuMonitorRemoveHostNetwork(priv->mon, vlan, hostnet_name) < 0) { - qemuDomainObjExitMonitor(driver, vm); - virDomainAuditNet(vm, detach, NULL, "detach", false); - goto cleanup; + if (!qemuDomainWaitForDeviceRemoval(vm)) { + qemuDomainObjEnterMonitor(driver, vm); + if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_NETDEV) && + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) { + if (qemuMonitorRemoveNetdev(priv->mon, hostnet_name) < 0) { + qemuDomainObjExitMonitor(driver, vm); + virDomainAuditNet(vm, detach, NULL, "detach", false); + goto cleanup; + } + } else { + if (qemuMonitorRemoveHostNetwork(priv->mon, vlan, hostnet_name) < 0) { + qemuDomainObjExitMonitor(driver, vm); + virDomainAuditNet(vm, detach, NULL, "detach", false); + goto cleanup; + } } - } - qemuDomainObjExitMonitor(driver, vm); + qemuDomainObjExitMonitor(driver, vm); - if (!qemuDomainWaitForDeviceRemoval(vm)) qemuDomainRemoveNetDevice(driver, vm, detach); - + } ret = 0; cleanup: -- 1.6.0.2
On Thu, Mar 27, 2014 at 20:51:24 +0800, x00221466 wrote:
Hi,
When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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.
This sounds like it could be correct, although I'd prefer Laine to express his opinion on this since he knows the corners in network device assignment...
I create a thread in qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU command "netdev_del".
Hmm, it took me some time to realize why you'd need to do this. It's because qemuDomainRemoveDevice is run from a DEVICE_DELETED event handler and thus it cannot talk back to the monitor, right? In that case, I suggest spawning a thread for qemuDomainRemoveDevice itself within the event handler (qemuProcessHandleDeviceDeleted) so that all qemuDomainRemove* methods can talk to monitor if they need to. To make the changes easier to follow, please do the change in two patches. The first one to move qemuDomainRemoveDevice into a new thread and the second one to move qemuMonitorRemoveNetdev and qemuMonitorRemoveHostNetwork calls inside qemuDomainRemoveNetDevice. But first, wait for Laine's input, please. Jirka
On Thu, Mar 27, 2014 at 03:14:06PM +0100, Jiri Denemark wrote:
On Thu, Mar 27, 2014 at 20:51:24 +0800, x00221466 wrote:
Hi,
When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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.
This sounds like it could be correct, although I'd prefer Laine to express his opinion on this since he knows the corners in network device assignment...
I create a thread in qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU command "netdev_del".
Hmm, it took me some time to realize why you'd need to do this. It's because qemuDomainRemoveDevice is run from a DEVICE_DELETED event handler and thus it cannot talk back to the monitor, right? In that case, I suggest spawning a thread for qemuDomainRemoveDevice itself within the event handler (qemuProcessHandleDeviceDeleted) so that all qemuDomainRemove* methods can talk to monitor if they need to.
To make the changes easier to follow, please do the change in two patches. The first one to move qemuDomainRemoveDevice into a new thread and the second one to move qemuMonitorRemoveNetdev and qemuMonitorRemoveHostNetwork calls inside qemuDomainRemoveNetDevice.
One complication is that DEVICE_DELETED only exists in very recent QEMU versions, and we need to be careful not to introduce a reliance on that existing, becuase it would cause a regression for libvirt against older QEMU. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Mar 27, 2014 at 14:18:46 +0000, Daniel Berrange wrote:
On Thu, Mar 27, 2014 at 03:14:06PM +0100, Jiri Denemark wrote:
On Thu, Mar 27, 2014 at 20:51:24 +0800, x00221466 wrote:
Hi,
When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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.
This sounds like it could be correct, although I'd prefer Laine to express his opinion on this since he knows the corners in network device assignment...
I create a thread in qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU command "netdev_del".
Hmm, it took me some time to realize why you'd need to do this. It's because qemuDomainRemoveDevice is run from a DEVICE_DELETED event handler and thus it cannot talk back to the monitor, right? In that case, I suggest spawning a thread for qemuDomainRemoveDevice itself within the event handler (qemuProcessHandleDeviceDeleted) so that all qemuDomainRemove* methods can talk to monitor if they need to.
To make the changes easier to follow, please do the change in two patches. The first one to move qemuDomainRemoveDevice into a new thread and the second one to move qemuMonitorRemoveNetdev and qemuMonitorRemoveHostNetwork calls inside qemuDomainRemoveNetDevice.
One complication is that DEVICE_DELETED only exists in very recent QEMU versions, and we need to be careful not to introduce a reliance on that existing, becuase it would cause a regression for libvirt against older QEMU.
Sure, that's already taken care of. The device removal code checks if DEVICE_DELETED is supported and if it's not, it directly calls the appropriate qemuDomainRemove* method that would otherwise be called from the event handler. Jirka
Thanks for your reply. On 2014/3/27 22:14, Jiri Denemark wrote:
On Thu, Mar 27, 2014 at 20:51:24 +0800, x00221466 wrote:
Hi,
When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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.
This sounds like it could be correct, although I'd prefer Laine to express his opinion on this since he knows the corners in network device assignment...
I create a thread in qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU command "netdev_del".
Hmm, it took me some time to realize why you'd need to do this. It's because qemuDomainRemoveDevice is run from a DEVICE_DELETED event handler and thus it cannot talk back to the monitor, right? In that
Yep! Sending the Qemu monitor command in event handler is no allowed, so I create a new thread to do this.
case, I suggest spawning a thread for qemuDomainRemoveDevice itself within the event handler (qemuProcessHandleDeviceDeleted) so that all qemuDomainRemove* methods can talk to monitor if they need to.
I will modify it as your suggest
To make the changes easier to follow, please do the change in two patches. The first one to move qemuDomainRemoveDevice into a new thread and the second one to move qemuMonitorRemoveNetdev and qemuMonitorRemoveHostNetwork calls inside qemuDomainRemoveNetDevice.
But first, wait for Laine's input, please.
Regards, -xie
On 03/28/2014 01:30 PM, xiexiangyou wrote:
Thanks for your reply.
On 2014/3/27 22:14, Jiri Denemark wrote:
On Thu, Mar 27, 2014 at 20:51:24 +0800, x00221466 wrote:
Hi,
When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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. This sounds like it could be correct, although I'd prefer Laine to express his opinion on this since he knows the corners in network device assignment...
I create a thread in qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU command "netdev_del". Hmm, it took me some time to realize why you'd need to do this. It's because qemuDomainRemoveDevice is run from a DEVICE_DELETED event handler and thus it cannot talk back to the monitor, right? In that
Yep! Sending the Qemu monitor command in event handler is no allowed, so I create a new thread to do this.
case, I suggest spawning a thread for qemuDomainRemoveDevice itself within the event handler (qemuProcessHandleDeviceDeleted) so that all qemuDomainRemove* methods can talk to monitor if they need to.
I will modify it as your suggest
To make the changes easier to follow, please do the change in two patches. The first one to move qemuDomainRemoveDevice into a new thread and the second one to move qemuMonitorRemoveNetdev and qemuMonitorRemoveHostNetwork calls inside qemuDomainRemoveNetDevice.
But first, wait for Laine's input, please.
Well, the level of my knowledge was that I noticed the problem caused by the asynchronous nature of device_del (exactly the error message that you're reporting) and reported this to QEMU, asking for an event to let us know when it is okay to reuse a device ID (i.e. the DEVICE_DELETED event). It appears that this isn't always good enough, though, so *something* apparently needs to be done. My understanding is that the problem is caused by the netdev_del being executed too soon after device_del, and then the device ID is forever lost due to the unclean "cleanup", is that correct? If so, then your solution sounds correct. But does netdev_del complete synchronously? If not, then we will also need a completion event for that as well.
Hi Laine, On 2014/3/28 23:21, Laine Stump wrote:
On 03/28/2014 01:30 PM, xiexiangyou wrote:
Thanks for your reply.
On 2014/3/27 22:14, Jiri Denemark wrote:
On Thu, Mar 27, 2014 at 20:51:24 +0800, x00221466 wrote:
Hi,
When live detaching the virtual net device, such as virtio nic、 RTL8139、E1000, 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. This sounds like it could be correct, although I'd prefer Laine to express his opinion on this since he knows the corners in network device assignment...
I create a thread in qemuDomainRemoveDevice,the handle of DEVICE_DELETED event, to execute QEMU command "netdev_del". Hmm, it took me some time to realize why you'd need to do this. It's because qemuDomainRemoveDevice is run from a DEVICE_DELETED event handler and thus it cannot talk back to the monitor, right? In that
Yep! Sending the Qemu monitor command in event handler is no allowed, so I create a new thread to do this.
case, I suggest spawning a thread for qemuDomainRemoveDevice itself within the event handler (qemuProcessHandleDeviceDeleted) so that all qemuDomainRemove* methods can talk to monitor if they need to.
I will modify it as your suggest
To make the changes easier to follow, please do the change in two patches. The first one to move qemuDomainRemoveDevice into a new thread and the second one to move qemuMonitorRemoveNetdev and qemuMonitorRemoveHostNetwork calls inside qemuDomainRemoveNetDevice.
But first, wait for Laine's input, please.
Well, the level of my knowledge was that I noticed the problem caused by the asynchronous nature of device_del (exactly the error message that you're reporting) and reported this to QEMU, asking for an event to let us know when it is okay to reuse a device ID (i.e. the DEVICE_DELETED event). It appears that this isn't always good enough, though, so *something* apparently needs to be done.
My understanding is that the problem is caused by the netdev_del being executed too soon after device_del, and then the device ID is forever lost due to the unclean "cleanup", is that correct? If so, then your solution sounds correct.
Yes :)
But does netdev_del complete synchronously? If not, then we will also need a completion event for that as well.
I think so, if do the job of executing Qemu command "netdev_del" after the "device_del" work is really finished, then call qemuDomainRemoveNetDevice to do cleanup. The solution is complete synchronously. It can guarantee the consistency of net device info between Libvirt side and Qemu side. Regards, -xie
participants (5)
-
Daniel P. Berrange -
Jiri Denemark -
Laine Stump -
x00221466 -
xiexiangyou