Open Stack

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 <
divakar.padiyar-nandavar at 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.gordon0 at 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 <zhangleiqiang at 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.gordon0 at 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.yuzhou at 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 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
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Qin Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/484fc562/attachment.html>