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