Hi Joe, my meaning is that cloud users may not hope to create new instances or new images, because those actions may require additional approval and additional charging. Or, due to instance/image quota limits, they can not do that. Anyway, from user's perspective, saving and reverting the existing instance will be preferred sometimes. Creating a new instance will be another story.
On Wed, Mar 5, 2014 at 3:20 AM, Joe Gordon <joe.gord...@gmail.com> wrote: > On Tue, Mar 4, 2014 at 1:06 AM, Qin Zhao <chaoc...@gmail.com> wrote: > > I think the current snapshot implementation can be a solution sometimes, > but > > it is NOT exact same as user's expectation. For example, a new blueprint > is > > created last week, > > https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot, > which > > seems a little similar with this discussion. I feel the user is > requesting > > Nova to create in-place snapshot (not a new image), in order to revert > the > > instance to a certain state. This capability should be very useful when > > testing new software or system settings. It seems a short-term temporary > > snapshot associated with a running instance for Nova. Creating a new > > instance is not that convenient, and may be not feasible for the user, > > especially if he or she is using public cloud. > > > > Why isn't it easy to create a new instance from a snapshot? > > > > > On Tue, Mar 4, 2014 at 1:32 PM, Nandavar, Divakar Padiyar > > <divakar.padiyar-nanda...@hp.com> wrote: > >> > >> >>> Why reboot an instance? What is wrong with deleting it and create a > >> >>> new one? > >> > >> You generally use non-persistent disk mode when you are testing new > >> software or experimenting with settings. If something goes wrong just > >> reboot and you are back to clean state and start over again. I feel > it's > >> convenient to handle this with just a reboot rather than recreating the > >> instance. > >> > >> Thanks, > >> Divakar > >> > >> -----Original Message----- > >> From: Joe Gordon [mailto:joe.gord...@gmail.com] > >> Sent: Tuesday, March 04, 2014 10:41 AM > >> To: OpenStack Development Mailing List (not for usage questions) > >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent storage(after > >> stopping VM, data will be rollback automatically), do you think we shoud > >> introduce this feature? > >> Importance: High > >> > >> On Mon, Mar 3, 2014 at 8:13 PM, Zhangleiqiang <zhangleiqi...@huawei.com > > > >> wrote: > >> >> > >> >> This sounds like ephemeral storage plus snapshots. You build a base > >> >> image, snapshot it then boot from the snapshot. > >> > > >> > > >> > Non-persistent storage/disk is useful for sandbox-like environment, > and > >> > this feature has already exists in VMWare ESX from version 4.1. The > >> > implementation of ESX is the same as what you said, boot from > snapshot of > >> > the disk/volume, but it will also *automatically* delete the transient > >> > snapshot after the instance reboots or shutdowns. I think the whole > >> > procedure may be controlled by OpenStack other than user's manual > >> > operations. > >> > >> Why reboot an instance? What is wrong with deleting it and create a new > >> one? > >> > >> > > >> > As far as I know, libvirt already defines the corresponding > <transient> > >> > element in domain xml for non-persistent disk ( [1] ), but it cannot > specify > >> > the location of the transient snapshot. Although qemu-kvm has provided > >> > support for this feature by the "-snapshot" command argument, which > will > >> > create the transient snapshot under /tmp directory, the qemu driver of > >> > libvirt don't support <transient> element currently. > >> > > >> > I think the steps of creating and deleting transient snapshot may be > >> > better to done by Nova/Cinder other than waiting for the <transient> > support > >> > added to libvirt, as the location of transient snapshot should > specified by > >> > Nova. > >> > > >> > > >> > [1] http://libvirt.org/formatdomain.html#elementsDisks > >> > ---------- > >> > zhangleiqiang > >> > > >> > Best Regards > >> > > >> > > >> >> -----Original Message----- > >> >> From: Joe Gordon [mailto:joe.gord...@gmail.com] > >> >> Sent: Tuesday, March 04, 2014 11:26 AM > >> >> To: OpenStack Development Mailing List (not for usage questions) > >> >> Cc: Luohao (brian) > >> >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent > >> >> storage(after stopping VM, data will be rollback automatically), do > >> >> you think we shoud introduce this feature? > >> >> > >> >> On Mon, Mar 3, 2014 at 6:00 PM, Yuzhou (C) <vitas.yuz...@huawei.com> > >> >> wrote: > >> >> > Hi stackers, > >> >> > > >> >> > As far as I know ,there are two types of storage used by VM in > >> >> > openstack: > >> >> Ephemeral Storage and Persistent Storage. > >> >> > Data on ephemeral storage ceases to exist when the instance it is > >> >> > associated > >> >> with is terminated. Rebooting the VM or restarting the host server, > >> >> however, will not destroy ephemeral data. > >> >> > Persistent storage means that the storage resource outlives any > >> >> > other > >> >> resource and is always available, regardless of the state of a > running > >> >> instance. > >> >> > > >> >> > There is a use case that maybe need a new type of storage, maybe we > >> >> > can > >> >> call it non-persistent storage . > >> >> > The use case is that VMs are assigned to the public ephemerally in > >> >> > public > >> >> areas. > >> >> > After the VM is used, new data on storage of VM ceases to exist > >> >> > when the > >> >> instance it is associated with is stopped. > >> >> > It means stop the VM, Non-persistent storage used by VM will be > >> >> > rollback > >> >> automatically. > >> >> > > >> >> > Is there any other suggestions? Or any BPs about this use case? > >> >> > > >> >> > >> >> This sounds like ephemeral storage plus snapshots. You build a base > >> >> image, snapshot it then boot from the snapshot. > >> >> > >> >> > Thanks! > >> >> > > >> >> > Zhou Yu > >> >> > > >> >> > _______________________________________________ > >> >> > 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 > >> > >> _______________________________________________ > >> 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 > -- Qin Zhao
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
