On Tue, Sep 13, 2011 at 17:00:38 -0600, Eric Blake wrote:
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?
Yes.
--- 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.
I was thinking that if we can't reboot (because we cannot create the thread), we should just shutdown normally, not kill the domain without giving qemu a chance to flush buffers. Jirka