On Fri, Mar 7, 2014 at 1:26 AM, Qin Zhao <chaoc...@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.gord...@gmail.com> wrote: > >> 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-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-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/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 >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> 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 >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > 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 >> > >> > >> > >> > >> > -- >> > 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