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 1263916 - boot guest with '-snapshot', base file is deleted after block-commit and live snapshot
Summary: boot guest with '-snapshot', base file is deleted after block-commit and live...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.2
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Jeff Cody
QA Contact: Qianqian Zhu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-17 05:29 UTC by Pei Zhang
Modified: 2016-11-07 20:38 UTC (History)
9 users (show)

Fixed In Version: 2.6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-07 20:38:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 0 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description Pei Zhang 2015-09-17 05:29:51 UTC 
Description of problem:
Boot guest with '-snapshot', after the guest start up, do block-commit to base file, then do 
blockdev-snapshot-sync and the base file on the disk is deleted. 


Version-Release number of selected component (if applicable):
Host:rhel7.2
kernel:3.10.0-316.el7.x86_64
qemu-kvm-rhev:qemu-kvm-rhev-2.3.0-23.el7.x86_64


Guest:rhel6.7z
kernel:2.6.32-573.7.1.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.boot guest with '-snapshot'
# /usr/libexec/qemu-kvm -name rhel6.7z -machine pc-i440fx-rhel7.1.0,accel=kvm \
-cpu SandyBridge -m 4G,slots=256,maxmem=40G -numa node \
-smp 4,sockets=2,cores=2,threads=1 \
-uuid 82b1a01e-5f6c-4f5f-8d27-3855a74e6b61 \
-netdev tap,id=hostnet0 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=12:54:00:5c:88:61 \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16 \
-vnc 0.0.0.0:1 \
-monitor stdio \
-qmp tcp:0:5555,server,nowait \
-serial unix:/tmp/monitor,server,nowait \
-drive file=/mnt/disk1/rhel6.7_virtio.qcow2,format=qcow2,if=none,id=drive-virtio-blk0,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-blk0,id=virtio-blk0 \
-snapshot \


check block info:
(qemu) info block
drive-virtio-blk0: /var/tmp/vl.ybabi1 (qcow2)
    Cache mode:       writeback, ignore flushes
    Backing file:     /mnt/disk1/rhel6.7_virtio.qcow2 (chain depth: 1)
...


2.do block-commit
{"execute":"block-commit","arguments":{"device":"drive-virtio-blk0"}}
{"return": {}}
{"timestamp": {"seconds": 1442467307, "microseconds": 932820}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-virtio-blk0", "len": 5701632, "offset": 5701632, "speed": 0, "type": "commit"}}
{"execute": "block-job-complete", "arguments": { "device": "drive-virtio-blk0"} }
{"return": {}}
{"timestamp": {"seconds": 1442467315, "microseconds": 895687}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-blk0", "len": 5701632, "offset": 5701632, "speed": 0, "type": "commit"}}

check block info:
(qemu) info block
drive-virtio-blk0: /mnt/disk1/rhel6.7_virtio.qcow2 (qcow2)
    Cache mode:       writeback, ignore flushes
......

# qemu-img info /mnt/disk1/rhel6.7_virtio.qcow2
image: /mnt/disk1/rhel6.7_virtio.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 2.7G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

3.do live snapshot, and after that, the base file is deleted.
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-blk0", "snapshot-file": "/mnt/disk2/snapshot1.qcow2", "format": "qcow2", "mode": "absolute-paths" } }
{"return": {}}

check block info:
(qemu) info block
drive-virtio-blk0: /mnt/disk2/snapshot1.qcow2 (qcow2)
    Cache mode:       writeback, ignore flushes
    Backing file:     /mnt/disk1/rhel6.7_virtio.qcow2 (chain depth: 1)

# qemu-img info /mnt/disk1/rhel6.7_virtio.qcow2
qemu-img: Could not open '/mnt/disk1/rhel6.7_virtio.qcow2': Could not open '/mnt/disk1/rhel6.7_virtio.qcow2': No such file or directory

# ll /mnt/disk1/rhel6.7_virtio.qcow2
ls: cannot access /mnt/disk1/rhel6.7_virtio.qcow2: No such file or directory

Actual results:
Base file is deleted after live snapshot.

Expected results:
Base file should not be deleted.

Additional info:
Comment 1 Pei Zhang 2015-09-17 05:36:09 UTC 
More info:
1. The guest is still running. Reboot several times, it still works well.

2. the snapshot file can not be found.
# ll /mnt/disk2/snapshot1.qcow2
ls: cannot access /mnt/disk2/snapshot1.qcow2: No such file or directory
Comment 2 Pei Zhang 2015-09-17 05:58:36 UTC 
More info(2):
1. After shutdown the guest, the space of the disk(/dev/sdc) will then be really released. 

before shutdown:
# df -h
Filesystem                           Size  Used Avail Use% Mounted on
/dev/mapper/rhel_dhcp--12--153-root   50G   18G   33G  35% /
...
/dev/sdc                              59G   50G  5.9G  90% /mnt/disk1
/dev/sdb                              97G   34G   58G  38% /mnt/disk2
...

after shutdown:
# df -h
Filesystem                           Size  Used Avail Use% Mounted on
/dev/mapper/rhel_dhcp--12--153-root   50G   18G   33G  35% /
...
/dev/sdc                              59G   48G  8.6G  85% /mnt/disk1
/dev/sdb                              97G   34G   58G  38% /mnt/disk2
...
Comment 3 Karen Noel 2015-09-17 10:57:21 UTC 
Is this a regression from RHEL 7.1?
Comment 4 Pei Zhang 2015-09-18 01:29:49 UTC 
(In reply to Karen Noel from comment #3)
> Is this a regression from RHEL 7.1?

re-tested:
Host:rhel7.1
Kernel:3.10.0-229.el7.x86_64
qemu-kvm-rhev:qemu-kvm-rhev-2.1.2-23.el7.x86_64

rhel7.1 hit the same issue. Seams it's not a regression.
Comment 7 Mike McCune 2016-03-28 22:44:25 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 9 Qianqian Zhu 2016-08-23 03:09:24 UTC 
Reproduced with:
qemu-kvm-rhev-2.3.0-31.el7_2.8.x86_64
qemu-img-rhev-2.3.0-31.el7_2.8.x86_64
kernel-3.10.0-461.el7.x86_64

Steps:
1. Launch guest with -snapshot:
/usr/libexec/qemu-kvm -name linux -cpu SandyBridge -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 7bef3814-631a-48bb-bae8-2b1de75f7a13 -nodefaults -monitor stdio -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot order=c,menu=on -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/mntnfs/RHEL-Server-7.3-64-virtio.qcow2,if=none,cache=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 -snapshot -qmp tcp::5555,server,nowait
2. Block commit: 
{"execute":"block-commit","arguments":{"device":"drive-virtio-disk0"}}
{"execute": "block-job-complete", "arguments": { "device": "drive-virtio-disk0"}}
3. Live snapshot:
{ "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0","snapshot-file": "/mntnfs/snapshot1.qcow2", "format": "qcow2", "mode": "absolute-paths" } }

Result:
Backing file is deleted:

(qemu) info block
drive-virtio-disk0: /mntnfs/snapshot1.qcow2 (qcow2)
    Cache mode:       writeback, ignore flushes
    Backing file:     /mntnfs/RHEL-Server-7.3-64-virtio.qcow2 (chain depth: 1)

# qemu-img info /mntnfs/RHEL-Server-7.3-64-virtio.qcow2 
qemu-img: Could not open '/mntnfs/RHEL-Server-7.3-64-virtio.qcow2': Could not open '/mntnfs/RHEL-Server-7.3-64-virtio.qcow2': No such file or directory


Verified with:
qemu-img-rhev-2.6.0-20.el7.x86_64
qemu-kvm-rhev-2.6.0-20.el7.x86_64
kernel-3.10.0-491.el7.x86_64

Steps same as above.

Results:
Backing file kept and no errors.

(qemu) info block
drive-virtio-disk0 (#block1558): /mntnfs/snapshot1.qcow2 (qcow2)
    Cache mode:       writeback, ignore flushes
    Backing file:     /mntnfs/RHEL-Server-7.3-64-virtio.qcow2 (chain depth: 1)

# qemu-img info /mntnfs/RHEL-Server-7.3-64-virtio.qcow2
image: /mntnfs/RHEL-Server-7.3-64-virtio.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 5.9G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

# qemu-img check /mntnfs/RHEL-Server-7.3-64-virtio.qcow2
No errors were found on the image.
80662/327680 = 24.62% allocated, 18.31% fragmented, 0.00% compressed clusters
Image end offset: 5287772160
Comment 10 Qianqian Zhu 2016-08-23 03:10:30 UTC 
Moving to VERIFIED as per comment 9
Comment 12 errata-xmlrpc 2016-11-07 20:38:58 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.

https://rhn.redhat.com/errata/RHBA-2016-2673.html
Note You need to log in before you can comment on or make changes to this bug.