thanks Mike. I shall have a look at the implementation details. Will be looking forward to any documentation if any.
Regards, Amit *CloudByte Inc.* <http://www.cloudbyte.com/> On Fri, Jul 18, 2014 at 8:58 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Hi Amit, > > I don't really know these details in depth (NetApp added this feature in > v4.3). > > I have CCed David La Motta from NetApp. Perhaps he can explain more than I > did. > > I do know that from a storage standpoint you don't have to implement > anything if you just want to ignore this feature. > > The idea is that if you want to support this feature, then you (I think) > need to implement a snapshot strategy (a CS interface) (or perhaps use the > one NetApp implemented). > > The overall idea is that this works for NFS if you want to take a snapshot > of a file on a share and you want to try to take the snapshot when the VM > is in a quiesced state. > > Step one is the VM gets quiesced. > > Step two is a hypervisor snapshot is taken (which leads to a new (delta) > file on the XenServer Shared (NFS) Storage Repository). > > Step three is you can have your storage plug-in notified and it can take a > snapshot of this new file. > > Step four is cleanup related on the hypervisor: The VM snapshot is deleted > and the delta file can be merged back into its parent by XenServer. > > I think the reason we take a hypervisor snapshot is so we can then quickly > un-quiesce the VM and asynchronously have the storage plug-in take its > snapshot. Then we can later go back and delete the hypervisor snapshot, so > this virtual disk can have its parent and delta files merged back together. > > Talk to you later, > Mike > > > On Wed, Jul 16, 2014 at 9:31 AM, Amit Das <amit....@cloudbyte.com> wrote: > >> W.r.t hypervisor specific snapshots : >> - why is this snapshot required when a VM or its hypervisor supports >> quiesce operation. >> - what exactly happens during hypervisor snapshot ? Can this step be >> excluded. >> >> >> On Wednesday, July 16, 2014, Mike Tutkowski <mike.tutkow...@solidfire.com> >> wrote: >> >>> This line at the bottom of my previous e-mail was redundant...I meant to >>> remove it before sending: >>> >>> A vendor snapshot can be created of the hypervisor snapshot file, then >>> CS can automatically delete >>> >>> >>> On Wed, Jul 16, 2014 at 8:10 AM, Mike Tutkowski < >>> mike.tutkow...@solidfire.com> wrote: >>> >>>> I believe this is what happens: >>>> >>>> * The VM gets quiesced. >>>> * Hypervisor snapshots are taken of all VM disks (so a new delta file >>>> shows up on each applicable SR). >>>> * The applicable storage plug-in can be invoked to take a >>>> vendor-specific snapshot of a given hypervisor snapshot delta file. >>>> * Once the storage plug-in is done, CS can delete the hypervisor >>>> snapshot delta file(s) that was/were created. >>>> >>>> A couple notes about this: >>>> >>>> * Since you are taking a vendor-side snap of a particular file, this >>>> relates to NFS. >>>> >>>> * I believe all disks of the VM need to be supported by the same >>>> storage vendor (i.e. if the root and data disks are on different SRs, each >>>> SR needs to be supported by the storage of the same backend vendor) >>>> >>>> A vendor snapshot can be created of the hypervisor snapshot file, then >>>> CS can automatically delete >>>> >>>> On Wednesday, July 16, 2014, Punith S <punit...@cloudbyte.com> wrote: >>>> >>>>> hi, >>>>> >>>>> while i was referring the ACS 4.3 doc for VM snapshot, >>>>> i see a feature Quiesce VM supported only by vmware hypervisor if the >>>>> cloudstack default primary storage is used, >>>>> but it also mentions that Quiesce VM can be supported if you are using >>>>> a >>>>> third party primary storage plugin, the quiesce operation is provided >>>>> by >>>>> plugin implementation! >>>>> >>>>> is Quiesce VM is a limitation of XEN hypervisor or is it not >>>>> implemented >>>>> by xen agent in cloudstack ? >>>>> >>>>> how is third party primary storage plugin related to hypervisor >>>>> feature ? >>>>> >>>>> -- >>>>> regards, >>>>> >>>>> punith s >>>>> cloudbyte.com >>>>> >>>> >>> >>> >>> -- >>> *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>*™* >>> >> >> >> -- >> Regards, >> Amit >> *CloudByte Inc.* <http://www.cloudbyte.com/> >> >> > > > -- > *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>*™* >
