[libvirt] [PATCH 1 of 2] Add internal cgroup manipulation functions
danms at us.ibm.com
Tue Sep 30 20:34:42 UTC 2008
DB> My thought on the overall design of this internal API is that it
DB> is too low level & pushing too much work to the caller. eg, the
DB> caller would have to lookup virCGroupPtr objects for each
DB> controller it cares about,
Well, that's not what I had in mind, actually.
DB> and has to remember the tunables & their data types.
Not pushing the actual value names up to the caller is a reasonable
abstraction, I suppose. It seems like in the future QEMU may want to
use one type of memory limit, where LXC wants another. I can see LXC
domains having multiple memory limits (soft, hard, per process, per
group, etc) where those might not be meaningful to QEMU domains.
DB> While this kind of interface is applicable for a general purpose
DB> API, libvirt's needs are not general purpose. While LXC driver is
DB> the only current user, as more controllers are added I anticipate
DB> that QEMU driver might use cgroups, eg for I/O controls and CPU
DB> schedular controls
DB> As such I'd expect an API to be at a slightly higher level of
DB> abstraction, strongly typed and a single cgroup object associated
DB> with a domain object.
DB> virDomainObjPtr dom = ...driver's internal domain object...
DB> virCGroupPtr cg = virCGroupNew(dom);
DB> # Set domain memory limit to 1 GB
DB> virCGroupSetMemory(cg, 1024 * 1024 * 1024);
DB> # Remove all device permissions
DB> # Allow access to /dev/null device
DB> virCGroupAllowDevice(cg, 3, 1)
DB> Some of the existing APIs could be made static since they'd be
DB> needed anyway, but some could be re-design to be tailored to
DB> the semantics we want.
Okay, I'll reswizzle it and re-post.
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the libvir-list