The current 'setvcpus' timeout message requires a deeper understanding of QEMU/Libvirt internals to proper react to it. One who knows how setvcpus unplug work (it is an asynchronous operation between QEMU and guest that Libvirt can't know for sure if it failed, unless an explicit error happened during the timeout period) will read the message and not assume a failed operation. But the regular user, most often than not, will read it and believe that the unplug operation failed. This leads to situations where the user isn't exactly relieved when accessing the guest and seeing that the unplug operation worked. Instead, the user feel mislead by the timeout message setvcpus threw. Changing the timeout message to let the user know that the unplug status is not known, and manual inspection in the guest is required, is not a silver bullet. But it gives a more realistic expectation of what happened, as best as we can tell from Libvirt side anyways. Signed-off-by: Daniel Henrique Barboza <danielhb413@xxxxxxxxx> --- src/qemu/qemu_hotplug.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index d3a3e25f08..53051807d7 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -6105,8 +6105,9 @@ qemuDomainHotplugDelVcpu(virQEMUDriverPtr driver, if ((rc = qemuDomainWaitForDeviceRemoval(driver, vm)) <= 0) { if (rc == 0) - virReportError(VIR_ERR_OPERATION_FAILED, "%s", - _("vcpu unplug request timed out")); + virReportError(VIR_ERR_OPERATION_TIMEOUT, "%s", + _("vcpu unplug request timed out. Unplug result " + "must be manually inspected in the domain")); goto cleanup; } -- 2.21.0 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list