qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC v3] VFIO Migration


From: Michael S. Tsirkin
Subject: Re: [RFC v3] VFIO Migration
Date: Mon, 16 Nov 2020 07:03:03 -0500

On Mon, Nov 16, 2020 at 11:41:25AM +0000, Daniel P. Berrangé wrote:
> > It is possible to simplify the problem, but we'll lose freedom. For
> > example, hard coding knowledge of the device implementation into the
> > management tool eliminates the need for a general migration checking
> > algorithm. Or we might be able to simplify it by explicitly not
> > supporting cross-device implementation migration (although that would
> > place stricter rules on what a new version of an existing device can
> > change in order to preserve migration compatibility).
> 
> Is migrating between 2 different vendors' impls of the same core
> device spec really a thing that's needed ? 

If there's intent to have this supercede vhost-user then certainly.
Same I'm guessing for NVMe.


> > I have doubts that these trade-offs can be made without losing support
> > for use cases that are necessary.
> 
> >From my POV, the key goal is that it should be possible to migrate
> between two hosts without needing to check every single possible
> config parameter that the device supports. It should only be neccessary
> to check the parameters that are actually changed from their default
> values. Then there just needs to be some simple string parameter that
> encodes a particular set of devices, akin to the versioned machine
> type.
> 
> Applications that want to migration between cross-vendor device impls
> could opt-in to checking every single little parameter, but most can
> just stick with a much simplified view where they only have to check
> the parameters that they've actually overriden/exposed.
> 
> Regards,
> Daniel

It's a problem even for a single vendor. And we have lots of experience
telling us it's a messy, difficult one. Just punting and saying
vendors will do the right thing will not lead to quality
implementations.


> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

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