qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Signal handling and qcow2 image corruption


From: David Barrett
Subject: [Qemu-devel] Signal handling and qcow2 image corruption
Date: Wed, 05 Mar 2008 13:18:04 -0800
User-agent: Thunderbird 2.0.0.12 (X11/20080227)

I'm tracking down a image corruption issue and I'm curious if you can answer the following:

1) Is there any difference between sending a "TERM" signal to the QEMU process and typing "quit" at the monitor?

2) Will sending TERM corrupt the 'gcow2' image (in ways other than normal guest OS dirty shutdown)?

3) Assuming I always start QEMU using "-loadvm", is there any risk in using 'kill' to send SIGTERM to the QMEU process when done?


I notice the entire implementation of "do_quit()" is simply:

        static void do_quit(void)
        {
                exit(0);
        }

So I don't see any special shutdown sequence being invoked, and I can't find any atexit() handler that's used in the general case. Thus it would seem to me that just killing the process should be the same as calling "quit" via the monitor.

(I also can't find a signal handler for SIGTERM, but I might have missed it.)

Furthermore, if I understand "-loadvm" correctly, then any change made by the guest OS (including any corruption of the image caused by a dirty shutdown) should be blown away on the next restart.

Thus it seems that I should be able to safely start QEMU with -loadvm, do my thing inside the guest OS, and then just "kill" the host process, again and again and again, without any risk of accumulated corruption.

Is this correct, or am I misunderstanding this?

I ask because I seem to be getting accumulated corruption in my guest OS, but it's not totally reproducible. Just trying to make sure QEMU works as it does to narrow down the debugging options.

Thanks!

-david





reply via email to

[Prev in Thread] Current Thread [Next in Thread]