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:
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]"
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?
(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 "
> # ~/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.
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.
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.
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.