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 17 March 2014 11:34, Yuzhou (C) vitas.yuz...@huawei.com wrote: Hi Duncan Thomas, Maybe the statement about approval process is not very exact. In fact in my mail, I mean: In the enterprise private cloud, if beyond the quota, you want to create a new VM ,that needs to wait for approval process. I'm still failing to understand something here. If you're over your quota, you need a bigger quota. The entire idea of cloud is that resources are created and deleted on demand, not perfectly laid out in advance and never changed. If you're over quota, you need to reduce your workload or get more quota. That is the cloud answer. Putting in weird behaviours that make no sense unless you're working at the very edge of your quota is not a path I think we want to go down. I've said it in other threads, but it bears repeating: Every new API, method, function we add comes at a significant and growing maintenance and testing cost. We need to evaluate new features carefully, and if something can trivially be done by stringing together a couple of existing primitives (like this case) we probably don't want to go add new behaviours, particularly if the only advantage of the new behaviour is that it enables you to do something when you're very tight for quota. If a private cloud has a billing model with perverse incentives, then fix the billing model. If many/most of your users are constantly running at the edge of their quota, particularly while doing development or evaluation, you probably want to rethink your cloud strategy - you might be able to paper over one crack but you are going to find there are a million others. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 17, 2014 at 9:32 PM, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote: From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Tuesday, March 18, 2014 2:28 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 Mar 17, 2014, at 4:34 AM, Yuzhou (C) vitas.yuz...@huawei.com wrote: Hi Duncan Thomas, Maybe the statement about approval process is not very exact. In fact in my mail, I mean: In the enterprise private cloud, if beyond the quota, you want to create a new VM ,that needs to wait for approval process. @stackers, I think the following two use cases show why non-persistent disk is useful: 1.Non-persistent VDI: When users access a non-persistent desktop, none of their settings or data is saved once they log out. At the end of a session, the desktop reverts back to its original state and the user receives a fresh image the next time he logs in. 1). Image manageability, Since non-persistent 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. 2.As the use case mentioned several days ago by zhangleiqiang: Let's take a virtual machine which hosts a web service, but it is primarily a read-only web site with content that rarely changes. This VM has three disks. Disk 1 contains the Guest OS and web application (e.g.Apache). Disk 2 contains the web pages for the web site. Disk 3 contains all the logging activity. In this case, disk 1 (OS app) are dependent (default) settings and is backed up nightly. Disk 2 is independent non-persistent (not backed up, and any changes to these pages will be discarded). Disk 3 is independent persistent (not backed up, but any changes are persisted to the disk). If updates are needed to the web site's pages, disk 2 must be taken out of independent non-persistent mode temporarily to allow the changes to be made. Now let's say that this site gets hacked, and the pages are doctored with something which is not very nice. A simple reboot of this host will discard the changes made to the web pages on disk 2, but will persist the logs on disk 3 so that a root cause analysis can be carried out. Hope to get more suggestions about non-persistent disk! Making the disk rollback on reboot seems like an unexpected side-effect we should avoid. Rolling back the system to a known state is a useful feature, but this should be an explicit api command, not a side-effect of rebooting the machine, IMHO. I think there is some misunderstanding about non-persistent disk, the non-persistent disk will only rollback if the instance is shutdown and start again, and will persistent the data if it is soft-reboot. I think your intent is understood here, however I think I have to agree with others that it's a use case that really is already provided for and in fact is pretty much the nature of an elastic cloud to begin with. I also want to highlight the comment by Vish about the confusion and unhappy users we'll have if we suddenly change the behavior of reboot. Certainly this could be an option but IMHO just because you *can* create an option in an API doesn't always mean that you should. I feel that we provide the necessary steps to do what you're asking here already, and if a provider does in fact restrict things like creating instances, then just as others said this is sort of against the whole point of having the cloud in the first place. This might be a great thing for them to implement as their own custom extension, but it doesn't seem to fit with the existing core project IMO. Non-persistent disk does have use cases. Using explicit API command can achieve it, but I think there will be some work need to be done before booting the instance or after shutdown the instance, including: 1. For cinder volume, create a snapshot; For libvirt ephemeral image backend, create new image 2.Update attached volume info for instance 3.Delete the cinder snapshot and libvirt ephemeral image, and update volume/image info for instance again These works can be done by users manually or by some Upper system ? Or non-persistent can be set as a metadata/property of volume/image, and handled by Nova? Vish Thanks. Zhou Yu -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Saturday, March 15, 2014 12:56 AM To: OpenStack Development Mailing
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
Hi Duncan Thomas, Maybe the statement about approval process is not very exact. In fact in my mail, I mean: In the enterprise private cloud, if beyond the quota, you want to create a new VM ,that needs to wait for approval process. @stackers, I think the following two use cases show why non-persistent disk is useful: 1.Non-persistent VDI: When users access a non-persistent desktop, none of their settings or data is saved once they log out. At the end of a session, the desktop reverts back to its original state and the user receives a fresh image the next time he logs in. 1). Image manageability, Since non-persistent 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. 2.As the use case mentioned several days ago by zhangleiqiang: Let's take a virtual machine which hosts a web service, but it is primarily a read-only web site with content that rarely changes. This VM has three disks. Disk 1 contains the Guest OS and web application (e.g. Apache). Disk 2 contains the web pages for the web site. Disk 3 contains all the logging activity. In this case, disk 1 (OS app) are dependent (default) settings and is backed up nightly. Disk 2 is independent non-persistent (not backed up, and any changes to these pages will be discarded). Disk 3 is independent persistent (not backed up, but any changes are persisted to the disk). If updates are needed to the web site's pages, disk 2 must be taken out of independent non-persistent mode temporarily to allow the changes to be made. Now let's say that this site gets hacked, and the pages are doctored with something which is not very nice. A simple reboot of this host will discard the changes made to the web pages on disk 2, but will persistthe logs on disk 3 so that a root cause analysis can be carried out. Hope to get more suggestions about non-persistent disk! Thanks. Zhou Yu -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Saturday, March 15, 2014 12:56 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 7 March 2014 08:17, Yuzhou (C) vitas.yuz...@huawei.com wrote: 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. This approval process admin action is the exact opposite to what cloud is all about. I'd suggest that anybody using such a process has little understanding of cloud and should be educated, not weird interfaces added to nova to support a broken premise. The cloud /is different/ from traditional IT, that is its strength, and we should be wary of undermining that to allow old-style thinking to continue. ___ 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
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 Mar 17, 2014, at 4:34 AM, Yuzhou (C) vitas.yuz...@huawei.com wrote: Hi Duncan Thomas, Maybe the statement about approval process is not very exact. In fact in my mail, I mean: In the enterprise private cloud, if beyond the quota, you want to create a new VM ,that needs to wait for approval process. @stackers, I think the following two use cases show why non-persistent disk is useful: 1.Non-persistent VDI: When users access a non-persistent desktop, none of their settings or data is saved once they log out. At the end of a session, the desktop reverts back to its original state and the user receives a fresh image the next time he logs in. 1). Image manageability, Since non-persistent 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. 2.As the use case mentioned several days ago by zhangleiqiang: Let's take a virtual machine which hosts a web service, but it is primarily a read-only web site with content that rarely changes. This VM has three disks. Disk 1 contains the Guest OS and web application (e.g. Apache). Disk 2 contains the web pages for the web site. Disk 3 contains all the logging activity. In this case, disk 1 (OS app) are dependent (default) settings and is backed up nightly. Disk 2 is independent non-persistent (not backed up, and any changes to these pages will be discarded). Disk 3 is independent persistent (not backed up, but any changes are persisted to the disk). If updates are needed to the web site's pages, disk 2 must be taken out of independent non-persistent mode temporarily to allow the changes to be made. Now let's say that this site gets hacked, and the pages are doctored with something which is not very nice. A simple reboot of this host will discard the changes made to the web pages on disk 2, but will persist the logs on disk 3 so that a root cause analysis can be carried out. Hope to get more suggestions about non-persistent disk! Making the disk rollback on reboot seems like an unexpected side-effect we should avoid. Rolling back the system to a known state is a useful feature, but this should be an explicit api command, not a side-effect of rebooting the machine, IMHO. Vish Thanks. Zhou Yu -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Saturday, March 15, 2014 12:56 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 7 March 2014 08:17, Yuzhou (C) vitas.yuz...@huawei.com wrote: 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. This approval process admin action is the exact opposite to what cloud is all about. I'd suggest that anybody using such a process has little understanding of cloud and should be educated, not weird interfaces added to nova to support a broken premise. The cloud /is different/ from traditional IT, that is its strength, and we should be wary of undermining that to allow old-style thinking to continue. ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Tuesday, March 18, 2014 2:28 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 Mar 17, 2014, at 4:34 AM, Yuzhou (C) vitas.yuz...@huawei.com wrote: Hi Duncan Thomas, Maybe the statement about approval process is not very exact. In fact in my mail, I mean: In the enterprise private cloud, if beyond the quota, you want to create a new VM ,that needs to wait for approval process. @stackers, I think the following two use cases show why non-persistent disk is useful: 1.Non-persistent VDI: When users access a non-persistent desktop, none of their settings or data is saved once they log out. At the end of a session, the desktop reverts back to its original state and the user receives a fresh image the next time he logs in. 1). Image manageability, Since non-persistent 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. 2.As the use case mentioned several days ago by zhangleiqiang: Let's take a virtual machine which hosts a web service, but it is primarily a read-only web site with content that rarely changes. This VM has three disks. Disk 1 contains the Guest OS and web application (e.g.Apache). Disk 2 contains the web pages for the web site. Disk 3 contains all the logging activity. In this case, disk 1 (OS app) are dependent (default) settings and is backed up nightly. Disk 2 is independent non-persistent (not backed up, and any changes to these pages will be discarded). Disk 3 is independent persistent (not backed up, but any changes are persisted to the disk). If updates are needed to the web site's pages, disk 2 must be taken out of independent non-persistent mode temporarily to allow the changes to be made. Now let's say that this site gets hacked, and the pages are doctored with something which is not very nice. A simple reboot of this host will discard the changes made to the web pages on disk 2, but will persist the logs on disk 3 so that a root cause analysis can be carried out. Hope to get more suggestions about non-persistent disk! Making the disk rollback on reboot seems like an unexpected side-effect we should avoid. Rolling back the system to a known state is a useful feature, but this should be an explicit api command, not a side-effect of rebooting the machine, IMHO. I think there is some misunderstanding about non-persistent disk, the non-persistent disk will only rollback if the instance is shutdown and start again, and will persistent the data if it is soft-reboot. Non-persistent disk does have use cases. Using explicit API command can achieve it, but I think there will be some work need to be done before booting the instance or after shutdown the instance, including: 1. For cinder volume, create a snapshot; For libvirt ephemeral image backend, create new image 2.Update attached volume info for instance 3.Delete the cinder snapshot and libvirt ephemeral image, and update volume/image info for instance again These works can be done by users manually or by some Upper system ? Or non-persistent can be set as a metadata/property of volume/image, and handled by Nova? Vish Thanks. Zhou Yu -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Saturday, March 15, 2014 12:56 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 7 March 2014 08:17, Yuzhou (C) vitas.yuz...@huawei.com wrote: 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. This approval process admin action is the exact opposite to what cloud is all about. I'd suggest that anybody using such a process has little understanding of cloud and should be educated, not weird interfaces added to nova to support a broken premise. The cloud /is different/ from traditional IT, that is its strength, and we should be wary of undermining that to allow old-style thinking to continue
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 7 March 2014 08:17, Yuzhou (C) vitas.yuz...@huawei.com wrote: 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. This approval process admin action is the exact opposite to what cloud is all about. I'd suggest that anybody using such a process has little understanding of cloud and should be educated, not weird interfaces added to nova to support a broken premise. The cloud /is different/ from traditional IT, that is its strength, and we should be wary of undermining that to allow old-style thinking to continue. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
Hi, Joe Qin Zhao: I think the user case from [1] is more typical for the non-persistent volume and the related independent persistent volume feature. Let's take a virtual machine which hosts a web service, but it is primarily a read-only web site with content that rarely changes. This VM has three disks. Disk 1 contains the Guest OS and web application (e.g. Apache). Disk 2 contains the web pages for the web site. Disk 3 contains all the logging activity. In this case, disk 1 (OS app) are dependent (default) settings and is backed up nightly. Disk 2 is independent non-persistent (not backed up, and any changes to these pages will be discarded). Disk 3 is independent persistent (not backed up, but any changes are persisted to the disk). If updates are needed to the web site's pages, disk 2 must be taken out of independent non-persistent mode temporarily to allow the changes to be made. Now let's say that this site gets hacked, and the pages are doctored with something which is not very nice. A simple reboot of this host will discard the changes made to the web pages on disk 2, but will persist the logs on disk 3 so that a root cause analysis can be carried out. The in-place snapshot and file system support snapshot can both achieve the purpose for test particular functionality. However, compared to non-persistent volume, in-place snapshot is more or less heavier, and the Instance-level snapshot has more larger granularity than volume, especially for the use case mentioned above. File system which supports snapshot will not be applicable for the situation when the system is got hacked. So I think the non-persistent volume feature is meaningful for public cloud. P.S. There is a misunderstanding before: Non-Persistent Volume: All the write options are temp. Changes are discarded when the virtual machine is force reset or powered off . If you restart the system , the data will still be available on the disk. Changes will be discarded only when the system is force RESET or POWERED OFF. Are there any other suggestions? Thanks. [1] http://cormachogan.com/2013/04/16/what-are-dependent-independent-disks-persistent-and-non-persisent-modes/ -- zhangleiqiang Best Regards 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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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
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 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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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. 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
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 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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
) 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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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. 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
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 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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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. 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
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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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. 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
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 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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
Agree. Snapshot seems to be a nature solution for it. -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
Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?
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
