cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Question regarding Quiesce VM feature in ACS 4.3 wrt XEN hypervisor
Date Fri, 18 Jul 2014 03:28:13 GMT
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.das@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.tutkowski@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.tutkowski@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 <punith.s@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message