Virtualization Best Practices #

Virtualization offers a lot of capabilities for your environment. It can be used in multiple scenarios. To get more details about it, refer to the Virtualization Guide, and in particular to the following sections:

This best practice guide provides advice for making the right choice in your environment. It recommends or discourages the use of options depending on your workload. Fixing configuration issues and performing tuning tasks increases the performance of VM Guests near to bare metal.

Allocation of resources for VM Guests is a crucial point when administrating virtual machines. When assigning resources to VM Guests, be aware that overcommitting resources may affect the performance of the VM Host Server and the VM Guests. If all VM Guests request all their resources simultaneously, the host needs to provide them all. If not, the host's performance is negatively affected and this in turn also has negative effects on the VM Guest's performance.

4.1 Memory #

 

Linux manages memory in units called pages. On most systems the default page size is 4 KB. Linux and the CPU need to know which pages belong to which process. That information is stored in a page table. If a lot of processes are running, it takes more time to find where the memory is mapped, because of the time required to search the page table. To speed up the search, the TLB (Translation Lookaside Buffer) was invented. But on a system with a lot of memory, the TLB is not enough. To avoid any fallback to normal page table (resulting in a cache miss, which is time consuming), huge pages can be used. Using huge pages will reduce TLB overhead and TLB misses (pagewalk). A host with 32 GB (32*1014*1024 = 33,554,432 KB) of memory and a 4 KB page size has a TLB with 33,554,432/4 = 8,388,608 entries. Using a 2 MB (2048 KB) page size, the TLB only has 33554432/2048 = 16384 entries, considerably reducing the TLB misses.

4.1.1 Configuring the VM Host Server and the VM Guest to use huge pages #

 

The AMD64/Intel 64 CPU architecture supports larger pages than 4 KB: huge pages. To determine the size of huge pages available on your system (could be 2 MB or 1 GB), check the flags line in the output of /proc/cpuinfo for occurrences of pse and/or pdpe1gb.

Table 1: Determine the available huge pages size #

 

CPU flag	Huge pages size available
Empty string	No huge pages available
pse	2 MB
pdpe1gb	1 GB

Using huge pages improves the performance of VM Guests and reduces host memory consumption.

By default, the system uses THP. To make huge pages available on your system, activate it at boot time with hugepages=1, and—optionally—add the huge pages size with, for example, hugepagesz=2MB.

Note: 1 GB huge pages

1 GB pages can only be allocated at boot time and cannot be freed afterward.

To allocate and use the huge page table (HugeTlbPage), you need to mount hugetlbfs with correct permissions.

Note: Restrictions of huge pages

Even if huge pages provide the best performance, they do come with some drawbacks. You lose features such as Memory ballooning (see Section 6.1.3, “virtio balloon”), KSM (see Section 4.1.4, “KSM and page sharing”), and huge pages cannot be swapped.

Procedure 2: Configuring the use of huge pages #

 

1. Mount hugetlbfs to /dev/hugepages:

   > sudo  mount -t hugetlbfs hugetlbfs /dev/hugepages

2. To reserve memory for huge pages, use the sysctl command. If your system has a huge page size of 2 MB (2048 KB), and you want to reserve 1 GB (1,048,576 KB) for your VM Guest, you need 1,048,576/2048=512 pages in the pool:

   > sudo  sysctl vm.nr_hugepages=512

   The value is written to /proc/sys/vm/nr_hugepages and represents the current number of persistent huge pages in the kernel's huge page pool. Persistent huge pages are returned to the huge page pool when freed by a task.

3. Add the memoryBacking element in the VM Guest configuration file (by running virsh edit CONFIGURATION).

   <memoryBacking>
     <hugepages/>
   </memoryBacking>

4. Start your VM Guest and check on the host whether it uses hugepages:

   > cat /proc/meminfo | grep HugePages_
   HugePages_Total:1     512
   HugePages_Free:2       92
   HugePages_Rsvd:3        0
   HugePages_Surp:4        0

   1	Size of the pool of huge pages
   2	Number of huge pages in the pool that are not yet allocated
   3	Number of huge pages for which a commitment to allocate from the pool has been made, but no allocation has yet been made
   4	Number of huge pages in the pool above the value in /proc/sys/vm/nr_hugepages. The maximum number of surplus huge pages is controlled by /proc/sys/vm/nr_overcommit_hugepages

4.1.2 Transparent huge pages #

 

Transparent huge pages (THP) provide a way to dynamically allocate huge pages with the khugepaged kernel thread, rather than manually managing their allocation and use. Workloads with contiguous memory access patterns can benefit greatly from THP. A 1000 fold decrease in page faults can be observed when running synthetic workloads with contiguous memory access patterns. Conversely, workloads with sparse memory access patterns (like databases) may perform poorly with THP. In such cases, it may be preferable to disable THP by adding the kernel parameter transparent_hugepage=never, rebuild your grub2 configuration, and reboot. Verify if THP is disabled with:

> cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

If disabled, the value never is shown in square brackets like in the example above.

Note: Xen

THP is not available under Xen.

4.1.3 Xen-specific memory notes #

 

4.1.3.1 Managing domain-0 memory #

 

In previous versions of SUSE Linux Enterprise Server, the default memory allocation scheme of a Xen host was to allocate all host physical memory to Dom0 and enable auto-ballooning. Memory was automatically ballooned from Dom0 when additional domains were started. This behavior has always been error prone and disabling it was strongly encouraged. Starting in SUSE Linux Enterprise Server 15 SP1, auto-ballooning has been disabled by default and Dom0 is given 10% of host physical memory + 1 GB. For example, on a host with 32 GB of physical memory, 4.2 GB of memory is allocated to Dom0.

The use of dom0_mem Xen command-line option in /etc/default/grub is still supported and encouraged (see Section 7.5, “Change kernel parameters at boot time” for more information). You can restore the old behavior by setting dom0_mem to the host physical memory size and enabling the autoballoon setting in /etc/xen/xl.conf.

4.1.4 KSM and page sharing #

 

Kernel Samepage Merging is a kernel feature that reduces memory consumption on the VM Host Server by sharing blocks of memory that VM Guests have in common. The KSM daemon ksmd periodically scans user memory, looking for pages with identical contents, which can be replaced by a single write-protected page. To enable the KSM service, first make sure that the package qemu-ksm is installed, then run the command:

> sudo  systemctl enable --now ksm.service

Alternatively, it can also be started by running the command:

#  echo 1 > /sys/kernel/mm/ksm/run

One advantage of using KSM from a VM Guest's perspective is that all guest memory is backed by host anonymous memory. You can share pagecache, tmpfs or any kind of memory allocated in the guest.

KSM is controlled by sysfs. You can check KSM's values in /sys/kernel/mm/ksm/:

• pages_shared: the number of shared pages that are being used (read-only).

• pages_sharing: the number of sites sharing the pages (read-only).

• pages_unshared: the number of pages that are unique and repeatedly checked for merging (read-only).

• pages_volatile: the number of pages that are changing too fast to be considered for merging (read-only).

• full_scans: the number of times all mergeable areas have been scanned (read-only).

• sleep_millisecs: the number of milliseconds ksmd should sleep before the next scan. A low value will overuse the CPU, consuming CPU time that could be used for other tasks. We recommend a value greater than 1000.

• pages_to_scan: the number of present pages to scan before ksmd goes to sleep. A high value will overuse the CPU. We recommend starting with a value of 1000 and then adjusting based on the KSM results observed while testing your deployment.

• merge_across_nodes: by default, the system merges pages across NUMA nodes. Set this option to 0 to disable this behavior.

Note: Use cases

KSM is a good technique to over-commit host memory when running multiple instances of the same application or VM Guest. When applications and VM Guest are heterogeneous and do not share any common data, it is preferable to disable KSM. To do that, run:

> sudo  systemctl disable --now ksm.service

Alternatively, it can also be disabled by running the command:

#  echo 0 > /sys/kernel/mm/ksm/run

In a mixed heterogeneous and homogeneous environment, KSM can be enabled on the host but disabled on a per VM Guest basis. Use virsh edit to disable page sharing of a VM Guest by adding the following to the guest's XML configuration:

<memoryBacking>
   <nosharepages/>
</memoryBacking>

Warning: Avoid out-of-memory conditions

KSM can free up certain memory on the host system, but the administrator should reserve enough swap to avoid out-of-memory conditions if that shareable memory decreases. If the amount of shareable memory decreases, the use of physical memory is increased.

Warning: KSM as a side channel

Because of its nature, KSM can form a side channel between otherwise isolated guests. It is discouraged to enable KSM in environments where guests from different security domains are executed.

Warning: Memory access latencies

By default, KSM will merge common pages across NUMA nodes. If the merged, common page is now located on a distant NUMA node (relative to the node running the VM Guest vCPUs), this may degrade VM Guest performance. If increased memory access latencies are noticed in the VM Guest, disable cross-node merging with the merge_across_nodes sysfs control:

#  echo 0 > /sys/kernel/mm/ksm/merge_across_nodes

4.1.5 VM Guest: memory hotplug #

 

To optimize the usage of your host memory, it may be useful to hotplug more memory for a running VM Guest when required. To support memory hotplugging, you must first configure the <maxMemory> tag in the VM Guest's configuration file:

<maxMemory1 slots='16'2 unit='KiB'>209715203</maxMemory>
  <memory4 unit='KiB'>1048576</memory>
<currentMemory5 unit='KiB'>1048576</currentMemory>

1	Runtime maximum memory allocation of the guest
2	Number of slots available for adding memory to the guest
3	Valid units are: “KB” for kilobytes (1,000 bytes) “k” or “KiB” for kibibytes (1,024 bytes) “MB” for megabytes (1,000,000 bytes) “M” or “MiB” for mebibytes (1,048,576 bytes) “GB” for gigabytes (1,000,000,000 bytes) “G” or “GiB” for gibibytes (1,073,741,824 bytes) “TB” for terabytes (1,000,000,000,000 bytes) “T” or “TiB” for tebibytes (1,099,511,627,776 bytes)
4	Maximum allocation of memory for the guest at boot time
5	Actual allocation of memory for the guest

To hotplug memory devices into the slots, create a file mem-dev.xml like the following:

<memory model='dimm'>
  <target>
  <size unit='KiB'>524287</size>
  <node>0</node>
  </target>
</memory>

And attach it with the following command:

> virsh attach-device vm-name mem-dev.xml

For memory device hotplug, the guest must have at least 1 NUMA cell defined (see Section 4.6.3.1, “VM Guest virtual NUMA topology”).

#  echo 35 > /proc/sys/vm/swappiness

> free -h
total       used       free     shared    buffers     cached
Mem:      24616680    4991492   19625188     167056     144340    2152408
-/+ buffers/cache:    2694744   21921936
Swap:      6171644          0    6171644

vm.swappiness = 35

<memtune>1
  <hard_limit unit='G'>1</hard_limit>2
  <soft_limit unit='M'>128</soft_limit>3
  <swap_hard_limit unit='G'>2</swap_hard_limit>4
</memtune>

w /sys/block/sda/queue/scheduler - - - - mq-deadline
w /sys/block/sdb/queue/scheduler - - - - none

fs.aio-max-nr = 1048576

nfs_server:/exported/vm_images1 /mnt/images2 nfs3 rw4,hard5,sync6, rsize=81927,wsize=81928 0 0

> sudo  nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
6401066    198          0          0

4.5 CPUs #

 

Host CPU “components” will be “translated” to virtual CPUs in a VM Guest when being assigned. These components can either be:

• CPU processor: this describes the main CPU unit, which normally has multiple cores and may support Hyper-Threading.

• CPU core: a main CPU unit can provide more than one core, and the proximity of cores speeds up the computation process and reduces energy costs.

• CPU Hyper-Threading: this implementation is used to improve the parallelization of computations, but this is not as efficient as a dedicated core.

4.5.1 Assigning CPUs #

 

CPU overcommit occurs when the cumulative number of virtual CPUs of all VM Guests becomes higher than the number of host CPUs. Best performance is achieved when there is no overcommit and each virtual CPU matches one hardware processor or core on the VM Host Server. VM Guests running on an overcommitted host will experience increased latency and a negative effect on per-VM Guest throughput is often observed. Therefore, try to avoid overcommitting CPUs.

Deciding whether to allow CPU overcommit or not requires good a priori knowledge of workload as a whole. For example, if you know that all the VM Guests' virtual CPUs will not be loaded over 50%, then you can assume that overcommitting the host by a factor of 2 (which means having 128 virtual CPUs in total, on a host with 64 CPUs) will work well. However, if you know that all the virtual CPUs of the VM Guests will try to run at 100% for most of the time, then even having one virtual CPU more than the host has CPUs is already a misconfiguration.

Overcommitting to a point where the cumulative number of virtual CPUs is higher than 8 times the number of physical cores of the VM Host Server may lead to a malfunctioning and unstable system and should hence be avoided.

Unless you know exactly how many virtual CPUs are required for a VM Guest, start with one. Target a CPU workload of approximately 70% inside your VM (see Section 2.3, “Processes” for information on monitoring tools). If you allocate more processors than needed in the VM Guest, this will negatively affect the performance of host and guest. Cycle efficiency will be degraded, as the unused vCPU will still cause timer interrupts. In case you primarily run single threaded applications on a VM Guest, a single virtual CPU is the best choice.

A single VM Guest with more virtual CPUs than the VM Host Server has CPUs is always a misconfiguration.

4.5.2 VM Guest CPU configuration #

 

This section describes how to choose and configure a CPU type for a VM Guest. You will also learn how to pin virtual CPUs to physical CPUs on the host system. For more information about virtual CPU configuration and tuning parameters, refer to the libvirt documentation at https://libvirt.org/formatdomain.html#elementsCPU.

4.5.2.1 Virtual CPU models and features #

 

The CPU model and topology can be specified individually for each VM Guest. Configuration options range from selecting specific CPU models to excluding certain CPU features. Predefined CPU models are listed in files in the directory /usr/share/libvirt/cpu_map/. A CPU model and topology that is similar to the host generally provides the best performance. The host system CPU model and topology can be displayed by running virsh capabilities.

Changing the default virtual CPU configuration will require a VM Guest shutdown when migrating it to a host with different hardware. More information on VM Guest migration is available in Chapter 17, Migrating VM Guests.

To specify a particular CPU model for a VM Guest, add a respective entry to the VM Guest configuration file. The following example configures a Broadwell CPU with the invariant TSC feature:

<cpu mode='custom' match='exact'>
  <model>Broadwell</model>
  <feature name='invtsc'/>
  </cpu>

For a virtual CPU that most closely resembles the host physical CPU, <cpu mode='host-passthrough'> can be used. A host-passthrough CPU model may not exactly resemble the host physical CPU, since, by default, KVM will mask any non-migratable features. For example, invtsc is not included in the virtual CPU feature set. Changing the default KVM behavior is not directly supported through libvirt, although it does allow arbitrary pass-through of KVM command-line arguments. Continuing with the invtsc example, you can achieve pass-through of the host CPU (including invtsc) with the following command-line pass-through in the VM Guest configuration file:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
     <qemu:commandline>
     <qemu:arg value='-cpu'/>
     <qemu:arg value='host,migratable=off,+invtsc'/>
     </qemu:commandline>
     ...
     </domain>

Note: The host-passthrough mode

Since host-passthrough exposes the physical CPU details to the virtual CPU, migration to dissimilar hardware is not possible. See Section 4.5.2.3, “Virtual CPU migration considerations” for more information.

4.5.2.2 Virtual CPU pinning #

 

Virtual CPU pinning is used to constrain virtual CPU threads to a set of physical CPUs. The vcpupin element specifies the physical host CPUs that a virtual CPU can use. If this element is not set and the attribute cpuset of the vcpu element is not specified, the virtual CPU is free to use any of the physical CPUs.

CPU intensive workloads can benefit from virtual CPU pinning by increasing the physical CPU cache hit ratio. To pin a virtual CPU to a specific physical CPU, run the following commands:

> virsh vcpupin DOMAIN_ID --vcpu vCPU_NUMBER
VCPU: CPU Affinity
----------------------------------
0: 0-7
# virsh vcpupin SLE15 --vcpu 0 0 --config

The last command generates the following entry in the XML configuration:

<cputune>
   <vcpupin vcpu='0' cpuset='0'/>
</cputune>

Note: Virtual CPU pinning on NUMA nodes

To confine a VM Guest's CPUs and its memory to a NUMA node, you can use virtual CPU pinning and memory allocation policies on a NUMA system. See Section 4.6, “NUMA tuning” for more information related to NUMA tuning.

Warning: Virtual CPU pinning and live migration

Even though vcpupin can improve performance, it can complicate live migration. See Section 4.5.2.3, “Virtual CPU migration considerations” for more information on virtual CPU migration considerations.

4.5.2.3 Virtual CPU migration considerations #

 

Selecting a virtual CPU model containing all the latest features may improve performance of a VM Guest workload, but often at the expense of migratability. Unless all hosts in the cluster contain the latest CPU features, migration can fail when a destination host lacks the new features. If migratability of a virtual CPU is preferred over the latest CPU features, a normalized CPU model and feature set should be used. The virsh cpu-baseline command can help define a normalized virtual CPU that can be migrated across all hosts. The following command, when run on each host in the migration cluster, illustrates the collection of all hosts' capabilities in all-hosts-caps.xml.

> sudo  virsh capabilities >> all-hosts-cpu-caps.xml

With the capabilities of each host collected in all-hosts-caps.xml, use virsh cpu-baseline to create a virtual CPU definition that will be compatible across all hosts.

> sudo  virsh cpu-baseline all-hosts-caps.xml

The resulting virtual CPU definition can be used as the cpu element in the VM Guest configuration file.

At a logical level, virtual CPU pinning is a form of hardware pass-through. CPU pinning couples physical resources to virtual resources, which can also be problematic for migration. For example, the migration will fail if the requested physical resources are not available on the destination host, or if the source and destination hosts have different NUMA topologies. For more recommendations about Live Migration, see Section 17.2, “Migration requirements”.

4.6 NUMA tuning #

 

NUMA is an acronym for Non Uniform Memory Access. A NUMA system has multiple physical CPUs, each with local memory attached. Each CPU can also access other CPUs' memory, known as “remote memory access”, but it is much slower than accessing local memory. NUMA systems can negatively affect VM Guest performance if not tuned properly. Although ultimately tuning is workload dependent, this section describes controls that should be considered when deploying VM Guests on NUMA hosts. Always consider your host topology when configuring and deploying VMs.

SUSE Linux Enterprise Server contains a NUMA auto-balancer that strives to reduce remote memory access by placing memory on the same NUMA node as the CPU processing it. Standard tools such as cgset and virtualization tools such as libvirt provide mechanisms to constrain VM Guest resources to physical resources.

numactl is used to check for host NUMA capabilities:

> sudo  numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 72 73 74 75 76 77 78
79 80 81 82 83 84 85 86 87 88 89
node 0 size: 31975 MB
node 0 free: 31120 MB
node 1 cpus: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 90 91 92 93
94 95 96 97 98 99 100 101 102 103 104 105 106 107
node 1 size: 32316 MB
node 1 free: 31673 MB
node 2 cpus: 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 108 109 110
111 112 113 114 115 116 117 118 119 120 121 122 123 124 125
node 2 size: 32316 MB
node 2 free: 31726 MB
node 3 cpus: 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 126 127 128
129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
node 3 size: 32314 MB
node 3 free: 31387 MB
node distances:
node   0   1   2   3
0:  10  21  21  21
1:  21  10  21  21
2:  21  21  10  21
3:  21  21  21  10

The numactl output shows this is a NUMA system with 4 nodes or cells, each containing 36 CPUs and approximately 32G memory. virsh capabilities can also be used to examine the systems NUMA capabilities and CPU topology.

4.6.1 NUMA balancing #

 

On NUMA machines, there is a performance penalty if remote memory is accessed by a CPU. Automatic NUMA balancing scans a task's address space and unmaps pages. By doing so, it detects whether pages are properly placed or whether to migrate the data to a memory node local to where the task is running. In defined intervals (configured with numa_balancing_scan_delay_ms), the task scans the next scan size number of pages (configured with numa_balancing_scan_size_mb) in its address space. When the end of the address space is reached, the scanner restarts from the beginning.

Higher scan rates cause higher system overhead as page faults must be trapped and data needs to be migrated. However, the higher the scan rate, the more quickly a task's memory migrates to a local node when the workload pattern changes. This minimizes the performance impact caused by remote memory accesses. These sysctl directives control the thresholds for scan delays and the number of pages scanned:

> sudo  sysctl -a | grep numa_balancing
kernel.numa_balancing = 11
kernel.numa_balancing_scan_delay_ms = 10002
kernel.numa_balancing_scan_period_max_ms = 600003
kernel.numa_balancing_scan_period_min_ms = 10004
kernel.numa_balancing_scan_size_mb = 2565

1	Enables/disables automatic page fault-based NUMA balancing
2	Starting scan delay used for a task when it initially forks
3	Maximum time in milliseconds to scan a task's virtual memory
4	Minimum time in milliseconds to scan a task's virtual memory
5	Size in megabytes' worth of pages to be scanned for a given scan

For more information, see Chapter 11, Automatic Non-Uniform Memory Access (NUMA) balancing.

The main goal of automatic NUMA balancing is either to reschedule tasks on the same node's memory (so the CPU follows the memory), or to copy the memory's pages to the same node (so the memory follows the CPU).

Warning: Task placement

There are no rules to define the best place to run a task, because tasks could share memory with other tasks. For the best performance, we recommend to group tasks sharing memory on the same node. Check NUMA statistics with # cat /proc/vmstat | grep numa_.

4.6.2 Memory allocation control with the CPUset controller #

 

The cgroups cpuset controller can be used confine memory used by a process to a NUMA node. There are three cpuset memory policy modes available:

• interleave: this is a memory placement policy which is also known as round-robin. This policy can provide substantial improvements for jobs that need to place thread local data on the corresponding node. When the interleave destination is not available, it will be moved to another node.

• bind: this will place memory only on one node, which means in case of insufficient memory, the allocation will fail.

• preferred: this policy will apply a preference to allocate memory to a node. If there is not enough space for memory on this node, it will fall back to another node.

You can change the memory policy mode with the cgset tool from the libcgroup-tools package:

> sudo  cgset -r cpuset.mems=NODE sysdefault/libvirt/qemu/KVM_NAME/emulator

To migrate pages to a node, use the migratepages tool:

> migratepages PID FROM-NODE TO-NODE

To check everything is fine. use: cat /proc/PID/status | grep Cpus.

Note: Kernel NUMA/cpuset memory policy

For more information, see Kernel NUMA memory policy and cpusets memory policy. Check also the Libvirt NUMA Tuning documentation.

4.6.3 VM Guest: NUMA related configuration #

 

libvirt allows to set up virtual NUMA and memory access policies. Configuring these settings is not supported by virt-install or virt-manager and needs to be done manually by editing the VM Guest configuration file with virsh edit.

4.6.3.1 VM Guest virtual NUMA topology #

 

Creating a VM Guest virtual NUMA (vNUMA) policy that resembles the host NUMA topology can often increase performance of traditional large, scale-up workloads. VM Guest vNUMA topology can be specified using the numa element in the XML configuration:

<cpu>
...
  <numa>
    <cell1 id="0"2 cpus='0-1'3 memory='512000' unit='KiB'/>
    <cell id="1" cpus='2-3' memory='256000'4
    unit='KiB'5 memAccess='shared'6/>
  </numa>
  ...
</cpu>

1	Each cell element specifies a vNUMA cell or node
2	All cells should have an id attribute, allowing to reference the cell in other configuration blocks. Otherwise, cells are assigned IDs in ascending order starting from 0.
3	The CPU or range of CPUs that are part of the node
4	The node memory
5	Units in which node memory is specified
6	Optional attribute which can control whether the memory is to be mapped as shared or private. This is valid only for hugepages-backed memory.

To find where the VM Guest has allocated its pages. use: cat /proc/PID/numa_maps and cat /sys/fs/cgroup/memory/sysdefault/libvirt/qemu/KVM_NAME/memory.numa_stat.

Warning: NUMA specification

The libvirt VM Guest NUMA specification is currently only available for QEMU/KVM.

4.6.3.2 Memory allocation control with libvirt #

 

If the VM Guest has a vNUMA topology (see Section 4.6.3.1, “VM Guest virtual NUMA topology”), memory can be pinned to host NUMA nodes using the numatune element. This method is currently only available for QEMU/KVM guests. See Important: Non-vNUMA VM Guest for how to configure non-vNUMA VM Guests.

<numatune>
    <memory mode="strict"1 nodeset="1-4,^3"2/>
    <memnode3 cellid="0"4 mode="strict" nodeset="1"/>
    <memnode cellid="2" placement="strict"5 mode="preferred" nodeset="2"/>
</numatune>

1	Policies available are: interleave (round-robin like), strict (default) or preferred.
2	Specify the NUMA nodes.
3	Specify memory allocation policies for each guest NUMA node (if this element is not defined, then this will fall back and use the memory element).
4	Addresses the guest NUMA node for which the settings are applied.
5	The placement attribute can be used to indicate the memory placement mode for a domain process, the value can be auto or strict.

Important: Non-vNUMA VM Guest

On a non-vNUMA VM Guest, pinning memory to host NUMA nodes is done as in the following example:

<numatune>
   <memory mode="strict" nodeset="0-1"/>
</numatune>

In this example, memory is allocated from the host nodes 0 and 1. If these memory requirements cannot be fulfilled, starting the VM Guest will fail. virt-install also supports this configuration with the --numatune option.

Warning: Memory and CPU across NUMA nodes

You should avoid allocating VM Guest memory across NUMA nodes, and prevent virtual CPUs from floating across NUMA nodes.

Images are virtual disks used to store the operating system and data of VM Guests. They can be created, maintained and queried with the qemu-img command. Refer to Section 36.2.2, “Creating, converting, and checking disk images” for more information on the qemu-img tool and examples.

5.1 VM Guest image formats #

 

Certain storage formats which QEMU recognizes have their origins in other virtualization technologies. By recognizing these formats, QEMU can use either data stores or entire guests that were originally targeted to run under these other virtualization technologies. Certain formats are supported only in read-only mode. To use them in read/write mode, convert them to a fully supported QEMU storage format (using qemu-img). Otherwise they can only be used as read-only data store in a QEMU guest.

Use qemu-img info VMGUEST.IMG to get information about an existing image, such as the format, the virtual size, the physical size and snapshots, if available.

Note: Performance

It is recommended to convert the disk images to either raw or qcow2 to achieve good performance.

Warning: Encrypted images cannot be compressed

When you create an image, you cannot use compression (-c) in the output file together with the encryption option (-e).

5.1.1 Raw format #

 

• This format is simple and easily exportable to all other emulators/hypervisors.

• It provides the best performance (least I/O overhead).

• It occupies all allocated space on the file system.

• The raw format allows to copy a VM Guest image to a physical device (dd if=VMGUEST.RAW of=/dev/sda).

• It is byte-for-byte the same as what the VM Guest sees, so this wastes a lot of space.

5.1.2 qcow2 format #

 

• Use this to have smaller images (useful if your file system does not support holes).

• It has optional AES encryption (now deprecated).

• Zlib-based compression option.

• Supports multiple VM snapshots (internal, external).

• Improved performance and stability.

• Supports changing the backing file.

• Supports consistency checks.

• Less performance than raw format.

l2-cache-size

qcow2 can provide the same performance for random read/write access as raw format, but it needs a well-sized cache size. By default, cache size is set to 1 MB. This will give good performance up to a disk size of 8 GB. If you need a bigger disk size, you need to adjust the cache size. For a disk size of 64 GB (64*1024 = 65536), you need 65536 / 8192 B = 8 MB of cache (-drive format=qcow2,l2-cache-size=8M).

Cluster size

The qcow2 format offers the capability to change the cluster size. The value must be between 512 KB and 2 MB. Smaller cluster sizes can improve the image file size, whereas larger cluster sizes provide better performance.

Preallocation

An image with preallocated metadata is initially larger but can improve performance when the image needs to grow.

Lazy refcounts

Reference count updates are postponed with the goal of avoiding metadata I/O and improving performance. This is particularly beneficial with cache=writethrough. This option does not batch metadata updates, but if in case of host crash, the reference count tables must be rebuilt, this is done automatically at the next open with qemu-img check -r all and takes a certain amount of time.

5.1.3 qed format #

 

qed is a follow-on qcow (QEMU Copy On Write) format. Because qcow2 provides all the benefits of qed and more, qed is now deprecated.

5.1.4 VMDK format #

 

VMware 3, 4 or 6 image format for exchanging images with that product.

5.2 Overlay disk images #

 

The qcow2 and qed formats provide a way to create a base image (also called backing file) and overlay images on top of the base image. A backing file is useful for reverting to a known state and discarding the overlay. If you write to the image, the backing image will be untouched and all changes will be recorded in the overlay image file. The backing file will never be modified unless you use the commit monitor command (or qemu-img commit).

To create an overlay image:

# qemu-img create -o1backing_file=vmguest.raw2,backing_fmt=raw3\
     -f4 qcow2 vmguest.cow5

1	Use -o ? for an overview of available options.
2	The backing file name.
3	Specify the file format for the backing file.
4	Specify the image format for the VM Guest.
5	Image name of the VM Guest, it will only record the differences from the backing file.

Warning: Backing image path

You should not change the path to the backing image, otherwise you will need to adjust it. The path is stored in the overlay image file. To update the path, make a symbolic link from the original path to the new path and then use the qemu-img rebase option.

# ln -sf /var/lib/images/OLD_PATH/vmguest.raw  \
 /var/lib/images/NEW_PATH/vmguest.raw
# qemu-img rebase1 -u2 -b3 \
 /var/lib/images/OLD_PATH/vmguest.raw /var/lib/images/NEW_PATH/vmguest.cow

1	The rebase subcommand tells qemu-img to change the backing file image.
2	The -u option activates the unsafe mode (see note below). There are two different modes in which rebase can operate: Safe: this is the default mode and performs a real rebase operation. The safe mode is a time-consuming operation. Unsafe: the unsafe mode (-u) only changes the backing files name and the format of the file name, making no checks on the file's contents. Use this mode to rename or move a backing file.
3	The backing image to be used is specified with -b and the image path is the last argument of the command.

A common use is to initiate a new guest with the backing file. Let's assume we have a sle15_base.img VM Guest ready to be used (fresh installation without any modification). This will be our backing file. Now you need to test a new package, on an updated system and on a system with a different kernel. We can use sle15_base.img to instantiate the new SUSE Linux Enterprise VM Guest by creating a qcow2 overlay file pointing to this backing file (sle15_base.img).

In our example, we will use sle15_updated.qcow2 for the updated system, and sle15_kernel.qcow2 for the system with a different kernel.

To create the two thin provisioned systems, use the qemu-img command line with the -b option:

# qemu-img create -b /var/lib/libvirt/sle15_base.img -f qcow2 \
/var/lib/libvirt/sle15_updated.qcow2
Formatting 'sle15_updated.qcow2', fmt=qcow2 size=17179869184
backing_file='sle15_base.img' encryption=off cluster_size=65536
lazy_refcounts=off nocow=off
# qemu-img create -b /var/lib/libvirt/sle15_base.img -f qcow2 \
/var/lib/libvirt/sle15_kernel.qcow2
Formatting 'sle15_kernel.qcow2', fmt=qcow2 size=17179869184
backing_file='vmguest-sle15_base.img' encryption=off cluster_size=65536
lazy_refcounts=off nocow=off

The images are now usable, and you can do your test without touching the initial sle15_base.img backing file. All changes will be stored in the new overlay images. You can also use these new images as a backing file and create a new overlay.

# qemu-img create -b sle15_kernel.qcow2 -f qcow2 sle15_kernel_TEST.qcow2

When using qemu-img info with the option --backing-chain, it will return all information about the entire backing chain recursively:

# qemu-img info --backing-chain
/var/lib/libvirt/images/sle15_kernel_TEST.qcow2
image: sle15_kernel_TEST.qcow2
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 196K
cluster_size: 65536
backing file: sle15_kernel.qcow2
Format specific information:
compat: 1.1
lazy refcounts: false

image: sle15_kernel.qcow2
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 196K
cluster_size: 65536
backing file: SLE15.qcow2
Format specific information:
compat: 1.1
lazy refcounts: false

image: sle15_base.img
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 16G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true

Figure 1: Understanding image overlay #

 

5.3 Opening a VM Guest image #

 

To access the file system of an image, use the guestfs-tools. If you do not have this tool installed on your system, you can mount an image with other Linux tools. Avoid accessing an untrusted or unknown VM Guest's image system because this can lead to security issues (for more information, read D. Berrangé's post).

5.3.1 Opening a raw image #

 

Procedure 5: Mounting a raw image #

 

1. To mount the image, find a free loop device. The following command displays the first unused loop device, /dev/loop1 in this example.

   # losetup -f
   /dev/loop1

2. Associate an image (SLE15.raw in this example) with the loop device:

   # losetup /dev/loop1 SLE15.raw

3. Check whether the image has successfully been associated with the loop device by getting detailed information about the loop device:

   # losetup -l
   NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
   /dev/loop1         0      0         0  0    /var/lib/libvirt/images/SLE15.raw

4. Check the image's partitions with kpartx:

   # kpartx -a1 -v2 /dev/loop1
   add map loop1p1 (254:1): 0 29358080 linear /dev/loop1 2048

   1	Add partition device mappings.
   2	Verbose mode.

5. Now mount the image partitions (to /mnt/sle15mount in the following example):

   # mkdir /mnt/sle15mount
   # mount /dev/mapper/loop1p1 /mnt/sle15mount

Note: Raw image with LVM

If your raw image contains an LVM volume group, you should use LVM tools to mount the partition. Refer to Section 5.3.3, “Opening images containing LVM”.

Procedure 6: Unmounting a raw image #

 

1. Unmount all mounted partitions of the image, for example:

   # umount /mnt/sle15mount

2. Delete partition device mappings with kpartx:

   # kpartx -d /dev/loop1

3. Detach the devices with losetup

   # losetup -d /dev/loop1

5.3.2 Opening a qcow2 image #

 

Procedure 7: Mounting a qcow2 image #

 

1. First, you need to load the nbd (network block devices) module. The following example loads it with support for 16 block devices (max_part=16). Check with dmesg whether the operation was successful:

   # modprobe nbd max_part=16
   # dmesg | grep nbd
   [89155.142425] nbd: registered device at major 43

2. Connect the VM Guest image, for example, SLE15.qcow2, to an NBD device (/debv/nbd0 in the following example) with the qemu-nbd command. Use a free NBD device:

   # qemu-nbd -c1 /dev/nbd02 SLE15.qcow23

   1	Connect SLE15.qcow2 to the local NBD device /dev/nbd0
   2	NBD device to use
   3	VM Guest image to use

   

   Tip: Checking for a free NBD device

   To check whether an NBD device is free, run the following command:

   # lsof /dev/nbd0
   COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
   qemu-nbd 15149 root   10u   BLK   43,0      0t0 47347 /dev/nbd0

   If the command produces an output like in the example above, the device is busy (not free). This can also be confirmed by the presence of the /sys/devices/virtual/block/nbd0/pid file.

3. Inform the operating system about partition table changes with partprobe:

   # partprobe /dev/nbd0 -s
   /dev/nbd0: msdos partitions 1 2
   # dmesg | grep nbd0 | tail -1
   [89699.082206]  nbd0: p1 p2

4. In the example above, the SLE15.qcow2 contains two partitions: /dev/nbd0p1 and /dev/nbd0p2. Before mounting these partitions, use vgscan to check whether they belong to an LVM volume:

   # vgscan -v
       Wiping cache of LVM-capable devices
       Wiping internal VG cache
       Reading all physical volumes. This may take a while...
       Using volume group(s) on command line.
       No volume groups found.

5. If no LVM volume has been found, you can mount the partition with mount:

   # mkdir /mnt/nbd0p2
   # mount /dev/nbd0p1 /mnt/nbd0p2

   Refer to Section 5.3.3, “Opening images containing LVM” for information on how to handle LVM volumes.

Procedure 8: Unmounting a qcow2 image #

 

1. Unmount all mounted partitions of the image, for example:

   # umount /mnt/nbd0p2

2. Disconnect the image from the /dev/nbd0 device.

   # qemu-nbd -d /dev/nbd0

5.3.3 Opening images containing LVM #

 

Warning

If your VM Host Server uses the VG name system, and the guest image also uses the VG name system, LVM will complain during its activation. A workaround is to temporarily rename the guest VG, while a correct approach is to use different VG names for the guests than for the VM Host Server.

Procedure 9: Mounting images containing LVM #

 

1. To check images for LVM groups, use vgscan -v. If an image contains LVM groups, the output of the command looks like the following:

   # vgscan -v
   Wiping cache of LVM-capable devices
   Wiping internal VG cache
   Reading all physical volumes.  This may take a while...
   Finding all volume groups
   Finding volume group "system"
   Found volume group "system" using metadata type lvm2

2. The system LVM volume group has been found on the system. You can get more information about this volume with vgdisplay VOLUMEGROUPNAME (in our case VOLUMEGROUPNAME is system). You should activate this volume group to expose LVM partitions as devices so the system can mount them. Use vgchange:

   # vgchange -ay -v
   Finding all volume groups
   Finding volume group "system"
   Found volume group "system"
   activation/volume_list configuration setting not defined: Checking only
   host tags for system/home
   Creating system-home
   Loading system-home table (254:0)
   Resuming system-home (254:0)
   Found volume group "system"
   activation/volume_list configuration setting not defined: Checking only
   host tags for system/root
   Creating system-root
   Loading system-root table (254:1)
   Resuming system-root (254:1)
   Found volume group "system"
   activation/volume_list configuration setting not defined: Checking only
   host tags for system/swap
   Creating system-swap
   Loading system-swap table (254:2)
   Resuming system-swap (254:2)
   Activated 3 logical volumes in volume group system
       3 logical volume(s) in volume group "system" now active

3. All partitions in the volume group will be listed in the /dev/mapper directory. You can simply mount them now.

   # ls /dev/mapper/system-*
   /dev/mapper/system-home  /dev/mapper/system-root /dev/mapper/system-swap
   
   # mkdir /mnt/system-root
   # mount  /dev/mapper/system-root /mnt/system-root
   
   # ls /mnt/system-root/
   bin   dev  home  lib64       mnt  proc        root  sbin     srv  tmp  var
   boot  etc  lib   lost+found  opt  read-write  run   selinux  sys  usr

Procedure 10: Unmounting images containing LVM #

 

1. Unmount all partitions (with umount)

   # umount /mnt/system-root

2. Deactivate the LVM volume group (with vgchange -an VOLUMEGROUPNAME)

   # vgchange -an -v system
   Using volume group(s) on command line
   Finding volume group "system"
   Found volume group "system"
   Removing system-home (254:0)
   Found volume group "system"
   Removing system-root (254:1)
   Found volume group "system"
   Removing system-swap (254:2)
   Deactivated 3 logical volumes in volume group system
   0 logical volume(s) in volume group "system" now active

3. Now you have two choices:

   • With a qcow2 image, proceed as described in Step 2 (qemu-nbd -d /dev/nbd0).

   • With a raw image, proceed as described in Step 2 (kpartx -d /dev/loop1; losetup -d /dev/loop1).

   

   Important: Check for a successful unmount

   You should double-check that unmounting succeeded by using a system command like losetup, qemu-nbd, mount or vgscan. If this is not the case, you may have trouble using the VM Guest because its system image is used in different places.

<filesystem type='mount'1 accessmode='mapped'2>
   <source dir='/data/shared'3>
   <target dir='shared'4/>
</filesystem>

# mkdir /opt/mnt_shared
# mount shared -t 9p /opt/mnt_shared -o trans=virtio

Copyright © 2006 – 2024 SUSE LLC y colaboradores. Reservados todos los derechos.

Está permitido copiar, distribuir y modificar este documento según los términos de la licencia de documentación gratuita GNU, versión 1.2 o (según su criterio) versión 1.3. Esta información de copyright y licencia deberán permanecer inalterados. En la sección titulada “GNU Free Documentation License” (Licencia de documentación gratuita GNU) se incluye una copia de la versión 1.2 de la licencia.

Para obtener información sobre las marcas comerciales de SUSE, consulte https://www.suse.com/company/legal/. Todas las marcas comerciales de otros fabricantes son propiedad de sus respectivas empresas. Los símbolos de marcas comerciales (®, ™, etc.) indican marcas comerciales de SUSE y sus afiliados. Los asteriscos (*) indican marcas comerciales de otros fabricantes.

Toda la información recogida en esta publicación se ha compilado prestando toda la atención posible al más mínimo detalle. Sin embargo, esto no garantiza una precisión total. Ni SUSE LLC, ni sus filiales, ni los autores o traductores serán responsables de los posibles errores o las consecuencias que de ellos pudieran derivarse.

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

You may copy and distribute the Document in any medium, either commercially or non-commercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled “GNU
Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.