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 32100b140e..72015e02e2 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -6007,8 +6007,9 @@ qemuDomainHotplugDelVcpu(virQEMUDriverPtr driver,
if ((rc = qemuDomainWaitForDeviceRemoval(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
