]> git.proxmox.com Git - pve-docs.git/blobdiff - qm.adoc
SPAM: [PATCH docs] pveum: Add information about realm certificates
[pve-docs.git] / qm.adoc
diff --git a/qm.adoc b/qm.adoc
index 2acf6b806bdd03b55783c5a68b24886d325fc405..d30672e4658206dc7aabbad450bb398e0fa90c74 100644 (file)
--- a/qm.adoc
+++ b/qm.adoc
@@ -144,7 +144,7 @@ hardware layout of the VM's virtual motherboard. You can choose between the
 default https://en.wikipedia.org/wiki/Intel_440FX[Intel 440FX] or the
 https://ark.intel.com/content/www/us/en/ark/products/31918/intel-82q35-graphics-and-memory-controller.html[Q35]
 chipset, which also provides a virtual PCIe bus, and thus may be desired if
-one want's to pass through PCIe hardware.
+one wants to pass through PCIe hardware.
 
 [[qm_hard_disk]]
 Hard Disk
@@ -253,9 +253,8 @@ The option *IO Thread* can only be used when using a disk with the
 *VirtIO* controller, or with the *SCSI* controller, when the emulated controller
  type is  *VirtIO SCSI single*.
 With this enabled, Qemu creates one I/O thread per storage controller,
-instead of a single thread for all I/O, so it increases performance when
+rather than a single thread for all I/O. This can increase performance when
 multiple disks are used and each disk has its own storage controller.
-Note that backups do not currently work with *IO Thread* enabled.
 
 
 [[qm_cpu]]
@@ -284,8 +283,8 @@ is greater than the number of cores on the server (e.g., 4 VMs with each 4
 cores on a machine with only 8 cores). In that case the host system will
 balance the Qemu execution threads between your server cores, just like if you
 were running a standard multithreaded application. However, {pve} will prevent
-you from assigning more virtual CPU cores than physically available, as this will
-only bring the performance down due to the cost of context switches.
+you from starting VMs with more virtual CPU cores than physically available, as
+this will only bring the performance down due to the cost of context switches.
 
 [[qm_cpu_resource_limits]]
 Resource Limits
@@ -353,6 +352,17 @@ the kvm64 default. If you don’t care about live migration or have a homogeneou
 cluster where all nodes have the same CPU, set the CPU type to host, as in
 theory this will give your guests maximum performance.
 
+Custom CPU Types
+^^^^^^^^^^^^^^^^
+
+You can specify custom CPU types with a configurable set of features. These are
+maintained in the configuration file `/etc/pve/virtual-guest/cpu-models.conf` by
+an administrator. See `man cpu-models.conf` for format details.
+
+Specified custom types can be selected by any user with the `Sys.Audit`
+privilege on `/nodes`. When configuring a custom CPU type for a VM via the CLI
+or API, the name needs to be prefixed with 'custom-'.
+
 Meltdown / Spectre related CPU flags
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -792,6 +802,44 @@ device of the host use device passthrough (see
 xref:qm_pci_passthrough[PCI Passthrough] and
 xref:qm_usb_passthrough[USB Passthrough]).
 
+[[qm_virtio_rng]]
+VirtIO RNG
+~~~~~~~~~~
+
+A RNG (Random Number Generator) is a device providing entropy ('randomness') to
+a system. A virtual hardware-RNG can be used to provide such entropy from the
+host system to a guest VM. This helps to avoid entropy starvation problems in
+the guest (a situation where not enough entropy is available and the system may
+slow down or run into problems), especially during the guests boot process.
+
+To add a VirtIO-based emulated RNG, run the following command:
+
+----
+qm set <vmid> -rng0 source=<source>[,max_bytes=X,period=Y]
+----
+
+`source` specifies where entropy is read from on the host and has to be one of
+the following:
+
+* `/dev/urandom`: Non-blocking kernel entropy pool (preferred)
+* `/dev/random`: Blocking kernel pool (not recommended, can lead to entropy
+  starvation on the host system)
+* `/dev/hwrng`: To pass through a hardware RNG attached to the host (if multiple
+  are available, the one selected in
+  `/sys/devices/virtual/misc/hw_random/rng_current` will be used)
+
+A limit can be specified via the `max_bytes` and `period` parameters, they are
+read as `max_bytes` per `period` in milliseconds. However, it does not represent
+a linear relationship: 1024B/1000ms would mean that up to 1 KiB of data becomes
+available on a 1 second timer, not that 1 KiB is streamed to the guest over the
+course of one second. Reducing the `period` can thus be used to inject entropy
+into the guest at a faster rate.
+
+By default, the limit is set to 1024 bytes per 1000 ms (1 KiB/s). It is
+recommended to always use a limiter to avoid guests using too many host
+resources. If desired, a value of '0' for `max_bytes` can be used to disable
+all limits.
+
 [[qm_startup_and_shutdown]]
 Automatic Start and Shutdown of Virtual Machines
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -872,6 +920,8 @@ Select the folder to share and then enable the checkbox.
 
 NOTE: Folder sharing currently only works in the Linux version of Virt-Viewer.
 
+CAUTION: Experimental! Currently this feature does not work reliably.
+
 Video Streaming
 ^^^^^^^^^^^^^^^
 
@@ -1192,6 +1242,28 @@ It will be called during various phases of the guests lifetime.
 For an example and documentation see the example script under
 `/usr/share/pve-docs/examples/guest-example-hookscript.pl`.
 
+[[qm_hibernate]]
+Hibernation
+-----------
+
+You can suspend a VM to disk with the GUI option `Hibernate` or with
+
+ qm suspend ID --todisk
+
+That means that the current content of the memory will be saved onto disk
+and the VM gets stopped. On the next start, the memory content will be
+loaded and the VM can continue where it was left off.
+
+[[qm_vmstatestorage]]
+.State storage selection
+If no target storage for the memory is given, it will be automatically
+chosen, the first of:
+
+1. The storage `vmstatestorage` from the VM config.
+2. The first shared storage from any VM disk.
+3. The first non-shared storage from any VM disk.
+4. The storage `local` as a fallback.
+
 Managing Virtual Machines with `qm`
 ------------------------------------
 
@@ -1301,6 +1373,10 @@ There are a few snapshot related properties like `parent` and
 relationship between snapshots. `snaptime` is the snapshot creation
 time stamp (Unix epoch).
 
+You can optionally save the memory of a running VM with the option `vmstate`.
+For details about how the target storage gets chosen for the VM state, see
+xref:qm_vmstatestorage[State storage selection] in the chapter
+xref:qm_hibernate[Hibernation].
 
 [[qm_options]]
 Options