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> *™*