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-rhev | Assignee: | Jeff Cody <jcody> |
| Status: | CLOSED ERRATA | QA Contact: | Qianqian Zhu <qizhu> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | 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: | |
| Embargoed: | |||
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 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 |
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: