Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > BARs directly to low memory). So let's start with a deprecation message
> > for the old 0.xx machine types so that the (hopefully) few users of these
> > old systems start switching over to newer machine types instead.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> >  Note: I've decided to print the warning for all pc-0.* machine types,
> >  but that of course doesn't mean that we also have to remove them all at
> >  once when we decide to finally really remove some. We could then also
> >  start by removing 0.10 and 0.11 only, for example (since there should
> >  really be no users left for these), or only up to 0.13 (to be able to
> >  kill rombar=0), as discussed in the "Deprecating old machine types"
> >  mail thread recently.
> 
> 
> As a point of reference here are the release dates:
> 
> v0.10.0: Mar 2009
> v0.11.0: Sep 2009
> v0.12.0: Dec 2009
> v0.13.0: Oct 2010
> v0.14.0: Feb 2011
> v0.15.0: Aug 2011
>    v1.0: Dec 2011
>  v1.1.0: Jun 2012
>  v1.2.0: Sep 2012
>  v1.3.0: Dec 2012
>  v1.4.0: Feb 2013
>  v1.5.0: May 2013
>  v1.6.0: Aug 2013
>  v1.7.0: Nov 2013
>  v2.0.0: Apr 2014
>  v2.1.0: Aug 2014
>  v2.2.0: Dec 2014
>  v2.3.0: Apr 2015
>  v2.4.0: Aug 2015
>  v2.5.0: Dec 2015
>  v2.6.0: May 2016
>  v2.7.0: Sep 2016
>  v2.8.0: Dec 2016
>  v2.9.0: Apr 2017
> 
> If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> release  (Dec 2017), that means our oldest machine type pc-1.0 is still
> going to be 6 years, or 18 major releases, old. This raises some questions
> 
>   - Do we really think that we still have users with VMs that are
>     stuck on a 6 year old machine type from 18 major releases ago ?

Our RHEL6 users are still on a 0.12 derivative.

>   - Is 6 years / 18 major releases going to be our cutoff point for
>     machine types going forward ?
> 
>   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
>     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
>     unless someone can show automated testing results that confirm
>     it is compatible.

I'll give you a manual one; I just migrated:
   /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic
to
   /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444

seems to have survived.
Not exactly conclusive or heavy coverage, but it's not completely
broken.

> FYI, I'm in favour of culling old machine types, but I think when we do
> this it should not be a one-off ad-hoc culling.
> 
> It should be accompanied by changes to the documentation that clearly
> state our official support policy for machine type lifetimes, so that
> users know what to expect for future releases.
> 
> Also unless we're going to get more serious about automated testing to
> validate machine type compatibility between *all* previously releases,
> I think that 6 years / 18 releases is too long a time to have any
> confidence in migration compatibility between versions.

The problem is we don't do that much testing; I know of more subtle
things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine
type? No, but it's a question of how you choose what to kill.

> IOW, I think you should be more aggressive in culling old machine types
> that this patch is...


Dave

> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK