Re: [RFC 0/6] Migration deprecated parts
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