Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D3C29115C6 for ; Fri, 28 Mar 2014 18:48:52 +0000 (UTC) Received: (qmail 6752 invoked by uid 500); 28 Mar 2014 18:48:51 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 6535 invoked by uid 500); 28 Mar 2014 18:48:49 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 6527 invoked by uid 99); 28 Mar 2014 18:48:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Mar 2014 18:48:48 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Alena.Prokharchyk@citrix.com designates 66.165.176.63 as permitted sender) Received: from [66.165.176.63] (HELO SMTP02.CITRIX.COM) (66.165.176.63) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Mar 2014 18:48:42 +0000 X-IronPort-AV: E=Sophos;i="4.97,752,1389744000"; d="scan'208,217";a="114770749" Received: from sjcpex01cl03.citrite.net ([10.216.14.145]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 28 Mar 2014 18:48:19 +0000 Received: from SJCPEX01CL02.citrite.net ([169.254.2.3]) by SJCPEX01CL03.citrite.net ([10.216.14.145]) with mapi id 14.02.0342.004; Fri, 28 Mar 2014 11:48:18 -0700 From: Alena Prokharchyk To: Mike Tutkowski CC: "dev@cloudstack.apache.org" Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5 Thread-Topic: [PROPOSAL] ROOT volume detach - feature for CS 4.5 Thread-Index: AQHPR5AljW18lzW8LkKRprxSMbhw7pryHteAgACFbQD//4x1gIAENU+AgABSnwCAAJVWAIAAAmcA//+NHoA= Date: Fri, 28 Mar 2014 18:48:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.13.107.78] Content-Type: multipart/alternative; boundary="_000_CF5B11E4432F1alenaprokharchykcitrixcom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CF5B11E4432F1alenaprokharchykcitrixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I will look into it more, Mike. vmWare indeed can be different. -Alena. From: Mike Tutkowski > Date: Friday, March 28, 2014 at 11:39 AM To: Alena Prokharchyk > Cc: "dev@cloudstack.apache.org" > Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5 VMware is also different because when you shut a VMware VM down from CloudS= tack, the VM still exists in vCenter Server (whereas for XenServer and KVM,= the VM is gone). Since the life of a datastore that was created for managed storage is tied = to the life of the CloudStack volume it stores, when the CloudStack volume = is deleted, the datastore goes away, as well. If the datastore in question was automatically created to store a root disk= (alongside VM config files) and you switch the VM to another root disk (wh= ich has to necessarily be in another datastore), you won't see a problem un= til the original root volume is expunged by CloudStack. At this point, its = datastore will go away along with your VM config files. On Fri, Mar 28, 2014 at 12:31 PM, Mike Tutkowski > wrote: Well, the reason I brought it up was mainly due to VMware. Let's use that as an example: I initiate the process of spinning up a VM based on managed storage. A volume is dynamically created on a SAN. VmwareStorageProcessor dynamically creates a datastore to consume the newly= created SAN volume. All VMware VM files (ex. VMX, NVRAM) are placed in the datastore alongside = the VMDK file that represents the root volume. Now, let's say we want to detach this root volume and give the VM a new roo= t volume. The new root volume will necessarily be on a different datastore than the d= atastore of the previous root volume (because a datastore created to consum= e managed storage will have at most one VMDK file*). Is it going to be a problem that the VM's files (ex. VMX, NVRAM) are on one= datastore, but its root disk is on another? I don't think it's really a problem until you go to delete the original roo= t volume from CloudStack. At that point, its datastore will be removed (inc= luding, of course, your VM's VMX, NVRAM, etc. files). This is not really a problem on XenServer because XenServer does not store = VM config files in the SR, so I think we're OK there. We should also be OK for KVM. * Technically it can have many if those other VMDK files are delta snapshot= s, but they still - together - represent a single disk. On Fri, Mar 28, 2014 at 10:36 AM, Alena Prokharchyk > wrote: Mike, thank you for the explanation on managed storage.. As far as I unders= tand from your email, the main difference is instead of creating an SR on t= he PS, CloudStack will recognize pre-existing volume created outside of the= CS. Am I correct? If so, I don=92t think there would be any difference. When root volume deta= ch happens, no storage attributes =96 path, clusterId =96 are being changed= . And we would apply the same set of checks to the root volume attach, as f= or a dataDisk attach. -Alena. From: Mike Tutkowski > Date: Thursday, March 27, 2014 at 9:40 PM To: Alena Prokharchyk > Cc: "dev@cloudstack.apache.org" > Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5 Hi Alena, I was wondering if you've taken "managed" storage into consideration for th= is? If you're unfamiliar with it, managed storage is named as such because Clou= dStack manages it on behalf of the admin (ex. dynamically creating SRs as n= eeded). For example, when I add primary storage to CloudStack that is based on the = SolidFire SAN, I use the SolidFire plug-in, which is an example of managed = storage. In this case, the primary storage represents a SAN as opposed to a prealloc= ated volume. When the time comes to, say, attach a data disk to a VM for the first time,= the SolidFire plug-in goes off to its SAN and dynamically creates a new vo= lume on it (with the appropriate size and IOPS requirements). CloudStack has logic that recognizes managed storage. For example, for XenServer, its logic has been augmented to automatically c= reate an SR based on the iSCSI target that was created on the SAN and to cr= eate a VDI within it that is attached to the VM in question. The big takeaway is that each CloudStack volume here will be associated wit= h a unique volume on a SAN and consumed as an SR (XenServer) or datastore (= ESX) (KVM handles this differently). In this situation, there is a 1:1 mapp= ing between a SAN volume and an SR. No other VDIs are stored on the SR exce= pt for the one representing this one CloudStack volume. That being the case, I was wondering what you thought of this with regards = to your root-volume-detach feature? If we don't want to look into this for 4.5, it might be best to simply fail= to detach a root volume from a VM if the volume is based on managed storag= e or to fail to attach a bootable volume to a VM if it is based on managed = storage. Talk to you later, Mike On Tue, Mar 25, 2014 at 1:24 PM, Alena Prokharchyk > wrote: Mike, Volume has a template_id referencing vm_template table. Vm_template has bootable flag, so we will derive information from there. And sure, this information will not change if the root disk is detached. On 3/25/14, 12:18 PM, "Mike Tutkowski" > wrote: >Hi Alena, > >I was wondering how we plan to keep track of the new "bootable" property? >When we create a VM, would we just mark its root disk as bootable and then >that property becomes immutable (for the upgrade case, all root disks >would >be marked as bootable)? > >I'm thinking we'd want to keep track of bootable disks even when there are >detached and turned into data disks. Is that what you had in mind? > >Thanks! >Mike > > >On Tue, Mar 25, 2014 at 12:20 PM, Alena Prokharchyk < >Alena.Prokharchyk@citrix.com> wrote: > >> Here is the link to the corresponding FS (placed in "4.5 Design >>documents" >> section) >> >> >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/ROOT+volume+detach >> >> -Alena. >> >> From: Alena Prokharchyk > alena.prokharchyk@citrix.com>> >> Date: Monday, March 24, 2014 at 11:37 AM >> To: "dev@cloudstack.apache.org>" < >> dev@cloudstack.apache.org>> >> Subject: [PROPOSAL] ROOT volume detach - feature for CS 4.5 >> >> I would like to propose a new feature for CS 4.5 - "ROOT volume detach" >>- >> that enables support for following use cases: >> >> 1) Replace current ROOT volume with the new one for existing vm. >> 2) Case when ROOT volume of vm1 gets corrupted, and you want to attach >>it >> to vm2 to run the recovery utils on it. With current CS implemntation, >>you >> have to perform several steps - create snapshot of vm1's volume, create >> volume from snapshot, attach volume to the vm2. New implementation will >> merge it all to one step. >> >> >> With the planned implementation, once the ROOT volume is detached, it >>can >> be attached to any existing vm (with respect to Admin/Domain/Physical >> resources limitations), either as a DataDisk or a Root disk. >> >> Amazon EC2 already has this functionality in place, so I think CS would >> only benefit from having it. Storage experts (Edison, others) please >>raise >> your concerns if you have any, or if you see any potential problems with >> the planned implementation. And if anyone can think of other use cases >>this >> feature can possible solve, I would appreciate this input as well. >> >> >> Feature limitations: >> >> * ROOT volume can be detached only when vm is in Stopped state >> * CS will fail to start the vm not having a ROOT volume >> >> I will send out the link to the FS once I start getting feedback on the >> proposal. >> >> -Alena. >> > > > >-- >*Mike Tutkowski* >*Senior CloudStack Developer, SolidFire Inc.* >e: mike.tutkowski@solidfire.com >o: 303.746.7302 >Advancing the way the world uses the >cloud >*(tm)* -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkowski@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud=99 -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkowski@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud=99 -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkowski@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud=99 --_000_CF5B11E4432F1alenaprokharchykcitrixcom_--