I agree...I think #2 is a good option, as well.
On Mon, Oct 7, 2013 at 11:01 AM, SuichII, Christopher <
chris.su...@netapp.com> wrote:
> 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>
> > *™*
>
>
--
*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>
*™*
