qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support
Date: Wed, 5 Jun 2019 17:19:59 +0100
User-agent: Mutt/1.11.4 (2019-03-13)

On Wed, Jun 05, 2019 at 12:04:28PM -0400, Laine Stump wrote:
> On 6/4/19 9:43 AM, Jens Freimann wrote:
> > On Mon, Jun 03, 2019 at 04:36:48PM -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote:
> > > > On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:
> > > > > On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
> > > > > > On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan
> > > > Gilbert wrote:
> > > > > > > > * Jens Freimann (address@hidden) wrote:
> > > > Why is it bad to fully re-create the device in case of a failed
> > > > migration?
> > > 
> > > Bad or not, I thought the whole point of doing it inside QEMU was
> > > to do something libvirt wouldn't be able to do (namely,
> > > unplugging the device while not freeing resources).  If we are
> > > doing something that management software is already capable of
> > > doing, what's the point?
> > 
> > Event though management software seems to be capable of it, a failover
> > implementation has never happened.
> 
> I'm pretty sure RHV/oVirt+vdsm has implemented it and it is even being used
> in production. Of course it requires a bond/team device to be configured in
> the guest OS, but the part about auto-detaching the VF before migration,
> then reattaching a similar VF on the destination is all done by vdsm. (Don't
> misunderstand this as discouraging this new method! Just wanted to set the
> record straight.)

OpenStack will detach/reattach PCI devices around a save-to-disk, but
does not currently do that for live migration, but easily could do. The
blocker why they've not done that is the issue around exposing to the
guest which pairs of devices are intended to be used together in the
bond.

OpenStack could have defined a way to express that, but it would be
specific to OpenStack which is not very desirable. Standardization
of how to express the relationship between the pair of devices would
be very desirable, allowing the host side solution to be done in either
QEMU or the mgmt app as they see fit.

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]