Xen
===
To manage xen domains with libvirt you have to set:

(xend-unix-server yes)

in /etc/xen/xend-config.sxp.

For xend HTTP access (not recommended) you also have to set:

(xend-http-server yes)
# only allow access from localhost:
(xend-address localhost)

Note that *every* user on the system has access to xend then. Better use
libvirtd to access xen with unprivileged users and add the users to the
"libvirtd" group (see "Access Control" below).

Debugging
=========
Use LIBVIRT_DEBUG=1 to enable libvirt's debugging output, e.g.:

LIBVIRT_DEBUG=1
export LIBVIRT_DEBUG
virt-manager

The default NAT network
=======================
To ease network configuration libvirt defines a NATed network named "default".
VMs using this network end up in 192.168.122.1/24 and DHCP is provided to them
via dnsmasq. This network is not automatically started. To start it use:

 virsh net-start default

To make the default network start automatically use:

 virsh net-autostart default

In order for things to work this way you need to have the recommended packages
dnsmasq-base, bridge-utils and iptables installed.

You don't need the package dnsmasq. However, if you install it, Debian's
default dnsmasq needs to be adjusted slightly to interoperate with libvirtd:

cat <<EOF >/etc/dnsmasq.d/00_libvirtd.conf
# only bind to loopback by default
interface=lo
bind-interfaces
EOF

This makes dnsmasq only bind to the loopback interface by default so libvirtd
can handle the virtual bridges.

Access Control
==============
Access to the libvirt socket is controlled by membership in the "libvirtd" group.
If you want to manage VMs as non root you need to add a user to that group.

QEMU/KVM: Dropping Capabilties
==============================
Network interfaces of type "ethernet" use a script like /etc/qemu-ifup to set up
the network device. In order to make this work you need to set
"clear_emulator_capabilities" to "0" in /etc/libvirt/qemu.conf since you need
CAP_NET_ADMIN.
This used to be the default prior to 0.8.1 in the Debian package.

SSH connections to the server
=============================

If you want to connect to the libvirt server via SSH, you need to install
netcat-openbsd on the server and configure the nc alternative to use it. This
is done automatically when netcat-openbsd is installed if you do not have
previously modified the nc alternative. Please see the following bug reports
for a complete explanation:

  <http://bugs.debian.org/453627>
  <http://bugs.debian.org/614291>

 -- Guido Günther <agx@sigxcpu.org>  Mon, 06 Feb 2011 17:28:35 +0200

AppArmor Profile
================
Libvirt now contains AppArmor integration when using KVM or QEMU using
libvirt's sVirt infrastructure. Libvirtd can be configured to launch virtual
machines that are confined by uniquely restrictive AppArmor profiles. This
feature significantly improves virtualization in Ubuntu by providing user-space
host protection as well as guest isolation.

In the sVirt model, if a profile is loaded for the libvirtd daemon, then each
qemu:///system QEMU virtual machine will have a profile created for it when
the virtual machine is started if one does not already exist. This generated
profile is based on a template file and uses a profile name based on the UUID
of the QEMU virtual machine and contains rules allowing access to only the
files it needs to run, such as its disks, pid file and log files. Just before
the QEMU virtual machine is started, the libvirtd daemon will change into this
unique profile, preventing the QEMU process from accessing any file resources
that are present in another QEMU process or the host machine.

The AppArmor sVirt implementation is flexible in that it allows a user to
customize the template file in /etc/apparmor.d/libvirt/TEMPLATE for
site-specific access for all newly created QEMU virtual machines. When a
new profile is generated, two files are created:

 /etc/apparmor.d/libvirt/libvirt-<uuid>
 /etc/apparmor.d/libvirt/libvirt-<uuid>.files

The former can be fine-tuned by the administrator to allow custom access for
this particular QEMU virtual machine, and the latter will be updated
appropriately when required file access changes, such as when a disk is added.
This flexibility allows for situations such as having one virtual machine in
complain mode with all others in enforce mode.

Profiles for /usr/sbin/libvirtd, /usr/lib/libvirt/virt-aa-helper (a helper
program which the libvirtd daemon uses instead of manipulating AppArmor
directly), and /etc/apparmor.d/abstractions/libvirt-qemu are used to configure
AppArmor confinement with sVirt. Administrators of libvirt in production
environments are encouraged to review these files (especially 'libvirt-qemu')
to ensure that only the access required is given to the virtual machines.

If the sVirt security model is active, then the node capabilities XML will
include its details. If a virtual machine is currently protected by the
security model, then the guest XML will include its assigned profile name. If
enabled at compile time, the sVirt security model will be activated if AppArmor
is available on the host OS and a profile for the libvirtd daemon is loaded
when libvirtd is started. To disable sVirt, and revert to the basic level of
AppArmor protection (host protection only), the /etc/libvirt/qemu.conf file can
be used to change the setting to security_driver="none". Users may also
disable AppArmor integration through AppArmor itself by performing:

$ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
$ sudo ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/usr.sbin.libvirtd

If your system uses AppArmor, please note that the shipped profile works with
the default installation, and changes in your configuration may require changes
to the installed apparmor profile. Before filing a bug against this software,
please see https://wiki.ubuntu.com/DebuggingApparmor before filing a bug
against this software.

qemu:///system
--------------
Adding users to the libvirtd group effectively grants them root access. In
Ubuntu, users in the sudo group (who already have 'sudo' access) are added to
this group automatically.

Virtual machines started from qemu:///system may run with or without root
privileges. As discussed above, in Ubuntu Qemu/KVM virtual machines are fully
isolated and confined by the AppArmor security driver. Users can adjust this
/etc/libvirt/qemu.conf so that virtual machines started under qemu:///system
run as a non-privileged user (new in libvirt 0.7). The 'libvirt-qemu' user and
'kvm' group are configured for this purpose. In Ubuntu, libvirt runs virtual
machines with non-root privileges as well as fully confined by AppArmor.

While the current non-root implementation does reduce the privileges of virtual
machines running under qemu:///system, continuing to use a MAC system such as
AppArmor is important because without the MAC system all VMs will still run
under the same user and there is no guest isolation. Additionally, if each VM
ran under its own user, an attacker could potentially break out of the VM and
have unconfined user access to the host machine.


Disk migration
==============
Libvirt versions earlier that 0.8.3 would probe a qemu disk to determine its
format and did not require that the format be declared in the XML. Newer
versions of libvirt will default to the 'raw' format when the format is not
specified in the XML. As a result, non-raw disks without unspecified disk
format will no longer be available in virtual machines.

libvirt-migrate-qemu-disks is provided to aid in transitioning virtual
machine definitions to the new required format. In essence, it will check
all domains for affected virtual machines, probe the affected disks and update
the domain definition accordingly. For example, a domain with:

    <disk type='file' device='disk'>
      <source file='/var/lib/libvirt/images/foo.qcow2'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>

will be updated to have:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/foo.qcow2'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>

This command will be run automatically on upgrade to 0.8.3-1ubuntu1. See
'man 1 libvirt-migrate-qemu-disks' for details.

 -- Jamie Strandboge <jamie@canonical.com>  Thu, 12 Aug 2010 15:03:07 -0500

QEMU/kvm Machine Type migration
===============================
QEMU/kvm is a full virtualization implementation supported by libvirt.  As
new QEMU versions are released, the pc machine type for that release is
frozen and encoded with the QEMU version.  For instance, the pc-0.10
machine type should never change, and always have the same features as the
pc machine type did in QEMU version 0.10.

In QEMU 1.0, the pc-0.12 machine type has become particularly buggy.  To
help users to automatically convert VMs which are using a bad machine
type, but which do not specifically need to be, the
libvirt-migrate-qemu-machinetype program has been provided.  This command
will not be automatically run, because some VMs may in fact depend on
the pc-0.12 machine type.  However, whenever a VM with a known troublesome
machine type is defined or started, a message will be printed to the
libvirt log.  Users can update the VM definition by hand, or use the
libvirt-migrate-qemu-machinetype program to do it for them.

 -- Serge Hallyn <serge.hallyn@ubuntu.com>  Tue, 22 May 2012 17:34:00 +0000
