Re: [RFC 0/6] Migration deprecated parts

[Jiri Denemark]

On Mon, Jun 12, 2023 at 21:33:38 +0200, Juan Quintela wrote:
> Hi this series describe the migration parts that have to be deprecated.
> 
> - It is an rfc because I doubt that I did the deprecation process right. 
> Hello Markus O:-)
> 
> - skipped field: It is older than me, I have never know what it stands
>   for.  As far as I know it has always been zero.

Libvirt doesn't use this.

> - inc/blk migrate command options.  They are only used by block
>   migration (that I deprecate on the following patch).  And they are really 
> bad.
>   grep must_remove_block_options.
>
> - block migration.  block jobs, whatever they are called this week are
>   way more flexible.  Current code works, but we broke it here and
>   there, and really nobody has stand up to maintain it.  It is quite
>   contained and can be left there.  Is anyone really using it?

We prefer nbd for storage migration if it is available.

> - old compression method.  It don't work.  See last try from Lukas to
>   make a test that works reliabely.  I failed with the same task years
>   ago.  It is really slow, and if compression is good for you, multifd
>   + zlib is going to perform/compress way more.

We do support these methods, but only enable them if a user explicitly
requests so. In other words, the user will just get an error once these
methods are removed, which is fine.

> - -incoming <uri>
> 
>   if you need to set parameters (multifd cames to mind, and preempt has
>   the same problem), you really needs to use defer.  So what should we do 
> here?
> 
>   This part is not urget, because management apps have a working
>   option that are already using "defer", and the code simplifacation
>   if we remove it is not so big.  So we can leave it until 9.0 or
>   whatever we think fit.

Right, libvirt already uses -incoming defer if supported.

In other words, no objection to removing anything on this list and no
additional work is needed on libvirt side.

Jirka