Re: VFIO Migration

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

* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> On Wed, Nov 04, 2020 at 05:32:02PM +0000, Dr. David Alan Gilbert wrote:
> > * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > > Michael replied in another sub-thread wondering if versions are really
> > > necessary since tools do the migration checks. Let's try dropping
> > > versions to simplify things. We can bring them back if needed later.
> > 
> > What does a user facing tool do?  If I say I want one of these NICs
> > and I'm on the latest QEMU machine type, who sets all these parameters?
> 
> The machine type is orthogonal since QEMU doesn't know about every
> possible VFIO device. The device is like a PCI adapter that is added to
> a physical machine aftermarket, it's not part of the base machine's
> specs.

OK, but ignoring migration, I think the same problem holds; if I'm a
tool creating one of these VMs, and I plug this device in, what do I do
with all it's configuration parameters?  I'd assume most of the time
that they don't know about or dont care about most of the parameters,
they just want the sane defaults unless told otherwise.

> The migration tool queries the parameters from the source device.
> VFIO/mdev will provide sysfs attrs. For vfio-user I'm not sure whether
> to print the parameters during device instantiation, require a
> VFIO-compatible FUSE directory, or to use a query-migration-params RPC
> command.

But on VM creation we have to answer the question of what config do we
want; so for example lets say I'm creating a new VM in my cluster,
but I want to be sure that later I can migrate it.  I can read the 
config off one of the other machines;  can I just use that even if my
new machine has a later device implementation?

Dave

> Let's discuss this more when the next revision of the document is sent
> out, because it modifies the approach so that migration parameters are
> logically separate from device configuration parameters. That changes
> things a bit.
> 
> Stefan


-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK