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).

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).

Line 390:

Line 388:

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

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

−

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

+

# virsh snapshot-create ''domain'' --disk-only --atomic

List snapshots:

List snapshots:

Line 400:

Line 398:

</nowiki>}}

</nowiki>}}

−

One can they copy the original image with {{ic|1=cp --sparse=true}} or {{ic|rsync -S}} and then merge the the original back into snapshot:

{{ic|domain.snapshot1}} becomes a new volume. After this is done the original volume ({{ic|domain.img}} and snapshot metadata can be deleted. The {{ic|virsh blockcommit}} would work opposite to {{ic|blockpull}} but it seems to be currently under development (including {{ic|snapshot-revert feature}}, scheduled to be released sometime next year.

+

# virsh snapshot-revert ''domain'' ''snapshot''

=== Other management ===

=== Other management ===

Revision as of 02:20, 13 October 2017

Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. These software pieces include a long term stable C API, a daemon (libvirtd), and a command line utility (virsh). A primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors, such as the KVM/QEMU, Xen, LXC, OpenVZ or VirtualBoxhypervisors (among others).

Some of the major libvirt features are:

VM management: Various domain lifecycle operations such as start, stop, pause, save, restore, and migrate. Hotplug operations for many device types including disk and network interfaces, memory, and CPUs.

Remote machine support: All libvirt functionality is accessible on any machine running the libvirt daemon, including remote machines. A variety of network transports are supported for connecting remotely, with the simplest being SSH, which requires no extra explicit configuration.

Network interface management: Any host running the libvirt daemon can be used to manage physical and logical network interfaces. Enumerate existing interfaces, as well as configure (and create) interfaces, bridges, vlans, and bond devices.

Virtual NAT and Route based networking: Any host running the libvirt daemon can manage and create virtual networks. Libvirt virtual networks use firewall rules to act as a router, providing VMs transparent access to the host machines network.

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. You need to use the ABS to modify libvirt's PKGBUILD and build it without the --without-xen option. As VirtualBox in turn has no planned stable support for Xen, you might as well replace it with --without-vbox.

Configuration

Note: For user-session administration, daemon setup and configuration is not required; authorization, however, is limited to local abilities; the front-end will launch a local instance of the libvirtd daemon.

Set up 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 /etc/libvirt/libvirtd.conf. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of none, polkit and sasl.

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 wheel group as an administrator: this is defined in /etc/polkit-1/rules.d/50-default.rules (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 wheel group: upon connection to the RW socket (e.g. via virt-manager) you will be prompted for your user's password.

Note: Prompting for a password relies on the presence of an authentication agent on the system. Console users may face an issue with the default pkttyagent agent which may or may not work properly.

As of libvirt 1.2.16 (commit:[1]), members of the libvirt group have passwordless access to the RW daemon socket by default. The easiest way to ensure your user has access is to ensure the libvirt group exists and they are a member of it. If you wish to change the group authorized to access the RW daemon socket to be the kvm group, create the following file:

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.

Daemon

Start both libvirtd.service and virtlogd.service. Optionally enablelibvirtd.service. There is no need to enable virtlogd.service, since libvirtd.service, when enabled, also enables the virtlogd.socket and virtlockd.socketunits.

Unencrypt TCP/IP sockets

Warning: This method is used to help remote domain, connection speed for trusted networks. This is the least secure connection method. This should only be used for testing or use over a secure, private, and trusted network. SASL is not enabled here, so all TCP traffic is cleartext. For real world use always enable SASL.

Edit /etc/libvirt/libvirtd.conf:

/etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
auth_tcp="none"

It is also necessary to start the server in listening mode by editing /etc/conf.d/libvirtd:

/etc/conf.d/libvirtd

LIBVIRTD_ARGS="--listen"

Access virtual machines using their hostnames

Note: While commands such as ping and ssh should work with virtual machine hostnames, commands such as host and nslookup may fail or produce unexpected results because they rely on DNS. Use getent hosts <vm-hostname> instead.

Test

To test if libvirt is working properly on a system level:

$ virsh -c qemu:///system

To test if libvirt is working properly for a user-session:

$ virsh -c qemu:///session

Management

Libvirt management is done mostly with three tools: virt-manager (GUI), virsh, and guestfish (which is part of libguestfsAUR).

virsh

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): virsh. 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*]

Storage pools

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, /var/lib/libvirt/images/ will be activated by default; on a user-session, virt-manager creates $HOME/VirtualMachines.

Print active and inactive storage pools:

$ virsh pool-list --all

Create a new pool using virsh

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

It is a good practice to dedicate a volume group to the storage pool only.

Choose a LVM volume group that differs from the pool name, otherwise when the storage pool is deleted the LVM group will be too.

Create a new pool using virt-manager

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.

Storage volumes

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.

virt-manager backing store type bug

On newer versions of virt-manager you can now specify a backing store to use when creating a new disk. This is very useful, in that you can have new domains be based on base images saving you both time and disk space when provisioning new virtual systems. There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1235406) in the current version of virt-manager which causes virt-manager to choose the wrong type of the backing image in the case where the backing image is a qcow2 type. In this case, it will errantly pick the backing type as raw. This will cause the new image to be unable to read from the backing store, and effectively remove the utility of having a backing store at all.

There is a workaround for this issue. qemu-img has long been able to do this operation directly. If you wish to have a backing store for your new domain before this bug is fixed, you may use the following command.

Then you can use this image as the base for your new domain and it will use the backing store as a COW volume saving you time and disk space.

Domains

Virtual machines are called domains. If working from the command line, use virsh to list, create, pause, shutdown domains, etc. virt-viewer can be used to view domains started with virsh. Creation of domains is typically done either graphically with virt-manager or with virt-install (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 .iso from the storage pool or an optical drive.

Print active and inactive domains:

# virsh list --all

Note:SELinux has a built-in exemption for libvirt that allows volumes in /var/lib/libvirt/images/ to be accessed. If using SELinux and there are issues with the volumes, ensure that volumes are in that directory, or ensure that other storage pools are correctly labeled.

Create a new domain using virt-install

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 virt-install and still run quite well. Minimum specifications are --name, --memory, guest storage (--disk, --filesystem, or --nodisks), and an install method (generally an .iso or CD). See virt-install(1) for more details and information about unlisted options.

Tip: Run osinfo-query --fields=name,short-id,version os to get argument for --os-variant; this will help define some specifications for the domain. However, --memory and --disk will need to be entered; one can look within the appropriate /usr/share/libosinfo/db/oses/os.xml if needing these specifications. After installing, it will likely be preferable to install the Spice Guest Tools that include the VirtIO drivers. For a Windows VirtIO network driver there is also virtio-winAUR. These drivers are referenced by a <model type='virtio' /> in the guest's .xml configuration section for the device. A bit more information can also be found on the QEMU article.

Create a new domain using virt-manager

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.

Manage a domain

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 libvirt-guests.service systemd service. This same service will resume/startup the suspended/shutdown domain automatically at host startup. Read /etc/conf.d/libvirt-guests for service options.

Edit a domain's XML configuration:

$ virsh edit domain

Note: Virtual Machines started directly by QEMU are not managable by libvirt tools.

Networks

By default, when the libvirtd systemd service is started, a NAT bridge is created called default to allow external network connectivity (IPv4-only). For other network connectivity needs, 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 additional to the default one. After creation, it needs to be specified in the respective guest's .xml configuration file.

network — a virtual network; has ability to share with other domains. Use a virtual network 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.

virsh 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 virt-manager), or to do so on creation with virt-install.

Note: libvirt handles DHCP and DNS with dnsmasq, launching a separate instance for every virtual network. It also adds iptables rules for proper routing, and enables the ip_forward kernel parameter. This also means that having dnsmasq running on the host system is not necessary to support libvirt requirements (and could interfere with libvirt dnsmasq instances).

IPv6

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 creating the following file (replace eth0 with the name of your physical interface). Reboot your machine afterwards.

/etc/sysctl.d/libvirt-bridge.conf

net.ipv6.conf.eth0.accept_ra = 2

Snapshots

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 so they have the potentiality to not take much space.

Create a snapshot

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 virsh list):

PulseAudio

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 /etc/libvirt/qemu.conf 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. First add the qemu namespace to you domain.