qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices
Date: Thu, 5 Nov 2015 20:44:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 11/05/2015 08:22 PM, Dr. David Alan Gilbert wrote:
* Eduardo Habkost (address@hidden) 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 / address@hidden / Manchester, UK





reply via email to

[Prev in Thread] Current Thread [Next in Thread]