All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org"
	<dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
	Flavio Leitner <fleitner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"dev-VfR2kkLFssw@public.gmane.org"
	<dev-VfR2kkLFssw@public.gmane.org>,
	Michal Privoznik
	<mprivozn-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Daniele Di Proietto
	<diproiettod-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>,
	"libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
	<libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Maxime Coquelin
	<maxime.coquelin-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [libvirt] [RFC] Vhost-user backends cross-version migration support
Date: Thu, 2 Feb 2017 17:13:57 +0000	[thread overview]
Message-ID: <20170202171357.GV2915@redhat.com> (raw)
In-Reply-To: <20170202190811-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

On Thu, Feb 02, 2017 at 07:09:24PM +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 02, 2017 at 11:47:57AM -0500, Laine Stump wrote:
> > On 02/02/2017 10:06 AM, Daniel P. Berrange wrote:
> > > On Thu, Feb 02, 2017 at 03:14:01PM +0100, Maxime Coquelin wrote:
> > > > 
> > > > On 02/01/2017 12:41 PM, Daniel P. Berrange wrote:
> > > > > It depends where / how in OVS it needs to be set. The only stuff libvirt
> > > > > does with OVS is to run 'add-port' and 'del-port' commands via the ovs
> > > > > cli tool.
> > 
> > (aside note: the code that exec's ovs-vsctl was written back when there was
> > no standardized API for performing such operations. libvirt would prefer to
> > not exec external programs though, and I've heard that OVS may now have an
> > official API of some sort for doing things like this (maybe via netlink or
> > dbus or something?) If that's the case, can someone point me in the right
> > direction?)
> > 
> > > > >   We pass through arguments from the port profile stored in the
> > > > > XML config.
> > > > > 
> > > > >    <interface type='bridge'>
> > > > >      <source bridge='ovsbr'/>
> > > > >      <virtualport type='openvswitch'>
> > > > >        <parameters profileid='menial' interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
> > > > >      </virtualport>
> > > > >    </interface>
> > > > > 
> > > > > eg those things in <parameters/> get passed as cli args to the 'add-port'
> > > > > command. Soo if add-port needs this new version string, then we'd need
> > > > > to add the version to the openvswitch virtualport XML.
> > > > > 
> > > > > If the version is provided to OVS in a different command, then it would
> > > > > probably be outside scope of libvirt.
> > > > I think it would make sense to be a parameter of the add-port command.
> > > > But it would be for vhost-user related add-port command, I didn't find
> > > > where/if this is managed in libvirt XML.
> > > For vhost-user, libvirt does not have any interaction with OVS at
> > > all. If the thing that's using the vhost-user UNIX socket, in turn
> > > connects to OVS, that's outside scope of libvirt. IOW, for vhost-user
> > > OVS it seems like that job is for Nova / os-vif to solve.
> > 
> > This brings up another tangentially related question I came up against last
> > night - qemu now has an option to report the host's MTU to the guest for
> > virtio and vhost-user interfaces, and Michal Privoznik recently pushed
> > patches to set the MTU sent to the guest via an explicit <mtu size='n'/> in
> > libvirt's interface config:
> > 
> >    https://bugzilla.redhat.com/1408701
> > 
> > But it would be much nicer if libvirt could learn the MTU of [that stuff at
> > the other end of the unix socket] without requiring intervention in
> > libvirt's config. For example, I'm just now testing patches for tap-based
> > interfaces (connecting to Linux host bridges or OVS switches) that query the
> > current MTU of the bridge and report that to qemu; this eliminates the
> > burden of configuring each interface of each guest individually (and
> > changing that config in all those places if someone ever wants to change the
> > MTU of the bridge).
> > 
> > As Dan says, though, libvirt's only interaction in the case of vhost-user is
> > with the unix socket. Is there any way to learn what is the appropriate MTU
> > from OVS in these cases? Or must Nova (or ovirt or some poor user) set that
> > up in the libvirt config for every single interface?
> 
> We could add commands for all kind of queries to the vhost-user
> protocol.  libvirt would have to learn the vhost-user protocol though.
> Interested?

No, I really don't think libvirt should implement the vhost-user protocol

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

  parent reply	other threads:[~2017-02-02 17:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01  8:35 [RFC] Vhost-user backends cross-version migration support Maxime Coquelin
2017-02-01  9:14 ` [libvirt] " Michal Privoznik
2017-02-01  9:43   ` Daniel P. Berrange
2017-02-01 11:33     ` Maxime Coquelin
2017-02-01 11:41       ` Daniel P. Berrange
     [not found]         ` <20170201114119.GE3232-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-01 22:32           ` Michael S. Tsirkin
2017-02-02 14:14         ` Maxime Coquelin
2017-02-02 15:06           ` Daniel P. Berrange
2017-02-02 16:21             ` Michael S. Tsirkin
     [not found]               ` <20170202181827-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-02-02 17:10                 ` Daniel P. Berrange
     [not found]                   ` <20170202171028.GT2915-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-02 17:20                     ` Michael S. Tsirkin
2017-02-02 17:29                       ` Daniel P. Berrange
     [not found]                         ` <20170202172908.GW2915-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-02 17:31                           ` Michael S. Tsirkin
     [not found]                             ` <20170202193041-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-02-02 18:21                               ` Daniel P. Berrange
     [not found]                                 ` <20170202182155.GA30916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-02 18:27                                   ` Michael S. Tsirkin
2017-02-03  9:27                                     ` Daniel P. Berrange
2017-02-03  9:41                                       ` Maxime Coquelin
     [not found]                                         ` <34bf53f0-7595-fd90-300d-41db10a43ece-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-03 10:11                                           ` Daniel P. Berrange
2017-02-03 11:36                                             ` Maxime Coquelin
2017-02-02 16:47             ` Laine Stump
2017-02-02 17:09               ` Michael S. Tsirkin
     [not found]                 ` <20170202190811-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-02-02 17:13                   ` Daniel P. Berrange [this message]
2017-02-02 17:16                 ` Maxime Coquelin
2017-02-03  9:12                   ` Michal Privoznik
     [not found]                     ` <3ca28dd9-140b-85c2-2040-b1397b3ea254-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-03 17:40                       ` Laine Stump
2017-02-03 14:11 ` Maxime Coquelin
     [not found]   ` <4cad5796-7024-4a48-a73a-8dd780259968-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-03 15:34     ` Michael S. Tsirkin
2017-02-03 15:54       ` Daniel P. Berrange
2017-02-03 16:10         ` Michael S. Tsirkin
2017-02-03 17:22       ` Maxime Coquelin

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=20170202171357.GV2915@redhat.com \
    --to=berrange-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
    --cc=diproiettod-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org \
    --cc=fleitner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=maxime.coquelin-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=mprivozn-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.