qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] pc: change default machine model and versio


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [RFC PATCH] pc: change default machine model and versions
Date: Tue, 10 Apr 2012 09:09:22 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Apr 08, 2012 at 08:30:47AM -0400, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > N.B. This is a small patch with significant implications.  Please
> > read
> > carefully.
> > 
> > Right now, '-M pc' is the default and, in general, this machine type
> > has guest
> > visible ABI changes in each version of QEMU.  At some point in each
> > release,
> > we create a '-M pc-X.Y' corresponding to the last release and attempt
> > to make
> > that look like the previous QEMU version's machine.
> > 
> > We've accumulated a bunch of '-M pc-X.Y's at this point and if we
> > move to a
> > three month release process, the problem will get much worse.
> 
> I agree that every 3 months seems excessive but moving from this to every 24 
> months seems to me to be taking it too far (and would cause too many 
> problems).
> There is a balance to be struck here and I think it should be somewhere 
> between 6 and 12 months.
> Take for example a qemu released 6 month before V2.0 and another one released 
> 3 months before V2.0, assuming the latter has some changes in it so that 
> pc-next means something else, in order to be able to migrate a VM between 
> them I'd need to use -M pc1.0 which would be at least 21 months old and not 
> be able to use any of the features introduced during this time.  


Indeed, this does seem like rather a long gap between versions.

I can understand the desire to minimize the number of machine
type versions we need to support, but this does seem like going
a bit too far in the other direction

> I have little doubt this would not hold water downstream where we'd have to 
> have a compatibility version per minor RHEL release.

I presume that regardless of what QEMU does here, RHEL will still end
up defining its own machine types & ignoring QEMUs, due to the need to
backport features from across releases.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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