[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 :|
- [RFC v3] VFIO Migration, Stefan Hajnoczi, 2020/11/10
- Re: [RFC v3] VFIO Migration, Paolo Bonzini, 2020/11/10
- Re: [RFC v3] VFIO Migration, Stefan Hajnoczi, 2020/11/11
- Re: [RFC v3] VFIO Migration, Daniel P . Berrangé, 2020/11/11
- Re: [RFC v3] VFIO Migration, Cornelia Huck, 2020/11/12
- Re: [RFC v3] VFIO Migration, Stefan Hajnoczi, 2020/11/16
- Re: [RFC v3] VFIO Migration, Stefan Hajnoczi, 2020/11/16
- Re: [RFC v3] VFIO Migration, Daniel P . Berrangé, 2020/11/16
- Re: [RFC v3] VFIO Migration,
Michael S. Tsirkin <=
- Re: [RFC v3] VFIO Migration, Daniel P . Berrangé, 2020/11/16
- Re: [RFC v3] VFIO Migration, Michael S. Tsirkin, 2020/11/16
- Re: [RFC v3] VFIO Migration, Daniel P . Berrangé, 2020/11/16
- Re: [RFC v3] VFIO Migration, Michael S. Tsirkin, 2020/11/16
- Re: [RFC v3] VFIO Migration, Gerd Hoffmann, 2020/11/16
- Re: [RFC v3] VFIO Migration, Michael S. Tsirkin, 2020/11/16
- Re: [RFC v3] VFIO Migration, Michael S. Tsirkin, 2020/11/16
Re: [RFC v3] VFIO Migration, Alex Williamson, 2020/11/10