SIGTERM to qemu-kvm process destroys qcow2 image?

SIGTERM to qemu-kvm process destroys qcow2 image?

[Kenni Lund]

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?

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.

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'

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 :-/

I'm on qemu-kvm 0.11.0 with kernel modules from 2.6.31.6.

Best Regards
Kenni Lund

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Avi Kivity]

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.

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Kenni Lund]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

2009/12/17 Avi Kivity <avi@redhat.com>:
> On 12/17/2009 02:52 AM, Kenni Lund wrote:
>> 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.

4K dump attached.

Best Regards
Kenni Lund

[-- Attachment #2: WindowsXP.img_4k_dump --]
[-- Type: application/octet-stream, Size: 4096 bytes --]

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Avi Kivity]

On 12/17/2009 11:38 AM, Kenni Lund wrote:
> 2009/12/17 Avi Kivity<avi@redhat.com>:
>    
>> On 12/17/2009 02:52 AM, Kenni Lund wrote:
>>      
>>> 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.
>>      
> 4K dump attached.
>
>    

Seems fine.  Kevin can you take a look?

You have a backing file.  Do qemu-img info and qemu-img check like it?

-- 
error compiling committee.c: too many arguments to function

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Kevin Wolf]

Am 17.12.2009 11:23, schrieb Avi Kivity:
> On 12/17/2009 11:38 AM, Kenni Lund wrote:
>> 2009/12/17 Avi Kivity<avi@redhat.com>:
>>    
>>> On 12/17/2009 02:52 AM, Kenni Lund wrote:
>>>      
>>>> 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.
>>>      
>> 4K dump attached.
>>
>>    
> 
> Seems fine.  Kevin can you take a look?

Agreed, the dump looks fine. Even qcow2_open succeeds if I just use this
header as a qcow2 file.

> You have a backing file.  Do qemu-img info and qemu-img check like it?

So I'd definitely have a look at the backing file. It's almost the only
thing that can go wrong after qcow2_open. qemu-img doesn't have known
problems with backing files in general, but it does have problems with
missing (or broken) backing files.

Kenni, could you check if your backing file is still alive? /tmp doesn't
sound like a safe place for images. If it still exists in the right
location (/tmp/WindowsXP.img.backup) and it is qcow2, can you please
attach the first 4k of the backing file?

Kevin

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Kenni Lund]

2009/12/17 Kevin Wolf <kwolf@redhat.com>:
> Am 17.12.2009 11:23, schrieb Avi Kivity:
>> On 12/17/2009 11:38 AM, Kenni Lund wrote:
>>> 2009/12/17 Avi Kivity<avi@redhat.com>:
>>>
>>>> On 12/17/2009 02:52 AM, Kenni Lund wrote:
>>>>
>>>>> 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.
>>>>
>>> 4K dump attached.
>>>
>>>
>>
>> Seems fine.  Kevin can you take a look?
>
> Agreed, the dump looks fine. Even qcow2_open succeeds if I just use this
> header as a qcow2 file.
>
>> You have a backing file.  Do qemu-img info and qemu-img check like it?
>
> So I'd definitely have a look at the backing file. It's almost the only
> thing that can go wrong after qcow2_open. qemu-img doesn't have known
> problems with backing files in general, but it does have problems with
> missing (or broken) backing files.
>
> Kenni, could you check if your backing file is still alive? /tmp doesn't
> sound like a safe place for images. If it still exists in the right
> location (/tmp/WindowsXP.img.backup) and it is qcow2, can you please
> attach the first 4k of the backing file?
>
> Kevin
>

Huh? Backing file? Is that the same as a base image? Eg. a write
protected image on which other images can be based?

If so, I'm quite confused...this should be a standalone image created
with a command like "qemu-img create -f WindowsXP.img 50G" half a year
ago on kvm 8x. I don't use libvirt/virt-manager etc. I start qemu-kvm
directly from a homemade bash script. I don't have any
/tmp/WindowsXP.img.backup file, and I would never put stuff inside
/tmp, especially not images, they belong to /data/virtualization/ on
my server and nowhere else....

If the image needs another image in /tmp/WindowsXP.img.backup I can
see why it doesn't work, but I have _no_ idea why or how this file was
created (?!??) - even if I was doing a test with base-images, I would
do it directly in /data/virtualization/ and never in /tmp/

Best Regards
Kenni Lund

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Avi Kivity]

On 12/18/2009 04:13 PM, Kenni Lund wrote:
>
> Huh? Backing file? Is that the same as a base image? Eg. a write
> protected image on which other images can be based?
>
>    

Yes.

> If so, I'm quite confused...this should be a standalone image created
> with a command like "qemu-img create -f WindowsXP.img 50G" half a year
> ago on kvm 8x. I don't use libvirt/virt-manager etc. I start qemu-kvm
> directly from a homemade bash script. I don't have any
> /tmp/WindowsXP.img.backup file, and I would never put stuff inside
> /tmp, especially not images, they belong to /data/virtualization/ on
> my server and nowhere else....
>    

The '/tmp' was prefixed by qemu-img, the actual path is 
'WindowsXP.img.backup', so on your setup qemu-img would look for it in 
/data/virtualization/.

> If the image needs another image in /tmp/WindowsXP.img.backup I can
> see why it doesn't work, but I have _no_ idea why or how this file was
> created (?!??) - even if I was doing a test with base-images, I would
> do it directly in /data/virtualization/ and never in /tmp/
>    

If it isn't there you can try to create it (qemu-img create 
/data/virtualization/WindowsXP.img.backup 31457280000).  If no data was 
actually stored there, your image will be recovered.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Kevin Wolf]

Am 18.12.2009 15:22, schrieb Avi Kivity:
>> If so, I'm quite confused...this should be a standalone image created
>> with a command like "qemu-img create -f WindowsXP.img 50G" half a year
>> ago on kvm 8x. I don't use libvirt/virt-manager etc. I start qemu-kvm
>> directly from a homemade bash script. I don't have any
>> /tmp/WindowsXP.img.backup file, and I would never put stuff inside
>> /tmp, especially not images, they belong to /data/virtualization/ on
>> my server and nowhere else....
>>    
> 
> The '/tmp' was prefixed by qemu-img, the actual path is 
> 'WindowsXP.img.backup', so on your setup qemu-img would look for it in 
> /data/virtualization/.

Whoops, I've been tricked by qemu-img. Sorry. I thought I had seen this
path in hexdump, but obviously that was wrong.

Kevin

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Kenni Lund]

2009/12/18 Avi Kivity <avi@redhat.com>:
> On 12/18/2009 04:13 PM, Kenni Lund wrote:
> The '/tmp' was prefixed by qemu-img, the actual path is
> 'WindowsXP.img.backup', so on your setup qemu-img would look for it in
> /data/virtualization/.
>
>> If the image needs another image in /tmp/WindowsXP.img.backup I can
>> see why it doesn't work, but I have _no_ idea why or how this file was
>> created (?!??) - even if I was doing a test with base-images, I would
>> do it directly in /data/virtualization/ and never in /tmp/
>>
>
> If it isn't there you can try to create it (qemu-img create
> /data/virtualization/WindowsXP.img.backup 31457280000).  If no data was
> actually stored there, your image will be recovered.

Thanks, this explains the whole thing - this is own mistake, I move
all the backups into a subdirectory, I didn't know that I had based
the image on a backup-image, bad design decision on my part.

I'm sorry for the false alarm, thanks a lot for your help :)

Best Regards
Kenni Lund

Re: SIGTERM to qemu-kvm process destroys qcow2 image?

[Avi Kivity]

On 12/18/2009 04:35 PM, Kenni Lund wrote:
>
> Thanks, this explains the whole thing - this is own mistake, I move
> all the backups into a subdirectory, I didn't know that I had based
> the image on a backup-image, bad design decision on my part.
>    

Note you can undo it using qemu-img convert, if you have the free space 
and the patience.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.