- Devel - libvirt List Archives

[libvirt] [PATCH 0/8] Add qcow2 extensions support
by Ján Tomko 16 May '13

16 May '13

Since QEMU 1.1 qcow2 supports a features bitfield, allowing to implement additional features without breaking compatibility with older QEMU versions. The version header on-disk is bumped to 3, however the format name is still 'qcow2', not 'qcow3' (which is what I used in v2). v2: https://www.redhat.com/archives/libvir-list/2013-February/msg00212.html qcow2 vs. qcow3 discussion: https://www.redhat.com/archives/libvir-list/2013-March/msg00094.html Ján Tomko (8): storage: rework qemu-img command line generation tests: don't overwrite error in storage xml-to-argv test util: add support for qcow2v3 image detection conf: add features to volume target XML storage: add support for creating qcow2 images with extensions conf: split out snapshot disk XML formatting Add qcow2 features support to snapshots qemu: add qcow2 extension support to inactive external snapshots docs/formatsnapshot.html.in | 5 + docs/formatstorage.html.in | 19 +++ docs/schemas/Makefile.am | 1 + docs/schemas/domainsnapshot.rng | 7 + docs/schemas/storagefilefeatures.rng | 24 ++++ docs/schemas/storagevol.rng | 7 + libvirt.spec.in | 1 + mingw-libvirt.spec.in | 2 + src/conf/snapshot_conf.c | 127 ++++++++++++++---- src/conf/snapshot_conf.h | 2 + src/conf/storage_conf.c | 76 ++++++++++- src/conf/storage_conf.h | 6 +- src/libvirt_private.syms | 2 + src/qemu/qemu_driver.c | 72 +++++++--- src/storage/storage_backend.c | 143 +++++++++++++------- src/storage/storage_backend_fs.c | 10 ++ src/util/virstoragefile.c | 164 ++++++++++++++++++----- src/util/virstoragefile.h | 12 ++ tests/domainsnapshotxml2xmlin/disk_snapshot.xml | 5 + tests/domainsnapshotxml2xmlout/disk_snapshot.xml | 4 + tests/storagevolxml2argvdata/qcow2-1.1.argv | 1 + tests/storagevolxml2argvdata/qcow2-lazy.argv | 1 + tests/storagevolxml2argvdata/vol-qcow2-1.1.xml | 32 +++++ tests/storagevolxml2argvdata/vol-qcow2-lazy.xml | 35 +++++ tests/storagevolxml2argvtest.c | 6 +- tests/storagevolxml2xmlin/vol-qcow2-1.1.xml | 32 +++++ tests/storagevolxml2xmlin/vol-qcow2-lazy.xml | 35 +++++ tests/storagevolxml2xmlout/vol-qcow2-1.1.xml | 33 +++++ tests/storagevolxml2xmlout/vol-qcow2-lazy.xml | 35 +++++ tests/storagevolxml2xmltest.c | 2 + 30 files changed, 769 insertions(+), 132 deletions(-) create mode 100644 docs/schemas/storagefilefeatures.rng create mode 100644 tests/storagevolxml2argvdata/qcow2-1.1.argv create mode 100644 tests/storagevolxml2argvdata/qcow2-lazy.argv create mode 100644 tests/storagevolxml2argvdata/vol-qcow2-1.1.xml create mode 100644 tests/storagevolxml2argvdata/vol-qcow2-lazy.xml create mode 100644 tests/storagevolxml2xmlin/vol-qcow2-1.1.xml create mode 100644 tests/storagevolxml2xmlin/vol-qcow2-lazy.xml create mode 100644 tests/storagevolxml2xmlout/vol-qcow2-1.1.xml create mode 100644 tests/storagevolxml2xmlout/vol-qcow2-lazy.xml -- 1.8.1.5

1 8

[libvirt] [PATCH] util: Fix build without devmapper
by Jiri Denemark 16 May '13

16 May '13

stdlib.h header file needed for getenv was only transitively included through libdevmapper.h. --- Pushed as a trivial build-breaker. src/util/virutil.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/util/virutil.c b/src/util/virutil.c index ab3c82f..7f4ecd6 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -26,6 +26,7 @@ #include <config.h> +#include <stdlib.h> #include <dirent.h> #include <stdio.h> #include <stdarg.h> -- 1.8.2.1

1 0

[libvirt] [PATCH 0/3] Fix the build failure
by Osier Yang 16 May '13

16 May '13

As exposed by [1], qemuxml2argvtest fails because of it tries to access non-existing sysfs files when building qemu command for scsi-generic device. This creates "tests/sysfsroot", uses it as the fake sysfs root, any future sysfs test input files should be put into it. [1] https://www.redhat.com/archives/libvir-list/2013-May/msg00923.html Osier Yang (3): qemu: Allow to specify the sysfs root for qemuBuildCommandLine tests: Feed the fake sysfs root to qemuBuildCommandLine tests: Move fchostdata into sysfsroot src/qemu/qemu_cgroup.c | 3 +- src/qemu/qemu_command.c | 12 +++-- src/qemu/qemu_command.h | 6 ++- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_hostdev.c | 9 ++-- src/qemu/qemu_hotplug.c | 4 +- src/qemu/qemu_process.c | 3 +- src/security/security_dac.c | 6 ++- src/security/security_selinux.c | 6 ++- src/util/virscsi.c | 51 ++++++++++++++++++---- src/util/virscsi.h | 6 ++- tests/Makefile.am | 2 +- tests/fchostdata/fc_host/host4/fabric_name | 1 - tests/fchostdata/fc_host/host4/max_npiv_vports | 1 - tests/fchostdata/fc_host/host4/node_name | 1 - tests/fchostdata/fc_host/host4/npiv_vports_inuse | 1 - tests/fchostdata/fc_host/host4/port_name | 1 - tests/fchostdata/fc_host/host4/port_state | 1 - tests/fchostdata/fc_host/host4/vport_create | 0 tests/fchostdata/fc_host/host4/vport_delete | 0 tests/fchostdata/fc_host/host5/fabric_name | 1 - tests/fchostdata/fc_host/host5/max_npiv_vports | 1 - tests/fchostdata/fc_host/host5/node_name | 1 - tests/fchostdata/fc_host/host5/npiv_vports_inuse | 1 - tests/fchostdata/fc_host/host5/port_name | 1 - tests/fchostdata/fc_host/host5/port_state | 1 - tests/fchostdata/fc_host/host5/vport_create | 0 tests/fchostdata/fc_host/host5/vport_delete | 0 tests/fchosttest.c | 2 +- tests/qemuxml2argvtest.c | 5 ++- tests/qemuxmlnstest.c | 3 +- .../bus/scsi/devices/0:0:0:0/scsi_generic/sg0/dev | 1 + tests/sysfsroot/class/fc_host/host4/fabric_name | 1 + .../sysfsroot/class/fc_host/host4/max_npiv_vports | 1 + tests/sysfsroot/class/fc_host/host4/node_name | 1 + .../class/fc_host/host4/npiv_vports_inuse | 1 + tests/sysfsroot/class/fc_host/host4/port_name | 1 + tests/sysfsroot/class/fc_host/host4/port_state | 1 + tests/sysfsroot/class/fc_host/host4/vport_create | 0 tests/sysfsroot/class/fc_host/host4/vport_delete | 0 tests/sysfsroot/class/fc_host/host5/fabric_name | 1 + .../sysfsroot/class/fc_host/host5/max_npiv_vports | 1 + tests/sysfsroot/class/fc_host/host5/node_name | 1 + .../class/fc_host/host5/npiv_vports_inuse | 1 + tests/sysfsroot/class/fc_host/host5/port_name | 1 + tests/sysfsroot/class/fc_host/host5/port_state | 1 + tests/sysfsroot/class/fc_host/host5/vport_create | 0 tests/sysfsroot/class/fc_host/host5/vport_delete | 0 48 files changed, 101 insertions(+), 45 deletions(-) delete mode 100644 tests/fchostdata/fc_host/host4/fabric_name delete mode 100644 tests/fchostdata/fc_host/host4/max_npiv_vports delete mode 100644 tests/fchostdata/fc_host/host4/node_name delete mode 100644 tests/fchostdata/fc_host/host4/npiv_vports_inuse delete mode 100644 tests/fchostdata/fc_host/host4/port_name delete mode 100644 tests/fchostdata/fc_host/host4/port_state delete mode 100644 tests/fchostdata/fc_host/host4/vport_create delete mode 100644 tests/fchostdata/fc_host/host4/vport_delete delete mode 100644 tests/fchostdata/fc_host/host5/fabric_name delete mode 100644 tests/fchostdata/fc_host/host5/max_npiv_vports delete mode 100644 tests/fchostdata/fc_host/host5/node_name delete mode 100644 tests/fchostdata/fc_host/host5/npiv_vports_inuse delete mode 100644 tests/fchostdata/fc_host/host5/port_name delete mode 100644 tests/fchostdata/fc_host/host5/port_state delete mode 100644 tests/fchostdata/fc_host/host5/vport_create delete mode 100644 tests/fchostdata/fc_host/host5/vport_delete create mode 100644 tests/sysfsroot/bus/scsi/devices/0:0:0:0/scsi_generic/sg0/dev create mode 100644 tests/sysfsroot/class/fc_host/host4/fabric_name create mode 100644 tests/sysfsroot/class/fc_host/host4/max_npiv_vports create mode 100644 tests/sysfsroot/class/fc_host/host4/node_name create mode 100644 tests/sysfsroot/class/fc_host/host4/npiv_vports_inuse create mode 100644 tests/sysfsroot/class/fc_host/host4/port_name create mode 100644 tests/sysfsroot/class/fc_host/host4/port_state create mode 100644 tests/sysfsroot/class/fc_host/host4/vport_create create mode 100644 tests/sysfsroot/class/fc_host/host4/vport_delete create mode 100644 tests/sysfsroot/class/fc_host/host5/fabric_name create mode 100644 tests/sysfsroot/class/fc_host/host5/max_npiv_vports create mode 100644 tests/sysfsroot/class/fc_host/host5/node_name create mode 100644 tests/sysfsroot/class/fc_host/host5/npiv_vports_inuse create mode 100644 tests/sysfsroot/class/fc_host/host5/port_name create mode 100644 tests/sysfsroot/class/fc_host/host5/port_state create mode 100644 tests/sysfsroot/class/fc_host/host5/vport_create create mode 100644 tests/sysfsroot/class/fc_host/host5/vport_delete -- 1.8.1.4

4 13

[libvirt] [PATCH] Move VirtualBox driver into libvirtd
by Daniel P. Berrange 16 May '13

16 May '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Change the build process & driver initialization so that the VirtualBox driver is built into libvirtd, instead of libvirt.so This change avoids the VirtualBox GPLv2-only license causing compatibility problems with libvirt.so which is under the GPLv2-or-later license. NB this change prevents use of the VirtualBox driver on the Windows platform, until such time as libvirtd can be made to work there. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- daemon/libvirtd.c | 9 +++++++++ docs/drvvbox.html.in | 12 ++++++++++++ src/Makefile.am | 24 +++++++++++++++++++----- src/libvirt.c | 7 ------- 4 files changed, 40 insertions(+), 12 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 1ac8e30..abb46ca 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -73,6 +73,9 @@ # ifdef WITH_UML # include "uml/uml_driver.h" # endif +#ifdef WITH_VBOX +# include "vbox/vbox_driver.h" +#endif # ifdef WITH_NETWORK # include "network/bridge_driver.h" # endif @@ -400,6 +403,9 @@ static void daemonInitialize(void) # ifdef WITH_UML virDriverLoadModule("uml"); # endif +# ifdef WITH_UML + virDriverLoadModule("vbox"); +# endif #else # ifdef WITH_NETWORK networkRegister(); @@ -434,6 +440,9 @@ static void daemonInitialize(void) # ifdef WITH_UML umlRegister(); # endif +# ifdef WITH_VBOX + vboxRegister(); +# endif #endif } diff --git a/docs/drvvbox.html.in b/docs/drvvbox.html.in index d59da57..e2a213c 100644 --- a/docs/drvvbox.html.in +++ b/docs/drvvbox.html.in @@ -31,6 +31,18 @@ vbox+tcp://user@example.com/session (remote access, SASl/Kerberos) vbox+ssh://user@example.com/session (remote access, SSH tunnelled) </pre> + <p> + <strong>NOTE: as of libvirt 1.0.6, the VirtualBox driver will always + run inside the libvirtd daemon, instead of being built-in to the + libvirt.so library directly. This change was required due to the + fact that VirtualBox code is GPLv2-only licensed, which is not + compatible with the libvirt.so license of GPLv2-or-later. The + daemon will be auto-started when the first connection to VirtualBox + is requested. This change also means it is no longer possible to + use the VirtualBox on the Windows platform, which lacks support + for the libvirtd daemon.</strong> + </p> + <h2><a name="xmlconfig">Example domain XML config</a></h2> <pre> diff --git a/src/Makefile.am b/src/Makefile.am index 6c626ac..8f26181 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -957,12 +957,26 @@ libvirt_driver_vmware_la_SOURCES = $(VMWARE_DRIVER_SOURCES) endif if WITH_VBOX +noinst_LTLIBRARIES += libvirt_driver_vbox_impl.la +libvirt_driver_vbox_la_SOURCES = +libvirt_driver_vbox_la_LIBADD = libvirt_driver_vbox_impl.la +if WITH_DRIVER_MODULES +mod_LTLIBRARIES += libvirt_driver_vbox.la +libvirt_driver_vbox_la_LIBADD += ../gnulib/lib/libgnu.la +libvirt_driver_vbox_la_LDFLAGS = -module -avoid-version +else noinst_LTLIBRARIES += libvirt_driver_vbox.la -libvirt_la_BUILT_LIBADD += libvirt_driver_vbox.la -libvirt_driver_vbox_la_CFLAGS = \ - -I$(top_srcdir)/src/conf $(AM_CFLAGS) -libvirt_driver_vbox_la_LIBADD = $(DLOPEN_LIBS) $(MSCOM_LIBS) -libvirt_driver_vbox_la_SOURCES = $(VBOX_DRIVER_SOURCES) +# GPLv2-only license requries that it be linked into +# libvirtd and *not* libvirt.so +#libvirt_la_BUILT_LIBADD += libvirt_driver_xen.la +endif + +libvirt_driver_vbox_impl_la_CFLAGS = \ + -I$(top_srcdir)/src/conf \ + $(AM_CFLAGS) +libvirt_driver_vbox_impl_la_LDFLAGS = $(AM_LDFLAGS) +libvirt_driver_vbox_impl_la_LIBADD = $(DLOPEN_LIBS) $(MSCOM_LIBS) +libvirt_driver_vbox_impl_la_SOURCES = $(VBOX_DRIVER_SOURCES) endif if WITH_XENAPI diff --git a/src/libvirt.c b/src/libvirt.c index 2b3515e..d0ec10a 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -81,9 +81,6 @@ #ifdef WITH_PHYP # include "phyp/phyp_driver.h" #endif -#ifdef WITH_VBOX -# include "vbox/vbox_driver.h" -#endif #ifdef WITH_ESX # include "esx/esx_driver.h" #endif @@ -465,10 +462,6 @@ virGlobalInit(void) if (phypRegister() == -1) goto error; #endif -#ifdef WITH_VBOX - if (vboxRegister() == -1) - goto error; -#endif #ifdef WITH_ESX if (esxRegister() == -1) goto error; -- 1.8.2.1

4 3

[libvirt] [PATCH v2 00/12] Multiple TX queue support
by Michal Privoznik 16 May '13

16 May '13

Just a rebased version of [1]. Kernel and subsequently QEMU learned multiple transmit queues a while ago. The feature has a nice advantage, it allows a single guest to transmit multiple flows of network data using multiple CPUs simultaneously which increase traffic bandwidth. A lot. The documentation how to use this is available at [2] or [3]. 1: https://www.redhat.com/archives/libvir-list/2013-April/msg01548.html 2: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/Docume… 3: http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;hb=HEAD#l1363 Michal Privoznik (12): Introduce /domain/devices/interface/driver/@queues attribute qemu: Move interface cmd line construction into a separate function qemu: Make qemuMonitorAddHostNetwork to pass multiple FDs qemu: Make qemuMonitorAddHostNetwork to pass multiple FDs qemu: Adapt command line generation to multiqueue net util: Learn virNetDevTapCreate multiqueue network qemu: Allow multiple vhost-net openings qemu: Rework qemuNetworkIfaceConnect qemu: Adapt qemuDomainAttachNetDevice to multiqueue net qemu: Change qemuOpenVhostNet return value qemu: Adapt qemuBuildInterfaceCommandLine to to multiqueue net qemu: Enable multiqueue network docs/formatdomain.html.in | 11 +- docs/schemas/domaincommon.rng | 5 + src/conf/domain_conf.c | 15 + src/conf/domain_conf.h | 1 + src/network/bridge_driver.c | 2 +- src/qemu/qemu_command.c | 453 +++++++++++++-------- src/qemu/qemu_command.h | 13 +- src/qemu/qemu_domain.c | 27 +- src/qemu/qemu_hotplug.c | 99 +++-- src/qemu/qemu_monitor.c | 78 ++-- src/qemu/qemu_monitor.h | 8 +- src/uml/uml_conf.c | 5 +- src/util/virnetdevtap.c | 115 +++--- src/util/virnetdevtap.h | 2 + tests/qemuxml2argvdata/qemuxml2argv-event_idx.xml | 2 +- .../qemuxml2argv-net-virtio-device.xml | 2 +- .../qemuxml2argvdata/qemuxml2argv-vhost_queues.xml | 51 +++ tests/qemuxml2argvdata/qemuxml2argv-virtio-lun.xml | 2 +- tests/qemuxml2xmltest.c | 1 + 19 files changed, 586 insertions(+), 306 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhost_queues.xml -- 1.8.2.1

3 24

[libvirt] [PATCH]write separate module for hostdev passthrough
by Chunyan Liu 16 May '13

16 May '13

This patch sets include two patches: 1/2 is the implementation of the hostdev passthrough common library. To meet two purposes: a. move qemu hostdev APIs to common library so that it could be used by all hypervisor drivers. b. maintain a global hostdev in-use state. 2/2 is the implementation of pci passthrough to libxl driver. There should be more patches to change qemu driver and lxc driver codes to switch to common library APIs, but I think it's better to have you review the common library first. After common library APIs confirmed, then modify qemu/lxc driver codes in a time. The implementation to libxl driver (2/2) is an example of using common library. Please review, thanks! Chunyan Liu (2): add pci passthrough common library add pci passthrough impl to libxl po/POTFILES.in | 1 + src/Makefile.am | 1 + src/libvirt.c | 5 + src/libvirt_private.syms | 15 + src/libxl/libxl_conf.c | 44 ++ src/libxl/libxl_driver.c | 21 +- src/util/virhostdevmanager.c | 1218 ++++++++++++++++++++++++++++++++++++++++++ src/util/virhostdevmanager.h | 91 ++++ src/util/virpci.c | 17 +- src/util/virpci.h | 7 +- src/util/virusb.c | 19 +- src/util/virusb.h | 4 +- 12 files changed, 1426 insertions(+), 17 deletions(-) create mode 100644 src/util/virhostdevmanager.c create mode 100644 src/util/virhostdevmanager.h

1 2

[libvirt] [PATCH] Expand documentation for LXC driver
by Daniel P. Berrange 16 May '13

16 May '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Update the LXC driver documentation to describe the way containers are setup by default. Also describe the common virsh commands for managing containers and a little about the security. Placeholders for docs about configuring containers still to be filled in. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/drvlxc.html.in | 401 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 366 insertions(+), 35 deletions(-) diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index beff214..a745956 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -3,49 +3,100 @@ <html xmlns="http://www.w3.org/1999/xhtml"> <body> <h1>LXC container driver</h1> + + <ul id="toc"></ul> + <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. +The libvirt LXC driver manages "Linux Containers". At their simplest, containers +can just be thought of as a collection of processes, separated from the main +host processes via a set of resource namespaces and constrained via control +groups resource tunables. The libvirt LXC driver has no dependancy on the LXC +userspace tools hosted on sourceforge.net. It directly utilizers the relevant +kernel features to build the container environment. This allows for sharing +of many libvirt technologies across both the QEMU/KVM and LXC drivers. In +particular sVirt for mandatory access control, auditing of operations, +integration with control groups and many other features. </p> - <h2><a name="project">Project Links</a></h2> +<h2><a name="cgroups">Control groups Requirements</a></h2> - <ul> - <li> - The <a href="http://lxc.sourceforge.net/">LXC</a> Linux - container system - </li> - </ul> +<p> +In order to control the resource usage of processes inside containers, 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'. Libvirt will not mount the cgroups filesystem itself, leaving +this upto the init system to take care of. Systemd will do the right thing +in this repect, while for other init systems the <code>cgconfig</code> +init service will be required. For further information, consult the general +libvirt <a href="cgroups.html">cgroups documentation</a>. +</p> -<h2>Cgroups Requirements</h2> +<h2><a name="namespaces">Namespace requirements</a></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: +In order to separate processes inside a container from those in the +primary "host" OS environment, the libvirt LXC driver requires that +certain kernel namespaces are compiled in. Libvirt currently requires +the 'mount', 'ipc', 'pid', and 'uts' namespaces to be available. If +separate network interfaces are desired, then the 'net' namespace is +requird. In the near future, the 'user' namespace will optionally be +supported. </p> -<pre> - # mount -t cgroup cgroup /dev/cgroup -o cpuacct,memory,devices,cpu,freezer,blkio -</pre> +<p> +<strong>NOTE: In the absence of support for the 'user' namespace, +processes inside containers cannot be securely isolated from host +process without the use of a mandatory access control technology +such as SELinux or AppArmor.</strong> +</p> + +<h2><a name="init">Default container setup</a></h2> + +<h3><a name="cliargs">Command line arguments</a></h3> <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. +When the container "init" process is started, it will typically +not be given any command line arguments (eg the equivalent of +the bootloader args visible in <code>/proc/cmdline</code>). If +any arguments are desired, then must be explicitly set in the +container XML configuration via one or more <code>initarg</code> +elements. For example, to run <code>systemd --unit emergency.service</code> +would use the following XML </p> +<pre> + <os> + <type arch='x86_64'>exe</type> + <init>/bin/systemd</init> + <initarg>--unit</initarg> + <initarg>emergency.service</initarg> + </os> +</pre> -<h2>Environment setup for the container init</h2> +<h3><a name="envvars">Environment variables</a></h3> <p> When the container "init" process is started, it will be given several useful -environment variables. +environment variables. The following standard environment variables are mandated +by <a href="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">systemd container interface</a> +to be provided by all container technologies on Linux. +</p> + +<dl> +<dt>container</dt> +<dd>The fixed string <code>libvirt-lxc</code> to identify libvirt as the creator</dd> +<dt>container_uuid</dt> +<dd>The UUID assigned to the container by libvirt</dd> +<dt>PATH</dt> +<dd>The fixed string <code>/bin:/usr/bin</code></dd> +<dt>TERM</dt> +<dd>The fixed string <code>linux</code></dd> +</dl> + +<p> +In addition to the standard variables, the following libvirt specific +environment variables are also provided </p> <dl> @@ -54,9 +105,152 @@ environment variables. <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> +<dd>The unparsed command line arguments specified in the container configuration. +Use of this is discouraged, in favour of passing arguments directly to the +container init process via the <code>initarg</code> config element.</dd> </dl> +<h3><a name="fsmounts">Filesystem mounts</a></h3> + +<p> +In the absence of any explicit configuration, the container will +inherit the host OS filesystem mounts. A number of mount points will +be made read only, or re-mounted with new instances to provide +container specific data. The following special mounts are setup +by libvirt +</p> + +<ul> +<li><code>/dev</code> a new "tmpfs" pre-populated with authorized device nodes</li> +<li><code>/dev/pts</code> a new private "devpts" instance for console devices</li> +<li><code>/sys</code> the host "sysfs" instance remounted read-only</li> +<li><code>/proc</code> a new instance of the "proc" filesystem</li> +<li><code>/proc/sys</code> the host "/proc/sys" bind-mounted read-only</li> +<li><code>/sys/fs/selinux</code> the host "selinux" instance remounted read-only</li> +<li><code>/sys/fs/cgroup/NNNN</code> the host cgroups controllers bind-mounted to +only expose the sub-tree associated with the container</li> +<li><code>/proc/meminfo</code> a FUSE backed file reflecting memory limits of the container</li> +</ul> + + +<h3><a name="devnodes">Device nodes</a></h3> + +<p> +The container init process will be started with <code>CAP_MKNOD</code> +capability removed & blocked from re-acquiring it. As such it will +not be able to create any device nodes in <code>/dev</code> or anywhere +else in its filesystems. Libvirt itself will take care of pre-populating +the <code>/dev</code> filesystem with any devices that the container +is authorized to use. The current devices that will be made available +to all containers are +</p> + +<ul> +<li><code>/dev/zero</code></li> +<li><code>/dev/null</code></li> +<li><code>/dev/full</code></li> +<li><code>/dev/random</code></li> +<li><code>/dev/urandom</code></li> +<li><code>/dev/stdin</code> symlinked to <code>/proc/self/fd/0</code></li> +<li><code>/dev/stdout</code> symlinked to <code>/proc/self/fd/1</code></li> +<li><code>/dev/stderr</code> symlinked to <code>/proc/self/fd/2</code></li> +<li><code>/dev/fd</code> symlinked to <code>/proc/self/fd</code></li> +<li><code>/dev/ptmx</code> symlinked to <code>/dev/pts/ptmx</code></li> +<li><code>/dev/console</code> symlinked to <code>/dev/pts/0</code></li> +</ul> + +<p> +In addition, for every console defined in the guest configuration, +a symlink will be created from <code>/dev/ttyN</code> symlinked to +the corresponding <code>/dev/pts/M</code> psuedo TTY device. The +first console will be <code>/dev/tty1</code>, with further consoles +numbered incrementally from there. +</p> + +<p> +Further block or character devices will be made available to containers +depending on their configuration. +</p> + + + +<h2>Container security</h2> + +<h3>sVirt SELinux</h3> + +<p> +In the absence of the "user" namespace being used, containers cannot +be considered secure against exploits of the host OS. The sVirt SELinux +driver provides a way to secure containers even when the "user" namespace +is not used. The cost is that writing a policy to allow execution of +arbitrary OS is not practical. The SELinux sVirt policy is typically +tailored to work with an simpler application confinement use case, +as provided by the "libvirt-sandbox" project. +</p> + +<h3>Auditing</h3> + +<p> +The LXC driver is integrated with libvirt's auditing subsystem, which +causes audit messages to be logged whenever there is an operation +performed against a container which has impact on host resources. +So for example, start/stop, device hotplug will all log audit messages +providing details about what action occurred & any resources +associated with it. There are the following 3 types of audit messages +</p> + +<ul> +<li><code>VIRT_MACHINE_ID</code> - details of the SELinux process and +image security labels assigned to the container.</li> +<li><code>VIRT_CONTROL</code> - details of an action / operation +performed against a container. There are the following types of +operation + <ul> + <li><code>op=start</code> - a container has been started. Provides + the machine name, uuid and PID of the <code>libvirt_lxc</code> + controller process</li> + <li><code>op=init</code> - the init PID of the container has been + started. Provides the machine name, uuid and PID of the + <code>libvirt_lxc</code> controller process and PID of the + init process (in the host PID namespace)</li> + <li><code>op=stop</code> - a container has been stopped. Provides + the machine name, uuid</li> + </ul> +</li> +<li><code>VIRT_RESOURCE</code> - details of a host resource +associated with a container action.</li> +</ul> + +<h3>Device access</h3> + +<p> +All containers are launched with the CAP_MKNOD capability cleared +and removed from the bounding set. Libvirt will ensure that the +/dev filesystem is pre-populated with all devices that a container +is allowed to use. In addition, the cgroup "device" controller is +configured to block read/write/mknod from all devices except those +that a container is authorized to use. +</p> + +<h2><a name="exconfig">Example configurations</a></h2> <h3>Example config version 1</h3> <p></p> @@ -121,21 +315,158 @@ debootstrap, whatever) under /opt/vm-1-root: </domain> </pre> + +<h2><a name="usage">Container usage / management</a></h2> + +<p> +As with any libvirt virtualization driver, LXC containers can be +managed via a wide variety of libvirt based tools. At the lowest +level the <code>virsh</code> command can be used to perform many +tasks, by passing the <code>-c lxc:///</code> argument. As an +alternative to repeating the URI with every command, the <code>LIBVIRT_DEFAULT_URI</code> +environment variable can be set to <code>lxc:///</code>. The +examples that follow outline some common operations with virsh +and LXC. For further details about usage of virsh consult its +manual page. +</p> + +<h3><a name="usageSave">Defining (saving) container configuration></a></h3> + <p> -In both cases, you can define and start a container using:</p> +The <code>virsh define</code> command takes an XML configuration +document and loads it into libvirt, saving the configuration on disk +</p> + +<pre> +# virsh -c lxc:/// define myguest.xml +</pre> + +<h3><a name="usageView">Viewing container configuration</a></h3> + +<p> +The <code>virsh dumpxml</code> command can be used to view the +current XML configuration of a container. By default the XML +output reflects the current state of the container. If the +container is running, it is possible to explicitly request the +persistent configuration, instead of the current live configuration +using the <code>--inactive</code> flag +</p> + +<pre> +# virsh -c lxc:/// dumpxml myguest +</pre> + +<h3><a name="usageStart">Starting containers</a></h3> + +<p> +The <code>virsh start</code> command can be used to start a +container from a previously defined persistent configuration +</p> + +<pre> +# virsh -c lxc:/// start myguest +</pre> + +<p> +It is also possible to start so called "transient" containers, +which do not require a persistent configuration to be saved +by libvirt, using the <code>virsh create</code> command. +</p> + <pre> -virsh --connect lxc:/// define v1.xml -virsh --connect lxc:/// start vm1 +# virsh -c lxc:/// create myguest.xml </pre> -and then get a console using: + + +<h3><a name="usageStop">Stopping containers</a></h3> + +<p> +The <code>virsh shutdown</code> command can be used +to request a graceful shutdown of the container. By default +this command will first attempt to send a message to the +init process via the <code>/dev/initctl</code> device node. +If no such device node exists, then it will send SIGTERM +to PID 1 inside the container. +</p> + <pre> -virsh --connect lxc:/// console vm1 +# virsh -c lxc:/// shutdown myguest </pre> -<p>Now doing 'ps -ef' will only show processes in the container, for -instance. You can undefine it using + +<p> +If the container does not respond to the graceful shutdown +request, it can be forceably stopped using the <code>virsh destroy</code> </p> + <pre> -virsh --connect lxc:/// undefine vm1 +# virsh -c lxc:/// destroy myguest </pre> + + +<h3><a name="usageReboot">Rebooting a container</a></h3> + +<p> +The <code>virsh reboot</code> command can be used +to request a graceful shutdown of the container. By default +this command will first attempt to send a message to the +init process via the <code>/dev/initctl</code> device node. +If no such device node exists, then it will send SIGHUP +to PID 1 inside the container. +</p> + +<pre> +# virsh -c lxc:/// reboot myguest +</pre> + +<h3><a name="usageDelete">Undefining (deleting) a container configuration</a></h3> + +<p> +The <code>virsh undefine</code> command can be used to delete the +persistent configuration of a container. If the guest is currently +running, this will turn it into a "transient" guest. +</p> + +<pre> +# virsh -c lxc:/// undefine myguest +</pre> + +<h3><a name="usageConnect">Connecting to a container console</a></h3> + +<p> +The <code>virsh console</code> command can be used to connect +to the text console associated with a container. If the container +has been configured with multiple console devices, then the +<code>--devname</code> argument can be used to choose the +console to connect to +</p> + +<pre> +# virsh -c lxc:/// console myguest +</pre> + +<h3><a name="usageEnter">Running commands in a container</a></h3> + +<p> +The <code>virsh lxc-enter-namespace</code> command can be used +to enter the namespaces & security context of a container +and then execute an arbitrary command. +</p> + +<pre> +# virsh -c lxc:/// lxc-enter-namespace myguest -- /bin/ls -al /dev +</pre> + +<h3><a name="usageTop">Monitoring container utilization</a></h3> + +<p> +The <code>virt-top</code> command can be used to monitor the +activity & resource utilization of all containers on a +host +</p> + +<pre> +# virt-top -c lxc:/// +</pre> + </body> </html> -- 1.8.1.4

2 1

[libvirt] [PATCH 0/2] VIR_STRDUP ease of use
by Eric Blake 16 May '13

16 May '13

As pointed out during my (ongoing) review of Michal's series, I think that letting VIR_STRDUP take a NULL source can make it easier to use; I also think that documenting the guarantee that it evaluates arguments exactly once is worth enforcing. Hmm, I guess that means I should write a 3/2 patch that enhances the testsuite to intentionally do a side effect and show that it happens exactly once. Eric Blake (2): alloc: make VIR_APPEND_ELEMENT safer string: make VIR_STRDUP easier to use HACKING | 19 ++++++++++++------- docs/hacking.html.in | 16 ++++++++++++---- src/util/viralloc.c | 9 ++++++--- src/util/viralloc.h | 36 +++++++++++++++++++++++++++--------- src/util/virstring.c | 12 ++++++++---- src/util/virstring.h | 22 ++++++++++++++++------ 6 files changed, 81 insertions(+), 33 deletions(-) -- 1.8.1.4

3 7

[libvirt] [PATCH v3] virsh: lookup interface by name or mac other than one by one
by Guannan Ren 16 May '13

16 May '13

Change virMacAddrParse() to accept NULL addr for mac address testing purpose. --- src/util/virmacaddr.c | 3 ++- tools/virsh-interface.c | 11 ++++++++--- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/src/util/virmacaddr.c b/src/util/virmacaddr.c index c4ca0a8..8e41844 100644 --- a/src/util/virmacaddr.c +++ b/src/util/virmacaddr.c @@ -166,7 +166,8 @@ virMacAddrParse(const char* str, virMacAddrPtr addr) (0xFF < result)) break; - addr->addr[i] = (unsigned char) result; + if (addr) + addr->addr[i] = (unsigned char) result; if ((i == 5) && (*end_ptr == '\0')) return 0; diff --git a/tools/virsh-interface.c b/tools/virsh-interface.c index f75c572..74b4ed7 100644 --- a/tools/virsh-interface.c +++ b/tools/virsh-interface.c @@ -35,6 +35,7 @@ #include "virbuffer.h" #include "viralloc.h" #include "virfile.h" +#include "virmacaddr.h" #include "virutil.h" #include "virxml.h" #include "virstring.h" @@ -46,6 +47,7 @@ vshCommandOptInterfaceBy(vshControl *ctl, const vshCmd *cmd, { virInterfacePtr iface = NULL; const char *n = NULL; + bool is_mac = false; virCheckFlags(VSH_BYNAME | VSH_BYMAC, NULL); if (!optname) @@ -62,14 +64,17 @@ vshCommandOptInterfaceBy(vshControl *ctl, const vshCmd *cmd, if (name) *name = n; + if (virMacAddrParse(n, NULL) == 0) + is_mac = true; + /* try it by NAME */ - if (flags & VSH_BYNAME) { + if (!is_mac && (flags & VSH_BYNAME)) { vshDebug(ctl, VSH_ERR_DEBUG, "%s: <%s> trying as interface NAME\n", cmd->def->name, optname); iface = virInterfaceLookupByName(ctl->conn, n); - } + /* try it by MAC */ - if (!iface && (flags & VSH_BYMAC)) { + } else if (is_mac && (flags & VSH_BYMAC)) { vshDebug(ctl, VSH_ERR_DEBUG, "%s: <%s> trying as interface MAC\n", cmd->def->name, optname); iface = virInterfaceLookupByMACString(ctl->conn, n); -- 1.8.1.4

3 4

[libvirt] [PATCH v4] nwfilter: check for inverted ctdir
by Stefan Berger 16 May '13

16 May '13

Linux netfilter at some point (Linux 2.6.39) inverted the meaning of the '--ctdir reply' and newer netfilter implementations now expect '--ctdir original' instead and vice-versa. We check for the kernel version and assume that all Linux kernels with version 2.6.39 have the newer inverted logic. Any distro backporting the Linux kernel patch that inverts the --ctdir logic (Linux commit 96120d86f) must also backport this patch for Linux and adapt the kernel version being tested for. Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- v2->v3: - using uname now to check for Linux kernel version number v1->v2: - using virSocketAddrParseIPv4 --- src/nwfilter/nwfilter_ebiptables_driver.c | 52 ++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) Index: libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c =================================================================== --- libvirt-acl.orig/src/nwfilter/nwfilter_ebiptables_driver.c +++ libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c @@ -27,6 +27,7 @@ #include <string.h> #include <sys/stat.h> #include <fcntl.h> +#include <sys/utsname.h> #include "internal.h" @@ -85,6 +86,17 @@ static char *iptables_cmd_path; static char *ip6tables_cmd_path; static char *grep_cmd_path; +/* + * --ctdir original vs. --ctdir reply's meaning was inverted in netfilter + * at some point (Linux 2.6.39) + */ +enum ctdirStatus { + CTDIR_STATUS_UNKNOWN = 0, + CTDIR_STATUS_CORRECTED = 1, + CTDIR_STATUS_OLD = 2, +}; +static enum ctdirStatus iptables_ctdir_corrected; + #define PRINT_ROOT_CHAIN(buf, prefix, ifname) \ snprintf(buf, sizeof(buf), "libvirt-%c-%s", prefix, ifname) #define PRINT_CHAIN(buf, prefix, ifname, suffix) \ @@ -1262,6 +1274,17 @@ iptablesEnforceDirection(int directionIn virNWFilterRuleDefPtr rule, virBufferPtr buf) { + switch (iptables_ctdir_corrected) { + case CTDIR_STATUS_UNKNOWN: + /* could not be determined or s.th. is seriously wrong */ + return; + case CTDIR_STATUS_CORRECTED: + directionIn = !directionIn; + break; + case CTDIR_STATUS_OLD: + break; + } + if (rule->tt != VIR_NWFILTER_RULE_DIRECTION_INOUT) virBufferAsprintf(buf, " -m conntrack --ctdir %s", (directionIn) ? "Original" @@ -4304,6 +4327,32 @@ ebiptablesDriverTestCLITools(void) return ret; } +static void +ebiptablesDriverProbeCtdir(void) +{ + struct utsname utsname; + unsigned long thisversion; + + iptables_ctdir_corrected = CTDIR_STATUS_UNKNOWN; + + if (uname(&utsname) < 0) { + VIR_ERROR(_("Call to utsname failed: %d"), errno); + return; + } + + /* following Linux lxr, the logic was inverted in 2.6.39 */ + if (virParseVersionString(utsname.release, &thisversion, true) < 0) { + VIR_ERROR(_("Could not determine kernel version from string %s"), + utsname.release); + return; + } + + if (thisversion >= 2 * 1000000 + 6 * 1000 + 39) + iptables_ctdir_corrected = CTDIR_STATUS_CORRECTED; + else + iptables_ctdir_corrected = CTDIR_STATUS_OLD; +} + static int ebiptablesDriverInit(bool privileged) { @@ -4341,6 +4390,9 @@ ebiptablesDriverInit(bool privileged) return -ENOTSUP; } + if (iptables_cmd_path) + ebiptablesDriverProbeCtdir(); + ebiptables_driver.flags = TECHDRV_FLAG_INITIALIZED; return 0;

3 2