On Wed, Dec 05, 2018 at 12:22:18PM -0500, Michael S. Tsirkin wrote: > On Wed, Dec 05, 2018 at 06:09:16PM +0100, Peter Krempa wrote: > > From managements point of view, bundling all this together is really not > > a good idea since it creates a very big matrix of failure scenarios. > > I think this is clear. This is why we are doing it in QEMU where we can > actually do all the rollbacks transparently. > > > In > > general even libvirt will prefer that upper layer management drives this > > externally, since any rolback scenario will result in a policy decision > > of what to do in certain cases, and what timeouts to pick. > > Architectural ugliness of implementing what is from users perspective a > mechanism and not a policy aside, experience teaches that this isn't > going to happen. People have been talking about the idea of doing > this at the upper layers for years. The ability to unplugg+replug VFIO devices either side of migration has existed in OpenStack for a long time. They also have metadata that can be exposed to the guest to allow it to describe which pairs of (emulated,vfio) devices should be used together. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
