Hi Joe,
Thanks for your reply!
First, generally, in public or private cloud, the end users of VMs have
no right to create new VMs directly.
If someone want to create new VMs, he or she need to wait for approval process.
Then, the administrator Of cloud create a new VM to applicant. So the workflow
that you suggested is not convenient.
Second, The feature that disk rollback automatically not based on
inter-VM software ,I am sure it is very useful.
For example, in VDI, a VM maybe is assigned to uncertain people. Many people
have right to use it.
Someone maybe install virus in this VM. Based on security considerations, after
one use VM, disk is hope to rollback to clean state.
then others can use it safely.
@stackers,
Let's discuss how to implement this feature!Is there any other
suggestions?
Best regards,
Zhou Yu
> -----Original Message-----
> From: Joe Gordon [mailto:joe.gord...@gmail.com]
> Sent: Friday, March 07, 2014 2:21 PM
> 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?
>
> On Wed, Mar 5, 2014 at 11:45 AM, Qin Zhao <chaoc...@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.gord...@gmail.com>
> wrote:
> >>
> >> On Wed, Mar 5, 2014 at 8:59 AM, Qin Zhao <chaoc...@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.gord...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Mar 4, 2014 at 6:21 PM, Qin Zhao <chaoc...@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.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-s
> >> >> >> > napshot,
> >> >> >> > 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/ope
> >> >> >> >> >> > nstack-dev
> >> >> >> >> >>
> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> OpenStack-dev mailing list
> >> >> >> >> >> OpenStack-dev@lists.openstack.org
> >> >> >> >> >>
> >> >> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
> >> >> >> >> >> tack-dev
> >> >> >> >> >
> >> >> >> >> > _______________________________________________
> >> >> >> >> > OpenStack-dev mailing list
> >> >> >> >> > OpenStack-dev@lists.openstack.org
> >> >> >> >> >
> >> >> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openst
> >> >> >> >> > ack-dev
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> OpenStack-dev mailing list
> >> >> >> >> OpenStack-dev@lists.openstack.org
> >> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> >> >> >> >> k-dev
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> OpenStack-dev mailing list
> >> >> >> >> OpenStack-dev@lists.openstack.org
> >> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> >> >> >> >> k-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-d
> >> >> >> ev
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Qin Zhao
> >> >> >
> >> >> > _______________________________________________
> >> >> > OpenStack-dev mailing list
> >> >> > OpenStack-dev@lists.openstack.org
> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de
> >> >> > v
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> 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
> >
>
> _______________________________________________
> 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
