Bug 1660572

RHEL8 is affected as well, so cloning

+++ This bug was initially created as a clone of Bug #1658981 +++

Description of problem:
Failed to create internal snapshot on blockdev

Version-Release number of selected component (if applicable):
Host:
4.18.0-50.el8.x86_64
qemu-kvm-3.1.0-0.module+el8+2266+616cf026.next.candidate.x86_64
seabios-bin-1.11.1-2.module+el8+2173+537e5cb5.noarch

Guest:
4.18.0-51.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot a guest with blockdev
 -blockdev driver=file,cache.direct=on,cache.no-flush=off,filename=/home/rhel80-64-virtio-scsi.qcow2,node-name=drive_scsi1 \
 -blockdev driver=qcow2,node-name=drive_scsi11,file=drive_scsi1 \
 -device scsi-hd,id=image1,drive=drive_scsi11,bus=virtio_scsi_pci0.0,channel=0,scsi-id=0,lun=0,bootindex=0 \

2.Create an internal snapshot via "save_vm"
qmp:
{"execute": "human-monitor-command", "arguments": {"command-line": "savevm aa1"}, "id": "WKIXiJxb"}
{"return": "Device '' is writable but does not support snapshots\r\n", "id": "WKIXiJxb"}
same with hmp:
(qemu) info block
drive_scsi11: /home/rhel80-64-virtio-scsi.qcow2 (qcow2)
    Attached to:      image1
    Cache mode:       writeback
(qemu) savevm ab
Device '' is writable but does not support snapshots

3.

Actual results:
Failed to create internal snapshot
{"return": "Device '' is writable but does not support snapshots\r\n", "id": "WKIXiJxb"}

Expected results:
succeed to create internal snapshot

Additional info:

--- Additional comment from Ademar Reis on 2018-12-14 14:33:17 BRST ---

Is it a regression from 3.1, or does it happen with qemu-2.12 (RHEL-8.0) as well?

We're deprecating internal snapshots, but given libvirt still defaults to them in virt-manager and virsh, we'll need it clonned if it happens in RHEL8.

--- Additional comment from xianwang on 2018-12-18 01:34:29 BRST ---

(In reply to Ademar Reis from comment #1)
> Is it a regression from 3.1, or does it happen with qemu-2.12 (RHEL-8.0) as
> well?
> 
> We're deprecating internal snapshots, but given libvirt still defaults to
> them in virt-manager and virsh, we'll need it clonned if it happens in RHEL8.

Hi, 
This issue also exists on qemu-2.12 (RHEL-8.0). what's more, savevm works well for "drive", this issue is only for "blockdev".

qemu build:
4.18.0-51.el8.x86_64
qemu-kvm-2.12.0-46.module+el8+2351+e14a4632.x86_64

--- Additional comment from CongLi on 2018-12-18 04:56:54 BRST ---

Refer:
https://bugzilla.redhat.com/show_bug.cgi?id=1621944#c16

Recording from Kevin:
"""
(In reply to xianwang from comment #14)
> {"execute": "human-monitor-command", "arguments": {"command-line": "savevm
> sn_test"}, "id": "WKIXiJxb"}    
> {"return": "Device '' is writable but does not support snapshots\r\n", "id":
> "WKIXiJxb"}

I think this is a QEMU bug, though I'm not sure what the correct behaviour would be.

Currently it tries to snapshot all nodes that are either created explicitly by the user or that are root nodes of BlockBackends (e.g. attached to a guest device). User created nodes includes the driver=file node in your example, and this node doesn't support snapshots. This is obviously not useful behaviour.

Maybe the best course of action would be to restrict the snapshotting to nodes that are roots of BlockBackends. This would, however, still include root nodes of block jobs, NBD servers, etc. This won't usually result in errors like here because the affected nodes will still be format level nodes, but could still be unexpected. Another option would be to further restrict this to BlockBackends that are actually attached to a device. Also, either option would exclude explicitly created qcow2 nodes which are not attached to any BlockBackend (e.g. -blockdev without using the node name anywhere else), which may or may not be what users expect.

Another possible option: Snapshot only if it is either a BlockBackend root or doesn't have any BDS parents.
"""