From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: SIGTERM to qemu-kvm process destroys qcow2 image? Date: Thu, 17 Dec 2009 07:34:39 +0200 Message-ID: <4B29C2EF.5010606@redhat.com> References: <3b1f68ef0912161652l94ad986lc3f3ee380614c108@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Kenni Lund Return-path: Received: from mx1.redhat.com ([209.132.183.28]:18685 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752407AbZLQFeq (ORCPT ); Thu, 17 Dec 2009 00:34:46 -0500 In-Reply-To: <3b1f68ef0912161652l94ad986lc3f3ee380614c108@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/17/2009 02:52 AM, Kenni Lund wrote: > Hi > > Sorry if this is a stupid question, but is it expected behaviour that > a qcow2 image will/can get damaged by killing the qemu-kvm process > with a SIGTERM signal? > > If it does, that's a serious bug. qcow2 should survive SIGTERM, SIGKILL, and host power loss. > I would expect data on filesystems within the virtual machine to > potentially get damaged if it's in use, but I though that the qemu-kvm > process would take care of finishing its writes correctly to the qcow2 > image before shutting down, ensuring the integrity of the qcow2 image. > No, it uses O_SYNC writes to ensure all writes are completed, and orders writes carefully so the image is consistent at all times. > Yesterday I entered an invalid boot device as an argument to my > qemu-kvm command for my Windows XP machine, causing an error about a > missing boot device in the qemu BIOS/POST. As I didn't have any > filesystems mounted inside the virtual machine (since it was stuck at > the BIOS asking for a device to boot), I did a kill $pid, fixed the > boot device in the qemu-kvm command and tried booting again...but with > no luck, whatever I try now with qemu-kvm gives me the error: > qemu: could not open disk image /data/virtualization/WindowsXP.img > > And qemu-img (check, convert, etc) gives me: > qemu-img: Could not open 'WindowsXP.img' > Can you post the first 4K of the image? It shouldn't contain private data, but go over it (or don't post) if you sensitive information there. > Is this expected behaviour? Luckily I do have backups of the most > important data on this machine, I'm just happy this didn't happen to > any of my critical machines :-/ > > It is not. > I'm on qemu-kvm 0.11.0 with kernel modules from 2.6.31.6. > Should be recent enough. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.