Page History

...

...

• If the VM is running, we will call the virDomainSnapshotCreateXML API, informing all the VM's volumes with the snapshot key and the external value, and using the flags:
  1. VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC: to make the snapshot atomic across all the volumes;
  2. VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY: to make the snapshot disk-only;
  3. VIR_DOMAIN_SNAPSHOT_CREATE_NO_METADATA: to tell Libvirt not to save any metadata for the snapshot. This flag will be informed because we do not need Libvirt to save any metadata, all the other processes regarding the VM snapshots will be done using qemu-img.
  4. VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE: if quiesceVM is true, this flag will be informed as well to keep the VM frozen during the snapshot process, once the snapshot is done it will be already thawed.
• Otherwise (if the VM is not running), we will call qemu-img create for every volume of the VM, to create a delta on top of the current file.
• If any VM snapshot has been taken after the last backup on this backup chain:
  1. Convert all the deltas starting from the previous backup delta, until the previous top delta, to the secondary storage. For example, in a volume backing chain like this: A <-- B <-- C <-- D, with A being the volume base file, B being the delta created during the last backup, C being the delta created by the VM snapshot operation, and D being the delta created on the last step, we will convert B and C to the secondary storage, when converting the deltas, we already inform their correct backing files, in this example, the backing file for B would be the last backup, while the one for C would be B;
  2. Call qemu-img commit, merging all the converted deltas from the last step into one. Here we must inform the -b parameter, to let qemu-img know not to commit all the way into the volume's base file. In the example above, C would be commited to B.
  3. Delete the emptied files. In the example above, C.
• Else:
  1. Call qemu-img convert on the previous top delta. If the backup is not the start of a chain, we inform its backing file on the secondary storage.
• If it is not the first backup on the backup chain:
  • If the VM is running:
    1. Call Libvirt's virDomainBlockCommit API informing the previous backup delta as the top and its parent as the base.
  • Else:
    1. Merge previous backup delta with its parent delta, using qemu-img commit, to commit the backup delta to it;
    2. Rebase children to point to previous backup delta's parent. After the commit, the previous backup delta file will be empty and has to be removed from the chain;
    3. Remove previous backup delta file;
  • If a VM snapshot was created after the last backup:
    1. We update the VM snapshot path. The file pointed by the VM snapshot was the same as the previous backup delta. Thus, we need to update the VM snapshot path, as it has changed.
• If the backup will be the last of its backup chain, we merge the newly created delta with its parent. If the VM is running we use Libvirt's virDomainBlockCommit; else use qemu-img commit.
• We set the VM as ready, even if the backup will be validated and compressed later, all the work with the VM itself is done, and thus it can be returned to the ready state.
• If the backup offering supports backup validationcompression, we validate the backup. The backup validation compression process will be explained in the backup validation compression section.
• If the backup offering supports backup compressionvalidation, we validate the backup. The backup compression validation process will be explained in the backup compression validation section.

In order to let users choose whether the VM will be frozen for the snapshot process, a new parameter will be added to the createBackup and createBackupSchedule APIs, called quiesceVM. The VM will only be kept frozen during the initial snapshot creation process, during the rest of the backup it will be running.

...

If the backup offering supports compression, after all the backup creation steps have finished (including but before validation, if supported), we will launch a asynchronous job to start the backup compression. The compression will be broken into two steps: compress the backup into new files and substitute the original backup files. The reason to break the compression into two steps is so that while the first step is being done, the backup may still be restored; the restore will only be blocked during the last step, which is the fastest. These jobs will execute in the compute plane hosts instead of the SSVMs.

...