General Settings
~~~~~~~~~~~~~~~~
-[thumbnail="gui-create-vm-general.png"]
+[thumbnail="screenshot/gui-create-vm-general.png"]
General settings of a VM include
OS Settings
~~~~~~~~~~~
-[thumbnail="gui-create-vm-os.png"]
+[thumbnail="screenshot/gui-create-vm-os.png"]
When creating a VM, setting the proper Operating System(OS) allows {pve} to
optimize some low level parameters. For instance Windows OS expect the BIOS
is an older type of paravirtualized controller. It has been superseded by the
VirtIO SCSI Controller, in terms of features.
-[thumbnail="gui-create-vm-hard-disk.png"]
+[thumbnail="screenshot/gui-create-vm-hard-disk.png"]
On each controller you attach a number of emulated hard disks, which are backed
by a file or a block device residing in the configured storage. The choice of
a storage type will determine the format of the hard disk image. Storages which
present block devices (LVM, ZFS, Ceph) will require the *raw disk image format*,
-whereas files based storages (Ext4, NFS, GlusterFS) will let you to choose
+whereas files based storages (Ext4, NFS, CIFS, GlusterFS) will let you to choose
either the *raw disk image format* or the *QEMU image format*.
* the *QEMU image format* is a copy on write format which allows snapshots, and
CPU
~~~
-[thumbnail="gui-create-vm-cpu.png"]
+[thumbnail="screenshot/gui-create-vm-cpu.png"]
A *CPU socket* is a physical slot on a PC motherboard where you can plug a CPU.
This CPU can then contain one or many *cores*, which are independent
host.
.Fixed Memory Allocation
-[thumbnail="gui-create-vm-memory-fixed.png"]
+[thumbnail="screenshot/gui-create-vm-memory.png"]
-When choosing a *fixed size memory* {pve} will simply allocate what you
-specify to your VM.
+When setting memory and minimum memory to the same amount
+{pve} will simply allocate what you specify to your VM.
Even when using a fixed memory size, the ballooning device gets added to the
VM, because it delivers useful information such as how much memory the guest
really uses.
In general, you should leave *ballooning* enabled, but if you want to disable
it (e.g. for debugging purposes), simply uncheck
-*Ballooning* or set
+*Ballooning Device* or set
balloon: 0
in the configuration.
.Automatic Memory Allocation
-[thumbnail="gui-create-vm-memory-dynamic.png", float="left"]
// see autoballoon() in pvestatd.pm
-When choosing to *automatically allocate memory*, {pve} will make sure that the
+When setting the minimum memory lower than memory, {pve} will make sure that the
minimum amount you specified is always available to the VM, and if RAM usage on
the host is below 80%, will dynamically add memory to the guest up to the
maximum memory specified.
-When the host is becoming short on RAM, the VM will then release some memory
+When the host is running low on RAM, the VM will then release some memory
back to the host, swapping running processes if needed and starting the oom
killer in last resort. The passing around of memory between host and guest is
done via a special `balloon` kernel driver running inside the guest, which will
When multiple VMs use the autoallocate facility, it is possible to set a
*Shares* coefficient which indicates the relative amount of the free host memory
that each VM should take. Suppose for instance you have four VMs, three of them
-running a HTTP server and the last one is a database server. To cache more
+running an HTTP server and the last one is a database server. To cache more
database blocks in the database server RAM, you would like to prioritize the
database VM when spare RAM is available. For this you assign a Shares property
of 3000 to the database VM, leaving the other VMs to the Shares default setting
of 1000. The host server has 32GB of RAM, and is currently using 16GB, leaving 32
* 80/100 - 16 = 9GB RAM to be allocated to the VMs. The database VM will get 9 *
3000 / (3000 + 1000 + 1000 + 1000) = 4.5 GB extra RAM and each HTTP server will
-get 1/5 GB.
+get 1.5 GB.
All Linux distributions released after 2010 have the balloon kernel driver
included. For Windows OSes, the balloon driver needs to be added manually and can
Network Device
~~~~~~~~~~~~~~
-[thumbnail="gui-create-vm-network.png"]
+[thumbnail="screenshot/gui-create-vm-network.png"]
Each VM can have many _Network interface controllers_ (NIC), of four different
types:
the Qemu user networking stack, where a built-in router and DHCP server can
provide network access. This built-in DHCP will serve addresses in the private
10.0.2.0/24 range. The NAT mode is much slower than the bridged mode, and
-should only be used for testing.
+should only be used for testing. This mode is only available via CLI or the API,
+but not via the WebUI.
You can also skip adding a network device when creating a VM by selecting *No
network device*.
//http://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html
When using the VirtIO driver with {pve}, each NIC network queue is passed to the
-host kernel, where the queue will be processed by a kernel thread spawn by the
+host kernel, where the queue will be processed by a kernel thread spawned by the
vhost driver. With this option activated, it is possible to pass _multiple_
network queues to the host kernel for each NIC.
as a router, reverse proxy or a busy HTTP server doing long polling.
-[[qm_cloud_init]]
-Cloud-Init Support
-~~~~~~~~~~~~~~~~~~
-
-http://cloudinit.readthedocs.io[Cloud-Init] is the defacto
-multi-distribution package that handles early initialization of a
-virtual machine instance. Using Cloud-Init, one can configure network
-devices and ssh keys on the hypervisor side. When the VM starts the
-first time, the Cloud-Init software inside the VM applies those
-settings.
-
-Many Linux distributions provides ready-to-use Cloud-Init images,
-mostly designed for 'OpenStack'. Those images also works with
-{pve}. While it may be convenient to use such read-to-use images, we
-usually recommend to prepare those images by yourself. That way you know
-exactly what is installed, and you can easily customize the image for
-your needs.
-
-Once you created such image, it is best practice to convert it into a
-VM template. It is really fast to create linked clones of VM
-templates, so this is a very fast way to roll out new VM
-instances. You just need to configure the network (any maybe ssh keys)
-before you start the new VM.
-
-We recommend the use of SSH key-based authentication to login to VMs
-provisioned by Cloud-Init. It is also possible to set a password, but
-{pve} needs to store an encrypted version of that password inside the
-Cloud-Init data. So this is not as safe as using SSH key-based
-authentication.
-
-{pve} generates an ISO image to pass the Cloud-Init data to the VM. So
-all Cloud-Init VMs needs to have an assigned CDROM drive for that
-purpose. Also, many Cloud-Init Images assumes to have a serial
-console, so it is best to add a serial console and use that as display
-for those VMs.
-
-
-Prepare Cloud-Init Templates
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The first step is to prepare your VM. You can basically use any VM,
-and simply install the Cloud-Init packages inside the VM you want to
-prepare. On Debian/Ubuntu based systems this is as simple as:
-
-----
-apt-get install cloud-init
-----
-
-Many distributions provides ready-to-use Cloud-Init images (provided
-as `.qcow2` files), so as alternative you can simply download and
-import such image. For the following example, we will use the cloud
-images provided by Ubuntu at https://cloud-images.ubuntu.com.
-
-----
-# download the image
-wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img
-
-# create a new VM
-qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0
-
-# import the downloaded disk to local-lvm storage
-qm importdisk 9000 bionic-server-cloudimg-amd64.img local-lvm
-
-# finally attach the new disk to the VM as scsi drive
-qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-1
-----
-
-NOTE: Ubuntu Cloud-Init images requires the `virtio-scsi-pci`
-controller type for SCSI drives.
-
-
-The next step is to configure a CDROM drive, used to pass the
-Cloud-Init data to the VM.
-
-----
-qm set 9000 --ide2 local-lvm:cloudinit
-----
-
-We want to boot directly from the Cloud-Init image, so we set the
-`bootdisk` parameter to `scsi0` and restrict BIOS to boot from disk
-only. This simply speeds up booting, because VM BIOS skips testing for
-a bootable CDROM.
-
-----
-qm set 9000 --boot c --bootdisk scsi0
-----
-
-We also want to configure a serial console and use that as display. Many Cloud-Init images rely on that, because it is an requirement for OpenStack images.
-
-----
-qm set 9000 --serial0 socket --vga serial0
-----
-
-Finally, it is usually a good idea to transform such VM into a template. You can create linked clones with them, so deployment from VM templates is much faster than creating a full clone (copy).
-
-----
-qm template 9000
-----
-
-
-Deploy Cloud-Init Templates
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can easily deploy such template by cloning:
-
-----
-qm clone 9000 123 --name ubuntu2
-----
-
-Then configure the SSH public key used for authentication, and the IP setup
-
-----
-qm set 123 --sshkey ~/.ssh/id_rsa.pub
-qm set 123 --ipconfig0 ip=10.0.10.123/24,gw=10.0.10.1
-----
-
-You can configure all Cloud-Init options using a single command. I
-just split above example to separate commands to reduce the line
-length. Also make sure you adopt the IP setup for your environment.
-
-
-Cloud-Init specific Options
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-
-
-include::qm-cloud-init-opts.adoc[]
-
-
-
[[qm_usb_passthrough]]
USB Passthrough
~~~~~~~~~~~~~~~
.Start and Shutdown Order
-[thumbnail="gui-qemu-edit-start-order.png"]
+[thumbnail="screenshot/gui-qemu-edit-start-order.png"]
In some case you want to be able to fine tune the boot order of your
VMs, for instance if one of your VM is providing firewalling or DHCP
Migration
---------
-[thumbnail="gui-qemu-migrate.png"]
+[thumbnail="screenshot/gui-qemu-migrate.png"]
If you have a cluster, you can migrate your VM to another host with
Copies and Clones
-----------------
-[thumbnail="gui-qemu-full-clone.png"]
+[thumbnail="screenshot/gui-qemu-full-clone.png"]
VM installation is usually done using an installation media (CD-ROM)
from the operation system vendor. Depending on the OS, this can be a
the disk images. If you want to change the template, create a linked
clone and modify that.
+VM Generation ID
+----------------
+
+{pve} supports Virtual Machine Generation ID ('vmgedid') footnote:[Official
+'vmgenid' Specification
+https://docs.microsoft.com/en-us/windows/desktop/hyperv_v2/virtual-machine-generation-identifier]
+for virtual machines.
+This can be used by the guest operating system to detect any event resulting
+in a time shift event, for example, restoring a backup or a snapshot rollback.
+
+When creating new VMs, a 'vmgenid' will be automatically generated and saved
+in its configuration file.
+
+To create and add a 'vmgenid' to an already existing VM one can pass the
+special value `1' to let {pve} autogenerate one or manually set the 'UUID'
+footnote:[Online GUID generator http://guid.one/] by using it as value,
+e.g.:
+
+----
+ qm set VMID -vmgenid 1
+ qm set VMID -vmgenid 00000000-0000-0000-0000-000000000000
+----
+
+In the rare case the 'vmgenid' mechanism is not wanted one can pass `0' for
+its value on VM creation, or retroactively delete the property in the
+configuration with:
+
+----
+ qm set VMID -delete vmgenid
+----
+
+The most prominent use case for 'vmgenid' are newer Microsoft Windows
+operating systems, which use it to avoid problems in time sensitive or
+replicate services (e.g., databases, domain controller) on snapshot
+rollback, backup restore or a whole VM clone operation.
+
Importing Virtual Machines and disk images
------------------------------------------
The VM is ready to be started.
+
+ifndef::wiki[]
+include::qm-cloud-init.adoc[]
+endif::wiki[]
+
+
+
Managing Virtual Machines with `qm`
------------------------------------
no longer running.
+ifdef::wiki[]
+
+See Also
+~~~~~~~~
+
+* link:/wiki/Cloud-Init_Support[Cloud-Init Support]
+
+endif::wiki[]
+
+
ifdef::manvolnum[]
Files
projects / pve-docs.git / blobdiff