Open Stack

On Fri, Mar 7, 2014 at 1:26 AM, Qin Zhao <chaochin at gmail.com> wrote:

> Hi Joe,
> Maybe my example is very rare. However, I think a new type of 'in-place'
> snapshot will have other advantages. For instance, the hypervisor can
> support to save memory content in snapshot file, so that user can revert
> his VM to running state. In this way, the user do not need to start each
> application again. Every thing is there. User can continue his work very
> easily. If the user spawn and boot a new VM, he will need to take a lot of
> time to resume his work. Does that make sense?
>

I am not sure I follow. I think the use case you have brought up can be
solved inside of the VM with something like
http://unionfs.filesystems.org/are a filesystem that supports
snapshotting.



>
>
> On Fri, Mar 7, 2014 at 2:20 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>> On Wed, Mar 5, 2014 at 11:45 AM, Qin Zhao <chaochin at gmail.com> wrote:
>> > Hi Joe,
>> > For example, I used to use a private cloud system, which will calculate
>> > charge bi-weekly. and it charging formula looks like "Total_charge =
>> > Instance_number*C1 + Total_instance_duration*C2 + Image_number*C3 +
>> > Volume_number*C4".  Those Instance/Image/Volume number are the number of
>> > those objects that user created within these two weeks. And it also has
>> > quota to limit total image size and total volume size. That formula is
>> not
>> > very exact, but you can see that it regards each of my 'create'
>> operation ass
>> > a 'ticket', and will charge all those tickets, plus the instance
>> duration
>>
>> Charging for creating a VM creation is not very cloud like.  Cloud
>> instances should be treated as ephemeral and something that you can
>> throw away and recreate at any time.  Additionally cloud should charge
>> on resources used (instance CPU hour, network load etc), and not API
>> calls (at least in any meaningful amount).
>>
>> > fee. In order to reduce the expense of my department, I am asked not to
>> > create instance very frequently, and not to create too many images and
>> > volume. The image quota is not very big. And I would never be permitted
>> to
>> > exceed the quota, since it request additional dollars.
>> >
>> >
>> > On Thu, Mar 6, 2014 at 1:33 AM, Joe Gordon <joe.gordon0 at gmail.com>
>> wrote:
>> >>
>> >> On Wed, Mar 5, 2014 at 8:59 AM, Qin Zhao <chaochin at gmail.com> wrote:
>> >> > Hi Joe,
>> >> > If we assume the user is willing to create a new instance, the
>> workflow
>> >> > you
>> >> > are saying is exactly correct. However, what I am assuming is that
>> the
>> >> > user
>> >> > is NOT willing to create a new instance. If Nova can revert the
>> existing
>> >> > instance, instead of creating a new one, it will become the
>> alternative
>> >> > way
>> >> > utilized by those users who are not allowed to create a new instance.
>> >> > Both paths lead to the target. I think we can not assume all the
>> people
>> >> > should walk through path one and should not walk through path two.
>> Maybe
>> >> > creating new instance or adjusting the quota is very easy in your
>> point
>> >> > of
>> >> > view. However, the real use case is often limited by business
>> process.
>> >> > So I
>> >> > think we may need to consider that some users can not or are not
>> allowed
>> >> > to
>> >> > creating the new instance under specific circumstances.
>> >> >
>> >>
>> >> What sort of circumstances would prevent someone from deleting and
>> >> recreating an instance?
>> >>
>> >> >
>> >> > On Thu, Mar 6, 2014 at 12:02 AM, Joe Gordon <joe.gordon0 at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Mar 4, 2014 at 6:21 PM, Qin Zhao <chaochin at gmail.com>
>> wrote:
>> >> >> > 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.
>> >> >> >
>> >> >>
>> >> >> Are you saying some users may not be able to create an instance at
>> >> >> all? If so why not just control that via quotas.
>> >> >>
>> >> >> Assuming the user has the power to rights and quota to create one
>> >> >> instance and one snapshot, your proposed idea is only slightly
>> >> >> different then the current workflow.
>> >> >>
>> >> >> Currently one would:
>> >> >> 1) Create instance
>> >> >> 2) Snapshot instance
>> >> >> 3) Use instance / break instance
>> >> >> 4) delete instance
>> >> >> 5) boot new instance from snapshot
>> >> >> 6) goto step 3
>> >> >>
>> >> >> From what I gather you are saying that instead of 4/5 you want the
>> >> >> user to be able to just reboot the instance. I don't think such a
>> >> >> subtle change in behavior is worth a whole new API extension.
>> >> >>
>> >> >> >
>> >> >> > On Wed, Mar 5, 2014 at 3:20 AM, Joe Gordon <joe.gordon0 at gmail.com
>> >
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Tue, Mar 4, 2014 at 1:06 AM, Qin Zhao <chaochin at 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-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
>> >> >> >> >
>> >> >> >> > _______________________________________________
>> >> >> >> > 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
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > 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
>> >> >
>> >> > _______________________________________________
>> >> > 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
>> >
>> > _______________________________________________
>> > 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140307/7fd22d5a/attachment.html>