Hi Slavka, Thanks for your mail/contribution. You implemention sounds interesting.
Let me ask some questions. 1. If you speak for RAW Disks you mean. Right? <disk type='block' device='disk‘> <driver name='qemu' type='raw‘/> 2. You wrote: 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. We use Netapp Solidfire Storage. I know they are using too RAW Format. You spoke about a third party plugin. "The solution is using the third party storages' plugins to create/revert/delete disk snapshots." The Plugins where they come and does they break any existing functionality? I don’t see that we if we use Solidfire we can use this plugin from Storepool. Right? 3. And some details about the implementation - we have added a new configuration option in the database named "kvm.vmsnapshot.enabled". At the moment there is already an flag „kvm.snapshot.enabled“. Well, I mean „kvm.vmsnapshot.enabled“ is to uniq to „kvm.snapshot.enabled“. Maybe this name should rather to be called „kvm.vmsnapshotexternalprovider.enabled“ or something like that… Naming is a bit long but maybe you will find another cool name. I think it should be more generic if anybody can create a plugin for a storage system like storepool, Netapp Solidfire ... . Thanks and Cheers Sven __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 20000-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 07.11.2019 um 14:17 schrieb Slavka Peleva <slav...@storpool.com>: > > 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
