Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt
提交 7f2b173f 编写于 作者: D Daniel P. Berrange
浏览文件
操作

Improve cgroups docs to cover systemd integration 

As of libvirt 1.1.1 and systemd 205, the cgroups layout used by
libvirt has some changes. Update the 'cgroups.html' file from
the website to describe how it works in a systemd world.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
上级 5087a5a0
隐藏空白更改
内联 并排
Showing with 172 addition and 40 deletion
docs/cgroups.html.in
浏览文件 @ 7f2b173f
...@@ -47,17 +47,121 @@ ...@@ -47,17 +47,121 @@
<p> <p>
As of libvirt 1.0.5 or later, the cgroups layout created by libvirt has been As of libvirt 1.0.5 or later, the cgroups layout created by libvirt has been
simplified, in order to facilitate the setup of resource control policies by simplified, in order to facilitate the setup of resource control policies by
administrators / management applications. The layout is based on the concepts of administrators / management applications. The new layout is based on the concepts
"partitions" and "consumers". Each virtual machine or container is a consumer, of "partitions" and "consumers". A "consumer" is a cgroup which holds the
and has a corresponding cgroup named <code>$VMNAME.libvirt-{qemu,lxc}</code>. processes for a single virtual machine or container. A "partition" is a cgroup
Each consumer is associated with exactly one partition, which also have a which does not contain any processes, but can have resource controls applied.
corresponding cgroup usually named <code>$PARTNAME.partition</code>. The A "partition" will have zero or more child directories which may be either
exceptions to this naming rule are the three top level default partitions, "consumer" or "partition".
named <code>/system</code> (for system services), <code>/user</code> (for </p>
user login sessions) and <code>/machine</code> (for virtual machines and
containers). By default every consumer will of course be associated with <p>
the <code>/machine</code> partition. This leads to a hierarchy that looks As of libvirt 1.1.1 or later, the cgroups layout will have some slight
like differences when running on a host with systemd 205 or later. The overall
tree structure is the same, but there are some differences in the naming
conventions for the cgroup directories. Thus the following docs split
in two, one describing systemd hosts and the other non-systemd hosts.
</p>
<h3><a name="currentLayoutSystemd">Systemd cgroups integration</a></h3>
<p>
On hosts which use systemd, each consumer maps to a systemd scope unit,
while partitions map to a system slice unit.
</p>
<h4><a name="systemdScope">Systemd scope naming</a></h4>
<p>
The systemd convention is for the scope name of virtual machines / containers
to be of the general format <code>machine-$NAME.scope</code>. Libvirt forms the
<code>$NAME</code> part of this by concatenating the driver type with the name
of the guest, and then escaping any systemd reserved characters.
So for a guest <code>demo</code> running under the <code>lxc</code> driver,
we get a <code>$NAME</code> of <code>lxc-demo</code> which when escaped is
<code>lxc\x2ddemo</code>. So the complete scope name is <code>machine-lxc\x2ddemo.scope</code>.
The scope names map directly to the cgroup directory names.
</p>
<h4><a name="systemdSlice">Systemd slice naming</a></h4>
<p>
The systemd convention for slice naming is that a slice should include the
name of all of its parents prepended on its own name. So for a libvirt
partition <code>/machine/engineering/testing</code>, the slice name will
be <code>machine-engineering-testing.slice</code>. Again the slice names
map directly to the cgroup directory names. Systemd creates three top level
slices by default, <code>system.slice</code> <code>user.slice</code> and
<code>machine.slice</code>. All virtual machines or containers created
by libvirt will be associated with <code>machine.slice</code> by default.
</p>
<h4><a name="systemdLayout">Systemd cgroup layout</a></h4>
<p>
Given this, a possible systemd cgroups layout involving 3 qemu guests,
3 lxc containers and 3 custom child slices, would be:
</p>
<pre>
$ROOT
|
+- system.slice
| |
| +- libvirtd.service
|
+- machine.slice
|
+- machine-qemu\x2dvm1.scope
| |
| +- emulator
| +- vcpu0
| +- vcpu1
|
+- machine-qemu\x2dvm2.scope
| |
| +- emulator
| +- vcpu0
| +- vcpu1
|
+- machine-qemu\x2dvm3.scope
| |
| +- emulator
| +- vcpu0
| +- vcpu1
|
+- machine-engineering.slice
| |
| +- machine-engineering-testing.slice
| | |
| | +- machine-lxc\x2dcontainer1.scope
| |
| +- machine-engineering-production.slice
| |
| +- machine-lxc\x2dcontainer2.scope
|
+- machine-marketing.slice
|
+- machine-lxc\x2dcontainer3.scope
</pre>
<h3><a name="currentLayoutGeneric">Non-systemd cgroups layout</a></h3>
<p>
On hosts which do not use systemd, each consumer has a corresponding cgroup
named <code>$VMNAME.libvirt-{qemu,lxc}</code>. Each consumer is associated
with exactly one partition, which also have a corresponding cgroup usually
named <code>$PARTNAME.partition</code>. The exceptions to this naming rule
are the three top level default partitions, named <code>/system</code> (for
system services), <code>/user</code> (for user login sessions) and
<code>/machine</code> (for virtual machines and containers). By default
every consumer will of course be associated with the <code>/machine</code>
partition.
</p>
<p>
Given this, a possible systemd cgroups layout involving 3 qemu guests,
3 lxc containers and 2 custom child slices, would be:
</p> </p>
<pre> <pre>
...@@ -87,23 +191,21 @@ $ROOT ...@@ -87,23 +191,21 @@ $ROOT
| +- vcpu0 | +- vcpu0
| +- vcpu1 | +- vcpu1
| |
+- container1.libvirt-lxc +- engineering.partition
| | |
+- container2.libvirt-lxc | +- testing.partition
| | |
| | +- container1.libvirt-lxc
| |
| +- production.partition
| |
| +- container2.libvirt-lxc
| |
+- container3.libvirt-lxc +- marketing.partition
|
+- container3.libvirt-lxc
</pre> </pre>
<p>
The default cgroups layout ensures that, when there is contention for
CPU time, it is shared equally between system services, user sessions
and virtual machines / containers. This prevents virtual machines from
locking the administrator out of the host, or impacting execution of
system services. Conversely, when there is no contention from
system services / user sessions, it is possible for virtual machines
to fully utilize the host CPUs.
</p>
<h2><a name="customPartiton">Using custom partitions</a></h2> <h2><a name="customPartiton">Using custom partitions</a></h2>
<p> <p>
...@@ -126,13 +228,55 @@ $ROOT ...@@ -126,13 +228,55 @@ $ROOT
... ...
</pre> </pre>
<p>
Note that the partition names in the guest XML are using a
generic naming format, not the low level naming convention
required by the underlying host OS. That is, you should not include
any of the <code>.partition</code> or <code>.slice</code>
suffixes in the XML config. Given a partition name
<code>/machine/production</code>, libvirt will automatically
apply the platform specific translation required to get
<code>/machine/production.partition</code> (non-systemd)
or <code>/machine.slice/machine-production.slice</code>
(systemd) as the underlying cgroup name
</p>
<p> <p>
Libvirt will not auto-create the cgroups directory to back Libvirt will not auto-create the cgroups directory to back
this partition. In the future, libvirt / virsh will provide this partition. In the future, libvirt / virsh will provide
APIs / commands to create custom partitions, but currently APIs / commands to create custom partitions, but currently
this is left as an exercise for the administrator. For this is left as an exercise for the administrator.
example, given the XML config above, the admin would need </p>
to create a cgroup named '/machine/production.partition'
<p>
<strong>Note:</strong> the ability to place guests in custom
partitions is only available with libvirt &gt;= 1.0.5, using
the new cgroup layout. The legacy cgroups layout described
later in this document did not support customization per guest.
</p>
<h3><a name="createSystemd">Creating custom partitions (systemd)</a></h3>
<p>
Given the XML config above, the admin on a systemd based host would
need to create a unit file <code>/etc/systemd/system/machine-production.slice</code>
</p>
<pre>
# cat &gt; /etc/systemd/system/machine-testing.slice &lt;&lt;EOF
[Unit]
Description=VM testing slice
Before=slices.target
Wants=machine.slice
EOF
# systemctl start machine-testing.slice
</pre>
<h3><a name="createNonSystemd">Creating custom partitions (non-systemd)</a></h3>
<p>
Given the XML config above, the admin on a non-systemd based host
would need to create a cgroup named '/machine/production.partition'
</p> </p>
<pre> <pre>
...@@ -147,18 +291,6 @@ $ROOT ...@@ -147,18 +291,6 @@ $ROOT
done done
</pre> </pre>
<p>
<strong>Note:</strong> the cgroups directory created as a ".partition"
suffix, but the XML config does not require this suffix.
</p>
<p>
<strong>Note:</strong> the ability to place guests in custom
partitions is only available with libvirt &gt;= 1.0.5, using
the new cgroup layout. The legacy cgroups layout described
later did not support customization per guest.
</p>
<h2><a name="resourceAPIs">Resource management APIs/commands</a></h2> <h2><a name="resourceAPIs">Resource management APIs/commands</a></h2>
<p> <p>
......
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或