mirror of https://gitee.com/openkylin/libvirt.git
140 lines
3.9 KiB
HTML
140 lines
3.9 KiB
HTML
<html>
|
|
<body>
|
|
<h1>LXC container driver</h1>
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<h2><a name="project">Project Links</a></h2>
|
|
|
|
<ul>
|
|
<li>
|
|
The <a href="http://lxc.sourceforge.net/">LXC</a> Linux
|
|
container system
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Cgroups Requirements</h2>
|
|
|
|
<p>
|
|
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'. The /etc/cgconfig.conf & cgconfig
|
|
init service used to mount cgroups at host boot time. To manually
|
|
mount them use:
|
|
</p>
|
|
|
|
<pre>
|
|
# mount -t cgroup cgroup /dev/cgroup -o cpuacct,memory,devices,cpu,freezer,blkio
|
|
</pre>
|
|
|
|
<p>
|
|
NB, the blkio controller in some kernels will not allow creation of nested
|
|
sub-directories which will prevent correct operation of the libvirt LXC
|
|
driver. On such kernels, it may be necessary to unmount the blkio controller.
|
|
</p>
|
|
|
|
|
|
<h2>Environment setup for the container init</h2>
|
|
|
|
<p>
|
|
When the container "init" process is started, it will be given several useful
|
|
environment variables.
|
|
</p>
|
|
|
|
<dl>
|
|
<dt>LIBVIRT_LXC_NAME</dt>
|
|
<dd>The name assigned to the container by libvirt</dd>
|
|
<dt>LIBVIRT_LXC_UUID</dt>
|
|
<dd>The UUID assigned to the container by libvirt</dd>
|
|
<dt>LIBVIRT_LXC_CMDLINE</dt>
|
|
<dd>The unparsed command line arguments specified in the container configuration</dd>
|
|
</dl>
|
|
|
|
|
|
<h3>Example config version 1</h3>
|
|
<p></p>
|
|
<pre>
|
|
<domain type='lxc'>
|
|
<name>vm1</name>
|
|
<memory>500000</memory>
|
|
<os>
|
|
<type>exe</type>
|
|
<init>/bin/sh</init>
|
|
</os>
|
|
<vcpu>1</vcpu>
|
|
<clock offset='utc'/>
|
|
<on_poweroff>destroy</on_poweroff>
|
|
<on_reboot>restart</on_reboot>
|
|
<on_crash>destroy</on_crash>
|
|
<devices>
|
|
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
|
<interface type='network'>
|
|
<source network='default'/>
|
|
</interface>
|
|
<console type='pty' />
|
|
</devices>
|
|
</domain>
|
|
</pre>
|
|
|
|
<p>
|
|
In the <emulator> element, be sure you specify the correct path
|
|
to libvirt_lxc, if it does not live in /usr/libexec on your system.
|
|
</p>
|
|
|
|
<p>
|
|
The next example assumes there is a private root filesystem
|
|
(perhaps hand-crafted using busybox, or installed from media,
|
|
debootstrap, whatever) under /opt/vm-1-root:
|
|
</p>
|
|
<p></p>
|
|
<pre>
|
|
<domain type='lxc'>
|
|
<name>vm1</name>
|
|
<memory>32768</memory>
|
|
<os>
|
|
<type>exe</type>
|
|
<init>/init</init>
|
|
</os>
|
|
<vcpu>1</vcpu>
|
|
<clock offset='utc'/>
|
|
<on_poweroff>destroy</on_poweroff>
|
|
<on_reboot>restart</on_reboot>
|
|
<on_crash>destroy</on_crash>
|
|
<devices>
|
|
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
|
<filesystem type='mount'>
|
|
<source dir='/opt/vm-1-root'/>
|
|
<target dir='/'/>
|
|
</filesystem>
|
|
<interface type='network'>
|
|
<source network='default'/>
|
|
</interface>
|
|
<console type='pty' />
|
|
</devices>
|
|
</domain>
|
|
</pre>
|
|
|
|
<p>
|
|
In both cases, you can define and start a container using:</p>
|
|
<pre>
|
|
virsh --connect lxc:/// define v1.xml
|
|
virsh --connect lxc:/// start vm1
|
|
</pre>
|
|
and then get a console using:
|
|
<pre>
|
|
virsh --connect lxc:/// console vm1
|
|
</pre>
|
|
<p>Now doing 'ps -ef' will only show processes in the container, for
|
|
instance. You can undefine it using
|
|
</p>
|
|
<pre>
|
|
virsh --connect lxc:/// undefine vm1
|
|
</pre>
|
|
</body>
|
|
</html>
|