Description of problem:
libvirt can not create an external snapshot of a virtual machine backed by a raw block device.
How reproducible:
Steps to Reproduce:
1. snapshot-create-as ${DOMAIN} ${SNAPSHOT_NAME} --diskspec vda,snapshot=external,file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.disk.qcow2 --memspec file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.mem.qcow2,snapshot=external --atomic
or
2. snapshot-create-as ${DOMAIN} ${SNAPSHOT_NAME} --diskspec vda,snapshot=external,driver=raw,file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.disk.qcow2 --memspec file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.mem.qcow2,snapshot=external --atomic
Actual results:
1.
libvirtd[7157]: internal error: invalid job statistics type
libvirtd[7157]: Could not get stats for completed job; domain fedora29
libvirtd[7157]: internal error: unable to execute QEMU command 'transaction': Could not open '/var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2': Invalid argument
libvirtd[7157]: Path '/var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2' is not accessible: No such file or directory
libvirtd[7157]: Failed to teardown cgroup for disk path /var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2
libvirtd[7157]: unable to set user and group to '0:0' on '/var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2': No such file or directory
libvirtd[7157]: Unable to restore security label on /var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2
or
2.
error: unsupported configuration: disk format 'raw' lacks backing file support
Expected results: creates an external snapshot
Additional info: the guest is a Fedora 29, but the host is Arch Linux with zfs. The raw block device is backed by a zvol. If necessary I can test it on a Fedora host as well (but not with the zfs file system).
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.
Description of problem: libvirt can not create an external snapshot of a virtual machine backed by a raw block device. How reproducible: Steps to Reproduce: 1. snapshot-create-as ${DOMAIN} ${SNAPSHOT_NAME} --diskspec vda,snapshot=external,file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.disk.qcow2 --memspec file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.mem.qcow2,snapshot=external --atomic or 2. snapshot-create-as ${DOMAIN} ${SNAPSHOT_NAME} --diskspec vda,snapshot=external,driver=raw,file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.disk.qcow2 --memspec file=/var/lib/libvirt/snapshots/${DOMAIN}.${SNAPSHOT_NAME}.mem.qcow2,snapshot=external --atomic Actual results: 1. libvirtd[7157]: internal error: invalid job statistics type libvirtd[7157]: Could not get stats for completed job; domain fedora29 libvirtd[7157]: internal error: unable to execute QEMU command 'transaction': Could not open '/var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2': Invalid argument libvirtd[7157]: Path '/var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2' is not accessible: No such file or directory libvirtd[7157]: Failed to teardown cgroup for disk path /var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2 libvirtd[7157]: unable to set user and group to '0:0' on '/var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2': No such file or directory libvirtd[7157]: Unable to restore security label on /var/lib/libvirt/snapshots/fedora29.test1.disk.qcow2 or 2. error: unsupported configuration: disk format 'raw' lacks backing file support Expected results: creates an external snapshot Additional info: the guest is a Fedora 29, but the host is Arch Linux with zfs. The raw block device is backed by a zvol. If necessary I can test it on a Fedora host as well (but not with the zfs file system).