Open Stack

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.yuzhou at 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.gordon0 at 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 <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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>