* Paolo Bonzini (pbonz...@redhat.com) wrote: > > > On 17/06/2015 13:40, Dr. David Alan Gilbert wrote: > > > Like Juan, I see where you're coming from. But it's a slippery slope, > > > and upstream chose not to go down it. > > > > Whatever choice upstream may have made, that was a long time ago > > and doesn't mean it can't change. > > My question really is: what has changed for this choice to not make > sense anymore?
At one time migration was used as an occasional facility to deal with a machine that was dieing; now you've got systems doing thousands of migrations a day between hosts for load balancing and power saving. At one time migrations were happening over GigE on small VMs, now we have people using 10-40GbE networks with 100GB of RAM in the VMs that take a significant time to migrate, even when mostly idle, spending ages migrating for it to fail with an answer of 'oh, it's data dependent, try again' is really bad. > Backward migration is not supported upstream except between minor > releases. It is really the same as in RHEL, except that a minor release > lasts a few years less. :) Of course for us on RHEL our minor releases don't correspond to QEMU minor releases, so we already support migrating from our downstream 7.1 (QEMU 2.1) derivative to our 7.0 (1.5.3) version. And the reason for this patch series is to support something >2.2 migrating back to that 2.1 (or maybe even to that 1.5.3). I don't believe we're alone in wanting to be able to do that type of thing; so you can either worry about not burdening upstream with compatibility patches like this, or think it's not fair to leave them out if others upstream might want them. How many others? Well I'd say it's got to be more than some of the other obscure features in QEMU! Dave > > Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
