On Tue, Oct 01, 2019 at 10:45:53 +0200, Kevin Wolf wrote: > Am 01.10.2019 um 02:24 hat John Snow geschrieben: > > > > > > On 9/30/19 3:26 PM, Craig Mull wrote: > > > How can have QEMU backup write the output to an encrypted target? > > > > > > Blocks in the dirty bitmap are unencrypted, and as such when I write > > > them with QEMU backup they are written to the target unencrypted. > > > > > > I've experimented with providing a json string as the target but with no > > > luck. > > > > > > > > > transaction='{ "execute": "transaction", > > > > > > "arguments": { > > > > > > "actions": [ > > > > > > {"type": "block-dirty-bitmap-add", > > > > > > "data": {"node": "drive-virtio-disk0", "granularity": 2097152, > > > "name": "mybitmap"} }, > > > > > > {"type": "drive-backup", > > > > > > "data": {"device": "drive-virtio-disk0", "target": > > > "json:{\"encrypt.format\": \"luks\", \"encrypt.key-secret\": > > > \"virtio-disk0-luks-secret0\", \"driver\": \"qcow2\", \"file\": > > > {\"driver\": \"file\", \"filename\": > > > \"/tmp/target-encrypt-test.qcow2\"}}", > > > > > > "sync": "full", "format": "qcow2"} } > > > > > > ] > > > > > > } > > > > > > }' > > > > > > > > > > > > virsh -c qemu:///system qemu-monitor-command --pretty 28 $transaction > > > > > > > > > > > > { > > > > > > "id": "libvirt-45", > > > > > > "error": { > > > > > > "class": "GenericError", > > > > > > "desc": "Unknown protocol 'json'" > > > > > > } > > > > > > } > > > > > > > > > > I'll be honest, I'm not very good at the json specifications and don't > > really know when they're appropriate to use. At the basic level, > > drive-backup expects a filename. Sometimes the filename can get fancy, > > but... I stay away from that. > > > > Try using qmp-blockdev-create to create the target node instead, and > > then using blockdev-backup to backup to that target. > > As the actual invocation is a virsh command, I think this is more of a > libvirt question than a QEMU one.
The above virsh command is a direct (unsupported/experimental) command passthrough to qemu, thus the syntax is identical to raw QMP. You must use blockdev-backup as outlined above along with any management necessary for adding the devices previously. Obviously this may desynchronize state with libvirt. > I suspect that libvirt won't support this without -blockdev support > (which will enable blockdev-backup instead of drive-backup), but even > then libvirt might not even offer an API for an encrypted target. Not > sure, though, so CCing Peter. The current state is that libvirt will support backup only with -blockdev. In that case everything including encrypted images should be supported same way as we (will [1]) support them with snapshots or normal disks. This is currently being worked on. [1] All the code for blockdev is in but it's not enabled yet as we are waiting for the possibility to detect the fix for 'savevm' done recently. -blockdev will be supported with qemu-4.2.