I'm a fan of option 2 - this gives us the most flexibility (as you stated). The
option is given to completely override the way VM snapshots work AND storage
providers are given to opportunity to work within the default VM snapshot
workflow.
I believe this option should satisfy your concern, Mike. The snapshot and
quiesce strategy would be in charge of communicating with the hypervisor.
Storage providers should be able to leverage the default strategies and simply
perform the storage operations.
I don't think it should be much of an issue that new method to the storage
driver interface may not apply to everyone. In fact, that is already the case.
Some methods such as un/maintain(), attachToXXX() and takeSnapshot() are
already not implemented by every driver - they just return false when asked if
they can handle the operation.
--
Chris Suich
chris.su...@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat
On Oct 5, 2013, at 12:11 AM, Mike Tutkowski <mike.tutkow...@solidfire.com>
wrote:
> Well, my first thought on this is that the storage driver should not be
> telling the hypervisor to do anything. It should be responsible for
> creating/deleting volumes, snapshots, etc. on its storage system only.
>
>
> On Fri, Oct 4, 2013 at 5:57 PM, Edison Su <edison...@citrix.com> wrote:
>
>> In 4.2, we added VM snapshot for Vmware/Xenserver. The current workflow
>> will be like the following:
>> createVMSnapshot api -> VMSnapshotManagerImpl: creatVMSnapshot -> send
>> CreateVMSnapshotCommand to hypervisor to create vm snapshot.
>>
>> If anybody wants to change the workflow, then need to either change
>> VMSnapshotManagerImpl directly or subclass VMSnapshotManagerImpl. Both are
>> not the ideal choice, as VMSnapshotManagerImpl should be able to handle
>> different ways to take vm snapshot, instead of hard code.
>>
>> The requirements for the pluggable VM snapshot coming from:
>> Storage vendor may have their optimization, such as NetApp.
>> VM snapshot can be implemented in a totally different way(For example, I
>> could just send a command to guest VM, to tell my application to flush disk
>> and hold disk write, then come to hypervisor to take a volume snapshot).
>>
>> If we agree on enable pluggable VM snapshot, then we can move on discuss
>> how to implement it.
>>
>> The possible options:
>> 1. coarse grained interface. Add a VMSnapshotStrategy interface, which has
>> the following interfaces:
>> VMSnapshot takeVMSnapshot(VMSnapshot vmSnapshot);
>> Boolean revertVMSnapshot(VMSnapshot vmSnapshot);
>> Boolean DeleteVMSnapshot(VMSnapshot vmSnapshot);
>>
>> The work flow will be: createVMSnapshot api -> VMSnapshotManagerImpl:
>> creatVMSnapshot -> VMSnapshotStrategy: takeVMSnapshot
>> VMSnapshotManagerImpl will manage VM state, do the sanity check, then
>> will handle over to VMSnapshotStrategy.
>> In VMSnapshotStrategy implementation, it may just send a
>> Create/revert/delete VMSnapshotCommand to hypervisor host, or do anything
>> special operations.
>>
>> 2. fine-grained interface. Not only add a VMSnapshotStrategy interface,
>> but also add certain methods on the storage driver.
>> The VMSnapshotStrategy interface will be the same as option 1.
>> Will add the following methods on storage driver:
>> /* volumesBelongToVM is the list of volumes of the VM that created on
>> this storage, storage vendor can either take one snapshot for this volumes
>> in one shot, or take snapshot for each volume separately
>> The pre-condition: vm is unquiesced.
>> It will return a Boolean to indicate, do need unquiesce vm or not.
>> In the default storage driver, it will return false.
>> */
>> boolean takeVMSnapshot(List<VolumeInfo> volumesBelongToVM, VMSnapshot
>> vmSnapshot);
>> Boolean revertVMSnapshot(List<VolumeInfo> volumesBelongToVM,
>> VMSnapshot vmSnapshot);
>> Boolean deleteVMSnapshot(List<VolumeInfo> volumesBelongToVM, VMSnapshot
>> vmSNapshot);
>>
>> The work flow will be: createVMSnapshot api -> VMSnapshotManagerImpl:
>> creatVMSnapshot -> VMSnapshotStrategy: takeVMSnapshot -> storage
>> driver:takeVMSnapshot
>> In the implementation of VMSnapshotStrategy's takeVMSnapshot, the pseudo
>> code looks like:
>> HypervisorHelper.quiesceVM(vm);
>> val volumes = vm.getVolumes();
>> val maps = new Map[driver, list[VolumeInfo]]();
>> Volumes.foreach(volume => maps.put(volume.getDriver, volume ::
>> maps.get(volume.getdriver())))
>> val needUnquiesce = true;
>> maps.foreach((driver, volumes) => needUnquiesce = needUnquiesce
>> && driver.takeVMSnapshot(volumes))
>> if (needUnquiesce ) {
>> HypervisorHelper.unquiesce(vm);
>> }
>>
>> By default, the quiesceVM in HypervisorHelper will actually take vm
>> snapshot through hypervisor.
>> Does above logic makes senesce?
>>
>> The pros of option 1 is that: it's simple, no need to change storage
>> driver interfaces. The cons is that each storage vendor need to implement a
>> strategy, maybe they will do the same thing.
>> The pros of option 2 is that, storage driver won't need to worry about how
>> to quiesce/unquiesce vm. The cons is that, it will add these methods on
>> each storage drivers, so it assumes that this work flow will work for
>> everybody.
>>
>> So which option we should take? Or if you have other options, please let's
>> know.
>>
>>
>>
>>
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
