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.
On Tue, Mar 4, 2014 at 1:32 PM, Nandavar, Divakar Padiyar < [email protected]> 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:[email protected]] > 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 <[email protected]> > 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:[email protected]] > >> 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) <[email protected]> > >> 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 > >> > [email protected] > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Qin Zhao
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
