<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin:0cm;
margin-bottom:.0001pt;
text-indent:21.0pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1580097632;
mso-list-type:hybrid;
mso-list-template-ids:138947980 -487011352 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:18.0pt;
text-indent:-18.0pt;
font-family:"Times New Roman","serif";
mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Hi Joe,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-indent:21.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">If the VM is hacked or compromised, the software solution inside of the VM maybe fail.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"> In fact, one of main use cases of non-persist disk is nonpersistent VDI. There are three advantages:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Image manageability,</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black;background:white">
Since nonpersistent desktops are built from a master image, <o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:0cm"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black;background:white">it's easier for administrators to patch and update the image,
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:0cm"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black;background:white">back it up quickly and deploy company-wide applications to all end users.<span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Greater security,</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black;background:white"> Users
can't alter desktop settings or install their own applications, <o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:0cm"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black;background:white">making the image more secure.<span class="apple-converted-space"> <o:p></o:p></span></span></p>
<p class="MsoNormal"><span class="apple-converted-space"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black;background:white">3. Less storage.</span></span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">The following two articles Maybe help you understand the usage of non-persisent disk:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="http://cormachogan.com/2013/04/16/what-are-dependent-independent-disks-persistent-and-non-persisent-modes/">http://cormachogan.com/2013/04/16/what-are-dependent-independent-disks-persistent-and-non-persisent-modes/</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="http://searchvirtualdesktop.techtarget.com/feature/Understanding-nonpersistent-vs-persistent-VDI">http://searchvirtualdesktop.techtarget.com/feature/Understanding-nonpersistent-vs-persistent-VDI</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Joe Gordon [mailto:joe.gordon0@gmail.com]
<br>
<b>Sent:</b> Saturday, March 08, 2014 4:40 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [nova][cinder] non-persistent storage(after stopping VM, data will be rollback automatically), do you think we shoud introduce this feature?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Fri, Mar 7, 2014 at 1:26 AM, Qin Zhao <<a href="mailto:chaochin@gmail.com" target="_blank">chaochin@gmail.com</a>> wrote:<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Joe,<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">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?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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 <a href="http://unionfs.filesystems.org/">http://unionfs.filesystems.org/</a> are a filesystem that supports
snapshotting.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Fri, Mar 7, 2014 at 2:20 PM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> wrote:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Wed, Mar 5, 2014 at 11:45 AM, Qin Zhao <<a href="mailto:chaochin@gmail.com" target="_blank">chaochin@gmail.com</a>> wrote:<br>
> Hi Joe,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">> For example, I used to use a private cloud system, which will calculate<br>
> charge bi-weekly. and it charging formula looks like "Total_charge =<br>
> Instance_number*C1 + Total_instance_duration*C2 + Image_number*C3 +<br>
> Volume_number*C4". Those Instance/Image/Volume number are the number of<br>
> those objects that user created within these two weeks. And it also has<br>
> quota to limit total image size and total volume size. That formula is not<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">> very exact, but you can see that it regards each of my 'create' operation ass<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">> a 'ticket', and will charge all those tickets, plus the instance duration<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">Charging for creating a VM creation is not very cloud like. Cloud<br>
instances should be treated as ephemeral and something that you can<br>
throw away and recreate at any time. Additionally cloud should charge<br>
on resources used (instance CPU hour, network load etc), and not API<br>
calls (at least in any meaningful amount).<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
> fee. In order to reduce the expense of my department, I am asked not to<br>
> create instance very frequently, and not to create too many images and<br>
> volume. The image quota is not very big. And I would never be permitted to<br>
> exceed the quota, since it request additional dollars.<br>
><br>
><br>
> On Thu, Mar 6, 2014 at 1:33 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Mar 5, 2014 at 8:59 AM, Qin Zhao <<a href="mailto:chaochin@gmail.com" target="_blank">chaochin@gmail.com</a>> wrote:<br>
>> > Hi Joe,<br>
>> > If we assume the user is willing to create a new instance, the workflow<br>
>> > you<br>
>> > are saying is exactly correct. However, what I am assuming is that the<br>
>> > user<br>
>> > is NOT willing to create a new instance. If Nova can revert the existing<br>
>> > instance, instead of creating a new one, it will become the alternative<br>
>> > way<br>
>> > utilized by those users who are not allowed to create a new instance.<br>
>> > Both paths lead to the target. I think we can not assume all the people<br>
>> > should walk through path one and should not walk through path two. Maybe<br>
>> > creating new instance or adjusting the quota is very easy in your point<br>
>> > of<br>
>> > view. However, the real use case is often limited by business process.<br>
>> > So I<br>
>> > think we may need to consider that some users can not or are not allowed<br>
>> > to<br>
>> > creating the new instance under specific circumstances.<br>
>> ><br>
>><br>
>> What sort of circumstances would prevent someone from deleting and<br>
>> recreating an instance?<br>
>><br>
>> ><br>
>> > On Thu, Mar 6, 2014 at 12:02 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Tue, Mar 4, 2014 at 6:21 PM, Qin Zhao <<a href="mailto:chaochin@gmail.com" target="_blank">chaochin@gmail.com</a>> wrote:<br>
>> >> > Hi Joe, my meaning is that cloud users may not hope to create new<br>
>> >> > instances<br>
>> >> > or new images, because those actions may require additional approval<br>
>> >> > and<br>
>> >> > additional charging. Or, due to instance/image quota limits, they can<br>
>> >> > not do<br>
>> >> > that. Anyway, from user's perspective, saving and reverting the<br>
>> >> > existing<br>
>> >> > instance will be preferred sometimes. Creating a new instance will be<br>
>> >> > another story.<br>
>> >> ><br>
>> >><br>
>> >> Are you saying some users may not be able to create an instance at<br>
>> >> all? If so why not just control that via quotas.<br>
>> >><br>
>> >> Assuming the user has the power to rights and quota to create one<br>
>> >> instance and one snapshot, your proposed idea is only slightly<br>
>> >> different then the current workflow.<br>
>> >><br>
>> >> Currently one would:<br>
>> >> 1) Create instance<br>
>> >> 2) Snapshot instance<br>
>> >> 3) Use instance / break instance<br>
>> >> 4) delete instance<br>
>> >> 5) boot new instance from snapshot<br>
>> >> 6) goto step 3<br>
>> >><br>
>> >> From what I gather you are saying that instead of 4/5 you want the<br>
>> >> user to be able to just reboot the instance. I don't think such a<br>
>> >> subtle change in behavior is worth a whole new API extension.<br>
>> >><br>
>> >> ><br>
>> >> > On Wed, Mar 5, 2014 at 3:20 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> On Tue, Mar 4, 2014 at 1:06 AM, Qin Zhao <<a href="mailto:chaochin@gmail.com" target="_blank">chaochin@gmail.com</a>> wrote:<br>
>> >> >> > I think the current snapshot implementation can be a solution<br>
>> >> >> > sometimes,<br>
>> >> >> > but<br>
>> >> >> > it is NOT exact same as user's expectation. For example, a new<br>
>> >> >> > blueprint<br>
>> >> >> > is<br>
>> >> >> > created last week,<br>
>> >> >> ><br>
>> >> >> > <a href="https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot" target="_blank">
https://blueprints.launchpad.net/nova/+spec/driver-specific-snapshot</a>,<br>
>> >> >> > which<br>
>> >> >> > seems a little similar with this discussion. I feel the user is<br>
>> >> >> > requesting<br>
>> >> >> > Nova to create in-place snapshot (not a new image), in order to<br>
>> >> >> > revert<br>
>> >> >> > the<br>
>> >> >> > instance to a certain state. This capability should be very useful<br>
>> >> >> > when<br>
>> >> >> > testing new software or system settings. It seems a short-term<br>
>> >> >> > temporary<br>
>> >> >> > snapshot associated with a running instance for Nova. Creating a<br>
>> >> >> > new<br>
>> >> >> > instance is not that convenient, and may be not feasible for the<br>
>> >> >> > user,<br>
>> >> >> > especially if he or she is using public cloud.<br>
>> >> >> ><br>
>> >> >><br>
>> >> >> Why isn't it easy to create a new instance from a snapshot?<br>
>> >> >><br>
>> >> >> ><br>
>> >> >> > On Tue, Mar 4, 2014 at 1:32 PM, Nandavar, Divakar Padiyar<br>
>> >> >> > <<a href="mailto:divakar.padiyar-nandavar@hp.com" target="_blank">divakar.padiyar-nandavar@hp.com</a>> wrote:<br>
>> >> >> >><br>
>> >> >> >> >>> Why reboot an instance? What is wrong with deleting it and<br>
>> >> >> >> >>> create a<br>
>> >> >> >> >>> new one?<br>
>> >> >> >><br>
>> >> >> >> You generally use non-persistent disk mode when you are testing<br>
>> >> >> >> new<br>
>> >> >> >> software or experimenting with settings. If something goes<br>
>> >> >> >> wrong<br>
>> >> >> >> just<br>
>> >> >> >> reboot and you are back to clean state and start over again. I<br>
>> >> >> >> feel<br>
>> >> >> >> it's<br>
>> >> >> >> convenient to handle this with just a reboot rather than<br>
>> >> >> >> recreating<br>
>> >> >> >> the<br>
>> >> >> >> instance.<br>
>> >> >> >><br>
>> >> >> >> Thanks,<br>
>> >> >> >> Divakar<br>
>> >> >> >><br>
>> >> >> >> -----Original Message-----<br>
>> >> >> >> From: Joe Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>]<br>
>> >> >> >> Sent: Tuesday, March 04, 2014 10:41 AM<br>
>> >> >> >> To: OpenStack Development Mailing List (not for usage questions)<br>
>> >> >> >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent<br>
>> >> >> >> storage(after<br>
>> >> >> >> stopping VM, data will be rollback automatically), do you think<br>
>> >> >> >> we<br>
>> >> >> >> shoud<br>
>> >> >> >> introduce this feature?<br>
>> >> >> >> Importance: High<br>
>> >> >> >><br>
>> >> >> >> On Mon, Mar 3, 2014 at 8:13 PM, Zhangleiqiang<br>
>> >> >> >> <<a href="mailto:zhangleiqiang@huawei.com" target="_blank">zhangleiqiang@huawei.com</a>><br>
>> >> >> >> wrote:<br>
>> >> >> >> >><br>
>> >> >> >> >> This sounds like ephemeral storage plus snapshots. You build<br>
>> >> >> >> >> a<br>
>> >> >> >> >> base<br>
>> >> >> >> >> image, snapshot it then boot from the snapshot.<br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> > Non-persistent storage/disk is useful for sandbox-like<br>
>> >> >> >> > environment,<br>
>> >> >> >> > and<br>
>> >> >> >> > this feature has already exists in VMWare ESX from version 4.1.<br>
>> >> >> >> > The<br>
>> >> >> >> > implementation of ESX is the same as what you said, boot from<br>
>> >> >> >> > snapshot of<br>
>> >> >> >> > the disk/volume, but it will also *automatically* delete the<br>
>> >> >> >> > transient<br>
>> >> >> >> > snapshot after the instance reboots or shutdowns. I think the<br>
>> >> >> >> > whole<br>
>> >> >> >> > procedure may be controlled by OpenStack other than user's<br>
>> >> >> >> > manual<br>
>> >> >> >> > operations.<br>
>> >> >> >><br>
>> >> >> >> Why reboot an instance? What is wrong with deleting it and create<br>
>> >> >> >> a<br>
>> >> >> >> new<br>
>> >> >> >> one?<br>
>> >> >> >><br>
>> >> >> >> ><br>
>> >> >> >> > As far as I know, libvirt already defines the corresponding<br>
>> >> >> >> > <transient><br>
>> >> >> >> > element in domain xml for non-persistent disk ( [1] ), but it<br>
>> >> >> >> > cannot<br>
>> >> >> >> > specify<br>
>> >> >> >> > the location of the transient snapshot. Although qemu-kvm has<br>
>> >> >> >> > provided<br>
>> >> >> >> > support for this feature by the "-snapshot" command argument,<br>
>> >> >> >> > which<br>
>> >> >> >> > will<br>
>> >> >> >> > create the transient snapshot under /tmp directory, the qemu<br>
>> >> >> >> > driver<br>
>> >> >> >> > of<br>
>> >> >> >> > libvirt don't support <transient> element currently.<br>
>> >> >> >> ><br>
>> >> >> >> > I think the steps of creating and deleting transient snapshot<br>
>> >> >> >> > may<br>
>> >> >> >> > be<br>
>> >> >> >> > better to done by Nova/Cinder other than waiting for the<br>
>> >> >> >> > <transient><br>
>> >> >> >> > support<br>
>> >> >> >> > added to libvirt, as the location of transient snapshot should<br>
>> >> >> >> > specified by<br>
>> >> >> >> > Nova.<br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> > [1] <a href="http://libvirt.org/formatdomain.html#elementsDisks" target="_blank">
http://libvirt.org/formatdomain.html#elementsDisks</a><br>
>> >> >> >> > ----------<br>
>> >> >> >> > zhangleiqiang<br>
>> >> >> >> ><br>
>> >> >> >> > Best Regards<br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> >> -----Original Message-----<br>
>> >> >> >> >> From: Joe Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>]<br>
>> >> >> >> >> Sent: Tuesday, March 04, 2014 11:26 AM<br>
>> >> >> >> >> To: OpenStack Development Mailing List (not for usage<br>
>> >> >> >> >> questions)<br>
>> >> >> >> >> Cc: Luohao (brian)<br>
>> >> >> >> >> Subject: Re: [openstack-dev] [nova][cinder] non-persistent<br>
>> >> >> >> >> storage(after stopping VM, data will be rollback<br>
>> >> >> >> >> automatically),<br>
>> >> >> >> >> do<br>
>> >> >> >> >> you think we shoud introduce this feature?<br>
>> >> >> >> >><br>
>> >> >> >> >> On Mon, Mar 3, 2014 at 6:00 PM, Yuzhou (C)<br>
>> >> >> >> >> <<a href="mailto:vitas.yuzhou@huawei.com" target="_blank">vitas.yuzhou@huawei.com</a>><br>
>> >> >> >> >> wrote:<br>
>> >> >> >> >> > Hi stackers,<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > As far as I know ,there are two types of storage used by VM<br>
>> >> >> >> >> > in<br>
>> >> >> >> >> > openstack:<br>
>> >> >> >> >> Ephemeral Storage and Persistent Storage.<br>
>> >> >> >> >> > Data on ephemeral storage ceases to exist when the instance<br>
>> >> >> >> >> > it<br>
>> >> >> >> >> > is<br>
>> >> >> >> >> > associated<br>
>> >> >> >> >> with is terminated. Rebooting the VM or restarting the host<br>
>> >> >> >> >> server,<br>
>> >> >> >> >> however, will not destroy ephemeral data.<br>
>> >> >> >> >> > Persistent storage means that the storage resource outlives<br>
>> >> >> >> >> > any<br>
>> >> >> >> >> > other<br>
>> >> >> >> >> resource and is always available, regardless of the state of a<br>
>> >> >> >> >> running<br>
>> >> >> >> >> instance.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > There is a use case that maybe need a new type of storage,<br>
>> >> >> >> >> > maybe<br>
>> >> >> >> >> > we<br>
>> >> >> >> >> > can<br>
>> >> >> >> >> call it non-persistent storage .<br>
>> >> >> >> >> > The use case is that VMs are assigned to the public<br>
>> >> >> >> >> > ephemerally<br>
>> >> >> >> >> > in<br>
>> >> >> >> >> > public<br>
>> >> >> >> >> areas.<br>
>> >> >> >> >> > After the VM is used, new data on storage of VM ceases to<br>
>> >> >> >> >> > exist<br>
>> >> >> >> >> > when the<br>
>> >> >> >> >> instance it is associated with is stopped.<br>
>> >> >> >> >> > It means stop the VM, Non-persistent storage used by VM will<br>
>> >> >> >> >> > be<br>
>> >> >> >> >> > rollback<br>
>> >> >> >> >> automatically.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > Is there any other suggestions? Or any BPs about this use<br>
>> >> >> >> >> > case?<br>
>> >> >> >> >> ><br>
>> >> >> >> >><br>
>> >> >> >> >> This sounds like ephemeral storage plus snapshots. You build<br>
>> >> >> >> >> a<br>
>> >> >> >> >> base<br>
>> >> >> >> >> image, snapshot it then boot from the snapshot.<br>
>> >> >> >> >><br>
>> >> >> >> >> > Thanks!<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > Zhou Yu<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > _______________________________________________<br>
>> >> >> >> >> > OpenStack-dev mailing list<br>
>> >> >> >> >> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">
OpenStack-dev@lists.openstack.org</a><br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >> >> >><br>
>> >> >> >> >> _______________________________________________<br>
>> >> >> >> >> OpenStack-dev mailing list<br>
>> >> >> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">
OpenStack-dev@lists.openstack.org</a><br>
>> >> >> >> >><br>
>> >> >> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >> >> ><br>
>> >> >> >> > _______________________________________________<br>
>> >> >> >> > OpenStack-dev mailing list<br>
>> >> >> >> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">
OpenStack-dev@lists.openstack.org</a><br>
>> >> >> >> ><br>
>> >> >> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >> >><br>
>> >> >> >> _______________________________________________<br>
>> >> >> >> OpenStack-dev mailing list<br>
>> >> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> >> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >> >><br>
>> >> >> >> _______________________________________________<br>
>> >> >> >> OpenStack-dev mailing list<br>
>> >> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> >> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > --<br>
>> >> >> > Qin Zhao<br>
>> >> >> ><br>
>> >> >> > _______________________________________________<br>
>> >> >> > OpenStack-dev mailing list<br>
>> >> >> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> >> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >> ><br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> OpenStack-dev mailing list<br>
>> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Qin Zhao<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > OpenStack-dev mailing list<br>
>> >> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> OpenStack-dev mailing list<br>
>> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Qin Zhao<br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Qin Zhao<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><br>
<br clear="all">
<br>
-- <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Qin Zhao<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>