<div dir="ltr"><div>Hi Vincent,<br></div>I feel your blueprint is interesting, too. Its objective seems similar with the existing one, and some new APIs also look similar as existing ones. For instance, 'RestoreFromSnapshot' looks like 'rebuild', and 'SpawnFromSnapshot' looks like 'spawn'. Does it benefit a lot, if we define these set of new APIs? </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 11:14 AM, Sheng Bo Hou <span dir="ltr"><<a href="mailto:sbhou@cn.ibm.com" target="_blank">sbhou@cn.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font face="Gentium Book Basic" size="3">Hi everyone,</font>
<br>
<br><font face="Gentium Book Basic" size="3">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.</font>
<br>
<br><font face="Gentium Book Basic" size="3">I registered a new blueprint
for Nova </font><a href="https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot" target="_blank"><font color="blue" face="Gentium Book Basic" size="3">https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot</font></a><font face="Gentium Book Basic" size="3">.
It is named driver-specific before, but can be changed later.</font>
<br>
<br><font face="Gentium Book Basic" size="3">The Nova API could be implemented
via the extension, the following API may be added:<br>
• CreateSnapshot: create a snapshot from the VM. <b>The snapshot can be
live snapshot or other hypervisor native way to create a snapshot.</b><br>
• RestoreFromSnapshot: restore/revert the VM from a snapshot.<br>
• DeleteSnapshot: delete a snapshot.<br>
• ListSnapshot: list all the snapshots or list all the snapshots if a
VM id is given.<br>
• 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.</font>
<br><font face="Gentium Book Basic" size="3">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. </font>
<br>
<br><font face="Gentium Book Basic" size="3">I sincerely need your comments
and hope we can figure it out in a most favorable way. </font>
<br><font face="Gentium Book Basic" size="3">Thank you so much.</font>
<br>
<br><font face="sans-serif">Best wishes,<br>
Vincent Hou (侯胜博)<br>
<br>
Staff Software Engineer, Open Standards and Open Source Team, Emerging
Technology Institute, IBM China Software Development Lab<br>
<br>
Tel: 86-10-82450778 Fax: 86-10-82453660<br>
Notes ID: Sheng Bo Hou/China/IBM@IBMCN    E-mail: <a href="mailto:sbhou@cn.ibm.com" target="_blank">sbhou@cn.ibm.com</a>
<br>
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
West Road, Haidian District, Beijing, P.R.C.100193<br>
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层
邮编：100193</font>
<br>
<br>
<br>
<p></p><table width="100%">
<tbody><tr valign="top">
<td width="40%"><font face="sans-serif" size="1"><b>Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></b>
</font>
<p><font face="sans-serif" size="1">2014/03/12 03:15</font>
</p><table border="">
<tbody><tr valign="top">
<td bgcolor="white">
<div align="center"><font face="sans-serif" size="1">Please respond to<br>
"OpenStack Development Mailing List \(not for usage questions\)"
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font></div></td></tr></tbody></table>
<br>
</td><td width="59%">
<table width="100%">
<tbody><tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">To</font></div>
</td><td><font face="sans-serif" size="1"><a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>, </font>
</td></tr><tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">cc</font></div>
</td><td>
</td></tr><tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">Subject</font></div>
</td><td><font face="sans-serif" size="1">Re: [openstack-dev] [nova] a question
about instance snapshot</font></td></tr></tbody></table>
<br>
<table>
<tbody><tr valign="top">
<td>
</td><td></td></tr></tbody></table>
<br></td></tr></tbody></table><div class="HOEnZb"><div class="h5">
<br>
<br>
<br><tt><font>On Tue, 2014-03-11 at 06:35 +0000, Bohai (ricky) wrote:<br>
> > -----Original Message-----<br>
> > From: Jay Pipes [</font></tt><a href="mailto:jaypipes@gmail.com" target="_blank"><tt><font>mailto:jaypipes@gmail.com</font></tt></a><tt><font>]<br>
> > Sent: Tuesday, March 11, 2014 3:20 AM<br>
> > To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
> > Subject: Re: [openstack-dev] [nova] a question about instance
snapshot<br>
> ><br>
> > On Mon, 2014-03-10 at 12:13 -0400, Shawn Hartsock wrote:<br>
> > > We have very strong interest in pursing this feature in
the VMware<br>
> > > driver as well. I would like to see the revert instance
feature<br>
> > > implemented at least.<br>
> > ><br>
> > > When I used to work in multi-discipline roles involving
operations it<br>
> > > would be common for us to snapshot a vm, run through an
upgrade<br>
> > > process, then revert if something did not upgrade smoothly.
This<br>
> > > ability alone can be exceedingly valuable in long-lived
virtual<br>
> > > machines.<br>
> > ><br>
> > > I also have some comments from parties interested in refactoring
how<br>
> > > the VMware drivers handle snapshots but I'm not certain
how much that<br>
> > > plays into this "live snapshot" discussion.<br>
> ><br>
> > I think the reason that there isn't much interest in doing this
kind of thing is<br>
> > because the worldview that VMs are pets is antithetical to the
worldview that<br>
> > VMs are cattle, and Nova tends to favor the latter (where DRS/DPM
on<br>
> > vSphere tends to favor the former).<br>
> ><br>
> > There's nothing about your scenario above of being able to "revert"
an instance<br>
> > to a particular state that isn't possible with today's Nova.<br>
> > Snapshotting an instance, doing an upgrade of software on the
instance, and<br>
> > then restoring from the snapshot if something went wrong (reverting)
is<br>
> > already fully possible to do with the regular Nova snapshot and
restore<br>
> > operations. The only difference is that the "live-snapshot"<br>
> > stuff would include saving the memory view of a VM in addition
to its disk state.<br>
> > And that, at least in my opinion, is only needed when you are
treating VMs like<br>
> > pets and not cattle.<br>
> ><br>
> <br>
> Hi Jay,<br>
> <br>
> I read every words in your reply and respect what you said.<br>
> <br>
> But i can't agree with you that memory snapshot is a feature for pat
not for cattle.<br>
> I think it's a feature whatever what do you look the instance as.<br>
> <br>
> The world doesn't care about what we look the instance as, in fact,
currently almost all the<br>
> mainstream hypervisors have supported the memory snapshot.<br>
> If it's just a dispensable feature and no users need it, I can't understand
why<br>
> the hypervisors provide it without exception.<br>
> <br>
> In the document " OPENSTACK OPERATIONS GUIDE" section "
Live snapshots" has the<br>
> below words:<br>
> " To ensure that important services have written their contents
to disk (such as, databases),<br>
> we recommend you read the documentation for those applications to
determine what commands<br>
> to issue to have them sync their contents to disk. If you are unsure
how to do this,<br>
>  the safest approach is to simply stop these running services
normally.<br>
> "<br>
> This just pushes all the responsibility to guarantee the consistency
of the instance to the end user.<br>
> It's absolutely not convenient and I doubt whether it's appropriate.<br>
<br>
Hi Ricky,<br>
<br>
I guess we will just have to disagree about the relative usefulness of<br>
this kind of thing for users of the cloud (and not users of traditional<br>
managed hosting) :) Like I said, if it does not affect the performance<br>
of other tenants' instances, I'm fine with adding the functionality in
a<br>
way that is generic (not hypervisor-specific).<br>
<br>
Best,<br>
-jay<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
<br>
</font></tt>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Qin Zhao<br></div>
</div>