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 chris.su...@netapp.com NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Sep 30, 2013, at 6:03 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> 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 < > mike.tutkow...@solidfire.com> 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 < >> chiradeep.vit...@citrix.com> wrote: >> >>> Is VM Quiescing sufficient to ensure consistency of the snapshot? >>> >>> >>> On 9/30/13 2:43 PM, "SuichII, Christopher" <chris.su...@netapp.com> >>> 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 >>>> chris.su...@netapp.com<mailto:chris.su...@netapp.com> >>>> NetApp Software Engineer >>>> Data Center Platforms Cloud Solutions >>>> Citrix, Cisco & Red Hat >>>> >>> >>> >> >> >> -- >> *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> >> *™* >> > > > > -- > *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> > *™*
