Libvirt Sandbox: Quick Start Guide

Interactive/batch Commands

The virt-sandbox command is used to dynamically create sandboxes for running interactive / batch commands.

• The libvirt guest is created when the virt-sandbox command starts
• The libvirt guest is automatically deleted when the virt-sandbox command completes, or dies from a signal
• The sandboxed command sees a read-only view of the entire host filesystem
• Specific areas can be made writable by mapping in an alternative host directory
• There is no network access inside the sandbox by default
• Virtual network interfaces can be associated with libvirt virtual networks
• The stdin/stdout/stderr file handles of the sandbox command will be connected to the controlling terminal.

The virt-sandbox support multiple virtualization drivers, so a URI should be specified when running them to choose the techology to use

• lxc:/// – valid if the calling user is root
• qemu:///session – valid if the calling user is non-root
• qemu:///system – valid if the calling user is root. NB there are some current known issues with this driver which temporarily prevent its use

Sandboxes can be used to run interactive commands, such as shells

# virt-sandbox -c lxc:/// /bin/sh

Or output-only commands

# virt-sandbox -c qemu:///session /bin/cat /proc/cpuinfo

System service sandboxes

The virt-sandbox-service command is used to provision libvirt guests configured to run system services.

• The libvirt guest config is defined by the ‘virt-sandbox-service create’ command
• The libvirt guest config is deleted by the ‘virt-sandbox-service delete’ command
• For systemd services, the libvirt guest is started/stopped by the ‘systemctl’ command
• For non-systemd services, the lbivirt guest is started/stopped by the “virsh” command
• For systemd services, certain areas of the /etc & /var directories will be made writable according to the RPM file list
• There is no network access inside the sandbox by default
• Virtual network interfaces can be associated with libvirt virtual networks
• The stdin file handle of the sandboxed service will be connected to /dev/null
• The stdout/stderr file handle of the sandboxed service will be directed into the systemd service log

The virt-sandbox-service command is only usable by the root user and currently only supports the lxc:/// libvirt driver URI. Support for KVM is deferred to a future release.

Systemd service sandbox lifecycle

The first step is to create a sandbox based on an existing systemd service, in this case, Apache. It will be connected to a libvirt virtual network called lan (which must be pre-configured by the admin).

# virt-sandbox-service create --clone --network dhcp,source=lan --unitfile httpd.service myhttpd

Starting of the sandbox should normally be done with the systemctl command

# systemctl start myhttpd_sandbox.service

To view the startup status, again the systemctl command can be used

# systemctl status myhttpd_sandbox.service

To perform admin tasks, a shell can be opened inside the sandbox

# virt-sandbox-service execute myhttpd -- /bin/sh

Or non-interactive commands can be directly executed

# virt-sandbox-service execute myhttpd -- /bin/apachectl graceful

To stop the sandbox, but leave its config defined in libvirt

# systemctl stop myhttpd_sandbox.service

To view all running sandboxes (and other containers) on the host

# virsh -c lxc:/// list

To view inactive sandboxes on the host

# virsh -c lxc:/// list --inactive

To monitor the performance of running sandboxes

# virt-top -c lxc:///

Since the virt-sandbox-service command defines a persistent libvirt guest config, many other virsh commands can also be used to manage the sandbox. While it is possible to edit the guest XML configuration with virsh this is discouraged, since changes will be lost if the admin later runs virt-sandbox-service upgrade.