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
