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 </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: 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: Haswell Intel ... 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 for further details. -- Guido Günther Wen, 24 Dec 2014 09:55:41 +0200