On Mon, Feb 07, 2011 at 02:56:50PM -0600, Anthony Liguori wrote: > On 02/07/2011 01:53 PM, Michael S. Tsirkin wrote: > >On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote: > >>On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote: > >>>New thread stated intentionally, the original patch is Message-ID: > >>><349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.s...@redhat.com> > >>> > >>>On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote: > >>>>Add a compat property for older machine types. When this is used (via > >>>>-M pc-0.13, for example), the new flow control mechanisms will not be > >>>>used. This is done to keep migration from a machine started with older > >>>>type on a pc-0.14+ qemu to an older machine working. > >>>> > >>>>The property is named 'flow_control' and defaults to on. > >>>> > >>>>Reported-by: Alex Williamson<alex.william...@redhat.com> > >>>>Signed-off-by: Amit Shah<amit.s...@redhat.com> > >>>So, I think there are two things that need to be agreed on: > >>> > >>>- Can we commit to support migration from new qemu version to an old one? > >>> We haven't in the past but downstreams do want this, > >>> so it makes sense to have the infrastructure upstream. > >>Only within a stable release series and only when it's possible > >>without sacrificing integrity. I know some downstreams disagree > >>with this but I don't think this is a business we want to get into. > >> > >>Regards, > >> > >>Anthony Liguori > >>>- The infrastructure/command line option for such support. > >>> We have the -M flags to describe the machine that > >>> we are running, but that abstracts away guest-visible machine, > >>> which the migration format is not. > >>> Also, same qemu could migrate to any older version. > >>> So I think we would have to add a flag (call it -V for now) > >>> to savevm/migrate commands to specify the format to be used. > >>> Naturally some machines would be incompatible with > >>> specific -V values, that's nothing new. > >>> > >>>Pls comment. > >OK, assuming we want this, let's talk about implementation. > >I think that spreading custom flags all over the code like > >this patch does would be pretty bad. > > > >What I'd like to see is a way to > >- map stable versions (e.g. machine type if we are going > > to tie to that) to savevm format using > > some kind of table > >- for save callbacks to be able to figure out what > > version to use > > Why doesn't subsections already solve this problem? > > Regards, > > Anthony Liguori
How does it? We need to know we are saving in 0.13 format and skip the new subsection, otherwise 0.13 will see a subsection it does not recognize and exit. We also need API to add subsections without vmstate, because virtio serial wasn't yet converted. -- MST