On 02/03/2017 04:12 AM, Michal Privoznik wrote:
On 02/02/2017 06:16 PM, Maxime Coquelin wrote:
On 02/02/2017 06:09 PM, 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?
I think it could be possible to query the MTU value from the OVS DB
using its JSON RPC-like API, but this is something I haven't tried.
I guess it would need to resolve the ovs interface from the vhost-user
socket path.
Can people familiar with OVS confirm this is something possible?
Libvirt does not use OVS' JSON RPC yet (it'll be long way to go anyway).
Therefore, for any OVS interaction it uses ovs-vsctl directly. Therefore:
ovs-vsctl get Interface ovsbr0 mtu
is what Laine is looking for. However, something fishy is happening here:
lisa ~ # ovs-vsctl set Interface ovsbr0 mtu=9000
lisa ~ # ovs-vsctl get Interface ovsbr0 mtu
1500
lisa ~ # ifconfig ovsbr0 mtu 9000
lisa ~ # ovs-vsctl get Interface ovsbr0 mtu
9000
(yes, Lisa Simpson)
But since we just want to query the bridge's MTU and not set it, we
should be safe.
Except that (as I just noted in the BZ) libvirt doesn't know the name of
the bridge in the case of vhost-user. It only knows the name of the
socket. So maybe in this case the only solution is for Nova (which
*does* know about the bridge) needs to query the MTU and populate
libvirt's XML appropriately.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
