From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41317)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Yfs1q-0008TQ-Sp
	for qemu-devel@nongnu.org; Wed, 08 Apr 2015 11:36:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Yfs1k-00063P-QW
	for qemu-devel@nongnu.org; Wed, 08 Apr 2015 11:36:34 -0400
Received: from mx1.redhat.com ([209.132.183.28]:50352)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Yfs1k-00063D-Is
	for qemu-devel@nongnu.org; Wed, 08 Apr 2015 11:36:28 -0400
Date: Wed, 8 Apr 2015 17:36:25 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20150408153625.GB3710@noname.str.redhat.com>
References: <5524B797.2080503@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5524B797.2080503@cisco.com>
Subject: Re: [Qemu-devel] SIGTERM signal to qemu-kvm process
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jatin Davey <jashokda@cisco.com>
Cc: qemu-devel@nongnu.org

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