(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