On Fri, Jul 10, 2020 at 02:09:06AM +0000, Tian, Kevin wrote: <...> > > > > We also can't even seem to agree that type is a necessary requirement > > > > for compatibility. Your discussion below of a type-A, which is > > > > equivalent to a type-B w/ aggregation set to some value is an example > > > > of this. We might also have physical devices with extensions to > > > > support migration. These could possibly be compatible with full mdev > > > > devices. We have no idea how an administrative tool would discover > > > > this other than an exhaustive search across every possible target. > > > > That's ugly but feasible when considering a single target host, but > > > > completely untenable when considering a datacenter. > > > > > > If exhaustive search can be done just one-off to build the compatibility > > > database for all assignable devices on each node, then it might be > > > still tenable in datacenter? > > > > > > I'm not sure what "one-off" means relative to this discussion. Is this > > trying to argue that if it's a disturbingly heavyweight operation, but > > a management tool only needs to do it once, it's ok? We should really > > yes > > > be including openstack and ovirt folks in any discussion about what > > might be acceptable across a datacenter. I can sometimes get away with > > representing what might be feasible for libvirt, but this is the sort > > of knowledge and policy decision that would occur above libvirt. > > Agree. and since this is more about general migration compatibility, > let's start new thread and involve openstack/ovirt guys. Yan, can you > initiate this? > sure. hi Alex, I'm not sure if below mailling lists are enough and accurate, do you know what extra people and lists I need to involve in? devel@xxxxxxxxx, openstack-discuss@xxxxxxxxxxxxxxxxxxx, libvir-list@xxxxxxxxxx BTW, I found a page about live migration of SRIOV devices in openstack. https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvirt-neutron-sriov-livemigration.html Thanks Yan
