Announce: libvirt-sandbox “Dashti Margo” 0.6.0 release – an application sandbox toolkit
I pleased to announce the a new public release of libvirt-sandbox, version 0.6.0, is now available from:
http://sandbox.libvirt.org/download/
The packages are GPG signed with
Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
The libvirt-sandbox package provides an API layer on top of libvirt-gobject which facilitates the cration of application sandboxes using virtualization technology. An application sandbox is a virtual machine or container that runs a single application binary, directly from the host OS filesystem. In other words there is no separate guest operating system install to build or manage.
At this point in time libvirt-sandbox can create sandboxes using either LXC or KVM, and should in theory be extendable to any libvirt driver.
This release contains a mixture of new features and bugfixes.
The first major feature is the ability to provide block devices to sandboxes. Most of the time sandboxes only want/need filesystems, but there are some use cases where block devices are useful. For example, some applications (like databases) can directly use raw block devices for storage. Another one is where a tool actually wishes to be able to format filesystems and have this done inside the container. The complexity with exposing block devices is giving the sandbox tools a predictable path for accessing the device which does not change across hypervisors. To solve this, instead of allowing users of virt-sandbox to specify a block device name, they provide an opaque tag name. The block device is then made available at a path /dev/disk/by-tag/TAGNAME, which symlinks back to whatever hypervisor specific disk name was used.
The second major feature is the ability to provide a custom root filesystem for the sandbox. The original intent of the sandbox tool was that it provide an easy way to confine and execute applications that are installed on the host filesystem, so by default the host / filesystem is mapped to the sandbox / filesystem read-only. There are some use cases, however, where the user may wish to have a completely different root filesystem. For example, they may wish to execute applications from some separate disk image. So virt-sandbox now allows the user to map in a different root filesystem for the sandbox.
Both of these features were developed as part of a Google Summer of Code 2015 project which is aiming to enhance libvirt sandbox so that it is capable of executing images distributed by the Docker container image repository service. The motivation for this goes back to the original reason for creating the libvirt-sandbox project in the first place, which was to provide a hypervisor agnostic framework for sandboxing applications, as a higher level above the libvirt API. Once this is work is complete it’ll be possible to launch Docker images via libvirt QEMU, KVM or LXC, with no need for the Docker toolchain itself.
The detailed list of changes in this release is:
- API/ABI in-compatible change, soname increased
- Prevent use of virt-sandbox-service as non-root upfront
- Fix misc memory leaks
- Block SIGHUP from the dhclient binary to prevent accidental death if the controlling terminal is closed & reopened
- Add support for re-creating libvirt XML from sandbox config to facilitate upgrades
- Switch to standard gobject introspection autoconf macros
- Add ability to set filters on network interfaces
- Search /usr/lib instead of /lib for systemd unit files, as the former is the canonical location even when / and /usr are merged
- Only set SELinux labels on hosts that support SELinux
- Explicitly link to selinux, instead of relying on indirect linkage
- Update compiler warning flags
- Fix misc docs comments
- Don’t assume use of SELinux in virt-sandbox-service
- Fix path checks for SUSE in virt-sandbox-service
- Add support for AppArmour profiles
- Mount /var after other FS to ensure host image is available
- Ensure state/config dirs can be accessed when QEMU is running non-root for qemu:///system
- Fix mounting of host images in QEMU sandboxes
- Mount images as ext4 instead of ext3
- Allow use of non-raw disk images as filesystem mounts
- Check if required static libs are available at configure time to prevent silent fallback to shared linking
- Require libvirt-glib >= 0.2.1
- Add support for loading lzma and gzip compressed kmods
- Check for support libvirt URIs when starting guests to ensure clear error message upfront
- Add LIBVIRT_SANDBOX_INIT_DEBUG env variable to allow debugging of kernel boot messages and sandbox init process setup
- Add support for exposing block devices to sandboxes with a predictable name under /dev/disk/by-tag/TAGNAME
- Use devtmpfs instead of tmpfs for auto-populating /dev in QEMU sandboxes
- Allow setup of sandbox with custom root filesystem instead of inheriting from host’s root.
- Allow execution of apps from non-matched ld-linux.so / libc.so, eg executing F19 binaries on F22 host
- Use passthrough mode for all QEMU filesystems