Hello,
I have virtual machines running with a ceph storage backend.
When creating an external qcow2 snapshot with a libvirt version without
support for the new object secret passing, the backing file info would
list the ceph secret in plain,e.g.
# virsh snapshot-create-as vm-123 --no-metadata --disk-only --diskspec
sda,file=/var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2
# qemu-img info /var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2
...
backing file:
rbd:vms_pool0/disk-123:id=libvirt:key=SECRET:auth_supported=cephx\;none:mon_host=192.168.1.1\:6789\;192.168.1.11\:6789\;192.168.1.21\:6789
While this is problematic from a security perspective (and one of the
reasons for the new method), it enabled starting the virtual machine
again in case it died or got powered off.
With the newer libvirt object secret passing the backing file
of the qcow image only references the secret id.
# qemu-img info /var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2
...
backing file: json:{"driver": "raw", "file":
{"password-secret":
"scsi0-0-0-0-secret0", "pool": "vms_pool",
"image": "disk-123",
"driver": "rbd", "user": "libvirt",
"=keyvalue-pairs":
"[\"auth_supported\", \"cephx;none\", \"mon_host\",
\"192.168.1.1:6789;192.168.1.11:6789;192.168.1.21:6789\"]"}}
This is fine as long as the virtual machine is running and with
qemu-2.10 it is even possible to block-commit this external snapshot
(Yeah!).
However, should the VM die or be powered off, it is now longer possible
to start the domain or at least recover the data:
Could not open backing file: No secret with id 'scsi0-0-0-0-secret0'
I guess this problems happens with any disk type that is accessed with
object secrets, which is why I would consider this a bug.
The question is, should/can this be fixed in libvirt or qemu?
I think libvirt should create the snapshot file with the object secret
stored in a persistent file (and reference this file in the backing file
definition)
Best regards,
Markus