"Same idea for root disks, but I'm first introducing support for them (XenServer and VMware) in 4.5."
I meant to say, "in 4.4." :) On Fri, Mar 28, 2014 at 6:22 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Think of it this way (you'll need a little SolidFire history to see where > I'm coming from): > > The big problem SolidFire solves is bringing predictable performance to > the cloud. With a SolidFire SAN, you are able to specify a minimum, > maximum, and burst number of IOPS on a volume-by-volume basis. This way you > have what appears to be dedicated resources (a guaranteed number of IOPS > per volume) within a shared storage infrastructure. The SAN is incredibly > resilient. It is a loosely coupled cluster or storage nodes. Any SSD within > a node or an entire node of SSDs can go offline and the SAN self heals and > can maintain its performance guarantees. The SAN was built to compete with > traditional SANs cost wise and, as such, has sophisticated efficiency > technologies built in from the ground up (inline compression, inline > de-dupe, and inline thin provisioning). > > The main driver is that only about 10% of an enterprise's workload is > hosted in the cloud at present. The primary reason sited for why more > workloads are not in the cloud is a lack of predictable performance. That > being the case, many enterprises won't move their mission-critical > applications to the cloud until performance can be guaranteed. > > So, bringing this around to CloudStack: > > CloudStack was initially built on the storage side to house many root > and/or data disks on the same NFS share or - what is of more interest to me > at present - on the same iSCSI target. > > That is a serious problem from a storage Quality of Service standpoint. > Even though our iSCSI target (SAN volume) has a guaranteed number of IOPS, > if you split those IOPS among many root and/or data disks, you cannot > guarantee a certain number of IOPS to any one particular root or data disk > (only to the SAN volume). > > That being the case, I developed the concept of so-called managed storage > for CloudStack (this is somewhat similar to how OpenStack's block storage > component works). > > In this model, primary storage is added to CloudStack that represents a > SAN - not a preallocated amount of storage from a SAN (i.e. not a > preallocated volume from a SAN). > > When the user, say, attaches a CloudStack volume to a VM for the first > time, the SolidFire plug-in creates a volume on its SAN (a new iSCSI target > is created). > > CloudStack understands managed storage and knows, say, for XenServer to > dynamically create an SR to consume this new iSCSI target. > > Inside of the SR will be a single VDI that represents the disk to attach > to the VM. > > No other VDI (except for snapshot deltas) will be placed inside of this > SR. The SR is dedicated to a single CloudStack volume. > > In this manner, we can guarantee IOPS for the disk being attached to the > VM. > > Same idea for root disks, but I'm first introducing support for them > (XenServer and VMware) in 4.5. > > KVM is a bit different because it doesn't apply a clustered file system to > the newly created iSCSI target, but - in the end - that iSCSI target will > only be used for one disk. Since the iSCSI target (SAN volume) has a > guaranteed number of IOPS and it's only being used for a single disk, the > disk therefore has a guaranteed number of IOPS. > > At present only the SolidFire plug-in supports managed storage, but it > doesn't have to be that way. > > For example, CloudByte has a rate-limiting feature (essentially a maximum > number of IOPS) and one of their developers sounded interested in > implementing a plug-in that takes advantage of the managed-storage feature. > > > On Fri, Mar 28, 2014 at 5:30 PM, Marcus <shadow...@gmail.com> wrote: > >> Yeah, VMware has many formats for storage and configs, and some suffer >> from insufficient abstraction between resources and definitions for >> cloud use. I'm sure it can be worked around in some regard. >> >> I still haven't wrapped my head around the datastore(or SR for >> xen)-per-volume, but I know that's how the SolidFire plugin works, so >> forgive me if I've made assumptions that make sense in the scope of >> how our plugins work. >> >> On Fri, Mar 28, 2014 at 5:22 PM, Mike Tutkowski >> <mike.tutkow...@solidfire.com> wrote: >> > See...I don't know the history behind this, but for VMware, when we >> shut a >> > VM down, the config files remain, which is not how this works on >> XenServer >> > or KVM. >> > >> > That is the "root" (pun intended) of our managed-storage problem here. >> > >> > >> > On Fri, Mar 28, 2014 at 5:20 PM, Mike Tutkowski >> > <mike.tutkow...@solidfire.com> wrote: >> >> >> >> Sure :) In the storage_pool table, there is a column called "managed". >> 1 = >> >> managed >> >> >> >> >> >> On Fri, Mar 28, 2014 at 5:18 PM, Alena Prokharchyk >> >> <alena.prokharc...@citrix.com> wrote: >> >>> >> >>> Ok, then can you please tell me the way how to determine if the >> >>> corresponding storage is managed, by looking at CS DB entry? >> >>> >> >>> For phase #1 of the feature, I will just implement it for the regular >> >>> storage in KVM/Xen/VmWare; and implement managed storage support some >> time >> >>> later. >> >>> >> >>> -Alena. >> >>> >> >>> From: Mike Tutkowski <mike.tutkow...@solidfire.com> >> >>> Date: Friday, March 28, 2014 at 4:15 PM >> >>> >> >>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >> >>> Cc: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>, >> >>> "shadow...@gmail.com" <shadow...@gmail.com> >> >>> Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5 >> >>> >> >>> Yes >> >>> >> >>> With non-managed storage, the admin determines when to manually create >> >>> and delete datastores. >> >>> >> >>> I think this will only be a problem with managed storage on VMware. >> >>> >> >>> >> >>> On Fri, Mar 28, 2014 at 5:14 PM, Alena Prokharchyk >> >>> <alena.prokharc...@citrix.com> wrote: >> >>>> >> >>>> So it only affects managed storage? >> >>>> >> >>>> From: Mike Tutkowski <mike.tutkow...@solidfire.com> >> >>>> Date: Friday, March 28, 2014 at 4:10 PM >> >>>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >> >>>> Cc: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>, >> >>>> "shadow...@gmail.com" <shadow...@gmail.com> >> >>>> >> >>>> Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5 >> >>>> >> >>>> Let me illustrate this with an example: >> >>>> >> >>>> * User creates a VM whose root disk is placed on managed storage >> >>>> >> >>>> * Storage plug-in creates a volume on its SAN >> >>>> >> >>>> * VMware server resource creates a datastore based on the newly >> created >> >>>> SAN volume (let me stress that this datastore was created by the >> VMware >> >>>> server resource - not manually by an admin as would be the case for >> >>>> non-managed storage) >> >>>> >> >>>> * Inside the datastore are placed the VMDK file (root disk) along >> with >> >>>> VM config files like VMX, NVRAM, etc. >> >>>> >> >>>> * User detaches the root volume (the VMDK file and VM config files >> >>>> remain in the datastore) >> >>>> >> >>>> * User attaches another root volume to the VM (the VMDK file is >> stored >> >>>> in a datastore different from the datastore where the VM config files >> >>>> reside, which is fine for now) >> >>>> >> >>>> * User deletes and expunges the original root disk (this leads to the >> >>>> datastore the VMDK file is on being removed...as a side effect, you >> will >> >>>> also lose your VM config files), SAN volume is deleted, CloudStack >> volume is >> >>>> marked as deleted in the database >> >>>> >> >>>> >> >>>> On Fri, Mar 28, 2014 at 5:05 PM, Mike Tutkowski >> >>>> <mike.tutkow...@solidfire.com> wrote: >> >>>>> >> >>>>> So, do you guys see my concern with VMware, though? >> >>>>> >> >>>>> VMware is different from XenServer and KVM in that its VM config >> files >> >>>>> are stored in the datastore along side the root volume (in >> CloudStack 4.3, >> >>>>> for example). >> >>>>> >> >>>>> If you switch the VM to use a VMDK file in a different datastore, >> the >> >>>>> config files will remain in the original datastore (unless we >> transfer them >> >>>>> ourselves to the new datastore). >> >>>>> >> >>>>> If they remain in the original datastore and that disk is deleted >> >>>>> later, the datastore that contains that disk will be removed (along >> with the >> >>>>> VM config files that are new being used in conjunction with a disk >> in >> >>>>> another datastore). >> >>>>> >> >>>>> >> >>>>> On Fri, Mar 28, 2014 at 4:58 PM, Alena Prokharchyk >> >>>>> <alena.prokharc...@citrix.com> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On 3/28/14, 3:50 PM, "Marcus" <shadow...@gmail.com> wrote: >> >>>>>> >> >>>>>> > 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. >> >>>>>> >> >>>>>> Correct. That¹s what I reflected in the spec. But I¹m going to >> test it >> >>>>>> on >> >>>>>> all major supported hypervisors - KVM/Xen/VmWare - anyway, just to >> be >> >>>>>> 100% >> >>>>>> sure nothing breaks. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> > >> >>>>>> >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+deta >> >>>>>> >>>>ch >> >>>>>> >>>> >> >>>>>> >>>> -Alena. >> >>>>>> >>>> >> >>>>>> >>>> From: Alena Prokharchyk >> >>>>>> >> >>>>>> >>>> >>>><alena.prokharc...@citrix.com<mailto: >> alena.prokharc...@citrix.com><mail >> >>>>>> >>>>to: >> >>>>>> >>>> >> >>>>>> >>>> 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) >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Mike Tutkowski >> >>>>> Senior CloudStack Developer, SolidFire Inc. >> >>>>> e: mike.tutkow...@solidfire.com >> >>>>> o: 303.746.7302 >> >>>>> Advancing the way the world uses the cloud(tm) >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Mike Tutkowski >> >>>> Senior CloudStack Developer, SolidFire Inc. >> >>>> e: mike.tutkow...@solidfire.com >> >>>> o: 303.746.7302 >> >>>> Advancing the way the world uses the cloud(tm) >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Mike Tutkowski >> >>> Senior CloudStack Developer, SolidFire Inc. >> >>> e: mike.tutkow...@solidfire.com >> >>> o: 303.746.7302 >> >>> Advancing the way the world uses the cloud(tm) >> >> >> >> >> >> >> >> >> >> -- >> >> Mike Tutkowski >> >> Senior CloudStack Developer, SolidFire Inc. >> >> e: mike.tutkow...@solidfire.com >> >> o: 303.746.7302 >> >> Advancing the way the world uses the cloud(tm) >> > >> > >> > >> > >> > -- >> > Mike Tutkowski >> > Senior CloudStack Developer, SolidFire Inc. >> > e: mike.tutkow...@solidfire.com >> > o: 303.746.7302 >> > Advancing the way the world uses the cloud(tm) >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 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 o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
