]> git.proxmox.com Git - pve-docs.git/blobdiff - qm.adoc
pve-gui.adoc: minor cleanups
[pve-docs.git] / qm.adoc
diff --git a/qm.adoc b/qm.adoc
index ffc15d210c7821afda8550b5a7477036b3bd5c95..85b939ade2b486f1c346e6432b8dcd1aeb177ea5 100644 (file)
--- a/qm.adoc
+++ b/qm.adoc
@@ -503,9 +503,9 @@ If you have local resources, you can still offline migrate your VMs,
 as long as all disk are on storages, which are defined on both hosts.
 Then the migration will copy the disk over the network to the target host.
 
-
-VM Templates, Copies and Clones
--------------------------------
+[[qm_copy_and_clone]]
+Copies and Clones
+-----------------
 
 [thumbnail="gui-qemu-full-clone.png"]
 
@@ -522,12 +522,20 @@ Full Clone::
 The result of such copy is an independent VM. The
 new VM does not share any storage resources with the original.
 +
+
 It is possible to select a *Target Storage*, so one can use this to
 migrate a VM to a totally different storage. You can also change the
 disk image *Format* if the storage driver supports several formats.
 +
+
 NOTE: A full clone need to read and copy all VM image data. This is
 usually much slower than creating a linked clone.
++
+
+Some storage types allows to copy a specific *Snapshot*, which
+defaults to the 'current' VM data. This also means that the final copy
+never includes any additional snapshots from the original VM.
+
 
 Linked Clone::
 
@@ -536,33 +544,47 @@ clones. Such a clone is a writable copy whose initial contents are the
 same as the original data. Creating a linked clone is nearly
 instantaneous, and initially consumes no additional space.
 +
+
 They are called 'linked' because the new image still refers to the
 original. Unmodified data blocks are read from the original image, but
 modification are written (and afterwards read) from a new
 location. This technique is called 'Copy-on-write'.
 +
-This implies that the original is either a read-only 'snapshot', or a
-read-only 'Template' VM. It is not possible to change the *Target
-storage* for linked clones, because this is a storage internal
-feature.
+
+This requires that the original volume is read-only. With {pve} one
+can convert any VM into a read-only <<qm_templates, Template>>). Such
+templates can later be used to create linked clones efficiently.
 +
-NOTE: You cannot delete the original template or snapshot while
-linked clones exists.
+
+NOTE: You cannot delete the original template while linked clones
+exists.
++
+
+It is not possible to change the *Target storage* for linked clones,
+because this is a storage internal feature.
 
 
 The *Target node* option allows you to create the new VM on a
 different node. The only restriction is that the VM is on shared
 storage, and that storage is also available on the target node.
 
-It is possible to clone a specific *Snapshot*, which defaults to the
-'current' VM data. This also means that the final copy does not
-include any additional snapshots from the original VM.
-
 To avoid resource conflicts, all network interface MAC addresses gets
 randomized, and we generate a new 'UUID' for the VM BIOS (smbios1)
 setting.
 
 
+[[qm_templates]]
+Virtual Machine Templates
+-------------------------
+
+One can convert a VM into a Template. Such templates are read-only,
+and you can use them to create linked clones.
+
+NOTE: It is not possible to start templates, because this would modify
+the disk images. If you want to change the template, create a linked
+clone and modify that.
+
+
 Managing Virtual Machines with `qm`
 ------------------------------------