Bug 1459436 - Conclude on the openvswitch permission changes for dpdkvhostuserclient type
Summary: Conclude on the openvswitch permission changes for dpdkvhostuserclient type
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ga
: 12.0 (Pike)
Assignee: Emilien Macchi
QA Contact: Yariv
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-07 07:13 UTC by Saravanan KR
Modified: 2018-02-05 19:07 UTC (History)
13 users (show)

Fixed In Version: openstack-tripleo-heat-templates-7.0.0-0.20170821194253.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-13 21:31:55 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 478163 0 None None None 2017-07-03 07:01:28 UTC
Red Hat Product Errata RHEA-2017:3462 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 12.0 Enhancement Advisory 2018-02-16 01:43:25 UTC

Description Saravanan KR 2017-06-07 07:13:38 UTC
As per the dicussion on BZ https://bugzilla.redhat.com/show_bug.cgi?id=1431556#c24 with neutron, openvswitch and os teams, it has been agreed that we create a new directory for hosting vhost sockets for type dpdkvhostuserclient mode (which is default from OSP11 onwards).

The new directory created is "/var/lib/vhost_sockets/" with qemu:qemu permission and the corresponding SELinux policies are added so that virt can access it. 

But even with this change, we need to openvswitch permission workarounds in the ovs-vswitchd service files, below ones:

              if [ -f /usr/lib/systemd/system/openvswitch-nonetwork.service ]; then
                ovs_service_path="/usr/lib/systemd/system/openvswitch-nonetwork.service"
              elif [ -f /usr/lib/systemd/system/ovs-vswitchd.service ]; then
                ovs_service_path="/usr/lib/systemd/system/ovs-vswitchd.service"
              fi
              grep -q "RuntimeDirectoryMode=.*" $ovs_service_path
              if [ "$?" -eq 0 ]; then
                sed -i 's/RuntimeDirectoryMode=.*/RuntimeDirectoryMode=0775/' $ovs_service_path
              else
                echo "RuntimeDirectoryMode=0775" >> $ovs_service_path
              fi
              grep -Fxq "Group=qemu" $ovs_service_path
              if [ ! "$?" -eq 0 ]; then
                echo "Group=qemu" >> $ovs_service_path
              fi
              grep -Fxq "UMask=0002" $ovs_service_path
              if [ ! "$?" -eq 0 ]; then
                echo "UMask=0002" >> $ovs_service_path
              fi
              ovs_ctl_path='/usr/share/openvswitch/scripts/ovs-ctl'
              grep -q "umask 0002 \&\& start_daemon \"\$OVS_VSWITCHD_PRIORITY\"" $ovs_ctl_path
              if [ ! "$?" -eq 0 ]; then
                sed -i 's/start_daemon \"\$OVS_VSWITCHD_PRIORITY.*/umask 0002 \&\& start_daemon \"$OVS_VSWITCHD_PRIORITY\" \"$OVS_VSWITCHD_WRAPPER\" \"$@\"/' $ovs_ctl_path
              fi



Raising this BZ to understand why it is still required and discuss on the alternatives.

Comment 1 Saravanan KR 2017-06-07 07:21:08 UTC
Alternatively, in the ODL deployments [1], instead of the new directory and ovs permission changes in the service file, the "user" and "group" values in the /etc/libvirt/qemu.conf[2] is set as "root".

This change works (tested by Tim Roznet with ODL). We would like to understand if the same can by used for neutron ml2 based ovs-dpdk deployments too, if there is no other implications.

[1] https://review.openstack.org/#/c/419648/19/extraconfig/pre_network/ovs_dpdk_config.yaml@71
[2] https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu.conf#L360

Comment 2 Michal Privoznik 2017-06-07 14:16:30 UTC
I'm not an openvswitch expert, but I think that is needed because giving qemu access is good but not enough. ovs has to have access too. We should probably ask some openvswitch developer.

Comment 3 Tim Rozet 2017-06-07 14:18:51 UTC
It should also work for neutron ovs agent dpdk.  I believe I tested it.

Comment 4 Karthik Sundaravel 2017-06-07 14:25:34 UTC
Michal,

Can you please throw some light on c#1 as well. we would like to understand if changing the permissions for user and group fields to root in /etc/libvirt/qemu.conf has other impacts ?

Comment 5 Michal Privoznik 2017-06-07 14:40:32 UTC
(In reply to Saravanan KR from comment #1)
> Alternatively, in the ODL deployments [1], instead of the new directory and
> ovs permission changes in the service file, the "user" and "group" values in
> the /etc/libvirt/qemu.conf[2] is set as "root".
> 

Setting user = group = "root" results in qemu processes running under root:root privileges. Of course qemu can then access whatever path. However, my understanding is that you don't want to run qemu with root privileges, therefore you have to either: a) set user & group variables to something else (e.g. qemu:qemu), or b) not set at all (defaults to qemu:qemu on RHEL).

Comment 6 Aaron Conole 2017-06-07 15:35:28 UTC
I've recently proposed a change to Open vSwitch upstream at:

  https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/333423.html

which makes ovs run with a group of hugetlbfs.  Perhaps we could settle on a group ID that they could share; we could then use that for as our DAC id?

Just throwing it out there.

Comment 10 Saravanan KR 2017-07-03 07:01:29 UTC
Patch create upstream.
https://review.openstack.org/#/c/478163/

Comment 17 errata-xmlrpc 2017-12-13 21:31:55 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:3462


Note You need to log in before you can comment on or make changes to this bug.