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

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

On Thu, Aug 27, 2015 at 02:05:49PM +0300, Michael S. Tsirkin wrote:
> 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 <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.
> 
> 2.3 simply didn't allow migration.
> We can have 2.3 and old be same as 2.4 + disable migration.

Ok that would be reasonable as it ensures query-machines still lists
all types that QEMU is capable of actually running.


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