Re: [PATCH] migration: Allow pipes to keep working for fd migrations

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@redhat.com> writes:

> Libvirt may still use pipes for old file migrations in fd: URI form,
> especially when loading old images dumped from Libvirt's compression
> algorithms.
>
> In that case, Libvirt needs to compress / uncompress the images on its own
> over the migration binary stream, and pipes are passed over to QEMU for
> outgoing / incoming migrations in "fd:" URIs.
>
> For future such use case, it should be suggested to use mapped-ram when
> saving such VM image.  However there can still be old images that was
> compressed in such way, so libvirt needs to be able to load those images,
> uncompress them and use the same pipe mechanism to pass that over to QEMU.
>
> It means, even if new file migrations can be gradually moved over to
> mapped-ram (after Libvirt start supporting it), Libvirt still needs the
> uncompressor for the old images to be able to load like before.
>
> Meanwhile since Libvirt currently exposes the compression capability to
> guest images, it may needs its own lifecycle management to move that over
> to mapped-ram, maybe can be done after mapped-ram saved the image, however
> Dan and PeterK raised concern on temporary double disk space consumption.
> I suppose for now the easiest is to enable pipes for both sides of "fd:"
> migrations, until all things figured out from Libvirt side on how to move
> on.
>
> And for "channels" QMP interface support on "migrate" / "migrate-incoming"
> commands, we'll also need to move away from pipe.  But let's leave that for
> later too.
>
> So far, still allow pipes to happen like before on both save/load sides,
> just like we would allow sockets to pass.
>
> Cc: qemu-stable <qemu-stable@nongnu.org>
> Cc: Fabiano Rosas <farosas@suse.de>
> Cc: Peter Krempa <pkrempa@redhat.com>
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Fixes: c55deb860c ("migration: Deprecate fd: for file migration")
> Signed-off-by: Peter Xu <peterx@redhat.com>

Reviewed-by: Fabiano Rosas <farosas@suse.de>