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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
