On Tue, Nov 29, 2011 at 05:44:23PM +0000, Daniel P. Berrange wrote:
On Tue, Nov 29, 2011 at 11:18:42AM -0600, Adam Litke wrote:
On Tue, Nov 29, 2011 at 04:50:19PM +0000, Daniel P. Berrange wrote:
On Tue, Nov 29, 2011 at 10:29:41AM -0600, Adam Litke wrote:
After discussing MOM / VDSM integration at length, two different strategies have emerged. I will call them Plan A and Plan B:
Plan A: MOM integration at the OS/Packaging level Plan B: MOM integration as a new VDSM thread
This RFC is about Plan A. I will start another thread to discuss Plan B once I have properly prototyped the idea in code.
Integration VDSM and MOM at the OS level is by far the simpler and least intrusive option. As you can see from the included patch, the changes to vdsm are very limited. In this model, VDSM interacts with MOM in the same way as it uses libvirt. Upon installation, VDSM installs its own MOM configuration file and restarts the MOM daemon (which continues to exist as an independent system-level daemon). Once restarted, MOM will load its policy from the VDSM configuration directory.
Pros:
- Simple and unobtrusive to either MOM or VDSM
- Clean API with no duplication or layering
- Maintain flexibility to tighten integration in the future
Cons:
- Momd runs as root (like supervdsm)
- If MOM will consume VDSM APIs, it must use the slower xmlrpc interface
I curious about the 'runs as root' bit. By listing it as a Con here, you imply that if it were a VDSM thread, it could run as non-root ? What is it that Momd has todo that requires root when run outside of VDSM, yet is not a problem when inside VDSM ? IOW can it not be made to run as 'momd' user/group when standalone ?
Very good questions -- thanks for raising them. I've listed it as a con because others have raised it as a concern. MOM runs as root for a few reasons: to connect to the qemu:///system libvirt URI, to connect to guest agent sockets, and (most difficult to mitigate) to reconfigure KSM via sysfs. As MOMs Controllers expand in functionality the need to root access will increase.
FWIW, connecitng to qemu:///system does not require root. Traditionally VDSM configures SASL, so all that would be required is to create a SASL username and password for Momd. Alternatively if the default policykit auth is in effect for libvirtd, the mom RPM could simply drop a policy file into the right location to allow processes under the 'momd' UNIX user to connect.
Yep. I've already got a patch for MOM to use SASL for libvirt connections.
I don't have a clear answer for the KSM thing & other tunables momd might need to deal with. There is perhaps a gap here for a system tunable daemon to provide an RPC service over DBus, which momd then uses to change sysfs tunables. Or something...
At the end of the day We have to let something be root, why not MOMd? It is already slim and narrowly focused on stats collection and response. Introducing yet another daemon just adds complexity and requires us to change more components each time we want to do something. A "generic" tunable daemon would likely not be part of oVirt and would not adhere to our release cadence; thus decreasing our ability to add new functionality.
The way vdsm works around this problem is that it spawns a 'supervdsm' process that has root privileges. To make MOM work from within a VDSM thread, all root-requiring operations must be routed through the supervdsm API. In my opinion, this is far from optimal and causes the MOM Controller API to become unnecessarily layered. It also peppers the vdsm codebase with bits of privileged code. Over time, this will become increasingly difficult to manage.
Yeah, I think that is really sub-optimal from the security POV, because both VDSM & supervdsm cover a very broad range of functionality so it will be hard to offer a meaningful level of security policy acround them, as compared to a dedicated Momd daemon.
IMHO, having a Momd that is a separate process from VDSM is pretty desirable from the security POV. It is much more practical to write a strict SELinux security policy for a fairly self-contained set of functionality like Momd, than to write a policy for the very broad functionality of VDSM as a whole.
I agree with this...
Also, if Momd is separate, and talking to libvirt at all, then we will also be able to take advantage of libvirt's future RBAC controls, to strictly limit what changes Momd can do down to the fine level of individual guests or groups of guests. eg you'll be able to write SELinux policy that allows a process of type 'momd_t' to only perform libvirt operations X & Y, against guests labelled "svirt_BLAH_t" while allowing operations X, Y & Z against guest labelled with "svirt_FOO_t".
... and this. Additionally, when running standalone, MOM can focus on being a system tuning mechanism. Some tuning and stats collection will necessarily go through the VDSM API but some will not need to. I think Plan A represents the UNIX model of orchestrating small components together to perform complex tasks.
-- Adam Litke agl@us.ibm.com IBM Linux Technology Center
-- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|