Bug 1263916 - boot guest with '-snapshot', base file is deleted after block-commit and live snapshot
boot guest with '-snapshot', base file is deleted after block-commit and live...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.2
x86_64 Linux
medium Severity high
: rc
: ---
Assigned To: Jeff Cody
Qianqian Zhu
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-17 01:29 EDT by Pei Zhang
Modified: 2016-11-07 15:38 EST (History)
9 users (show)

See Also:
Fixed In Version: 2.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-07 15:38:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pei Zhang 2015-09-17 01:29:51 EDT
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 01:36:09 EDT
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 01:58:36 EDT
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 06:57:21 EDT
Is this a regression from RHEL 7.1?
Comment 4 Pei Zhang 2015-09-17 21:29:49 EDT
(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 18:44:25 EDT
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-22 23:09:24 EDT
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-22 23:10:30 EDT
Moving to VERIFIED as per comment 9
Comment 12 errata-xmlrpc 2016-11-07 15:38:58 EST
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.