Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Marcel Apfelbaum (marcel@redhat.com) wrote:
> 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) ?

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 / dgilbert@redhat.com / Manchester, UK
> >
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK