From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yg8m2-000431-Ce for qemu-devel@nongnu.org; Thu, 09 Apr 2015 05:29:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yg8ly-0008TQ-DD for qemu-devel@nongnu.org; Thu, 09 Apr 2015 05:29:22 -0400 Received: from alln-iport-8.cisco.com ([173.37.142.95]:13632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yg8ly-0008TD-6f for qemu-devel@nongnu.org; Thu, 09 Apr 2015 05:29:18 -0400 Message-ID: <55264670.7000105@cisco.com> Date: Thu, 9 Apr 2015 14:59:20 +0530 From: Jatin Davey MIME-Version: 1.0 References: <5524B797.2080503@cisco.com> <20150408153625.GB3710@noname.str.redhat.com> In-Reply-To: <20150408153625.GB3710@noname.str.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] SIGTERM signal to qemu-kvm process List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org On 4/8/2015 9:06 PM, Kevin Wolf wrote: > Am 08.04.2015 um 07:07 hat Jatin Davey geschrieben: >> I am using QEMU 0.12.1 as the hypervisor in my RHEL installation of 6.5. >> >> I wanted to know if there are any side-effects with respect to VM image >> corruption when i use SIGTERM signal to kill a qemu-kvm process which >> effectively stops my VM running on the host. >> >> Appreciate if you can provide me some valuable information in this regard. > Sending SIGTERM is equivalent to sending a 'quit' monitor command. This > is a clean shutdown as far as qemu is concerned, but of course it isn't > for your guest OS. > > If your guest behaves correctly, you may lose data that wasn't flushed > to disk yet, but you should not get any corruption. The image file > structure itself (i.e. what 'qemu-img check' checks) should be fully > consistent. > > Sending SIGKILL is a bit worse (just like a host crash/power failure), > because then even the image file may be inconsistent. But again, if the > guest behaves correct (and assuming there are no qemu bugs and you're > not using cache=unsafe), even in this case the result should never be > corruption, but only loss of data that wasn't flushed to disk yet. > > Kevin Thanks Kevin. Appreciate your prompt response in this regard. Thanks Jatin