[openstack-dev] [nova] a question about instance snapshot

Sheng Bo Hou sbhou at cn.ibm.com
Mon Mar 17 14:27:57 UTC 2014


Hi Jay and Zhao Qin,

Thank you for your reply. I have recap my recent ideas about the 
blueprints and put them in the link: 
https://etherpad.openstack.org/p/live-snapshot.
Waiting for your comments. 
Thank you folks again.

Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM at IBMCN    E-mail: sbhou at cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编:100193



Jay Pipes <jaypipes at gmail.com> 
2014/03/14 11:40

To
Sheng Bo Hou/China/IBM at IBMCN, 
cc
chaochin at gmail.com
Subject
Re: 转发: Re: [openstack-dev] [nova] a question about instance snapshot






Hi again, Vincent! I'm including Qin Zhao (cc'd) in our conversation,
since we were chatting about this on IRC :)

Qin helpfully created an Etherpad where we are beginning to discuss this
blueprint (and the related half-completed one).

https://etherpad.openstack.org/p/live-snapshot

See you on the etherpad! :)

Best,
-jay

On Fri, 2014-03-14 at 09:47 +0800, Sheng Bo Hou wrote:
> Hi Jay, 
> 
> I found you are in the discussion about live snapshot. I came up with
> a relatively generic solution for Nova in the following mail. Hope you
> can take a look review and give me your feedbacks. 
> 
> Thank you so much. 
> 
> Best wishes,
> Vincent Hou (侯胜博)

> Hi everyone,
> 
> I got excited to hear that this live snapshot has been taken into
> discussion in our community. Recently my clients in China came up with
> this live snapshot requirement as well, because they have already had
> their legacy environment and expect the original functions work fine
> when they transfer to use OpenStack. In my opinion, we need to think a
> little bit about these clients' needs, because it is also a potential
> market for OpenStack.
> 
> I registered a new blueprint for Nova
> https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot.
> It is named driver-specific before, but can be changed later.
> 
> The Nova API could be implemented via the extension, the following API
> may be added:
> • CreateSnapshot: create a snapshot from the VM. The snapshot can be
> live snapshot or other hypervisor native way to create a snapshot.
> • RestoreFromSnapshot: restore/revert the VM from a snapshot.
> • DeleteSnapshot: delete a snapshot.
> • ListSnapshot: list all the snapshots or list all the snapshots if a
> VM id is given.
> • SpawnFromSnapshot: spawn a new VM from an existing snapshot, which
> is the live snapshot or the snapshot of other snapshot created in a
> hypervisor native way. 
> The features in this blueprint can be optional for any drivers. If a
> driver does not have a "native way" to do live snapshot or other kind
> of snapshots, it is fine to leave the API not implemented; if a driver
> can provide the "native feature" to do snapshot, it is an opportunity
> to reinforce Nova with this snapshot support. 
> 
> I sincerely need your comments and hope we can figure it out in a most
> favorable way. 
> Thank you so much. 
> 
> Best wishes,
> Vincent Hou (侯胜博)
> 
> Staff Software Engineer, Open Standards and Open Source Team, Emerging
> Technology Institute, IBM China Software Development Lab
> 
> Tel: 86-10-82450778 Fax: 86-10-82453660
> Notes ID: Sheng Bo Hou/China/IBM at IBMCN    E-mail: sbhou at cn.ibm.com 
> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
> West Road, Haidian District, Beijing, P.R.C.100193
> 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编:
> 100193 
> 
> Jay Pipes <jaypipes at gmail.com> 
> 
> 2014/03/12 03:15 
> Please respond to
> "OpenStack Development Mailing List
> \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> 
> To
> openstack-dev at lists.openstack.org, 
> cc
> 
> Subject
> Re:
> [openstack-dev]
> [nova] a question
> about instance
> snapshot
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, 2014-03-11 at 06:35 +0000, Bohai (ricky) wrote:
> > > -----Original Message-----
> > > From: Jay Pipes [mailto:jaypipes at gmail.com]
> > > Sent: Tuesday, March 11, 2014 3:20 AM
> > > To: openstack-dev at lists.openstack.org
> > > Subject: Re: [openstack-dev] [nova] a question about instance
> snapshot
> > >
> > > On Mon, 2014-03-10 at 12:13 -0400, Shawn Hartsock wrote:
> > > > We have very strong interest in pursing this feature in the
> VMware
> > > > driver as well. I would like to see the revert instance feature
> > > > implemented at least.
> > > >
> > > > When I used to work in multi-discipline roles involving
> operations it
> > > > would be common for us to snapshot a vm, run through an upgrade
> > > > process, then revert if something did not upgrade smoothly. This
> > > > ability alone can be exceedingly valuable in long-lived virtual
> > > > machines.
> > > >
> > > > I also have some comments from parties interested in refactoring
> how
> > > > the VMware drivers handle snapshots but I'm not certain how much
> that
> > > > plays into this "live snapshot" discussion.
> > >
> > > I think the reason that there isn't much interest in doing this
> kind of thing is
> > > because the worldview that VMs are pets is antithetical to the
> worldview that
> > > VMs are cattle, and Nova tends to favor the latter (where DRS/DPM
> on
> > > vSphere tends to favor the former).
> > >
> > > There's nothing about your scenario above of being able to
> "revert" an instance
> > > to a particular state that isn't possible with today's Nova.
> > > Snapshotting an instance, doing an upgrade of software on the
> instance, and
> > > then restoring from the snapshot if something went wrong
> (reverting) is
> > > already fully possible to do with the regular Nova snapshot and
> restore
> > > operations. The only difference is that the "live-snapshot"
> > > stuff would include saving the memory view of a VM in addition to
> its disk state.
> > > And that, at least in my opinion, is only needed when you are
> treating VMs like
> > > pets and not cattle.
> > >
> > 
> > Hi Jay,
> > 
> > I read every words in your reply and respect what you said.
> > 
> > But i can't agree with you that memory snapshot is a feature for pat
> not for cattle.
> > I think it's a feature whatever what do you look the instance as.
> > 
> > The world doesn't care about what we look the instance as, in fact,
> currently almost all the
> > mainstream hypervisors have supported the memory snapshot.
> > If it's just a dispensable feature and no users need it, I can't
> understand why
> > the hypervisors provide it without exception.
> > 
> > In the document " OPENSTACK OPERATIONS GUIDE" section " Live
> snapshots" has the
> > below words:
> > " To ensure that important services have written their contents to
> disk (such as, databases),
> > we recommend you read the documentation for those applications to
> determine what commands
> > to issue to have them sync their contents to disk. If you are unsure
> how to do this,
> >  the safest approach is to simply stop these running services
> normally.
> > "
> > This just pushes all the responsibility to guarantee the consistency
> of the instance to the end user.
> > It's absolutely not convenient and I doubt whether it's appropriate.
> 
> Hi Ricky,
> 
> I guess we will just have to disagree about the relative usefulness of
> this kind of thing for users of the cloud (and not users of
> traditional
> managed hosting) :) Like I said, if it does not affect the performance
> of other tenants' instances, I'm fine with adding the functionality in
> a
> way that is generic (not hypervisor-specific).
> 
> Best,
> -jay
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/213bc646/attachment.html>


More information about the OpenStack-dev mailing list