* Marcel Apfelbaum (mar...@redhat.com) wrote: > On 11/05/2015 08:22 PM, Dr. David Alan Gilbert wrote: > >* Eduardo Habkost (ehabk...@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) ?
Note that (d) is talking about making it fail on a new version of qemu with an old machine type; e.g. if you know that your new device for some reason just won't work on pc-i440fx-2.4 or older then add a check in - I'm not sure if we've got any easy way to do that at the moment but it shouldn't be hard. However I don't think I'm aware of any device with that type of interaction; but maybe there is somewhere. > 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? (d) is entirely separate from knowing that it won't work on an old machine type on an old qemu. No, I don't think we have anything for minimum version for features; but, management tools can probe for all features, so some management tool could group those feature sets together somewhere to know the features of all the hosts involved; but it doesn't sound that easy. Dave > > Thanks, > Marcel > > > > >Dave > > > >> > >>-- > >>Eduardo > >-- > >Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK