Bug 570387 - qemu-kvm failed to save changes in snapshot based on LV
qemu-kvm failed to save changes in snapshot based on LV
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Kevin Wolf
Virtualization Bugs
: Triaged
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2010-03-04 01:17 EST by Keqin Hong
Modified: 2011-07-18 05:47 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-18 05:47:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Keqin Hong 2010-03-04 01:17:38 EST
Description of problem:
Given a snapshot chain: /dev/vgtest/lv_20G <-- sn1, changes made on sn1 couldn't be saved.

Version-Release number of selected component (if applicable):
kvm-83-161.el5

How reproducible:
100%

CLI:
#guestf=/dev/vgtest/lv20G #or sn1
#/usr/libexec/qemu-kvm -m 2G -smp 2 -drive file=$guestf,if=ide,cache=off,boot=on -net nic,model=rtl8139,vlan=1,macaddr=02:00:40:3F:20:10 -net tap,vlan=1,script=/etc/qemu-ifup -boot c -uuid 17544ecc-d3a1-4d3c-a386-12daf50015f1 -usbdevice tablet -no-hpet -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -notify all -cpu qemu64,+sse2 -balloon none -startdate now -vnc :1

Steps to Reproduce:
1. prepare a new LV:
# lvs
  LV     VG     Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  lv_20G vgtest -wi-a- 20.00G    

1. install on LV a new guest or convert from an existing img.
#qemu-img convert -f raw RHEL-Server-5.4-64.raw -O raw /dev/vgtest/lv_20G
2. make sure the cloned guest can be booted (from /dev/vgtest/lv_20G).
3. create a snapshot chain "/dev/vgtest/lv_20G <-- sn1".
#qemu-img create -b /dev/vgtest/lv_20G -f qcow2 sn1
4. boot from sn1 and create a file inside, like "dd if=/dev/urandom of=sn1_100M bs=1M count=100", then shut down guest.
5. boot from sn1 again, and check if sn1_100M can be found.

Actual results:
after step 4, no changes were saved inside sn1.
after step 5, no sn_100M file was found.

# ls -lh sn1
-rw-r--r-- 1 root root 1.3M Mar  3 16:56 sn1

# qemu-img info sn1
image: sn1
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.1M
cluster_size: 65536
backing file: /dev/vgtest/lv_20G (actual path: /dev/vgtest/lv_20G)

# qemu-img info /dev/vgtest/lv_20G 
image: /dev/vgtest/lv_20G
file format: host_device
virtual size: 20G (21474836480 bytes)
disk size: 0

Expected results:
after step 4 or 5, changes made should be saved inside sn1, i.e. we should get "/dev/vgtest/lv_20G (guest) <-- sn1 (sn1_100M)".

Addtional info:
Comment 4 Keqin Hong 2010-03-04 21:38:45 EST
Kevin, Bill,
I find where the problem lies in -- the "-F" option of qemu-img command.

(citing comment #0)
> 1. install on LV a new guest or convert from an existing img.
> #qemu-img convert -f raw RHEL-Server-5.4-64.raw -O raw /dev/vgtest/lv_20G
> 2. make sure the cloned guest can be booted (from /dev/vgtest/lv_20G).
> 3. create a snapshot chain "/dev/vgtest/lv_20G <-- sn1".
> #qemu-img create -b /dev/vgtest/lv_20G -f qcow2 sn1

Here if I use "#qemu-img create -F raw -b /dev/vgtest/lv_20G -f qcow2 sn1",
the issue reported disappears. So the problem is whether "-F" option is strictly required or not.

In case that $baseimg is a raw disk file or qcow2 img file, "-F" option is not really needed since it will be guessed automatically. Besides, we can see from the man page or help, "-F" is indeed an optional as in: 
"create [-e] [-6] [-F base_fmt] [-b base_image] [-f fmt] filename [size]"
Comment 5 Kevin Wolf 2010-03-05 08:01:38 EST
Yes, -F should not be needed as the default is supposed to work. To be precise, host_device is the default for a block device (and not raw), but it should make no difference - does it work with -F host_device, too? Anyway, if it hadn't used the right thing, it would be really hard to explain why you could even boot up the guest.

I have tried to reproduce it with a scenario that looks very similar from a qemu point of view (couldn't use exactly the same without major effort because of disk space limitations on my test box):

# ~/source/kvm-userspace-rhel5/qemu/qemu-img convert -f qcow2 f11.qcow2 -O raw /tmp/test.img
# losetup /dev/loop0 test.img
# ~/source/kvm-userspace-rhel5/qemu/qemu-img create -b /dev/loop0 -f qcow2 sn1
# ~/source/kvm-userspace-rhel5/qemu/x86_64-softmmu/qemu-system-x86_64 -hda sn1 -m 768 -vnc :0 -k de -L ~/source/pc-bios/

Then in the guest run your dd command, shut it down, restart it and look for the file. This did work for me. Maybe this is something else you could try if it works for you?
Comment 6 Keqin Hong 2010-03-08 01:09:43 EST
(In reply to comment #5)
> Yes, -F should not be needed as the default is supposed to work. To be precise,
> host_device is the default for a block device (and not raw), but it should make
> no difference - does it work with -F host_device, too? Anyway, if it hadn't
> used the right thing, it would be really hard to explain why you could even
> boot up the guest.

It didn't work with "-F host_device". After creating a sn1_100M file inside sn1, shutting down and starting sn1 again, no sn1_100M file could be found. Further you could see the size of sn1 was very small (after dd).
"
[root@localhost ~]# qemu-img info sn1
image: sn1
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.1M
cluster_size: 65536
backing file: /dev/vgtest/lv_20G (actual path: /dev/vgtest/lv_20G)

[root@localhost ~]# hexdump -C -n 1024 sn1
00000000  51 46 49 fb 00 00 00 02  00 00 00 00 00 00 00 60  |QFI............`|
00000010  00 00 00 12 00 00 00 10  00 00 00 05 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 28  00 00 00 00 00 01 00 00  |.......(........|
00000030  00 00 00 00 00 02 00 00  00 00 00 01 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  e2 79 2a ca 00 00 00 0b  |.........y*.....|
00000050  68 6f 73 74 5f 64 65 76  69 63 65 00 00 00 00 00  |host_device.....|
00000060  2f 64 65 76 2f 76 67 74  65 73 74 2f 6c 76 5f 32  |/dev/vgtest/lv_2|
00000070  30 47 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0G..............|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400
"

> 
> I have tried to reproduce it with a scenario that looks very similar from a
> qemu point of view (couldn't use exactly the same without major effort because
> of disk space limitations on my test box):
> 
> # ~/source/kvm-userspace-rhel5/qemu/qemu-img convert -f qcow2 f11.qcow2 -O raw
> /tmp/test.img
> # losetup /dev/loop0 test.img
> # ~/source/kvm-userspace-rhel5/qemu/qemu-img create -b /dev/loop0 -f qcow2 sn1
> # ~/source/kvm-userspace-rhel5/qemu/x86_64-softmmu/qemu-system-x86_64 -hda sn1
> -m 768 -vnc :0 -k de -L ~/source/pc-bios/
> 
> Then in the guest run your dd command, shut it down, restart it and look for
> the file. This did work for me. Maybe this is something else you could try if
> it works for you?    

No, it didn't work for me. To be precise, it worked only with "-F raw" while not with "-F host_device" or with no "-F" option. I was using kvm-83-161.el5.

"
[root@dhcp-91-175 ~]# qemu-img info sn1
image: sn1
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 2.1M
cluster_size: 65536
backing file: /dev/loop0 (actual path: /dev/loop0)

[root@dhcp-91-175 ~]# hexdump -C -n 1024 sn1
00000000  51 46 49 fb 00 00 00 02  00 00 00 00 00 00 00 60  |QFI............`|
00000010  00 00 00 0a 00 00 00 10  00 00 00 05 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 28  00 00 00 00 00 01 00 00  |.......(........|
00000030  00 00 00 00 00 02 00 00  00 00 00 01 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  e2 79 2a ca 00 00 00 0b  |.........y*.....|
00000050  68 6f 73 74 5f 64 65 76  69 63 65 00 00 00 00 00  |host_device.....|
00000060  2f 64 65 76 2f 6c 6f 6f  70 30 00 00 00 00 00 00  |/dev/loop0......|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400
"
Comment 9 Keqin Hong 2010-05-24 00:59:18 EDT
> # ~/source/kvm-userspace-rhel5/qemu/qemu-img convert -f qcow2 f11.qcow2 -O raw
> /tmp/test.img
> # losetup /dev/loop0 test.img
> # ~/source/kvm-userspace-rhel5/qemu/qemu-img create -b /dev/loop0 -f qcow2 sn1
> # ~/source/kvm-userspace-rhel5/qemu/x86_64-softmmu/qemu-system-x86_64 -hda sn1
> -m 768 -vnc :0 -k de -L ~/source/pc-bios/
> 
> Then in the guest run your dd command, shut it down, restart it and look for
> the file. This did work for me. Maybe this is something else you could try if
> it works for you?    

Tested again under kvm-83-164.el5. Still the problem existed if "-F raw" option was omitted in "qemu-img create" cmd or if "-F host_device" was used.
Using "-F raw" (qemu-img create -F raw -b /dev/loop0 -f qcow2 sn1) didn't have the problem.

BTW, RHEV always uses -F option with "qemu-img create ...", this might not be a problem for it.
Comment 12 RHEL Product and Program Management 2011-01-11 15:27:58 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 13 RHEL Product and Program Management 2011-01-11 17:50:07 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 15 Ronen Hod 2011-07-18 05:47:24 EDT
Summary:
16 Months old bug, not very frequent / urgent
RHEV is explicitly using QEMU's -F flag properly, so it doesn't suffer from this bug.
Not easily reproduced by Kevin.
Closing.

Note You need to log in before you can comment on or make changes to this bug.