mirror of https://gitee.com/openkylin/libvirt.git
119 lines
4.1 KiB
Plaintext
119 lines
4.1 KiB
Plaintext
|
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:
|
||
|
|
|
||
|
|
<https://bugs.debian.org/453627>
|
||
|
|
<https://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
|