Red Hat Bugzilla – Bug 1263916
boot guest with '-snapshot', base file is deleted after block-commit and live snapshot
Last modified: 2016-11-07 15:38:58 EST
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:
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
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 ...
Is this a regression from RHEL 7.1?
(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.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
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
Moving to VERIFIED as per comment 9
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