From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUx2X-0004e6-W2 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 09:16:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUx2T-000429-CV for qemu-devel@nongnu.org; Thu, 27 Aug 2015 09:16:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUx2T-00041y-4K for qemu-devel@nongnu.org; Thu, 27 Aug 2015 09:16:21 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id B113F8E3E7 for ; Thu, 27 Aug 2015 13:16:20 +0000 (UTC) Date: Thu, 27 Aug 2015 14:16:16 +0100 From: "Daniel P. Berrange" Message-ID: <20150827131616.GR24486@redhat.com> References: <1439939502-4722-1-git-send-email-ehabkost@redhat.com> <20150819095526.GB2332@work-vm> <55D4C813.1070308@redhat.com> <87vbc5qadz.fsf@blackfin.pond.sub.org> <20150825162116.GD25920@redhat.com> <20150827134638-mutt-send-email-mst@redhat.com> <20150827110117.GO24486@redhat.com> <20150827140259-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150827140259-mutt-send-email-mst@redhat.com> Subject: Re: [Qemu-devel] [PATCH] q35: Remove old machine versions Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Eduardo Habkost , Marcel Apfelbaum , Laszlo Ersek , qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , John Snow , "Dr. David Alan Gilbert" 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 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 :|