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