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 < [email protected]> wrote: > 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 correct, Mike. But the way we plan on implementing the > quiesce uses hypervisor APIs that ensure that all disk writes have > completed. This does not completely solve the problem, but it helps. If > applications using the DB are properly coded, then all transactions will > complete before the snapshot is taken and any new transactions will be > queued in memory and will not start being written to disk until the quiesce > is completed. > > Yes, application level quiesce would be ideal, but that would be a much > larger undertaking. > > -- > Chris Suich > [email protected] > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Sep 30, 2013, at 6:03 PM, Mike Tutkowski <[email protected]> > wrote: > > > 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 < > > [email protected]> wrote: > > > >> 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 > >> snapshot. > >> > >> > >> On Mon, Sep 30, 2013 at 3:52 PM, Chiradeep Vittal < > >> [email protected]> wrote: > >> > >>> Is VM Quiescing sufficient to ensure consistency of the snapshot? > >>> > >>> > >>> On 9/30/13 2:43 PM, "SuichII, Christopher" <[email protected]> > >>> wrote: > >>> > >>>> 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 snapshot, there are ways around this and > >>>> 'quiescing' the vm without actually quiescing it (through hypervisor > >>>> APIs). I would like to propose that there be an option to quiesce VMs > >>>> when taking snapshots both manually and through recurring snapshot > >>>> policies. One issue I see with this is that this option is not always > >>>> applicable. If the default storage provider is used, a hypervisor > >>>> snapshot will be taken and therefore the VM will always be quiesced. > Some > >>>> storage providers may not respect the user's request to quiesce. > Because > >>>> of this, I suggest that the option be shown to the user as 'Quiesce VM > >>>> (if applicable)'. This indicates to the user that the option will be > >>>> passed to the management server and respected if possible. > >>>> > >>>> I will work on formalizing a full functional spec if needed but > wanted to > >>>> get this up for discussion ASAP. > >>>> > >>>> I have created a JIRA ticket: > >>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4774 > >>>> > >>>> Thanks, > >>>> Chris > >>>> -- > >>>> Chris Suich > >>>> [email protected]<mailto:[email protected]> > >>>> NetApp Software Engineer > >>>> Data Center Platforms Cloud Solutions > >>>> Citrix, Cisco & Red Hat > >>>> > >>> > >>> > >> > >> > >> -- > >> *Mike Tutkowski* > >> *Senior CloudStack Developer, SolidFire Inc.* > >> e: [email protected] > >> 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: [email protected] > > 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: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
