@@ -1359,18 +1359,31 @@ How to Snapshot a Volume
13591359KVM volume Snapshot specifics
13601360~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13611361
1362- In recent CloudStack versions, by default, creating a Volume Snapshot for a running Instance is disabled
1363- due to a possible volume corruption in certain cases. To enable creating a Volume Snapshots while the Instance
1364- is running, the global setting ' kvm.snapshot.enabled' must be set to ' True' .
1362+ Since 4.22.0.0, creating a Volume Snapshot for a running Instance on KVM is allowed by default; in earlier
1363+ versions it was disabled by default. This is controlled by the global setting ` ` kvm.snapshot.enabled` ` .
1364+ Because taking a snapshot of a running Instance can lead to volume corruption in certain cases,
1365+ administrators who want to require Instances to be stopped before a Volume Snapshot can be taken should set
1366+ this global setting to ` ` false` ` .
13651367
13661368The Volume Snapshot creation has changed in recent versions:
13671369
1368- When the VM is running, a disk-only VM snapshot is taken, exclusively for the volume in question.
1369- If the VM is stopped, the volume will be converted (with qemu-img convert). The final storage location is
1370- determined by the ` ` snapshot.backup.to.secondary` ` configuration; if it is false the snapshot will be copied
1371- to a different directory in the same primary storage as the volume; if it is true the snapshot will be copied
1372- to the secondary storage. If the snapshot is being taken in a file-based storage (NFS, SharedMountPoint, Local),
1373- it will be copied directly to its final storage location, according to the configuration.
1370+ For volumes on file-based primary storage (NFS, SharedMountPoint, Local), when the VM is running, a
1371+ disk-only VM snapshot is taken, exclusively for the volume in question. If the VM is stopped, the volume
1372+ will be converted (with qemu-img convert). For volumes on RBD (Ceph) and CLVM primary storage, the Volume
1373+ Snapshot is instead taken natively by the storage layer (via the RBD ` ` snap create` ` operation, or the
1374+ ` ` managesnapshot.sh` ` script for CLVM), without any interaction with the libvirt domain; the same
1375+ storage-side mechanism is used whether the Instance is running or stopped. Note that on RBD, a snapshot
1376+ taken while the Instance is running is only crash-consistent, as writes still held in the Instance' s memory
1377+ are not flushed before the snapshot is taken.
1378+
1379+ The final storage location is determined by the ``snapshot.backup.to.secondary`` configuration; if it is
1380+ false the snapshot will be copied to a different directory in the same primary storage as the volume; if it
1381+ is true the snapshot will be copied to the secondary storage. If the snapshot is being taken in a
1382+ file-based storage (NFS, SharedMountPoint, Local), it will be copied directly to its final storage
1383+ location, according to the configuration.
1384+
1385+ Snapshots of encrypted volumes are only supported while the Instance is stopped. Taking a Volume Snapshot
1386+ of an encrypted volume attached to a running Instance will fail.
13741387
13751388Since 4.21.0.0, ACS supports incremental snapshots for the KVM hypervisor when using file-based storage (NFS, SharedMountPoint, Local),
13761389to enable incremental snapshots the ``kvm.incremental.snapshot`` configuration must be enabled. Furthermore, in order to take incremental snapshots
0 commit comments