On 05/14/2013 07:37 AM, Daniel P. Berrange wrote: > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> > > Update the LXC driver documentation to describe the way > containers are setup by default. Also describe the common > virsh commands for managing containers and a little about > the security. Placeholders for docs about configuring > containers still to be filled in. > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > --- > docs/drvlxc.html.in | 401 +++++++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 366 insertions(+), 35 deletions(-) > > -The libvirt LXC driver manages "Linux Containers". Containers are sets of processes > -with private namespaces which can (but don't always) look like separate machines, but > -do not have their own OS. Here are two example configurations. The first is a very > -light-weight "application container" which does not have its own root image. > +The libvirt LXC driver manages "Linux Containers". At their simplest, containers > +can just be thought of as a collection of processes, separated from the main > +host processes via a set of resource namespaces and constrained via control > +groups resource tunables. The libvirt LXC driver has no dependancy on the LXC s/dependancy/dependency/ > +userspace tools hosted on sourceforge.net. It directly utilizers the relevant s/utilizers/utilizes/ > +kernel features to build the container environment. This allows for sharing > +of many libvirt technologies across both the QEMU/KVM and LXC drivers. In > +particular sVirt for mandatory access control, auditing of operations, > +integration with control groups and many other features. > </p> > +<p> > +In order to control the resource usage of processes inside containers, the > +libvirt LXC driver requires that certain cgroups controllers are mounted on > +the host OS. The minimum required controllers are 'cpuacct', 'memory' and > +'devices', while recommended extra controllers are 'cpu', 'freezer' and > +'blkio'. Libvirt will not mount the cgroups filesystem itself, leaving > +this upto the init system to take care of. Systemd will do the right thing s/upto/up to/ > +in this repect, while for other init systems the <code>cgconfig</code> s/repect/respect/ > +In order to separate processes inside a container from those in the > +primary "host" OS environment, the libvirt LXC driver requires that > +certain kernel namespaces are compiled in. Libvirt currently requires > +the 'mount', 'ipc', 'pid', and 'uts' namespaces to be available. If > +separate network interfaces are desired, then the 'net' namespace is > +requird. In the near future, the 'user' namespace will optionally be s/requird/required/ > + > + > +<h3><a name="devnodes">Device nodes</a></h3> > + > +<p> > +The container init process will be started with <code>CAP_MKNOD</code> > +capability removed & blocked from re-acquiring it. As such it will s/&/and/ > + > +<p> > +In addition, for every console defined in the guest configuration, > +a symlink will be created from <code>/dev/ttyN</code> symlinked to > +the corresponding <code>/dev/pts/M</code> psuedo TTY device. The s/psuedo/pseudo/ > +The LXC driver is integrated with libvirt's auditing subsystem, which > +causes audit messages to be logged whenever there is an operation > +performed against a container which has impact on host resources. > +So for example, start/stop, device hotplug will all log audit messages > +providing details about what action occurred & any resources s/&/and/ > + > +<p> > +The <code>virsh lxc-enter-namespace</code> command can be used > +to enter the namespaces & security context of a container s/&/and/ > +<p> > +The <code>virt-top</code> command can be used to monitor the > +activity & resource utilization of all containers on a s/&/and/ ACK as corrected. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list