[libvirt] libvirt mdev migration, mdevctl integration

[Cornelia Huck]

On Tue, 26 Nov 2019 10:54:59 +0100
Boris Fiuczynski <fiuczy at linux.ibm.com> wrote:

> On 11/25/19 6:14 PM, Cornelia Huck wrote:
> > Also, I'm wondering if we need special care for vfio-ap, although I'm
> > not sure if it is feasible to add migration support for it all. We
> > currently have a matrix device (always same parent) defined by the
> > UUID, and adapters/domains configured for this matrix device (which is
> > handled as extra parameters in the mdevctl device config). I'm not sure
> > how different adapters/domains translate between systems we want to
> > migrate between. Not sure how much sense it makes to dwell on this at  
> Aside from the card preparation with the appropriate masterkeys the 
> adapter/domain configuration (including the card types) for an mdev 
> needs to remain the same since there is no virtualization of 
> adapter/domain addresses in the current vfio-ap driver implementation. 
> As a result a currently possible migration scenario is cross-CEC.

Ok, given the non-virtualization of queue addresses, we need an exact
match on both sides.

> 
>  From libvirts perspective:
> Assuming that mdevs on the source and target system exist, would a 
> matching UUID be enough assurance that these two host resources match 
> for a migration? If not, is a check performed on the configuration of 
> the two mdevs? What is in that case considered migration save? Where are 
> these checks implemented? Does the checking for migratablity go beyond 
> the configuration data of mdev devices, e.g. vfio-ap: check for 
> existence of masterkeys, card type equivalency or as Connie mentioned 
> before on vfio-ccw the equivalency of the child ccw device of the 
> subchannels.

Entrusting a management layer with setting up the other side probably
makes the most sense, at the very least for an initial implementation.

One concern I have: How easy is it to find out that the management
layer has messed things up? Ideally, we want to find out as early as
possible that the other side does not match and abort the migration.
Limping on with subtle errors would be the worst case.