You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2013/10/01 00:02:27 UTC
Re: [PROPOSAL] Provide Option to Quiesce VMs While Taking Snapshots
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.Vittal@citrix.com> wrote:
> Is VM Quiescing sufficient to ensure consistency of the snapshot?
>
>
> On 9/30/13 2:43 PM, "SuichII, Christopher" <Ch...@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.suich@netapp.com<ma...@netapp.com>
> >NetApp Software Engineer
> >Data Center Platforms Cloud Solutions
> >Citrix, Cisco & Red Hat
> >
>
>
--
*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>
*™*
Re: [PROPOSAL] Provide Option to Quiesce VMs While Taking Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.Suich@netapp.com> 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
> chris.suich@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
>
> On Sep 30, 2013, at 6:03 PM, Mike Tutkowski <mi...@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.tutkowski@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.Vittal@citrix.com> wrote:
> >>
> >>> Is VM Quiescing sufficient to ensure consistency of the snapshot?
> >>>
> >>>
> >>> On 9/30/13 2:43 PM, "SuichII, Christopher" <Ch...@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.suich@netapp.com<ma...@netapp.com>
> >>>> NetApp Software Engineer
> >>>> Data Center Platforms Cloud Solutions
> >>>> Citrix, Cisco & Red Hat
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> *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>
> >> *™*
> >>
> >
> >
> >
> > --
> > *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>
> > *™*
>
>
--
*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>
*™*
Re: [PROPOSAL] Provide Option to Quiesce VMs While Taking Snapshots
Posted by "SuichII, Christopher" <Ch...@netapp.com>.
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.suich@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat
On Sep 30, 2013, at 6:03 PM, Mike Tutkowski <mi...@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.tutkowski@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.Vittal@citrix.com> wrote:
>>
>>> Is VM Quiescing sufficient to ensure consistency of the snapshot?
>>>
>>>
>>> On 9/30/13 2:43 PM, "SuichII, Christopher" <Ch...@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.suich@netapp.com<ma...@netapp.com>
>>>> NetApp Software Engineer
>>>> Data Center Platforms Cloud Solutions
>>>> Citrix, Cisco & Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> *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>
>> *™*
>>
>
>
>
> --
> *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>
> *™*
Re: [PROPOSAL] Provide Option to Quiesce VMs While Taking Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.Vittal@citrix.com> wrote:
>
>> Is VM Quiescing sufficient to ensure consistency of the snapshot?
>>
>>
>> On 9/30/13 2:43 PM, "SuichII, Christopher" <Ch...@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.suich@netapp.com<ma...@netapp.com>
>> >NetApp Software Engineer
>> >Data Center Platforms Cloud Solutions
>> >Citrix, Cisco & Red Hat
>> >
>>
>>
>
>
> --
> *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>
> *™*
>
--
*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>
*™*