[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [libvirt] [RFC 0/2] Attempt to implement the standby fe
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] [libvirt] [RFC 0/2] Attempt to implement the standby feature for assigned network devices |
Date: |
Wed, 5 Dec 2018 17:26:34 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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 :|