Bug 1263916

Summary: boot guest with '-snapshot', base file is deleted after block-commit and live snapshot
Product: Red Hat Enterprise Linux 7 Reporter: Pei Zhang <pezhang>
Component: qemu-kvm-rhevAssignee: Jeff Cody <jcody>
Status: CLOSED ERRATA QA Contact: Qianqian Zhu <qizhu>
Severity: high Docs Contact:
Priority: medium    
Version: 7.2CC: chayang, huding, juzhang, knoel, michen, mrezanin, mst, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 2.6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-07 20:38:58 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:

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@redhat.com 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