Yeah, I've been through a project that dealt with application-level
quiescing - as you say, that's a much larger undertaking.
Thanks for the clarification.
On Mon, Sep 30, 2013 at 6:38 PM, SuichII, Christopher <
chris.su...@netapp.com> wrote:
> I should clarify (because it may not have been cle
I should clarify (because it may not have been clear) that I'm talking about vm
disk snapshots which go through the storage subsystem API, NOT entire VM
snapshots. The important distinction is that calls to the storage subsystem
would not snapshot VM memory - just VM volumes.
In general, you're
VM quiescing should be sufficient for hypervisor snapshots, though, because
you are presumably snapping the disks and the memory.
On Mon, Sep 30, 2013 at 4:02 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> I would say 'no'. Let's say you have a DB app running in your host OS and
> i
I would say 'no'. Let's say you have a DB app running in your host OS and
it's in the middle of writing a transaction to a data disk...quiescing the
VM - without quiescing the DB app (like SQL Server via VSS) - does not give
you a properly quiesced snapshot on the data disk - just a point-in-time
s
Is VM Quiescing sufficient to ensure consistency of the snapshot?
On 9/30/13 2:43 PM, "SuichII, Christopher" wrote:
>CloudStack currently snapshots vm disks by taking hypervisor snapshots.
>However, when implementing the storage subsystem API interface
>takeSnapshot(), the VM associated with th
CloudStack currently snapshots vm disks by taking hypervisor snapshots.
However, when implementing the storage subsystem API interface takeSnapshot(),
the VM associated with the requested volume is not quiesced since a hypervisor
snapshot is not necessarily taken. When creating a storage level s
