X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;f=qm.adoc;h=cd6641f89c4c02f5adaac54120129934ec1b4402;hb=adb2c91d584189792bcf03ab84b58bc4b56e6646;hp=e1499316e3aa13bf698c098565ced9a299c617f2;hpb=69f44be252ede013f8e690366ef59b3a167d5e0b;p=pve-docs.git diff --git a/qm.adoc b/qm.adoc index e149931..cd6641f 100644 --- 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 @@ -283,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 @@ -791,6 +791,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 -rng0 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -871,6 +909,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 ^^^^^^^^^^^^^^^ @@ -1191,6 +1231,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` ------------------------------------ @@ -1300,6 +1362,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