(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