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.
Use LIBVIRT_DEBUG=1 to enable libvirt's debugging output, e.g.:
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
This makes dnsmasq only bind to the loopback interface by default so libvirtd
can handle the virtual bridges.
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 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
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:
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
<cpu mode='custom' match='exact'>
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
for further details.
-- Guido Günther <email@example.com> Wen, 24 Dec 2014 09:55:41 +0200