Post on persisting resource control options for containers.

1 files changed, 76 insertions, 0 deletions

diff --git a/content/devops/nspawn_resource_control.rst b/content/devops/nspawn_resource_control.rst
new file mode 100644
index 0000000..eff33fe
--- /dev/null
+++ b/content/devops/nspawn_resource_control.rst
@@ -0,0 +1,76 @@
+Persisting resource control options for systemd-nspawn containers
+#################################################################
+
+:date: 2015-12-15 20:30
+:slug: persist_resource_control
+:author: copyninja
+:tags: systemd, systemd-nspawn, resource-control, containers
+:summary: Steps to persist the resource control options for
+	  systemd-nspawn containers.
+
+In my previous `post on systemd-nspawn
+<https://copyninja.info/blog/taming_systemd_nsapwn.html>`_ I
+mentioned, I was unclear on how to persist resource control options
+for a container.  Today I accidentally discovered how can the property
+be persisted across boot without modifying service file or writing
+custom service file for container. It is done using *systemctl
+set-property*
+
+To set *CPUAccounting* and *CPUShares* for a container we need to run
+following command.
+
+.. code-block:: shell
+
+   systemctl set-property systemd-nspawn@container.service  CPUACCounting=1 CPUShares=200
+
+This actually persists these settings at location,
+*/etc/systemd/systemd-nspawn@container.service.d/* folder. So in our
+case there will be 2 files created under above location by name
+*50-CPUAccounting.conf* and *50-CPUShares.conf* with following
+contents.
+
+.. code-block:: ini
+
+   # 50-CPUAccounting.conf
+   [Service]
+   CPUAccounting=yes
+
+   # 50-CPUShares.conf
+   [Service]
+   CPUShares=200
+
+Today when I discovered this folder and saw the file contents, I
+became curious and started to wonder who created this folder. The look
+at systemctl man page made showed me this.
+
+       set-property NAME ASSIGNMENT...
+           Set the specified unit properties at runtime where this is
+           supported. This allows changing configuration parameter
+           properties such as resource control settings at
+           runtime. Not all properties may be changed at runtime, but
+           many resource control settings (primarily those in
+           systemd.resource-control(5)) may. The changes are applied
+           instantly, and stored on disk for future boots,
+           unless --runtime is passed, in which case the settings only
+           apply until the next reboot. The syntax of the property
+           assignment follows closely the syntax of assignments in
+           unit files.
+
+           Example: systemctl set-property foobar.service CPUShares=777
+
+           Note that this command allows changing multiple properties
+           at the same time, which is preferable over setting them
+           individually. Like unit file configuration settings,
+           assigning the empty list to list parameters will reset the
+           list.
+
+I did remember doing this for my container and hence it became clear
+these files are actually written by *systemctl set-property* (Though
+there is no indication in man page on where actually these changes are
+stored in disk).
+
+In case you don't want to persist the properties across boot you can
+simply pass *--runtime* switch.
+
+Basically this is not just for container, resource control can be thus
+applied to any running service on the system. This is actually cool.