Re: [libvirt] [Qemu-devel] [PATCH 1/2] qapi: deprecate drive-mirror and drive-backup

On Wed, Aug 14, 2019 at 15:22:15 -0400, John Snow wrote: [...] Thanks for the heads up! Currently libvirt does not use 'drive-backup' at all so that one can be deprecated immediately. In case of 'drive-mirror' the situation is a bit more complex: Libvirt uses 'drive-mirror' currently in the following places 1) virDomainBlockCopy API With blockdev integration enabled this will go away. Pathces are being reviewed: https://www.redhat.com/archives/libvir-list/2019-August/msg00295.html 2) VM migration with non-shared storage Currently uses 'drive-mirror' in most cases but there is pre-existing integration for blockdev-mirror for nbd+tls. I need to make sure that the blockdev version will be used unconditionally once the integration is enabled. This is a TODO. There is also one gotcha. In case when an 'sd' card device is used for the VM, libvirt disables all of blockdev, because SD cards can't be expressed with blockdev. There's too many code paths which would need checking to be worth it. To be fair, I'm not even sure when a sd card can be emulated by qemu as all of my basic tests failed and I did not care more. For libvirt to enable blockdev there's one more part missing and that's snapshot integration. I'm currently testing patches to integrate it with external snapshots, which should be posted soon. I also found a bug in qemu, which prevents creation of internal snapshots when -blockdev is used: When savevm HMP command is used (via QMP->HMP bridge) qemu invokes save_snapshot(), which calls bdrv_all_can_snapshot(). That function uses bdrv_next() to iterate all nodes which correspond to a block backend first, but then also iterates any other node which is monitor-owned. Since with blockdev all nodes including the ones for the 'file' protocol are monitor-owned, and 'file' does not support snapshots that check fails. A simple hack of skipping the second part in bdrv_next() allows to do a snapshot actually. Kevin told me that the idea is that also non-attached nodes should be considered for internal snapshod which is okay in my opinion, but given how the snapshot works for the files attached to backeds (and also in pre-blockdev use) only the top level of a chain should ever be considered for snapshot. So the summary is, that I'm pretty hopeful that we should be able to get rid of all reasonable uses of drive-mirror very soon after I finish snapshot integration. The only question is how much we care about SD card users being able to do a drive-mirror in the future.