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

From: Eduardo Habkost <ehabkost@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: pkrempa@redhat.com, berrange@redhat.com, aadam@redhat.com,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org, laine@redhat.com,
	Jens Freimann <jfreimann@redhat.com>,
	ailan@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support
Date: Fri, 31 May 2019 15:42:12 -0300	[thread overview]
Message-ID: <20190531184212.GE22103@habkost.net> (raw)
In-Reply-To: <20190531135059-mutt-send-email-mst@kernel.org>

On Fri, May 31, 2019 at 02:04:49PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 31, 2019 at 02:01:54PM -0300, Eduardo Habkost wrote:
> > > Yes. It's just lots of extremely low level interfaces
> > > and all rather pointless.
> > > 
> > > And down the road extensions like surprise removal support will make it
> > > all cleaner and more transparent. Floating things up to libvirt means
> > > all these low level details will require more and more hacks.
> > 
> > Why do you call it pointless?
> 
> We'd need APIs to manipulate device visibility to guest, hotplug
> controller state and separately manipulate the resources allocated. This
> is low level stuff that users really have no idea what to do about.
> Exposing such a level of detail to management is imho pointless.
> We are better off with a high level API, see below.

I don't disagree it's low level.  I just disagree it's pointless.
The goal here is to provide an API that management software can
use.

> 
> > If we want this to work before
> > surprise removal is implemented, we need to provide an API that
> > works for management software.
> >  Don't we want to make this work
> > without surprise removal too?
> 
> This patchset adds an optional, off by default support for
> migrating guests with an assigned network device.
> If enabled this requires guest to allow migration.
> 
> Of course this can be viewed as a security problem since it allows guest
> to block migration. We can't detect a malicious guest reliably imho.
> What we can do is report to management when guest allows migration.
> Policy such what to do when this does not happen for a while and
> what timeout to set would be up to management.
> 
> The API in question would be a high level one, something
> along the lines of a single "guest allowed migration" event.

If you want to hide the low level details behind a higher level
API, that's OK.  I just want to be sure we have really listened
to management software developers to confirm the API we're
providing will work for them.

This will probably require documenting the new interface in more
detail (as you have already mentioned in this thread).

-- 
Eduardo