qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15
Date: Wed, 10 May 2017 16:14:05 +0100
User-agent: Mutt/1.8.2 (2017-04-18)

* Daniel P. Berrange (address@hidden) wrote:
> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (address@hidden) wrote:
> > > 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.
> 
> Yep, but not using upstream machine types. So we can kill machine
> types without affecting RHEL-6.  The separate question is whether
> we can kill the associated features that are needed for RHEL to
> create its legacy machine types (eg the rombar setting mentioned)

Right, it just felt a bit odd to kill it off upstream if we know
of users ourselves who use old versions like that.

Also remember machine types are not just about migration compatibility;
if we kill a machine type then:
  a) The users will need to modify their libvirt xml for each VM to
change machine type
  b) That change in guest view of the machine might upset the OS
installed.

I've certainly got VMs that were installed ages ago and are still using
the XML from the old installation; so that probably means using an old
machine type on a modern QEMU.

Dave

> > 
> > >   - 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.
> 
> You know of the breaks between 2.6 & 2.7 because those are modern versions
> people are using & thus getting lots of attention & analysis from yourself
> and other people. Arguably it just looks worse because no one is actively
> using, testing or analysing 1.0 vs 2.7.
> 
> Ideally, we would only claim to support combinations that we have active
> compatibility test coverage for. We lacking right now, but for the sake
> of discussion, lets assume we did have some level of automated coverage.
> Then there's still the question of how far back we want to be running the
> testing for. I think the latter is the more important question, as it sets
> us a clear process to follow, as well as a goal to reach for testing coverage.
> 
> IOW, we should be able to set ourselves a goal / process, even if we don't
> yet achieve that in terms of testing.
> 
> 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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]