[libvirt-users] Problem with net-define using Open vSwitch bridge

[Will Dennis]

(Replies inlined as requested...)

> libvirtd is running as root, so that should be plenty of permissions.
I assume you can run /usr/local/bin/ovs-vsctl from a root shell,
correct?

Yes.

> Does your system have AppArmor or SELinux installed? Anything in their
logs that could indicate the reason for the denial? Anybody else have an
idea?

Have AppArmor, no SELinux. I did a status on the AppArmor, and I see
that libvirtd was in 'enforce' mode:

# apparmor_status
apparmor module is loaded.
6 profiles are loaded.
6 profiles are in enforce mode.
   /sbin/dhclient
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/libvirt/virt-aa-helper
   /usr/sbin/libvirtd
   /usr/sbin/tcpdump
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/libvirtd (6941)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

So I changed the mode across the board to 'complain':

# aa-complain /etc/apparmor.d/*
Setting /etc/apparmor.d/sbin.dhclient to complain mode.
Setting /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper to complain mode.
Setting /etc/apparmor.d/usr.sbin.libvirtd to complain mode.
Setting /etc/apparmor.d/usr.sbin.rsyslogd to complain mode.
Setting /etc/apparmor.d/usr.sbin.tcpdump to complain mode.

# apparmor_status
apparmor module is loaded.
7 profiles are loaded.
0 profiles are in enforce mode.
7 profiles are in complain mode.
   /sbin/dhclient
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/libvirt/virt-aa-helper
   /usr/sbin/libvirtd
   /usr/sbin/rsyslogd
   /usr/sbin/tcpdump
2 processes have profiles defined.
0 processes are in enforce mode.
1 processes are in complain mode.
   /usr/sbin/libvirtd (6941)
1 processes are unconfined but have a profile defined.
   /usr/sbin/rsyslogd (815)

And then virt-manager could indeed attach the VM nic to the defined
network! (used "10-net" on this one, which corresponds to the
"vl10-ovsbr0" fake bridge):

# /usr/local/bin/ovs-vsctl show
3e0d861b-efb7-46b1-af1b-4a76cd833558
    Bridge "ovsbr0"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vnet0"	<<<<<<<<<<<
            tag: 10		<<<<<<<<<<<
            Interface "vnet0"
        Port "vl10-ovsbr0"
            tag: 10
            Interface "vl10-ovsbr0"
                type: internal
        Port "vl20-ovsbr0"
            tag: 20
            Interface "vl20-ovsbr0"
                type: internal

Yay.

>> The reason I want to use OVS "fake bridges" is to keep it simple for 
>> the team that will be using this virtualization server. If they just 
>> select the correct libvirt network (which is tied to the OVS "fake 
>> bridge") then the ports will be automatically tagged with the correct

>> VLAN. (I think of OVS fake bridges as something akin to VMware "Port 
>> Groups" on an OVS level.)  I have defined libvirt networks as
detailed 
>> in Kyle's blogpost you referenced, but there does not seem to be a
way 
>> in the virt-manager UI to select the desired portgroup as defined in 
>> the network XML. (Yes, you can edit the VM's XML config and hack the 
>> portgroup into there, but that's not what I want these users to have 
>> to do...)
>
> Sigh.
>
> Yes, setting up a portgroup in the network definition for each vlan,
then telling the users to select the proper portgroup would be the right
way to do what you want, 
> but unfortunately there has been little active development to support
new libvirt features in virt-manager for "awhile" now, and the addition
of portgroups to libvirt 
> has happened in the meantime.
>
> If you're familiar with python and would like to add support for that,
I'm sure virt-manager would *gladly* accept a patch. Otherwise,
hopefully there will be some new 
> blood in virt-manager, and they'll think this is a good request to
take on.

Sadly I have (very) little python-fu, so no doubt am unqualified to try
to patch virt-manager at this point... (Hopefully someday when I have
more time to dive into Python!)
It would be a great thing to add to the virt-manager UI, IMHO... Is
there a separate list for virt-manager (or is virt-manager, virt-viewer,
etc. devel discussed here?)

Thanks again for your guidance, Laine - community rocks!

Best,
Will