On 09/13/2011 10:20 AM, Jiri Denemark wrote:
Ever since we introduced fake reboot, we call qemuProcessKill as a
reaction to SHUTDOWN event. Unfortunately, qemu doesn't guarantee it
flushed all internal buffers before sending SHUTDOWN, in which case
killing the process forcibly may result in (virtual) disk corruption.
By sending SIGQUIT instead of SIGTERM followed by SIGKILL we tell qemu
to flush all buffers and exit. Once qemu exits, we will see an EOF on
monitor connection and tear down the domain. In case qemu ignores
SIGQUIT or just hangs there, the process stays running but that's not
any different from a possible hang anytime during the shutdown process
so I think it's just fine.
This affects virDomainShutdown, virDomainReboot, and guest-initiated
shutdown, but not virDomainDestroy, right?
---
src/qemu/qemu_process.c | 21 +++++++++++++++++++--
src/qemu/qemu_process.h | 1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index f8a8475..8a12e2a 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -445,12 +445,12 @@ qemuProcessHandleShutdown(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
qemuProcessFakeReboot,
vm)< 0) {
VIR_ERROR(_("Failed to create reboot thread, killing domain"));
- qemuProcessKill(vm);
+ qemuProcessQuit(vm);
Is this hunk right? If we're that bad off that we can't create a
thread, killing might actually be better.
if (virDomainObjUnref(vm) == 0)
vm = NULL;
}
} else {
- qemuProcessKill(vm);
+ qemuProcessQuit(vm);
But this seems right to me, although I'd like some weigh-in from danpb
before committing it.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list