There is another thread on the ML discussing this: http://lists.openstack.org/pipermail/openstack-dev/2014-March/029278.html
On Mon, Mar 10, 2014 at 1:06 AM, Yuzhou (C) <vitas.yuz...@huawei.com> wrote: > Hi Joe, > > > > If the VM is hacked or compromised, the software solution inside of the VM > maybe fail. > > > > In fact, one of main use cases of non-persist disk is nonpersistent > VDI. There are three advantages: > > 1. Image manageability, Since nonpersistent desktops are built from a > master image, > > it's easier for administrators to patch and update the image, > > back it up quickly and deploy company-wide applications to all end users. > > 2. Greater security, Users can't alter desktop settings or install > their own applications, > > making the image more secure. > > 3. Less storage. > > > > The following two articles Maybe help you understand the usage of > non-persisent disk: > > > > http://cormachogan.com/2013/04/16/what-are-dependent-independent-disks-persistent-and-non-persisent-modes/ > > > > http://searchvirtualdesktop.techtarget.com/feature/Understanding-nonpersistent-vs-persistent-VDI > > > > > > > > > > > > From: Joe Gordon [mailto:joe.gord...@gmail.com] > Sent: Saturday, March 08, 2014 4:40 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? > > > > > > > > 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev