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