Lines Matching +full:always +full:- +full:running
2 Running nested guests with KVM
6 can be KVM-based or a different hypervisor). The straightforward
10 .----------------. .----------------.
15 |----------------'--'----------------|
20 .------------------------------------------------------.
23 |------------------------------------------------------|
25 '------------------------------------------------------'
29 - L0 – level-0; the bare metal host, running KVM
31 - L1 – level-1 guest; a VM running on L0; also called the "guest
32 hypervisor", as it itself is capable of running KVM.
34 - L2 – level-2 guest; a VM running on L1, this is the "nested guest"
40 For example, s390x always has an LPAR (LogicalPARtition)
41 hypervisor running on bare metal, adding another layer and
43 metal, running the LPAR hypervisor), L1 (host hypervisor), L2
46 This document will stick with the three-level terminology (L0,
52 ---------
57 - As a developer, you want to test your software on different operating
60 hypervisor" (level-1 guest). This in turn allows you to create
61 multiple nested guests (level-2 guests), running different OSes, on
64 - Live migration of "guest hypervisors" and their nested guests, for
67 - VM image creation tools (e.g. ``virt-install``, etc) often run
70 - Some OSes use virtualization internally for security (e.g. to let
75 -----------------------
81 In case you are running a Linux kernel older than v4.19, to enable
89 $ lsmod | grep -i kvm
95 $ modinfo kvm_intel | grep -i nested
103 options kvm-intel nested=y
105 4. Unload and re-load the KVM Intel module::
107 $ sudo rmmod kvm-intel
108 $ sudo modprobe kvm-intel
116 name is ``kvm-amd``.
119 Additional nested-related kernel parameters (x86)
120 -------------------------------------------------
137 .. note:: If you suspect your L2 (i.e. nested guest) is running slower,
143 -----------------------------
148 $ qemu-kvm -cpu host [...]
150 The above will pass through the host CPU's capabilities as-is to the
154 $ qemu-kvm -cpu Haswell-noTSX-IBRS,vmx=on
156 then the guest hypervisor will subsequently be capable of running a
161 -------------------------
175 (via the command-line ``-cpu host``).
183 ------------------------------
192 or save-and-load an L1 guest while an L2 guest is running will result in
197 actually running L2 guests, is expected to function normally even on AMD
200 Migrating an L2 guest is always expected to succeed, so all the following
203 - Migrating a nested guest (L2) to another L1 guest on the *same* bare
206 - Migrating a nested guest (L2) to another L1 guest on a *different*
209 - Migrating a nested guest (L2) to a bare metal host.
212 -----------------------------------
215 L0, L1 and L2; this can result in tedious back-n-forth between the bug
218 - Mention that you are in a "nested" setup. If you are running any kind
223 - Ensure you are actually running KVM on KVM. Sometimes people do not
225 them running with pure emulation or what QEMU calls it as "TCG", but
226 they think they're running nested KVM. Thus confusing "nested Virt"
234 - Kernel, libvirt, and QEMU version from L0
236 - Kernel, libvirt and QEMU version from L1
238 - QEMU command-line of L1 -- when using libvirt, you'll find it here:
241 - QEMU command-line of L2 -- as above, when using libvirt, get the
242 complete libvirt-generated QEMU command-line
244 - ``cat /sys/cpuinfo`` from L0
246 - ``cat /sys/cpuinfo`` from L1
248 - ``lscpu`` from L0
250 - ``lscpu`` from L1
252 - Full ``dmesg`` output from L0
254 - Full ``dmesg`` output from L1
256 x86-specific info to collect
262 - Output of: ``x86info -a`` from L0
264 - Output of: ``x86info -a`` from L1
266 - Output of: ``dmidecode`` from L0
268 - Output of: ``dmidecode`` from L1
270 s390x-specific info to collect
276 - ``/proc/sysinfo`` from L1; this will also include the info from L0