Hello everyone, My name is Slavka Peleva and I work for StorPool Storage. I have recently joined the mailing list.
Me and my colleagues have been working over а new feature for storage-based live VM snapshots under the KVM hypervisor. With the current implementation (which is using libvirt to perform the snapshotting) it is not possible for storage providers that keep VM's disks in RAW format to take VM snapshots. That's why we have decided to implement an alternative for VM snapshots under the KVM hypervisor. It will be useful mostly for storages that are keeping their disks in RAW format or in case of VMs with mixed set of disks (RAW and QCOW). The solution is using the third party storages' plugins to create/revert/delete disk snapshots. The snapshots will be consistent, because the virtual machines will be frozen until the snapshotting is done. For the qcow images we have an alternative solution with the qemu drive-backup command. It could be used if a VM has mixed disks with raw and qcow images (in this case “snapshot.backup.to.secondary” should be set to true). Qemu version 1.6+ is required, latest Ubuntu should already cover this, for RHEL/CentOS7 the qemu-kvm-ev package is required. And some details about the implementation - we have added a new configuration option in the database named "kvm.vmsnapshot.enabled". For the VM takeSnapshot method we have split the takeSnapshot (of disk method) into two parts - takeSnapshot and backupSnapshot. In order to make all snapshots consistent, the virtual machine would have to be frozen with the domfsfreeze command. While it’s frozen an asynchronous snapshot will be taken for all disks with the appropriate datastore driver implementation. Once the execution is complete, the virtual machine will be unfreezed by using the domfsthaw command. Finally a backup to secondary storage is invoked. The final backup operation is mandatory for VMs qcow disks attached. Does this feature sound right to be accepted? Please let us know if you have any questions, comments, concerns about this. Kind regards, Slavka Peleva
