Xen
===
Libvirt uses libxl to manage xen domains. In order to migrate your
configuration from a xend based setup use:

    virsh define <(virsh domxml-from-native xen-xm /etc/xen/yourxendomain.cfg)

For some more details see #783901.

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.

Bridged network
===============
libvirt can use the qemu-bridge-helper to create bridged network interfaces for
session domains. For this to work the helper must have the capability to create
TUN/TAP devices or must have the SUID permission set.
This can be done by running the following command as the user root:

    setcap cap_net_admin+ep /usr/lib/qemu/qemu-bridge-helper

The allowed bridges must be configured in the file '/etc/qemu/bridge.conf'. For
each bridge add a line like 'allow br0'.

Access Control
==============
Access to the libvirt managing tasks is controlled by PolicyKit. To ease
configuration membership in the "libvirt" group is sufficient. If you want to
manage VMs as non-root you need to add a user to that group.

Note that this will allow users in this group to use all of libvirt's
API including modifying files on the host. For finer grained access
control have a look at libvirt's ACLs.

System QEMU/KVM processes are run as user and group libvirt-qemu. This can be
adjusted via /etc/libvirt/qemu.conf.

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>

Libvirt CPU models and microcode updates
========================================
CPU microcode updates (e.g. via the intel-microcode package) might change the
available CPU flags. One example is version 3.20140913.1 of the intel-microcode
removing TSX-NI which results in the kernel no longer reporting the *hle* flag.

In this case if you hard coded the CPU model in your virtual machine
configuration via:

   <cpu mode='custom' match='exact'>
     <model fallback='forbid'>Haswell</model>
     <vendor>Intel</vendor>
     ...
   </cpu>

and update the CPU microcode the VM might fail to start with errors like

  error: Failed to start domain foo
  error: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: hle

since libvirt doesn't differentiate between microcode versions. It is therefore
recommended to copy over the needed CPU flags instead of hard coding the CPU
model. See

  <https://www.redhat.com/archives/libvir-list/2014-December/msg00950.html>

for further details.

 -- Guido Günther <agx@sigxcpu.org>  Wen, 24 Dec 2014 09:55:41 +0200