Re: [RFC v3] VFIO Migration

[Daniel P . Berrangé]

On Mon, Nov 16, 2020 at 07:03:03AM -0500, Michael S. Tsirkin wrote:
> 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.
> 
> 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.

I'm not suggesting we punt on the problem. I'm saying that checking for
migration compatibility should not need to be made more complex than what
we already do for QEMU. The core problem being tackled is essentially the
same in both cases.

Regards,
Daniel
-- 
|: 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 :|