From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuPWs-0006uB-7P for qemu-devel@nongnu.org; Thu, 05 Nov 2015 13:44:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuPWn-0005fA-8O for qemu-devel@nongnu.org; Thu, 05 Nov 2015 13:44:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuPWm-0005eN-QP for qemu-devel@nongnu.org; Thu, 05 Nov 2015 13:44:53 -0500 References: <1446119788-19722-1-git-send-email-marcel@redhat.com> <20151030152048.GQ4180@thinpad.lan.raisama.net> <5635D82C.6030400@redhat.com> <20151102100730.6836dc5f.cornelia.huck@de.ibm.com> <56372AF2.8040500@redhat.com> <20151102105425.32230aca.cornelia.huck@de.ibm.com> <56373462.2050601@redhat.com> <20151102130531.6a4a4175.cornelia.huck@de.ibm.com> <56375330.70702@redhat.com> <20151105174216.GQ4180@thinpad.lan.raisama.net> <20151105182209.GC2445@work-vm> From: Marcel Apfelbaum Message-ID: <563BA39E.70706@redhat.com> Date: Thu, 5 Nov 2015 20:44:46 +0200 MIME-Version: 1.0 In-Reply-To: <20151105182209.GC2445@work-vm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , Eduardo Habkost Cc: mst@redhat.com, Juan Quintela , qemu-devel@nongnu.org, Amit Shah , kraxel@redhat.com, Cornelia Huck On 11/05/2015 08:22 PM, Dr. David Alan Gilbert wrote: > * Eduardo Habkost (ehabkost@redhat.com) wrote: >> On Mon, Nov 02, 2015 at 02:12:32PM +0200, Marcel Apfelbaum wrote: >>> On 11/02/2015 02:05 PM, Cornelia Huck wrote: >> [...] >>>> What's the word on compat machines and new device types, btw.? If we >>>> fire up a compat machine, we can still specify devices that were added >>>> with later machine versions, but of course we can't migrate to an old >>>> machine as the device types did not exist there. Do we want to give the >>>> user a hint here by disallowing new device types? >>>> >>> >>> I started to wonder about this too, so I added to this thread the migration >>> maintainers that should be qualified to answer this :) >> >> This looks no different from all other features that are available on >> newer QEMU versions and prevent migration to older hosts (even ones that >> are not guest-visible, like backend configuration). Management can >> easily detect the unavailability of those features in other hosts, long >> before trying migration (and have better ways to warn the user if >> necessary). >> >> Also, it looks like a potential nightmare for downstream maintainers >> that cherry-pick and rebase patches, so I hope we don't consider >> implementing that. :) > > a) It's fine to add new devices and allow them to be used with old machine > types > b) The rule is that any old machine type used in the way it used to be used > must stay the same. > c) That also means it's fine to add new features that can be turned on > with old machine types; as long as the default is that they behave > just like they always did. > d) If you know a new device just isn't going to work with an old > machine type then please make it fail early with an obvious > error. > > Having said all that; I have seen requests for some magic which would > tell the management tool whether something is 'safe for migration'; > so imagine that a user has a pile of hosts, some of which have qemu 2.n on > and some have qemu 2.n+1 ; if he creates his VM on 2.n+1 and uses > a feature that's new in 2.n+1 the management tool can't warn him > because they've not yet expressed an interest in migrating to > the 2.n machine. Exactly, so how can I do (d) ? A "migration possible" machine mapping qemu-pc-2.x -> qemu-pc-2.y is not enough, we need to compare also the QEMU versions and have a "minimum QEMU version per feature." Do we have a way to do this today in QEMU? Thanks, Marcel > > Dave > >> >> -- >> Eduardo > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK >