libvirt

Install the libvirt package, as well as at least one hypervisor:

• The libvirt KVM/QEMU driver is the primary libvirt driver and if KVM is enabled, fully virtualized, hardware accelerated guests will be available. See the QEMU article for more information.

• Other supported hypervisors include LXC, VirtualBox and Xen. See the respective articles for installation instructions. With respect to libvirtd installation note:
  • The libvirt LXC driver has no dependency on the LXC userspace tools provided by lxc, therefore there is no need to install the package if planning on using the driver.
  • Xen support is available, but not by default (FS#27356). You need to use the ABS to modify libvirt's PKGBUILD and build it without the option.

For network connectivity, install:

• iptables-nft, and for the default NAT/DHCP networking.
• bridge-utils for bridged networking.
• for remote management over SSH.

The client is the user interface that will be used to manage and access the virtual machines.

• Remote Viewer — Simple remote display client.

https://virt-manager.org/ || virt-viewer

A list of libvirt-compatible software can be found here.

From libvirt: Connection authentication:

The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in . Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of , and .

The easiest way to ensure your user has access to libvirt daemon is to add member to user group.

Members of the group have passwordless access to the RW daemon socket by default.

Because libvirt pulls as a dependency during installation, polkit is used as the default value for the unix_sock_auth parameter (source). File-based permissions remain nevertheless available.

The libvirt daemon provides two polkit actions in :

• for full management access (RW daemon socket), and
• org.libvirt.unix.monitor for monitoring only access (read-only socket).

The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to sudo auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.

Arch defaults to consider anybody in the group as an administrator: this is defined in (see Polkit#Administrator identities). Therefore there is no need to create a new group and rule file if your user is a member of the group: upon connection to the RW socket (e.g. via ) you will be prompted for your user's password.

You may change the group authorized to access the RW daemon socket. As an example, to authorize the group, create the following file:

Then add yourself to the group and relogin. Replace mykvm with any group of your preference just make sure it exists and that your user is a member of it (see Users and groups for more information).

Do not forget to relogin for group changes to take effect.

To define file-based permissions for users in the libvirt group to manage virtual machines, uncomment and define:

While some guides mention changed permissions of certain libvirt directories to ease management, keep in mind permissions are lost on package update. To edit these system directories, root user is expected.

Start both and . Optionally enable (which will also enable and units, so there is NO need to also enable ).

Edit :

It is also necessary to start the server in listening mode by editing :

For host access to guests on non-isolated, bridged networks, enable the NSS module provided by libvirt.

Edit :

The virsh program is for managing guest domains (virtual machines) and works well for scripting, virtualization administration. Though most virsh commands require root privileges to run due to the communication channels used to talk to the hypervisor, typical management, creation, and running of domains (like that done with VirtualBox) can be done as a regular user.

Virsh includes an interactive terminal that can be entered if no commands are passed (options are allowed though): . The interactive terminal has support for tab completion.

From the command line:

$ virsh [option] <command> [argument]...

From the interactive terminal:

virsh # <command> [argument]...

Help is available:

$ virsh help [option*] or [group-keyword*]

A pool is a location where storage volumes can be kept. What libvirt defines as volumes others may define as "virtual disks" or "virtual machine images". Pool locations may be a directory, a network filesystem, or partition (this includes a LVM). Pools can be toggled active or inactive and allocated for space.

On the system-level, will be activated by default; on a user-session, creates $HOME/VirtualMachines.

Print active and inactive storage pools:

$ virsh pool-list --all

If one wanted to add a storage pool, here are examples of the command form, adding a directory, and adding a LVM volume:

$ virsh pool-define-as name type [source-host] [source-path] [source-dev] [source-name] [<target>] [--source-format format]
$ virsh pool-define-as poolname dir - - - - /home/username/.local/libvirt/images
$ virsh pool-define-as poolname fs - -  /dev/vg0/images - mntpoint

The above command defines the information for the pool, to build it:

$ virsh pool-build     poolname
$ virsh pool-start     poolname
$ virsh pool-autostart poolname

To remove it:

$ virsh pool-undefine  poolname

First, connect to a hypervisor (e.g. QEMU/KVM system, or user-session). Then, right-click on a connection and select Details; select the Storage tab, push the + button on the lower-left, and follow the wizard.

Once the pool has been created, volumes can be created inside the pool. If building a new domain (virtual machine), this step can be skipped as a volume can be created in the domain creation process.

Create volume, list volumes, resize, and delete:

$ virsh vol-create-as      poolname volumename 10GiB --format aw|bochs|raw|qcow|qcow2|vmdk
$ virsh vol-upload  --pool poolname volumename volumepath
$ virsh vol-list           poolname
$ virsh vol-resize  --pool poolname volumename 12GiB
$ virsh vol-delete  --pool poolname volumename
$ virsh vol-dumpxml --pool poolname volumename  # for details.

Virtual machines are called domains. If working from the command line, use to list, create, pause, shutdown domains, etc. can be used to view domains started with . Creation of domains is typically done either graphically with or with (a command line program installed as part of the virt-install package).

Creating a new domain typically involves using some installation media, such as an from the storage pool or an optical drive.

Print active and inactive domains:

# virsh list --all

For an extremely detailed domain (virtual machine) setup, it is easier to #Create a new domain using virt-manager. However, basics can easily be done with and still run quite well. Minimum specifications are , , guest storage (--disk, , or ), and an install method (generally an or CD). See for more details and information about unlisted options.

Arch Linux install (two GiB, qcow2 format volume create; user-networking):

$ virt-install  \
  --name arch-linux_testing \
  --memory 1024             \
  --vcpus=2,maxvcpus=4      \
  --cpu host                \
  --cdrom $HOME/Downloads/arch-linux_install.iso \
  --disk size=2,format=qcow2  \
  --network user            \
  --virt-type kvm

Fedora testing (Xen hypervisor, non-default pool, do not originally view):

$ virt-install  \
  --connect xen:///     \
  --name fedora-testing \
  --memory 2048         \
  --vcpus=2             \
  --cpu=host            \
  --cdrom /tmp/fedora20_x84-64.iso      \
  --os-type=linux --os-variant=fedora20 \
  --disk pool=testing,size=4            \
  --network bridge=br0                  \
  --graphics=vnc                        \
  --noautoconsole
$ virt-viewer --connect xen:/// fedora-testing

Windows:

$ virt-install \
  --name=windows7           \
  --memory 2048             \
  --cdrom /dev/sr0          \
  --os-variant=win7         \
  --disk /mnt/storage/domains/windows7.qcow2,size=20GiB \
  --network network=vm-net  \
  --graphics spice

Import existing volume:

$ virt-install  \
  --name demo  \
  --memory 512 \
  --disk /home/user/VMs/mydisk.img \
  --import

First, connect to the hypervisor (e.g. QEMU/KVM system or user session), right click on a connection and select New, and follow the wizard.

• On the fourth step, de-selecting Allocate entire disk now will make setup quicker and can save disk space in the interum; however, it may cause volume fragmentation over time.
• On the fifth step, open Advanced options and make sure that Virt Type is set to kvm (this is usually the preferred method). If additional hardware setup is required, select the Customize configuration before install option.

Start a domain:

$ virsh start domain
$ virt-viewer --connect qemu:///session domain

Gracefully attempt to shutdown a domain; force off a domain:

$ virsh shutdown domain
$ virsh destroy  domain

Autostart domain on libvirtd start:

$ virsh autostart domain
$ virsh autostart domain --disable

Shutdown domain on host shutdown:

Running domains can be automatically suspended/shutdown at host shutdown using the systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read for service options.

Edit a domain's XML configuration:

$ virsh edit domain

A decent overview of libvirt networking.

Four network types exist that can be created to connect a domain to:

• bridge — a virtual device; shares data directly with a physical interface. Use this if the host has static networking, it does not need to connect other domains, the domain requires full inbound and outbound trafficking, and the domain is running on a system-level. See Network bridge on how to add a bridge. After creation, it needs to be specified in the respective guest's configuration file.
• network — a virtual network; has ability to share with other domains. Libvirt offers many virtual network modes, such as NAT mode (Network address translation), routed mode and isolated mode. Using a virtual network is particularly indicated if the host has dynamic networking (e.g. NetworkManager), or using wireless.
• macvtap — connect directly to a host physical interface.
• user — local ability networking. Use this only for a user session.

has the ability to create networking with numerous options for most users, however, it is easier to create network connectivity with a graphic user interface (like ), or to do so on creation with virt-install.

You could get VM ip address via (in case it connected to network and receives IP address via dhcp):

$ virsh net-dhcp-leases default

command (replacing with network name VM connected to), or if VM has running via:

$ virsh domifaddr --source agent $vm

replacing $vm with actual virtual machine name (or domain id).

To modify your virtual networks, it is highly recommended to read the basic command line usage for virtual networks guide from the libvirt wiki. It is also recommended to read the libvirt networking wiki to know more about its usage.

When adding an IPv6 address through any of the configuration tools, you will likely receive the following error:

Check the host setup: enabling IPv6 forwarding with RA routes without accept_ra set to 2 is likely to cause routes loss. Interfaces to look at: eth0

Fix this by running the following command (replace with the name of your physical interface):

# sysctl net.ipv6.conf.eth0.accept_ra=2

Snapshots take the disk, memory, and device state of a domain at a point-of-time, and save it for future use. They have many uses, from saving a "clean" copy of an OS image to saving a domain's state before a potentially destructive operation. Snapshots are identified with a unique name.

Snapshots are saved within the volume itself and the volume must be the format: qcow2 or raw. Snapshots use deltas in order not to take as much space as a full copy would.

Once a snapshot is taken it is saved as a new block device and the original snapshot is taken offline. Snapshots can be chosen from and also merged into another (even without shutting down the domain).

Print a running domain's volumes (running domains can be printed with ):

To see a volume's physical properties:

Create a disk-only snapshot (the option --atomic will prevent the volume from being modified if snapshot creation fails):

# virsh snapshot-create-as domain snapshot1 --disk-only --atomic

List snapshots:

One can then copy the original image with or and then merge the the original back into snapshot:

# virsh blockpull --domain domain --path /vms/domain.snapshot1

becomes a new volume.  After this is done the original volume (domain.img and snapshot metadata can be deleted.   The  would work opposite to  but it seems to be currently under development (including , scheduled to be released sometime next year.

Connect to non-default hypervisor:

$ virsh --connect xen:///
virsh # uri
xen:///

Connect to the QEMU hypervisor over SSH; and the same with logging:

$ virsh --connect qemu+ssh://username@host/system
$ LIBVIRT_DEBUG=1 virsh --connect qemu+ssh://username@host/system

Connect a graphic console over SSH:

$ virt-viewer  --connect qemu+ssh://username@host/system domain
$ virt-manager --connect qemu+ssh://username@host/system domain

Connect to the VirtualBox hypervisor (VirtualBox support in libvirt is not stable yet and may cause libvirtd to crash):

$ virsh --connect vbox:///system

Network configurations:

$ virsh -c qemu:///system net-list --all
$ virsh -c qemu:///system net-dumpxml default

Hooks are represented by scripts located at . If the folder does not exist, you have to create it. Each hook is represented by a script in this folder with the same name (e.g. ) or a subfolder (e.g. /etc/libvirt/hooks/qemu.d/). The later can contain different scripts, which are all run at the trigger points. The scripts are run like any other scripts, so they need to start whith the declaration of the command interpreter to use (e.g. ). The script have to be executable by the libvirt user ().

Everytime a trigger point is met, the script is run. For example, the daemon script would run at least two times in a start/stop cycle of the system, at start and at shutdown. To run an command only at a given point, you have to implement conditions in the script. To do this, libvirt passes parameters which can be used to identify the current trigger condition.

According to the libvirt documentation these parameters are defined as follows:

• Parameter 1: The name of the object involved in the operation
• Parameter 2: The name of the operation being performed
• Parameter 3: Used if a sub-operation is to be named
• Parameter 4: An extra argument if needed

If one of the arguments is not applicable, a dash is passed.

To run an command everytime you start an qemu guest, before any ressources are allocated, you can use the qemu hook. At this point, libvirt runs the hooks like this: /etc/libvirt/hooks/qemu <guest_name> prepare begin - The script for this could like this:

If the guest is stopped, the same script would be run, but this time the daemon would start the command like this:

The description here will use hugepages to enable the usage of shared folders. Sharing files with Virtio-FS lists an overview of the supported options to enable filesharing with the guest.

First you need to enable hugepages which are used by the virtual machine:

To determine the number of hugepages needed check the size of the hugepages:

$ grep Hugepagesize /proc/meminfo

The number of hugepages is memory size of virtual machine / Hugepagesize. Add to this value some additional pages. You have to reboot after this step, so that the hugepages are allocated.

Now you have to prepare the configuration of the virtual machine:

It is necessary to add the NUMA definition so that the memory access can be declared as shared. id and cpus values for NUMA will be inserted by virsh.

It should now be possible to mount the folder in the shared machine:

# mount -t virtiofs mount_tag /mnt/mount/path

Add the following fstab entry to mount the folder automatically at boot:

File system directories can be shared using the 9P protocol. Details are available in QEMU's documentation of 9psetup.

Configure the virtual machine as follows:

<domain>
...
  <devices>
    ...
    <filesystem type="mount" accessmode="mapped">
      <source dir="''/path/on/host''"/>
      <target dir="''mount_tag''"/>
    </filesystem>
  </devices>
</domain>

Boot the guest and mount the shared directory from it using:

# mount -t 9p -o trans=virtio,version=9p2000.L mount_tag /path/to/mount_point/on/guest

See https://docs.kernel.org/filesystems/9p.html for more mount options.

To mount it at boot, add it to the guest's fstab:

The module for the 9p transport (i.e. for trans=virtio) will not be automatically loaded, so mounting the file system from will fail and you will encounter an error like . The solution is to preload the module during boot:

An other easy way to share data between guest and host is to use the smb protocol. While performance and latency may not be as good as in the other described ways, its sufficient for simple tasks like transfering simple files like images or documents from and to the guest.

The smb server can be set up directly on either the host, or the guest, for example using Samba, eliminating the need for a dedicated file server. Windows guests have the ability to create smb shares included right after installation (Microsoft Supportpage).

One possible way to access the share under linux (either from the host, or from the guest, depending, where you have installed your server) is to create an entry in your fstab. The package is required.

ensures that the share is only mounted when needed without causing issues if the vm is not booted. user,credentials=/home/user/.config/my_vm.key,gid=1000,uid=984 gives you the ability to mount the share on the fly while first accessing it, without needing a password.

The package provides a Python API in .

General examples are given in /usr/share/doc/libvirt-python-your_libvirt_version/examples/

Unofficial example using and :

To turn a disk into an Advanced Format 4Kn disk, both its physical and logical sector size needs to be set to 4 KiB. For virtio-blk and virtio-scsi this can be done by setting the and options with the the <blockio> element. For example:

The PulseAudio daemon normally runs under your regular user account, and will only accept connections from the same user. This can be a problem if QEMU is being run as root through libvirt. To run QEMU as a regular user, edit and set the user option to your username.

user = "dave"

You will also need to tell QEMU to use the PulseAudio backend and identify the server to connect to. Add the following section to your domain configuration using .

  <audio id="1" type="pulseaudio" serverName="/run/user/1000/pulse/native">
    <input latency="20000"/>
    <output latency="20000"/>
  </audio>

is your user id. Change it if necessary.

You can omit the latency settings (in microseconds) but using the defaults might result in crackling.

Default VM configuration generated by virt-manager may cause rather high (10-20%) CPU use caused by the QEMU process. If you plan to run the VM in headless mode, consider removing some of the unnecessary devices.

If you are using a disk image format such as qcow2 which has a specified virtual capacity, but only stores what is needed, then you need to have space on the host partition for the image to grow. If you see I/O related errors when attempting to start the VM, it's possible that the host partition holding the virtual disk image is is full. You can run on the host to verify how much free space is available.

If this is the case, see System maintenance#Clean the filesystem for ways to free up space.

If the Redirect USB Device menu item is greyed out, check that the following hardware is configured for the VM:

• A USB Controller.
• One or more USB Redirectors.

When you try to open a virtual machine this error may pop up. This is because when you try to open a existing virtual machine libvirt tries to search for the default network which is not available. To make it available you have to autostart your network interface so that whenever your restart your computer your network interface is always active. See libvirt networking page.

Look at the name of your network interface with the following command:

# virsh net-list

To autostart your network interface:

# virsh net-autostart name_of_the_network

To start your network interface:

# virsh net-start name_of_the_network

Ensure the folder containing your virtual machine files and installation ISO are owned by the group

$ sudo chown -R $USER:libvirt-qemu /path/to/virtual/machine