to the same value as the total core count.
The second CPU resource limiting setting, *cpuunits* (nowadays often called CPU
-shares or CPU weight), controls how much CPU time a VM gets in regards to other
-VMs running. It is a relative weight which defaults to `1024`, if you increase
-this for a VM it will be prioritized by the scheduler in comparison to other
-VMs with lower weight. E.g., if VM 100 has set the default 1024 and VM 200 was
-changed to `2048`, the latter VM 200 would receive twice the CPU bandwidth than
-the first VM 100.
+shares or CPU weight), controls how much CPU time a VM gets compared to other
+running VMs. It is a relative weight which defaults to `100` (or `1024` if the
+host uses legacy cgroup v1). If you increase this for a VM it will be
+prioritized by the scheduler in comparison to other VMs with lower weight. E.g.,
+if VM 100 has set the default `100` and VM 200 was changed to `200`, the latter
+VM 200 would receive twice the CPU bandwidth than the first VM 100.
For more information see `man systemd.resource-control`, here `CPUQuota`
-corresponds to `cpulimit` and `CPUShares` corresponds to our `cpuunits`
+corresponds to `cpulimit` and `CPUWeight` corresponds to our `cpuunits`
setting, visit its Notes section for references and implementation details.
CPU Type
* *qxl*, is the QXL paravirtualized graphics card. Selecting this also
enables https://www.spice-space.org/[SPICE] (a remote viewer protocol) for the
VM.
+* *virtio-gl*, often named VirGL is a virtual 3D GPU for use inside VMs that
+ can offload workloads to the host GPU without requiring special (expensive)
+ models and drivers and neither binding the host GPU completely, allowing
+ reuse between multiple guests and or the host.
++
+NOTE: VirGL support needs some extra libraries that aren't installed by
+default due to being relatively big and also not available as open source for
+all GPU models/vendors. For most setups you'll just need to do:
+`apt install libgl1 libegl1`
You can edit the amount of memory given to the virtual GPU, by setting
the 'memory' option. This can enable higher resolutions inside the VM,
* The hosts have a working (and reliable) network connection.
* The target host must have the same or higher versions of the
{pve} packages. (It *might* work the other way, but this is never guaranteed)
+* The hosts have CPUs from the same vendor. (It *might* work otherwise, but this
+ is never guaranteed)
Offline Migration
~~~~~~~~~~~~~~~~~
--customize=./copy_pub_ssh.sh \
--sparse --image vm600.raw
-You can now create a new target VM for this image.
+You can now create a new target VM, importing the image to the storage `pvedir`
+and attaching it to the VM's SCSI controller:
----
# qm create 600 --net0 virtio,bridge=vmbr0 --name vm600 --serial0 socket \
- --bootdisk scsi0 --scsihw virtio-scsi-pci --ostype l26
-----
-
-Add the disk image as +unused0+ to the VM, using the storage +pvedir+:
-
-----
-# qm importdisk 600 vm600.raw pvedir
-----
-
-Finally attach the unused disk to the SCSI controller of the VM:
-
-----
-# qm set 600 --scsi0 pvedir:600/vm-600-disk-1.raw
+ --boot order=scsi0 --scsihw virtio-scsi-pci --ostype l26 \
+ --scsi0 pvedir:0,import-from=/path/to/dir/vm600.raw
----
The VM is ready to be started.