I see this feature as mainly just shuffling around object properties in the database. I don't expect any major issues to arise with any storage if an inactive "root" disk is marked as a "data" disk in the DB, for example. In the end, when you start a VM you're always going to have a root disk in the vm instance object, and volumes that are attached/detached are going to be passed as data disks (If I understand correctly). It doesn't really matter to the storage drivers if the volume object was previously of type root or data.
On Fri, Mar 28, 2014 at 12:48 PM, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > I will look into it more, Mike. vmWare indeed can be different. > > -Alena. > > From: Mike Tutkowski > <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> > Date: Friday, March 28, 2014 at 11:39 AM > To: Alena Prokharchyk > <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> > Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto: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 > CloudStack, 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 (which > has to necessarily be in another datastore), you won't see a problem until > 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 > <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> 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 root > volume. > > The new root volume will necessarily be on a different datastore than the > datastore of the previous root volume (because a datastore created to consume > 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 root > volume from CloudStack. At that point, its datastore will be removed > (including, 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 snapshots, > but they still - together - represent a single disk. > > > On Fri, Mar 28, 2014 at 10:36 AM, Alena Prokharchyk > <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> wrote: > Mike, thank you for the explanation on managed storage.. As far as I > understand from your email, the main difference is instead of creating an SR > on the PS, CloudStack will recognize pre-existing volume created outside of > the CS. Am I correct? > > If so, I don't think there would be any difference. When root volume detach > happens, no storage attributes - path, clusterId - are being changed. And we > would apply the same set of checks to the root volume attach, as for a > dataDisk attach. > > -Alena. > > From: Mike Tutkowski > <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> > Date: Thursday, March 27, 2014 at 9:40 PM > To: Alena Prokharchyk > <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> > Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto: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 this? > > If you're unfamiliar with it, managed storage is named as such because > CloudStack manages it on behalf of the admin (ex. dynamically creating SRs as > needed). > > 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 > preallocated 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 > volume 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 > create an SR based on the iSCSI target that was created on the SAN and to > create a VDI within it that is attached to the VM in question. > > The big takeaway is that each CloudStack volume here will be associated with > 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 mapping > between a SAN volume and an SR. No other VDIs are stored on the SR except 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 storage > 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 > <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> 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" > <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> > 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.prokharc...@citrix.com<mailto:alena.prokharc...@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.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com><mailto: >>> alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>>> >>> Date: Monday, March 24, 2014 at 11:37 AM >>> To: >>> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>" >>> < >>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org<mailto: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.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> >>o: 303.746.7302<tel:303.746.7302> >>Advancing the way the world uses the >>cloud<http://solidfire.com/solution/overview/?video=play> >>*(tm)* > > > > > -- > Mike Tutkowski > Senior CloudStack Developer, SolidFire Inc. > e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> > o: 303.746.7302<tel:303.746.7302> > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play>(tm) > > > > -- > Mike Tutkowski > Senior CloudStack Developer, SolidFire Inc. > e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> > o: 303.746.7302<tel:303.746.7302> > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play>(tm) > > > > -- > Mike Tutkowski > Senior CloudStack Developer, SolidFire Inc. > e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play>(tm)
