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

2014-03-17 Thread Sheng Bo Hou
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@IBMCNE-mail: sb...@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  
2014/03/14 11:40

To
Sheng Bo Hou/China/IBM@IBMCN, 
cc
chaoc...@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@IBMCNE-mail: sb...@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  
> 
> 2014/03/12 03:15 
> Please respond to
> "OpenStack Development Mailing List
> \(not for usage questions\)"
> 
> 
> To
> openstack-dev@lists.openstack.org, 
> cc
> 
> Subject
> Re:
> [openstack-dev]
> [nova] a question
> about instance
> snapshot
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, 2014-03-11 at 06:35 +, Bohai (ricky) wrote:
> > > -Original Message-
> > > From: Jay Pipes [mailto:jaypi...@gmail.com]
> > > Sent: Tuesday, March 11, 2014 3:20 AM
> > > To: openstack-dev@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-disciplin

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

2014-03-13 Thread Qin Zhao
Hi Vincent,
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?


On Wed, Mar 12, 2014 at 11:14 AM, Sheng Bo Hou  wrote:

> 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@IBMCNE-mail: sb...@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 >*
>
> 2014/03/12 03:15
>  Please respond to
> "OpenStack Development Mailing List \(not for usage questions\)" <
> openstack-dev@lists.openstack.org>
>
>   To
> openstack-dev@lists.openstack.org,
> cc
>   Subject
> Re: [openstack-dev] [nova] a question about instance snapshot
>
>
>
>
> On Tue, 2014-03-11 at 06:35 +, Bohai (ricky) wrote:
> > > -Original Message-
> > > From: Jay Pipes [mailto:jaypi...@gmail.com ]
> > > Sent: Tuesday, March 11, 2014 3:20 AM
> > > To: openstack-dev@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 No

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

2014-03-11 Thread Sheng Bo 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@IBMCNE-mail: sb...@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  
2014/03/12 03:15
Please respond to
"OpenStack Development Mailing List \(not for usage questions\)" 



To
openstack-dev@lists.openstack.org, 
cc

Subject
Re: [openstack-dev] [nova] a question about instance snapshot






On Tue, 2014-03-11 at 06:35 +, Bohai (ricky) wrote:
> > -Original Message-
> > From: Jay Pipes [mailto:jaypi...@gmail.com]
> > Sent: Tuesday, March 11, 2014 3:20 AM
> > To: openstack-dev@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 a

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

2014-03-11 Thread Qin Zhao
Live-snapshot is definitely generic. Mainstream hypervisors (vmware, kvm,
hyperv) already support it for a long time. In
https://review.openstack.org/#/c/34036/, I see the last comment made by
Russell Bryant is that only libvirt backend request to implement it. I am
very curious about that. To my understanding, at least vmware, kvm, hyperv
should propose to implement this function. Why did we abandon that last
year? Can we consider to continue this work in Juno?


On Wed, Mar 12, 2014 at 3:15 AM, Jay Pipes  wrote:

> On Tue, 2014-03-11 at 06:35 +, Bohai (ricky) wrote:
> > > -Original Message-
> > > From: Jay Pipes [mailto:jaypi...@gmail.com]
> > > Sent: Tuesday, March 11, 2014 3:20 AM
> > > To: openstack-dev@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Qin Zhao
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-11 Thread Jay Pipes
On Tue, 2014-03-11 at 06:35 +, Bohai (ricky) wrote:
> > -Original Message-
> > From: Jay Pipes [mailto:jaypi...@gmail.com]
> > Sent: Tuesday, March 11, 2014 3:20 AM
> > To: openstack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-11 Thread Kashyap Chamarthy
On Fri, Mar 07, 2014 at 02:29:04AM +, Liuji (Jeremy) wrote:
> Hi, all
> 
> Current openstack seems not support to snapshot instance with memory
> and dev states.  I searched the blueprint and found two relational
> blueprint like below.  But these blueprint failed to get in the
> branch.
> 
> [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots [2]:
> https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
> 
> In the blueprint[1], there is a comment," We discussed this pretty
> extensively on the mailing list and in a design summit session.  The
> consensus is that this is not a feature we would like to have in nova.
> --russellb " But I can't find the discuss mail about it. I hope to
> know why we think so ?  Without memory snapshot, we can't to provide
> the feature for user to revert a instance to a checkpoint. 

I agree, it's a useful feature.

Speaking from a libvirt/QEMU standpoint, with recent upstream versions,
it's entirely possible to do a live memory and disk snapshot in a single
operation. I think it's a matter of someone adding wiring up the support
in Nova.

In libvirt's parlance, it's called External 'system checkpoint' snapshot
i.e: the guest's disk-state will be saved in one file, its RAM &
device-state will be saved in another new file.

  NOTE: 'system checkpoint' meaning - it captures VM state and disk
  state; VM state meaning - it captures memory and device state (but
  _not_ "disk" state).

 
I just did a quick test  libvirt's virsh:

1. Start the guest:

  $ virsh start ostack-controller
  Domain ostack-controller started

2. List its block device in use:

  $ virsh domblklist ostack-controller
  Target Source
  
  vda/var/lib/libvirt/images/ostack-controller.qcow2

3. Take a LIVE external system checkpoint snapshot, specifying both disk
   file _and_ memory file:

  $ virsh snapshot-create-as --domain ostack-controller snap1 \
--diskspec vda,file=/export/vmimages/disk-snap.qcow2,snapshot=external \
--memspec file=/export/vmimages/mem-snap.qcow2,snapshot=external \
--atomic
  Domain snapshot snap1 created

  NOTE: Once the above command is issued, the original disk image of
ostack-controller will become the backing_file & the new overlay
image specified (disk-snap.qcow2) will be used to track the new
changes. Here on, libvirt will use this overlay for further
write operations (while using the original image as a read-only
backing_file).

4. List the snapshot: 

  $ virsh snapshot-list ostack-controller
  Name Creation Time State
  
  snap12014-03-11 20:01:54 +0530 running

5. Optionally, check if the snapshot file we specified (disk-snap.qocw2)
   is indeed the new overlay


That's the versions I used to test the above:

  $ uname -r; rpm -q qemu-system-x86 libvirt
  3.13.4-200.fc20.x86_64
  qemu-system-x86-1.7.0-5.fc21.x86_64
  libvirt-1.2.3-1.fc20.x86_64


Hope that helps.

-- 
/kashyap

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-10 Thread Bohai (ricky)
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, March 11, 2014 3:20 AM
> To: openstack-dev@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.


Best regards to you.
Ricky

> Best,
> -jay
>
> > On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky) 
> wrote:
> > >> -Original Message-
> > >> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
> > >> Sent: Sunday, March 09, 2014 10:04 PM
> > >> To: OpenStack Development Mailing List (not for usage questions)
> > >> Subject: Re: [openstack-dev] [nova] a question about instance
> > >> snapshot
> > >>
> > >> Hi, Jeremy, the discussion at here
> > >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/0136
> > >> 88.html
> > >>
> > >
> > > I have a great interest in the topic too.
> > > I read the link you provided, and there is a little confusion for me.
> > > I agree with the security consideration in the discussion and memory
> snapshot can't be used for the cloning instance easily.
> > >
> > > But I think it's safe for the using for Instance revert.
> > > And revert the instance to a checkpoint is valuable for the user.
> > > Why we didn't use it for instance revert in the first step?
> > >
> > > Best regards to you.
> > > Ricky
> > >
> > >> Thanks
> > >> Alex
> > >> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
> > >> > Hi, all
> > >> >
> > >> > Current openstack seems not support to snapshot instance with
> > >> > memory and
> > >> dev states.
> > >> > I searched the blueprint and found two relational bl

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

2014-03-10 Thread laserjetyang
the live snapshot has some issue on KVM, and I think it is a problem of KVM
hypervisor. For VMware, live snapshot is quite mature, and I think it is a
good way to start with VMware live snapshot.


On Tue, Mar 11, 2014 at 1:37 PM, Qin Zhao  wrote:

> Hi Jay,
> When users move from old tools to new cloud tools, they also hope the new
> tool can inherit some good and well-known capabilities. Sometimes, assuming
> users can change their habit is dangerous. (Eg. removing Windows Start
> button). Live-snapshot is indeed a very useful feature of hypervisors, and
> it is widely used for several years (especially for VMware). I think it is
> not harmful to existing Nova structure and workflow, and will let more
> people to adopt OpenStack easier.
>
>
> On Tue, Mar 11, 2014 at 6:15 AM, Jay Pipes  wrote:
>
>> On Mon, 2014-03-10 at 15:52 -0600, Chris Friesen wrote:
>> > On 03/10/2014 02:58 PM, Jay Pipes wrote:
>> > > On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:
>> > >> While I understand the general argument about pets versus cattle. The
>> > >> question is, would you be willing to poke a few holes in the strict
>> > >> "cattle" abstraction for the sake of pragmatism. Few shops are going
>> > >> to make the direct transition in one move. Poking a hole in the
>> cattle
>> > >> abstraction allowing them to keep a pet VM might be very valuable to
>> > >> some shops making a migration.
>> > >
>> > > Poking holes in cattle aside, my experience with shops that prefer the
>> > > pets approach is that they are either:
>> > >
>> > >   * Not managing their servers themselves at all and just relying on
>> some
>> > > IT operations organization to manage everything for them, including
>> all
>> > > aspects of backing up their data as well as failing over and balancing
>> > > servers, or,
>> > >   * Hiding behind rationales of "needing to be secure" or "needing
>> 100%
>> > > uptime" or "needing no customer disruption" in order to avoid any
>> change
>> > > to the status quo. This is because the incentives inside legacy IT
>> > > application development and IT operations groups are typically towards
>> > > not rocking the boat in order to satisfy unrealistic expectations and
>> > > outdated interface agreements that are forced upon them by management
>> > > chains that haven't crawled out of the waterfall project management
>> funk
>> > > of the 1980s.
>> > >
>> > > Adding pet-based features to Nova would, IMO, just perpetuate the
>> above
>> > > scenarios and incentives.
>> >
>> > What about the cases where it's not a "preference" but rather just the
>> > inertia of pre-existing systems and procedures?
>>
>> You mean what I wrote in the second bullet point above?
>>
>> > If we can get them in the door with enough support for legacy stuff,
>> > then they might be easier to convince to do things the "cloud" way in
>> > the future.
>>
>> Yes, fair point, and that's what Shawn was saying as well. Just noting
>> that in my experience, the second part of the above sentence just
>> doesn't happen. Once you bring them over and offer them the tools from
>> their legacy environment, they aren't interested in changing. :)
>>
>> > If we stick with the hard-line cattle-only approach we run the risk of
>> > alienating them completely since redoing everything at once is generally
>> > not feasible.
>>
>> Yes, I understand that. I'm actually fine with including functionality
>> like memory snapshotting, but only if under no circumstances does it
>> negatively impact the service of compute to other tenants/users and will
>> not negatively impact the scaling factor of Nova either.
>>
>> I'm just not as optimistic as you are that once legacy IT folks have
>> their old tools, they will consider changing their habits. ;)
>>
>> Best,
>> -jay
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Qin Zhao
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-10 Thread Qin Zhao
Hi Jay,
When users move from old tools to new cloud tools, they also hope the new
tool can inherit some good and well-known capabilities. Sometimes, assuming
users can change their habit is dangerous. (Eg. removing Windows Start
button). Live-snapshot is indeed a very useful feature of hypervisors, and
it is widely used for several years (especially for VMware). I think it is
not harmful to existing Nova structure and workflow, and will let more
people to adopt OpenStack easier.


On Tue, Mar 11, 2014 at 6:15 AM, Jay Pipes  wrote:

> On Mon, 2014-03-10 at 15:52 -0600, Chris Friesen wrote:
> > On 03/10/2014 02:58 PM, Jay Pipes wrote:
> > > On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:
> > >> While I understand the general argument about pets versus cattle. The
> > >> question is, would you be willing to poke a few holes in the strict
> > >> "cattle" abstraction for the sake of pragmatism. Few shops are going
> > >> to make the direct transition in one move. Poking a hole in the cattle
> > >> abstraction allowing them to keep a pet VM might be very valuable to
> > >> some shops making a migration.
> > >
> > > Poking holes in cattle aside, my experience with shops that prefer the
> > > pets approach is that they are either:
> > >
> > >   * Not managing their servers themselves at all and just relying on
> some
> > > IT operations organization to manage everything for them, including all
> > > aspects of backing up their data as well as failing over and balancing
> > > servers, or,
> > >   * Hiding behind rationales of "needing to be secure" or "needing 100%
> > > uptime" or "needing no customer disruption" in order to avoid any
> change
> > > to the status quo. This is because the incentives inside legacy IT
> > > application development and IT operations groups are typically towards
> > > not rocking the boat in order to satisfy unrealistic expectations and
> > > outdated interface agreements that are forced upon them by management
> > > chains that haven't crawled out of the waterfall project management
> funk
> > > of the 1980s.
> > >
> > > Adding pet-based features to Nova would, IMO, just perpetuate the above
> > > scenarios and incentives.
> >
> > What about the cases where it's not a "preference" but rather just the
> > inertia of pre-existing systems and procedures?
>
> You mean what I wrote in the second bullet point above?
>
> > If we can get them in the door with enough support for legacy stuff,
> > then they might be easier to convince to do things the "cloud" way in
> > the future.
>
> Yes, fair point, and that's what Shawn was saying as well. Just noting
> that in my experience, the second part of the above sentence just
> doesn't happen. Once you bring them over and offer them the tools from
> their legacy environment, they aren't interested in changing. :)
>
> > If we stick with the hard-line cattle-only approach we run the risk of
> > alienating them completely since redoing everything at once is generally
> > not feasible.
>
> Yes, I understand that. I'm actually fine with including functionality
> like memory snapshotting, but only if under no circumstances does it
> negatively impact the service of compute to other tenants/users and will
> not negatively impact the scaling factor of Nova either.
>
> I'm just not as optimistic as you are that once legacy IT folks have
> their old tools, they will consider changing their habits. ;)
>
> Best,
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Qin Zhao
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-10 Thread Jay Pipes
On Mon, 2014-03-10 at 15:52 -0600, Chris Friesen wrote:
> On 03/10/2014 02:58 PM, Jay Pipes wrote:
> > On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:
> >> While I understand the general argument about pets versus cattle. The
> >> question is, would you be willing to poke a few holes in the strict
> >> "cattle" abstraction for the sake of pragmatism. Few shops are going
> >> to make the direct transition in one move. Poking a hole in the cattle
> >> abstraction allowing them to keep a pet VM might be very valuable to
> >> some shops making a migration.
> >
> > Poking holes in cattle aside, my experience with shops that prefer the
> > pets approach is that they are either:
> >
> >   * Not managing their servers themselves at all and just relying on some
> > IT operations organization to manage everything for them, including all
> > aspects of backing up their data as well as failing over and balancing
> > servers, or,
> >   * Hiding behind rationales of "needing to be secure" or "needing 100%
> > uptime" or "needing no customer disruption" in order to avoid any change
> > to the status quo. This is because the incentives inside legacy IT
> > application development and IT operations groups are typically towards
> > not rocking the boat in order to satisfy unrealistic expectations and
> > outdated interface agreements that are forced upon them by management
> > chains that haven't crawled out of the waterfall project management funk
> > of the 1980s.
> >
> > Adding pet-based features to Nova would, IMO, just perpetuate the above
> > scenarios and incentives.
> 
> What about the cases where it's not a "preference" but rather just the 
> inertia of pre-existing systems and procedures?

You mean what I wrote in the second bullet point above?

> If we can get them in the door with enough support for legacy stuff, 
> then they might be easier to convince to do things the "cloud" way in 
> the future.

Yes, fair point, and that's what Shawn was saying as well. Just noting
that in my experience, the second part of the above sentence just
doesn't happen. Once you bring them over and offer them the tools from
their legacy environment, they aren't interested in changing. :)

> If we stick with the hard-line cattle-only approach we run the risk of 
> alienating them completely since redoing everything at once is generally 
> not feasible.

Yes, I understand that. I'm actually fine with including functionality
like memory snapshotting, but only if under no circumstances does it
negatively impact the service of compute to other tenants/users and will
not negatively impact the scaling factor of Nova either.

I'm just not as optimistic as you are that once legacy IT folks have
their old tools, they will consider changing their habits. ;)

Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-10 Thread Chris Friesen

On 03/10/2014 02:58 PM, Jay Pipes wrote:

On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:

While I understand the general argument about pets versus cattle. The
question is, would you be willing to poke a few holes in the strict
"cattle" abstraction for the sake of pragmatism. Few shops are going
to make the direct transition in one move. Poking a hole in the cattle
abstraction allowing them to keep a pet VM might be very valuable to
some shops making a migration.


Poking holes in cattle aside, my experience with shops that prefer the
pets approach is that they are either:

  * Not managing their servers themselves at all and just relying on some
IT operations organization to manage everything for them, including all
aspects of backing up their data as well as failing over and balancing
servers, or,
  * Hiding behind rationales of "needing to be secure" or "needing 100%
uptime" or "needing no customer disruption" in order to avoid any change
to the status quo. This is because the incentives inside legacy IT
application development and IT operations groups are typically towards
not rocking the boat in order to satisfy unrealistic expectations and
outdated interface agreements that are forced upon them by management
chains that haven't crawled out of the waterfall project management funk
of the 1980s.

Adding pet-based features to Nova would, IMO, just perpetuate the above
scenarios and incentives.


What about the cases where it's not a "preference" but rather just the 
inertia of pre-existing systems and procedures?


If we can get them in the door with enough support for legacy stuff, 
then they might be easier to convince to do things the "cloud" way in 
the future.


If we stick with the hard-line cattle-only approach we run the risk of 
alienating them completely since redoing everything at once is generally 
not feasible.


Chris





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-10 Thread Jay Pipes
On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:
> While I understand the general argument about pets versus cattle. The
> question is, would you be willing to poke a few holes in the strict
> "cattle" abstraction for the sake of pragmatism. Few shops are going
> to make the direct transition in one move. Poking a hole in the cattle
> abstraction allowing them to keep a pet VM might be very valuable to
> some shops making a migration.

Poking holes in cattle aside, my experience with shops that prefer the
pets approach is that they are either:

 * Not managing their servers themselves at all and just relying on some
IT operations organization to manage everything for them, including all
aspects of backing up their data as well as failing over and balancing
servers, or,
 * Hiding behind rationales of "needing to be secure" or "needing 100%
uptime" or "needing no customer disruption" in order to avoid any change
to the status quo. This is because the incentives inside legacy IT
application development and IT operations groups are typically towards
not rocking the boat in order to satisfy unrealistic expectations and
outdated interface agreements that are forced upon them by management
chains that haven't crawled out of the waterfall project management funk
of the 1980s.

Adding pet-based features to Nova would, IMO, just perpetuate the above
scenarios and incentives.

> To be fair, the places where I've heard interest are looking to "walk
> not run" from a pets approach to a cattle approach. This conceit in
> the abstraction might be valuable enough to them to spell the
> difference between cautiously adopting and tacitly rejecting
> OpenStack.
> 
> That's how I would argue *for* the change anyhow, it's not an argument
> based on ideology but on pragmatism.

Yeah, I understand your point, and I do see how it might lead some folks
towards OpenStack.

But then again, I wouldn't port a bunch of Prolog language constructs
and quirks to Python just to lure Prolog and Erlang developers.

In the end, I know I'm probably just over-zealous on this stuff, but I
just can't help it :)

Best,
-jay

> On Mon, Mar 10, 2014 at 3:19 PM, Jay Pipes  wrote:
> > 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.
> >
> > Best,
> > -jay
> >
> >> On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky)  wrote:
> >> >> -Original Message-
> >> >> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
> >> >> Sent: Sunday, March 09, 2014 10:04 PM
> >> >> To: OpenStack Development Mailing List (not for usage questions)
> >> >> Subject: Re: [openstack-dev] [nova] a question about instance snapshot
> >> >>
> >> >> Hi, Jeremy, the discussion at here
> >> >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
> >> >>
> >> >
> >> > I have a great interest in 

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

2014-03-10 Thread Joe Gordon
On Mar 10, 2014 12:29 PM, "Jay Pipes"  wrote:
>
> 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.

++, well said.

>
> Best,
> -jay
>
> > On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky) 
wrote:
> > >> -Original Message-
> > >> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
> > >> Sent: Sunday, March 09, 2014 10:04 PM
> > >> To: OpenStack Development Mailing List (not for usage questions)
> > >> Subject: Re: [openstack-dev] [nova] a question about instance
snapshot
> > >>
> > >> Hi, Jeremy, the discussion at here
> > >>
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
> > >>
> > >
> > > I have a great interest in the topic too.
> > > I read the link you provided, and there is a little confusion for me.
> > > I agree with the security consideration in the discussion and memory
snapshot can't be used for the cloning instance easily.
> > >
> > > But I think it's safe for the using for Instance revert.
> > > And revert the instance to a checkpoint is valuable for the user.
> > > Why we didn't use it for instance revert in the first step?
> > >
> > > Best regards to you.
> > > Ricky
> > >
> > >> Thanks
> > >> Alex
> > >> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
> > >> > Hi, all
> > >> >
> > >> > Current openstack seems not support to snapshot instance with
memory and
> > >> dev states.
> > >> > I searched the blueprint and found two relational blueprint like
below.
> > >> > But these blueprint failed to get in the branch.
> > >> >
> > >> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
> > >> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
> > >> >
> > >> > In the blueprint[1], there is a comment,"
> > >> > We discussed this pretty extensively on the mailing list and in a
design
> > >> summit session.
> > >> > The consensus is that this is not a feature we would like to have
in nova.
> > >> --russellb "
> > >> > But I can't find the discuss mail about it. I hope to know why we
think so ?
> > >> > Without memory snapshot, we can't to provide the feature for user
to revert
> > >> a instance to a checkpoint.
> > >> >
> > >> > Anyone who knows the history can help me or give me a hint how to
find the
> > >> discuss mail?
> > >> >
> > >> > I am a newbie for openstack and I apologize if I am missing
something very
> > >> obvious.
> > >> >
> > >> >
> > >> > Thanks,
> > >> > Jeremy Liu
> > >> >
> > >> >
> > >> > ___
> > &g

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

2014-03-10 Thread Shawn Hartsock
While I understand the general argument about pets versus cattle. The
question is, would you be willing to poke a few holes in the strict
"cattle" abstraction for the sake of pragmatism. Few shops are going
to make the direct transition in one move. Poking a hole in the cattle
abstraction allowing them to keep a pet VM might be very valuable to
some shops making a migration.

To be fair, the places where I've heard interest are looking to "walk
not run" from a pets approach to a cattle approach. This conceit in
the abstraction might be valuable enough to them to spell the
difference between cautiously adopting and tacitly rejecting
OpenStack.

That's how I would argue *for* the change anyhow, it's not an argument
based on ideology but on pragmatism.

On Mon, Mar 10, 2014 at 3:19 PM, Jay Pipes  wrote:
> 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.
>
> Best,
> -jay
>
>> On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky)  wrote:
>> >> -----Original Message-
>> >> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
>> >> Sent: Sunday, March 09, 2014 10:04 PM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: Re: [openstack-dev] [nova] a question about instance snapshot
>> >>
>> >> Hi, Jeremy, the discussion at here
>> >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
>> >>
>> >
>> > I have a great interest in the topic too.
>> > I read the link you provided, and there is a little confusion for me.
>> > I agree with the security consideration in the discussion and memory 
>> > snapshot can't be used for the cloning instance easily.
>> >
>> > But I think it's safe for the using for Instance revert.
>> > And revert the instance to a checkpoint is valuable for the user.
>> > Why we didn't use it for instance revert in the first step?
>> >
>> > Best regards to you.
>> > Ricky
>> >
>> >> Thanks
>> >> Alex
>> >> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
>> >> > Hi, all
>> >> >
>> >> > Current openstack seems not support to snapshot instance with memory and
>> >> dev states.
>> >> > I searched the blueprint and found two relational blueprint like below.
>> >> > But these blueprint failed to get in the branch.
>> >> >
>> >> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
>> >> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
>> >> >
>> >> > In the blueprint[1], there is a comment,"
>> >> > We discussed this pretty extensively on the mailing list and in a design
>> >> summit session.
>> >> > The consensus is that this is not a feature we would like to have in 
>> >> > nova.
>> >&

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

2014-03-10 Thread Jay Pipes
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.

Best,
-jay

> On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky)  wrote:
> >> -Original Message-
> >> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
> >> Sent: Sunday, March 09, 2014 10:04 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [nova] a question about instance snapshot
> >>
> >> Hi, Jeremy, the discussion at here
> >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
> >>
> >
> > I have a great interest in the topic too.
> > I read the link you provided, and there is a little confusion for me.
> > I agree with the security consideration in the discussion and memory 
> > snapshot can't be used for the cloning instance easily.
> >
> > But I think it's safe for the using for Instance revert.
> > And revert the instance to a checkpoint is valuable for the user.
> > Why we didn't use it for instance revert in the first step?
> >
> > Best regards to you.
> > Ricky
> >
> >> Thanks
> >> Alex
> >> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
> >> > Hi, all
> >> >
> >> > Current openstack seems not support to snapshot instance with memory and
> >> dev states.
> >> > I searched the blueprint and found two relational blueprint like below.
> >> > But these blueprint failed to get in the branch.
> >> >
> >> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
> >> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
> >> >
> >> > In the blueprint[1], there is a comment,"
> >> > We discussed this pretty extensively on the mailing list and in a design
> >> summit session.
> >> > The consensus is that this is not a feature we would like to have in 
> >> > nova.
> >> --russellb "
> >> > But I can't find the discuss mail about it. I hope to know why we think 
> >> > so ?
> >> > Without memory snapshot, we can't to provide the feature for user to 
> >> > revert
> >> a instance to a checkpoint.
> >> >
> >> > Anyone who knows the history can help me or give me a hint how to find 
> >> > the
> >> discuss mail?
> >> >
> >> > I am a newbie for openstack and I apologize if I am missing something 
> >> > very
> >> obvious.
> >> >
> >> >
> >> > Thanks,
> >> > Jeremy Liu
> >> >
> >> >
> >> > ___
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-10 Thread Shawn Hartsock
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.

On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky)  wrote:
>> -Original Message-
>> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
>> Sent: Sunday, March 09, 2014 10:04 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [nova] a question about instance snapshot
>>
>> Hi, Jeremy, the discussion at here
>> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
>>
>
> I have a great interest in the topic too.
> I read the link you provided, and there is a little confusion for me.
> I agree with the security consideration in the discussion and memory snapshot 
> can't be used for the cloning instance easily.
>
> But I think it's safe for the using for Instance revert.
> And revert the instance to a checkpoint is valuable for the user.
> Why we didn't use it for instance revert in the first step?
>
> Best regards to you.
> Ricky
>
>> Thanks
>> Alex
>> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
>> > Hi, all
>> >
>> > Current openstack seems not support to snapshot instance with memory and
>> dev states.
>> > I searched the blueprint and found two relational blueprint like below.
>> > But these blueprint failed to get in the branch.
>> >
>> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
>> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
>> >
>> > In the blueprint[1], there is a comment,"
>> > We discussed this pretty extensively on the mailing list and in a design
>> summit session.
>> > The consensus is that this is not a feature we would like to have in nova.
>> --russellb "
>> > But I can't find the discuss mail about it. I hope to know why we think so 
>> > ?
>> > Without memory snapshot, we can't to provide the feature for user to revert
>> a instance to a checkpoint.
>> >
>> > Anyone who knows the history can help me or give me a hint how to find the
>> discuss mail?
>> >
>> > I am a newbie for openstack and I apologize if I am missing something very
>> obvious.
>> >
>> >
>> > Thanks,
>> > Jeremy Liu
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
# Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-09 Thread Bohai (ricky)
> -Original Message-
> From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
> Sent: Sunday, March 09, 2014 10:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] a question about instance snapshot
> 
> Hi, Jeremy, the discussion at here
> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
> 

I have a great interest in the topic too.
I read the link you provided, and there is a little confusion for me.
I agree with the security consideration in the discussion and memory snapshot 
can't be used for the cloning instance easily. 

But I think it's safe for the using for Instance revert.
And revert the instance to a checkpoint is valuable for the user. 
Why we didn't use it for instance revert in the first step?

Best regards to you.
Ricky

> Thanks
> Alex
> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
> > Hi, all
> >
> > Current openstack seems not support to snapshot instance with memory and
> dev states.
> > I searched the blueprint and found two relational blueprint like below.
> > But these blueprint failed to get in the branch.
> >
> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
> >
> > In the blueprint[1], there is a comment,"
> > We discussed this pretty extensively on the mailing list and in a design
> summit session.
> > The consensus is that this is not a feature we would like to have in nova.
> --russellb "
> > But I can't find the discuss mail about it. I hope to know why we think so ?
> > Without memory snapshot, we can't to provide the feature for user to revert
> a instance to a checkpoint.
> >
> > Anyone who knows the history can help me or give me a hint how to find the
> discuss mail?
> >
> > I am a newbie for openstack and I apologize if I am missing something very
> obvious.
> >
> >
> > Thanks,
> > Jeremy Liu
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-03-09 Thread Alex Xu
Hi, Jeremy, the discussion at here 
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html


Thanks
Alex
On 2014年03月07日 10:29, Liuji (Jeremy) wrote:

Hi, all

Current openstack seems not support to snapshot instance with memory and dev 
states.
I searched the blueprint and found two relational blueprint like below.
But these blueprint failed to get in the branch.

[1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
[2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms

In the blueprint[1], there is a comment,"
We discussed this pretty extensively on the mailing list and in a design summit 
session.
The consensus is that this is not a feature we would like to have in nova. 
--russellb "
But I can't find the discuss mail about it. I hope to know why we think so ?
Without memory snapshot, we can't to provide the feature for user to revert a 
instance to a checkpoint.

Anyone who knows the history can help me or give me a hint how to find the 
discuss mail?

I am a newbie for openstack and I apologize if I am missing something very 
obvious.


Thanks,
Jeremy Liu


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev