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

["Daniel P. Berrange" <berrange@redhat.com>]

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 <jsnow@redhat.com> writes:
> > > 
> > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > > >> * Eduardo Habkost (ehabkost@redhat.com) 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.

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