[libvirt] [PATCH 0/3] Fix the build failure
by Osier Yang
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
12 years, 1 month
[libvirt] [PATCH] Move VirtualBox driver into libvirtd
by Daniel P. Berrange
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
12 years, 1 month
[libvirt] [PATCH v2 00/12] Multiple TX queue support
by Michal Privoznik
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/Docu...
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
12 years, 1 month
[libvirt] [PATCH]write separate module for hostdev passthrough
by Chunyan Liu
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
12 years, 1 month
[libvirt] [PATCH] Expand documentation for LXC driver
by Daniel P. Berrange
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 configuration</h2>
+
+<h3>Init process</h3>
+
+<h3>Console devices</h3>
+
+<h3>Filesystem devices</h3>
+
+<h3>Disk devices</h3>
+
+<h3>Block devices</h3>
+
+<h3>USB devices</h3>
+
+<h3>Character devices</h3>
+
+<h3>Network devices</h3>
+-->
+
+<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
12 years, 1 month
[libvirt] [PATCH 0/2] VIR_STRDUP ease of use
by Eric Blake
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
12 years, 1 month
[libvirt] [PATCH v3] virsh: lookup interface by name or mac other than one by one
by Guannan Ren
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
12 years, 1 month
[libvirt] [PATCH v4] nwfilter: check for inverted ctdir
by Stefan Berger
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;
12 years, 1 month
[libvirt] [PATCH] FreeBSD: disable buggy -fstack-protector-all
by Roman Bogorodskiy
FreeBSD ships an old gcc 4.2.1 which generates
bogus code, e.g. getsockopt() call returns
struct xucred with bogus values, which doesn't even
allow to connect to libvirtd:
error: Failed to find group record for gid '1284660778': No error: 0
So roll back to just -fstack-protector on FreeBSD.
---
m4/virt-compile-warnings.m4 | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/m4/virt-compile-warnings.m4 b/m4/virt-compile-warnings.m4
index dc0e7d7..ce4e244 100644
--- a/m4/virt-compile-warnings.m4
+++ b/m4/virt-compile-warnings.m4
@@ -191,7 +191,7 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[
dnl -fstack-protector stuff passes gl_WARN_ADD with gcc
dnl on Mingw32, but fails when actually used
case $host in
- *-*-linux*|*-*-freebsd*)
+ *-*-linux*)
dnl Fedora only uses -fstack-protector, but doesn't seem to
dnl be great overhead in adding -fstack-protector-all instead
dnl gl_WARN_ADD([-fstack-protector])
@@ -205,6 +205,13 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[
dnl off the following clang specific warning
gl_WARN_ADD([-Wno-unused-command-line-argument])
;;
+ *-*-freebsd*)
+ dnl FreeBSD ships old gcc 4.2.1 which doesn't handle
+ dnl -fstack-protector-all well
+ gl_WARN_ADD([-fstack-protector])
+
+ gl_WARN_ADD([-Wno-unused-command-line-argument])
+ ;;
esac
gl_WARN_ADD([-fexceptions])
gl_WARN_ADD([-fasynchronous-unwind-tables])
--
1.8.0
12 years, 1 month
[libvirt] [PATCH v2 0/4] Extra validation for the <sysinfo> section
by John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=890494
The <sysinfo> section needs an extra uuid validation check. The current
check compares the numerical sysinfo/system_uuid with the domain uuid;
however, it's possible that someone added extra hyphens into the sysinfo
uuid which results in the inability to start the domain (at least qemu).
Rather than fail due to improper format, adjust/save to the expected format.
The bug report indicates the 'date' field should at least be syntax checked
based on what's desribed in the SMBIOS spec. From the spec:
"String number of the BIOS release date. The date string, if supplied, is
in either mm/dd/yy or mm/dd/yyyy format. If the year portion of the string
is two digits, the year is assumed to be 19yy.
NOTE: The mm/dd/yyyy format is required for SMBIOS version 2.3 and later"
v2 -> v1 differences:
- Moved Sysinfo field validation checks from virDomainDefParseXML() into
virSysinfoParseXML()
- As long as the virUUIDParse() value matches the domain's UUID field
save the 'correct' format in the system_uuid field - that is don't
error out just because of extraneous space or dash in provided UUID.
- Added tests for date field and uuid comparison parsing errors.
NOTE: 01 and 02 are unchanged
John Ferlan (4):
docs: Fix syntax in sysinfo description
docs: Update description of SMBIOS fields
Validate the bios_date format for <sysinfo>
Adjust improperly formatted <sysinfo> uuid
docs/formatdomain.html.in | 51 +++++++++++---
src/conf/domain_conf.c | 78 ++++++++++++++++------
.../qemuxml2argvdata/qemuxml2argv-smbios-date.xml | 23 +++++++
.../qemuxml2argv-smbios-uuid-match.xml | 23 +++++++
tests/qemuxml2argvtest.c | 2 +
5 files changed, 148 insertions(+), 29 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smbios-date.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smbios-uuid-match.xml
--
1.8.1.4
12 years, 1 month
