Peter Xu <[email protected]> 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 <[email protected]> > Cc: Fabiano Rosas <[email protected]> > Cc: Peter Krempa <[email protected]> > Cc: Daniel P. Berrangé <[email protected]> > Fixes: c55deb860c ("migration: Deprecate fd: for file migration") > Signed-off-by: Peter Xu <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
