From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Laine Stump <laine@redhat.com>
Cc: pkrempa@redhat.com, Eduardo Habkost <ehabkost@redhat.com>,
mst@redhat.com, aadam@redhat.com,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
qemu-devel@nongnu.org, Jens Freimann <jfreimann@redhat.com>,
ailan@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support
Date: Wed, 5 Jun 2019 17:19:59 +0100 [thread overview]
Message-ID: <20190605161959.GM8956@redhat.com> (raw)
In-Reply-To: <037855ae-1c21-53a1-8ebb-fcc677d751d9@redhat.com>
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 (jfreimann@redhat.com) 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 :|
next prev parent reply other threads:[~2019-06-05 16:22 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 12:58 [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices Jens Freimann
2019-05-17 12:58 ` [Qemu-devel] [PATCH 1/4] migration: allow unplug during migration for failover devices Jens Freimann
2019-05-21 9:33 ` Dr. David Alan Gilbert
2019-05-21 9:47 ` Daniel P. Berrangé
2019-05-23 8:01 ` Jens Freimann
2019-05-23 15:37 ` Dr. David Alan Gilbert
2019-05-17 12:58 ` [Qemu-devel] [PATCH 2/4] qdev/qbus: Add hidden device support Jens Freimann
2019-05-21 11:33 ` Michael S. Tsirkin
2019-05-17 12:58 ` [Qemu-devel] [PATCH 3/4] net/virtio: add failover support Jens Freimann
2019-05-21 9:45 ` Dr. David Alan Gilbert
2019-05-30 14:56 ` Jens Freimann
2019-05-30 17:46 ` Michael S. Tsirkin
2019-05-30 18:00 ` Dr. David Alan Gilbert
2019-05-30 18:09 ` Michael S. Tsirkin
2019-05-30 18:22 ` Eduardo Habkost
2019-05-30 23:06 ` Michael S. Tsirkin
2019-05-31 17:01 ` Eduardo Habkost
2019-05-31 18:04 ` Michael S. Tsirkin
2019-05-31 18:42 ` Eduardo Habkost
2019-05-31 18:45 ` Dr. David Alan Gilbert
2019-05-31 20:29 ` Alex Williamson
2019-05-31 21:05 ` Michael S. Tsirkin
2019-05-31 21:59 ` Eduardo Habkost
2019-06-03 8:59 ` Dr. David Alan Gilbert
2019-05-31 20:43 ` Michael S. Tsirkin
2019-05-31 21:03 ` Eduardo Habkost
2019-06-03 8:06 ` Dr. David Alan Gilbert
2019-05-30 19:08 ` Dr. David Alan Gilbert
2019-05-30 19:21 ` Michael S. Tsirkin
2019-05-31 8:23 ` Dr. David Alan Gilbert
2019-06-05 15:23 ` Daniel P. Berrangé
2019-05-30 18:17 ` Eduardo Habkost
2019-05-30 19:09 ` Dr. David Alan Gilbert
2019-05-31 21:47 ` Eduardo Habkost
2019-06-03 8:24 ` Jens Freimann
2019-06-03 9:26 ` Jens Freimann
2019-06-03 18:10 ` Laine Stump
2019-06-03 18:46 ` Alex Williamson
2019-06-05 15:20 ` Daniel P. Berrangé
2019-06-06 15:00 ` Roman Kagan
2019-06-03 19:36 ` Eduardo Habkost
2019-06-04 13:43 ` Jens Freimann
2019-06-04 14:09 ` Eduardo Habkost
2019-06-04 17:06 ` Michael S. Tsirkin
2019-06-04 19:00 ` Dr. David Alan Gilbert
2019-06-07 14:14 ` Jens Freimann
2019-06-07 14:32 ` Michael S. Tsirkin
2019-06-07 17:51 ` Dr. David Alan Gilbert
2019-06-05 14:36 ` Daniel P. Berrangé
2019-06-05 16:04 ` Laine Stump
2019-06-05 16:19 ` Daniel P. Berrangé [this message]
2019-05-17 12:58 ` [Qemu-devel] [PATCH 4/4] vfio/pci: unplug failover primary device before migration Jens Freimann
2019-05-20 22:56 ` [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices Alex Williamson
2019-05-21 7:21 ` Jens Freimann
2019-05-21 11:37 ` Michael S. Tsirkin
2019-05-21 18:49 ` Jens Freimann
2019-05-29 0:14 ` si-wei liu
2019-05-29 2:54 ` Michael S. Tsirkin
2019-06-03 18:06 ` Laine Stump
2019-06-03 18:12 ` Michael S. Tsirkin
2019-06-03 18:18 ` Laine Stump
2019-06-06 21:49 ` Michael S. Tsirkin
2019-05-29 2:40 ` Michael S. Tsirkin
2019-05-29 7:48 ` Jens Freimann
2019-05-30 18:12 ` Michael S. Tsirkin
2019-05-31 15:12 ` Jens Freimann
2019-05-21 14:18 ` Alex Williamson
2019-05-21 8:37 ` Daniel P. Berrangé
2019-05-21 10:10 ` Michael S. Tsirkin
2019-05-21 19:17 ` Jens Freimann
2019-05-21 21:43 ` Michael S. Tsirkin
2019-06-11 15:42 ` Laine Stump
2019-06-11 15:51 ` Michael S. Tsirkin
2019-06-11 16:12 ` Laine Stump
2019-06-12 9:11 ` Daniel P. Berrangé
2019-06-12 11:59 ` Jens Freimann
2019-06-12 15:54 ` Laine Stump
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190605161959.GM8956@redhat.com \
--to=berrange@redhat.com \
--cc=aadam@redhat.com \
--cc=ailan@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jfreimann@redhat.com \
--cc=laine@redhat.com \
--cc=mst@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).