Quoting Daniel P. Berrange (berrange(a)redhat.com):
On Fri, Feb 18, 2011 at 03:48:29PM -0600, Serge E. Hallyn wrote:
> Quoting apevec(a)gmail.com (apevec(a)gmail.com):
> > From: Alan Pevec <apevec(a)redhat.com>
> =============================================
> # libvirt-cgred-wait
> start on starting libvirt-bin
> stop on started cgred or stopped cgred
>
> task
> normal exit 2
> script
> status cgred | grep -q "start/running" && exit 0
> start cgred || true
> sleep 3600
> end script
> =============================================
FYI, libvirt has no need for the cgred to be present / running, and
Absolutely. And so the above job ships with the libcgroup package,
not with libvirt.
indeed if you're not careful with the rules you create for cgred
it
could really mess things up by moving VM proceses to a different
cgroup behind libvirt's back.
Yes. And with the default rules, if libcgroup is installed *and*
if libvirt does not wait until libcgroup is configured at boot, then
VMs won't start up.
So when just libvirt is installed, the above job is not needed (and
not installed on the machine). When just libcgroup is installed, the
above job will be installed, but since it starts on 'starting libvirt',
it won't ever run if libvirt is not installed.
For cgroups integration, libvirt merely requires that something has
mounted the various cgroups controllers. The can be mounted in any
location, and with any combination of controllers. libvirtd will
detect what cgroups it is located in at startup, and create its
own cgroups below these points in the hierarchy.
Yup, I definately don't want to suggest that there is anything wrong
with what libvirt does.
On Fedora we do this with the 'cgconfig' init script which
more or
less just runs 'cgconfigparse -l /etc/cgconfig.conf' to mount the
bits
Right, and the above job just makes sure that the above has finished
before libvirt starts.
thanks,
-serge