Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Thu, Aug 27, 2015 at 12:01:17PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> > > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> > > > John Snow <address@hidden> writes:
> > > > 
> > > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > > > >> * Eduardo Habkost (address@hidden) wrote:
> > > > >>> Migration with q35 was not possible before commit
> > > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 
> > > > >>> unconditionally creates
> > > > >>> an ich9-ahci device, that was marked as unmigratable. So all q35 
> > > > >>> machines
> > > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > > >>> compatibility code for them.
> > > > >>>
> > > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > > > >> 
> > > > >> But doesn't that mean that anyone who has a machine configured with 
> > > > >> one
> > > > >> of those machine types will suddenly find it wont start?
> > > > >> 
> > > > >> Dave
> > > > >> 
> > > > >
> > > > > To some extent, all versions of this board prior to 2.4 should be
> > > > > considered unsupported and we should discourage their use anyway.
> > > > >
> > > > > If you really want, I suppose we could just alias them to 2.4 ...
> > > > 
> > > > I'd very much prefer an honest "won't start" over a silent change of the
> > > > machine type.
> > > > 
> > > > If we really want to bend over backwards for existing uses of these
> > > > machine types, we could make them error out with "use pc-q35-2.5
> > > > instead".  Since I don't think they exist outside testing, I wouldn't
> > > > bother.
> > > 
> > > Agreed, we should be reporting a hard error for any machine types we
> > > have deleted. Or if we care about smooth upgrade path then we shouldn't
> > > be deleting them in the first place. Silently changing the user's
> > > requested machine type into a different machine type is violating
> > > the semantics of stable machine types.
> > 
> > The reason we are deleting them is because changes in behaviour are not
> > user visible implementation details, and live migration is unsupported.
> > 
> > In other words 2.4 is identical to <2.3 in all respect except live
> > migration, which didn't work in <2.3 and works in 2.4, that's why
> > aliasing them is fine.
> 
> If you run a guest with machine type 2.3 on new QEMU, it will
> in fact be running machine type 2.4.  Libvirt will still believe
> it is using machine type 2.3, so will happily allow you to start
> a migrate to a host with old QEMU with the original 2.3 machine
> type. This is bad because the machine types are not compatible
> for migration and we should report this up front, not let the
> migration start and that fail with some problem loading the
> migration data stream.

2.3 simply didn't allow migration.
We can have 2.3 and old be same as 2.4 + disable migration.

> 
> We know 2.3 machine type is broken, so should just be upfront
> about this and drop support for it and have users update their
> guests to a non-broken machine type.
> 
> Regards,
> Daniel

They aren't broken any more than any other old machine type.
The reason we can drop most of compatibility code is
because it's only important for live migration, and
that was blocked anyway.


> -- 
> |: 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 :|