On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote: >> >>>> We cannot even create a new 'hack section' for new code since the >>>> sections are ordered and expected to be exact match on the >>>> destination. >>>> >>>> The result is that new->old migration cannot work. This is not cross >>>> releases even! It means that even a small bug in current release >>>> prevents live migration between various instances of the code. >>>> It forces us to decide whether to fix pvclock migration issue vs >>>> allow new->old migration. Another ugly hack is to add cmdline that >>>> will control this behavior. Still it's a pain to mgmt stack and >>>> users. >>>> >>> This is a pretty normal policy (backwards compat but not forwards compat). >>> >> >> No one is asking that old qemu magically understands new format. It >> would be enough that new qemu is able to migrate to a format that old >> one understands. >> > > I've got no problem with that provided it's something explicitly > requested by the user. This requires no migration protocol change > though so if this is what folks are asking for, why is this thread > focused around changing the live migration protocol?
I think the claim is that a section-based migration protocol would make implementing this easier than version-based one, especially for downstream which might cherry-pick a feature from a new release to an old one. It seems the requirement discussion and the implementation discussion are going on together in this thread. > Regards, > > Anthony Liguori > >
