Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 877339

Summary: fail to commit live snapshot image(lv) to a backing image(lv)
Product: Red Hat Enterprise Linux 6 Reporter: Sibiao Luo <sluo>
Component: qemu-kvmAssignee: Jeff Cody <jcody>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 6.4CC: acathrow, areis, bsarathy, chayang, chetan, dyasny, jcody, juzhang, kwolf, michen, mkenneth, qzhang, shu, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.338.el6 Doc Type: Bug Fix
Doc Text:
The drive format had no bdrv_reopen_prepare() method, so the drive reopen() call could not be performed. Without drive reopen(), you could not commit live snapshot images to backing images via qemu-img. This update adds bdrv_reopen() support for RAW hdev, floppy, and CD-ROM formats, so committing live snapshot images to backing images succeeds.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 13:07:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace log. none

Description Sibiao Luo 2012-11-16 09:54:32 UTC 
Description of problem:
boot a guest with a lv base data disk, and make live snapshot to a lv image, then shutdown guest and commit commit live snapshot image(lv) to a backing image(lv), it will fail and prompt that 'qemu-img: Image is read-only'. 

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-331.el6.x86_64
qemu-kvm-0.12.1.2-2.327.el6.x86_64
guest info(windows& rhev):
windows_server_2012_x64
kernel-2.6.32-331.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a guest with a lv base data disk.
eg:...-drive file=/dev/vg-90.100-sluo/sluo-snap1,if=none,id=data-virtio-disk,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=data-virtio-disk,id=data-disk
2.make live snapshot to a lv image.
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "data-virtio-disk", "snapshot-file": "/dev/vg-90.100-sluo/sluo-snap1", "format": "qcow2" } }
3.copy a big file into the data disk.
4.shutdown guest and commit commit live snapshot image(lv) to a backing image(lv).
# qemu-img commit -f qcow2 /dev/vg-90.100-sluo/sluo-snap1

Actual results:
after step 2, it make live snapshot successfully with {"return": {}}.
(qemu) info block
...
data-virtio-disk: removable=0 io-status=ok file=/dev/vg-90.100-sluo/sluo-snap1 backing_file=/dev/vg-90.100-sluo/sluo-base ro=0 drv=qcow2 encrypted=0
...
after step 3, 
# strace -o /home/strace-log.txt qemu-img commit -f qcow2 /dev/vg-90.100-sluo/sluo-snap1
qemu-img: Image is read-only

Note: I will attach the strace-log.txt later.

Expected results:
Commit the changes recorded in snapshot image in its base image successfully, the big file should be existing on base image.

Additional info:
both the base and snapshot lv write access is read/write, and the permissions on the dm-4 is 'brwxrwxrwx'.
# lvscan 
  ACTIVE            '/dev/vg-90.100-sluo/sluo-base' [5.00 GiB] inherit
  ACTIVE            '/dev/vg-90.100-sluo/sluo-snap1' [5.00 GiB] inherit
# qemu-img info /dev/vg-90.100-sluo/sluo-base
image: /dev/vg-90.100-sluo/sluo-base
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 0
cluster_size: 65536
# lvdisplay /dev/vg-90.100-sluo/sluo-base
  --- Logical volume ---
  LV Path                /dev/vg-90.100-sluo/sluo-base
  LV Name                sluo-base
  VG Name                vg-90.100-sluo
  LV UUID                BfpjyV-8AP2-6RgV-Xby9-OOwg-3rT0-CSN5SV
  LV Write Access        read/write
  LV Creation host, time localhost.localdomain, 2012-11-13 10:05:16 +0800
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4
# ls -l /dev/vg-90.100-sluo/sluo-base
lrwxrwxrwx. 1 root root 7 Nov 13 10:05 /dev/vg-90.100-sluo/sluo-base -> ../dm-4
# ls -l /dev/dm-4
brwxrwxrwx. 1 root disk 253, 4 Nov 16 16:57 /dev/dm-4
Comment 1 Sibiao Luo 2012-11-16 09:56:21 UTC 
Created attachment 646271 [details]
strace log.
Comment 2 Sibiao Luo 2012-11-16 09:58:03 UTC 
my host cpuinfo:

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping	: 7
cpu MHz		: 1600.000
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 6784.81
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
Comment 4 Sibiao Luo 2012-11-16 12:25:34 UTC 
Hi all,

   I tried the 'live commit' test with lv, and it can commit of data from overlay image nodes into backing nodes - writes data between 'top' and 'base' into 'base'.
steps: 
1.boot a guest with /dev/vg-90.100-sluo/sluo-base as a data disk
2.create the first live snapshot sluo-snap1 and copy a big file S1 to the data disk.
3.create the second live snapshot sluo-snap2 and copy a big file S2 to the data disk.
4.create the third live snapshot sluo-snap3 and copy a big file S3 to the data disk.
5.do live commit.
{ "execute": "__com.redhat_block-commit", "arguments": { "device": "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top": "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
6.shutdown guest and boot it with sluo-snap1 to check the file.

Result:
1.after the step 5, do live commit successfully.
{ "execute": "__com.redhat_block-commit", "arguments": { "device": "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top": "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
{"return": {}}
{"timestamp": {"seconds": 1353067638, "microseconds": 182526}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "data-virtio-disk", "len": 5368709120, "offset": 5368709120, "speed": 1000000000, "type": "commit"}}
2.after the step 6, 
the big file S1 and S2 can be existing on sluo-snap1 image correctly.

Best Regards.
sluo
Comment 5 Jeff Cody 2012-11-16 12:39:13 UTC 
Hello,

In summary, it sounds like:

1. offline commit, via qemu-img, fails
2. live commit, via QMP, is successful

Could you try the HMP 'commit' command, and see if it fails like in #1, above?

Thanks,
Jeff
Comment 6 Sibiao Luo 2012-11-16 12:58:54 UTC 
(In reply to comment #5)
> Could you try the HMP 'commit' command, and see if it fails like in #1,
> above?
yes, i have tried as your indication, but not like comment #0. 
It can do 'commit' via HMP monitor successfully and the file changed in the snapshot can be existing on base image correctly.

Steps:
1.boot a guest with /dev/vg-90.100-sluo/sluo-base as a data disk
2.create the first live snapshot sluo-snap1 and copy a big file S1 to the data disk.
3.do commit via HMP monitor.
(qemu) info block
drive-virtio-disk0: removable=0 io-status=ok file=/dev/vg-90.100-sluo/lv-90-100-windows_2012_sluo_x64 ro=0 drv=qcow2 encrypted=0
data-virtio-disk: removable=0 io-status=ok file=/dev/vg-90.100-sluo/sluo-snap1 backing_file=/dev/vg-90.100-sluo/sluo-base ro=0 drv=qcow2 encrypted=0
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]
(qemu) ? commit 
commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files
(qemu) commit data-virtio-disk
(qemu)
4.shutdown guest and boot it with sluo-base to check the file.

Result:
1.after the step 3, do commit via HMP successfully.
2.after the step 4, 
the big file S1 can be existing on sluo-base image correctly.

Best Regards.
sluo
Comment 7 Jeff Cody 2012-11-16 13:14:08 UTC 
(In reply to comment #6)
> (In reply to comment #5)
> > Could you try the HMP 'commit' command, and see if it fails like in #1,
> > above?
> yes, i have tried as your indication, but not like comment #0. 
> It can do 'commit' via HMP monitor successfully and the file changed in the
> snapshot can be existing on base image correctly.
> 

Thank you - could you try one more thing for me please?  Perform the same steps as live commit that worked, however shut down the guest prior to performing the live commit.  That is, do the following steps (note, steps 5 & 6 are new):

1.boot a guest with /dev/vg-90.100-sluo/sluo-base as a data disk
2.create the first live snapshot sluo-snap1 and copy a big file S1 to the data disk.
3.create the second live snapshot sluo-snap2 and copy a big file S2 to the data disk.
4.create the third live snapshot sluo-snap3 and copy a big file S3 to the data disk.
5. shut down the guest
6. start the guest up using the latest sluo-snap3 snapshot.
7. do live commit.
{ "execute": "__com.redhat_block-commit", "arguments": { "device": "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top": "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
6.shutdown guest and boot it with sluo-snap1 to check the file.

Thanks,
Jeff
Comment 8 Sibiao Luo 2012-11-16 13:39:52 UTC 
(In reply to comment #7)
> Thank you - could you try one more thing for me please?  Perform the same
> steps as live commit that worked, however shut down the guest prior to
> performing the live commit.  That is, do the following steps (note, steps 5
> & 6 are new):
> 
> 1.boot a guest with /dev/vg-90.100-sluo/sluo-base as a data disk
> 2.create the first live snapshot sluo-snap1 and copy a big file S1 to the
> data disk.
> 3.create the second live snapshot sluo-snap2 and copy a big file S2 to the
> data disk.
> 4.create the third live snapshot sluo-snap3 and copy a big file S3 to the
> data disk.
> 5. shut down the guest
yes, i do as your indication.
> 6. start the guest up using the latest sluo-snap3 snapshot.
yes, i do as your indication.
eg... -drive file=/dev/vg-90.100-sluo/sluo-snap3,if=none,id=data-virtio-disk,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=data-virtio-disk,id=data-disk
(qemu) info block
drive-virtio-disk0: removable=0 io-status=ok file=/dev/vg-90.100-sluo/lv-90-100-windows_2012_sluo_x64 ro=0 drv=qcow2 encrypted=0
data-virtio-disk: removable=0 io-status=ok file=/dev/vg-90.100-sluo/sluo-snap3 backing_file=/dev/vg-90.100-sluo/sluo-snap2 ro=0 drv=qcow2 encrypted=0
> 7. do live commit.
> { "execute": "__com.redhat_block-commit", "arguments": { "device":
> "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top":
> "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
yes, i do as your indication, but fail with error "NotSupported".
{"execute":"qmp_capabilities"}
{"return": {}}

{ "execute": "__com.redhat_block-commit", "arguments": { "device": "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top": "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
{"error": {"class": "NotSupported", "desc": "Not supported", "data": {}}}

{"execute":"query-kvm"}
{"return": {"enabled": true, "present": true}}


# qemu-img info /dev/vg-90.100-sluo/sluo-snap1
image: /dev/vg-90.100-sluo/sluo-snap1
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 0
cluster_size: 65536
backing file: /dev/vg-90.100-sluo/sluo-base
# qemu-img info /dev/vg-90.100-sluo/sluo-snap2
image: /dev/vg-90.100-sluo/sluo-snap2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 0
cluster_size: 65536
backing file: /dev/vg-90.100-sluo/sluo-snap1
# qemu-img info /dev/vg-90.100-sluo/sluo-snap3
image: /dev/vg-90.100-sluo/sluo-snap3
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 0
cluster_size: 65536
backing file: /dev/vg-90.100-sluo/sluo-snap2

> 6.shutdown guest and boot it with sluo-snap1 to check the file.
> 
the step 5 fail, and i check that only the S1 file existing there.

Best Regards.
sluo
Comment 9 Jeff Cody 2012-11-16 14:01:56 UTC 
(In reply to comment #8)

> > 7. do live commit.
> > { "execute": "__com.redhat_block-commit", "arguments": { "device":
> > "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top":
> > "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
> yes, i do as your indication, but fail with error "NotSupported".
> {"execute":"qmp_capabilities"}
> {"return": {}}
> 
> { "execute": "__com.redhat_block-commit", "arguments": { "device":
> "data-virtio-disk", "base": "/dev/vg-90.100-sluo/sluo-snap1", "top":
> "/dev/vg-90.100-sluo/sluo-snap2", "speed": 1000000000 } }
> {"error": {"class": "NotSupported", "desc": "Not supported", "data": {}}}
> 

Thank you, that gives me the information I need to fix this.  The drive reopen() is failing, because there is not a bdrv_reopen_prepare() method for the drive format.  Without drive reopen() live commit or normal commit will not work properly, so the reopen() method needs to be implemented.
Comment 10 Jeff Cody 2012-11-16 23:12:01 UTC 
*** Bug 874953 has been marked as a duplicate of this bug. ***
Comment 12 Jeff Cody 2012-11-21 16:42:44 UTC 
Patches are posted upstream, and in Stefan's block branch:

https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02138.html
Comment 17 Shaolong Hu 2012-12-07 02:05:35 UTC 
Verified on qemu-kvm-rhev-0.12.1.2-2.340.el6.x86_64:

Two scenario tested:

1. 
qemu-img create -f qcow2 /dev/disk/by-path/ip-10.66.6.222\:3260-iscsi-iqn.2001-04.com.example\:storage.disk1.amiens.sys1.xyz-lun-1 1G

qemu-img create -f qcow2 -F qcow2 -b /dev/disk/by-path/ip-10.66.6.222\:3260-iscsi-iqn.2001-04.com.example\:storage.disk1.amiens.sys1.xyz-lun-1 /dev/disk/by-path/ip-10.66.6.222\:3260-iscsi-iqn.2001-04.com.example\:storage.disk1.amiens.sys1.xyz-lun-2

qemu-img commit /dev/disk/by-path/ip-10.66.6.222\:3260-iscsi-iqn.2001-04.com.example\:storage.disk1.amiens.sys1.xyz-lun-2
Image committed.

2.
{ "execute": "__com.redhat_block-commit", "arguments": { "device": "drive-virtio-disk0", "base": "/dev/disk/by-path/ip-10.66.6.222:3260-iscsi-iqn.2001-04.com.example:storage.disk1.amiens.sys1.xyz-lun-1", "top": "/dev/disk/by-path/ip-10.66.6.222:3260-iscsi-iqn.2001-04.com.example:storage.disk1.amiens.sys1.xyz-lun-2", "speed": 1000000000 } }
{"return": {}}
{"timestamp": {"seconds": 1354846099, "microseconds": 239272}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 1073741824, "offset": 1073741824, "speed": 1000000000, "type": "commit"}}
Comment 21 errata-xmlrpc 2013-02-21 13:07:56 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0543.html