You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alena Prokharchyk <Al...@citrix.com> on 2014/03/24 19:37:45 UTC
[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.
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
If you're interested, I talked about this at CCC in Amsterdam:
https://www.youtube.com/watch?v=EJumlujVTFo
On Fri, Mar 28, 2014 at 6:26 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> "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.tutkowski@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 <sh...@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
>>> <mi...@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
>>> > <mi...@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
>>> >> <Al...@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 <mi...@solidfire.com>
>>> >>> Date: Friday, March 28, 2014 at 4:15 PM
>>> >>>
>>> >>> To: Alena Prokharchyk <al...@citrix.com>
>>> >>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
>>> >>> "shadowsor@gmail.com" <sh...@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
>>> >>> <Al...@citrix.com> wrote:
>>> >>>>
>>> >>>> So it only affects managed storage?
>>> >>>>
>>> >>>> From: Mike Tutkowski <mi...@solidfire.com>
>>> >>>> Date: Friday, March 28, 2014 at 4:10 PM
>>> >>>> To: Alena Prokharchyk <al...@citrix.com>
>>> >>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
>>> >>>> "shadowsor@gmail.com" <sh...@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
>>> >>>> <mi...@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
>>> >>>>> <Al...@citrix.com> wrote:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>> >>>>>> ><Al...@citrix.com> wrote:
>>> >>>>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>> >>>>>> >>
>>> >>>>>> >> -Alena.
>>> >>>>>> >>
>>> >>>>>> >> From: Mike Tutkowski
>>> >>>>>> >><mike.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@solidfire.com>>
>>> >>>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>> >>>>>> >> To: Alena Prokharchyk
>>> >>>>>> >><alena.prokharchyk@citrix.com<mailto:
>>> alena.prokharchyk@citrix.com>>
>>> >>>>>> >> Cc: "dev@cloudstack.apache.org<mailto:
>>> dev@cloudstack.apache.org>"
>>> >>>>>> >><de...@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.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@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.Prokharchyk@citrix.com<mailto:
>>> Alena.Prokharchyk@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.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@solidfire.com>>
>>> >>>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>> >>>>>> >> To: Alena Prokharchyk
>>> >>>>>> >><alena.prokharchyk@citrix.com<mailto:
>>> alena.prokharchyk@citrix.com>>
>>> >>>>>> >> Cc: "dev@cloudstack.apache.org<mailto:
>>> dev@cloudstack.apache.org>"
>>> >>>>>> >><de...@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.Prokharchyk@citrix.com<mailto:
>>> Alena.Prokharchyk@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.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@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.Prokharchyk@citrix.com<mailto:
>>> 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+deta
>>> >>>>>> >>>>ch
>>> >>>>>> >>>>
>>> >>>>>> >>>> -Alena.
>>> >>>>>> >>>>
>>> >>>>>> >>>> From: Alena Prokharchyk
>>> >>>>>>
>>> >>>>>> >>>> >>>><alena.prokharchyk@citrix.com<mailto:
>>> alena.prokharchyk@citrix.com><mail
>>> >>>>>> >>>>to:
>>> >>>>>> >>>>
>>> >>>>>> >>>> alena.prokharchyk@citrix.com<mailto:
>>> alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
>>> >>>>>> >>>>
>>> >>>>>>
>>> >>>>>> >>>> >>>>dev@cloudstack.apache.org<mailto:
>>> dev@cloudstack.apache.org><mailto:dev@
>>> >>>>>> >>>>cloudstack.apache.org<ma...@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<mailto:
>>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>>> mike.tutkowski@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.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(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(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(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(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<http://solidfire.com/solution/overview/?video=play>
>> *(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<http://solidfire.com/solution/overview/?video=play>
> *(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
"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.tutkowski@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 <sh...@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
>> <mi...@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
>> > <mi...@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
>> >> <Al...@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 <mi...@solidfire.com>
>> >>> Date: Friday, March 28, 2014 at 4:15 PM
>> >>>
>> >>> To: Alena Prokharchyk <al...@citrix.com>
>> >>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
>> >>> "shadowsor@gmail.com" <sh...@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
>> >>> <Al...@citrix.com> wrote:
>> >>>>
>> >>>> So it only affects managed storage?
>> >>>>
>> >>>> From: Mike Tutkowski <mi...@solidfire.com>
>> >>>> Date: Friday, March 28, 2014 at 4:10 PM
>> >>>> To: Alena Prokharchyk <al...@citrix.com>
>> >>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
>> >>>> "shadowsor@gmail.com" <sh...@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
>> >>>> <mi...@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
>> >>>>> <Al...@citrix.com> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>> >>>>>> ><Al...@citrix.com> wrote:
>> >>>>>> >> I will look into it more, Mike. vmWare indeed can be different.
>> >>>>>> >>
>> >>>>>> >> -Alena.
>> >>>>>> >>
>> >>>>>> >> From: Mike Tutkowski
>> >>>>>> >><mike.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>>
>> >>>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>> >>>>>> >> To: Alena Prokharchyk
>> >>>>>> >><alena.prokharchyk@citrix.com<mailto:
>> alena.prokharchyk@citrix.com>>
>> >>>>>> >> Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
>> >"
>> >>>>>> >><de...@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@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.Prokharchyk@citrix.com<mailto:
>> Alena.Prokharchyk@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>>
>> >>>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>> >>>>>> >> To: Alena Prokharchyk
>> >>>>>> >><alena.prokharchyk@citrix.com<mailto:
>> alena.prokharchyk@citrix.com>>
>> >>>>>> >> Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
>> >"
>> >>>>>> >><de...@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.Prokharchyk@citrix.com<mailto:
>> Alena.Prokharchyk@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@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.Prokharchyk@citrix.com<mailto:
>> 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+deta
>> >>>>>> >>>>ch
>> >>>>>> >>>>
>> >>>>>> >>>> -Alena.
>> >>>>>> >>>>
>> >>>>>> >>>> From: Alena Prokharchyk
>> >>>>>>
>> >>>>>> >>>> >>>><alena.prokharchyk@citrix.com<mailto:
>> alena.prokharchyk@citrix.com><mail
>> >>>>>> >>>>to:
>> >>>>>> >>>>
>> >>>>>> >>>> alena.prokharchyk@citrix.com<mailto:
>> alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
>> >>>>>> >>>>
>> >>>>>>
>> >>>>>> >>>> >>>>dev@cloudstack.apache.org<mailto:
>> dev@cloudstack.apache.org><mailto:dev@
>> >>>>>> >>>>cloudstack.apache.org<ma...@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<mailto:
>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@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.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(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(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(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(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<http://solidfire.com/solution/overview/?video=play>
> *(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <sh...@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
> <mi...@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
> > <mi...@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
> >> <Al...@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 <mi...@solidfire.com>
> >>> Date: Friday, March 28, 2014 at 4:15 PM
> >>>
> >>> To: Alena Prokharchyk <al...@citrix.com>
> >>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
> >>> "shadowsor@gmail.com" <sh...@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
> >>> <Al...@citrix.com> wrote:
> >>>>
> >>>> So it only affects managed storage?
> >>>>
> >>>> From: Mike Tutkowski <mi...@solidfire.com>
> >>>> Date: Friday, March 28, 2014 at 4:10 PM
> >>>> To: Alena Prokharchyk <al...@citrix.com>
> >>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
> >>>> "shadowsor@gmail.com" <sh...@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
> >>>> <mi...@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
> >>>>> <Al...@citrix.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
> >>>>>> ><Al...@citrix.com> wrote:
> >>>>>> >> I will look into it more, Mike. vmWare indeed can be different.
> >>>>>> >>
> >>>>>> >> -Alena.
> >>>>>> >>
> >>>>>> >> From: Mike Tutkowski
> >>>>>> >><mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com
> >>
> >>>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
> >>>>>> >> To: Alena Prokharchyk
> >>>>>> >><alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
> >>
> >>>>>> >> Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
> >"
> >>>>>> >><de...@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.Prokharchyk@citrix.com<mailto:Alena.Prokharchyk@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.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com
> >>
> >>>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
> >>>>>> >> To: Alena Prokharchyk
> >>>>>> >><alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
> >>
> >>>>>> >> Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
> >"
> >>>>>> >><de...@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.Prokharchyk@citrix.com<mailto:Alena.Prokharchyk@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.Prokharchyk@citrix.com<mailto: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+deta
> >>>>>> >>>>ch
> >>>>>> >>>>
> >>>>>> >>>> -Alena.
> >>>>>> >>>>
> >>>>>> >>>> From: Alena Prokharchyk
> >>>>>>
> >>>>>> >>>> >>>><alena.prokharchyk@citrix.com<mailto:
> alena.prokharchyk@citrix.com><mail
> >>>>>> >>>>to:
> >>>>>> >>>>
> >>>>>> >>>> alena.prokharchyk@citrix.com<mailto:
> alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
> >>>>>> >>>>
> >>>>>>
> >>>>>> >>>> >>>>dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
> ><mailto:dev@
> >>>>>> >>>>cloudstack.apache.org<ma...@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<mailto:
> mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.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(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(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(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(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Marcus <sh...@gmail.com>.
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
<mi...@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
> <mi...@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
>> <Al...@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 <mi...@solidfire.com>
>>> Date: Friday, March 28, 2014 at 4:15 PM
>>>
>>> To: Alena Prokharchyk <al...@citrix.com>
>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
>>> "shadowsor@gmail.com" <sh...@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
>>> <Al...@citrix.com> wrote:
>>>>
>>>> So it only affects managed storage?
>>>>
>>>> From: Mike Tutkowski <mi...@solidfire.com>
>>>> Date: Friday, March 28, 2014 at 4:10 PM
>>>> To: Alena Prokharchyk <al...@citrix.com>
>>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>,
>>>> "shadowsor@gmail.com" <sh...@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
>>>> <mi...@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
>>>>> <Al...@citrix.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>>>>> ><Al...@citrix.com> wrote:
>>>>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>>>>> >>
>>>>>> >> -Alena.
>>>>>> >>
>>>>>> >> From: Mike Tutkowski
>>>>>> >><mi...@solidfire.com>>
>>>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>>>>> >> To: Alena Prokharchyk
>>>>>> >><al...@citrix.com>>
>>>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>>>> >><de...@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
>>>>>> >><mi...@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
>>>>>> >><Al...@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
>>>>>> >><mi...@solidfire.com>>
>>>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>>>>> >> To: Alena Prokharchyk
>>>>>> >><al...@citrix.com>>
>>>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>>>> >><de...@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
>>>>>> >><Al...@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"
>>>>>> >><mi...@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.Prokharchyk@citrix.com<ma...@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
>>>>>>
>>>>>> >>>> >>>><al...@citrix.com><mail
>>>>>> >>>>to:
>>>>>> >>>>
>>>>>> >>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>>>>>> >>>> Date: Monday, March 24, 2014 at 11:37 AM
>>>>>> >>>> To:
>>>>>>
>>>>>> >>>> >>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:dev
>>>>>> >>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>>>>>> >>>>
>>>>>>
>>>>>> >>>> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:dev@
>>>>>> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.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(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(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(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(tm)
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.Prokharchyk@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 <mi...@solidfire.com>
>> Date: Friday, March 28, 2014 at 4:15 PM
>>
>> To: Alena Prokharchyk <al...@citrix.com>
>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
>> shadowsor@gmail.com" <sh...@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.Prokharchyk@citrix.com> wrote:
>>
>>> So it only affects managed storage?
>>>
>>> From: Mike Tutkowski <mi...@solidfire.com>
>>> Date: Friday, March 28, 2014 at 4:10 PM
>>> To: Alena Prokharchyk <al...@citrix.com>
>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
>>> shadowsor@gmail.com" <sh...@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.tutkowski@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.Prokharchyk@citrix.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>>>> ><Al...@citrix.com> wrote:
>>>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>>>> >>
>>>>> >> -Alena.
>>>>> >>
>>>>> >> From: Mike Tutkowski
>>>>> >><mi...@solidfire.com>>
>>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>>>> >> To: Alena Prokharchyk
>>>>> >><al...@citrix.com>>
>>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>>> >><de...@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
>>>>> >><mi...@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
>>>>> >><Al...@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
>>>>> >><mi...@solidfire.com>>
>>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>>>> >> To: Alena Prokharchyk
>>>>> >><al...@citrix.com>>
>>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>>> >><de...@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
>>>>> >><Al...@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"
>>>>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
>>>>> ><mail
>>>>> >>>>to:
>>>>> >>>> alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
>>>>> >>>>
>>>>> >>>>dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
>>>>> ><mailto:dev@
>>>>> >>>>cloudstack.apache.org<ma...@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<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
If when shutting a VMware VM down we removed the VM config info from
vCenter and then added it back to vCenter when starting the VM back up
(which is essentially how it works with XenServer and KVM...even though
they don't have the same kind of centralized managed as VMware has), we
would not have this problem.
On Fri, Mar 28, 2014 at 5:21 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:
> Great, thanks, I will update the spec accordingly.
>
> From: Mike Tutkowski <mi...@solidfire.com>
> Date: Friday, March 28, 2014 at 4:20 PM
>
> To: Alena Prokharchyk <al...@citrix.com>
> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
> shadowsor@gmail.com" <sh...@gmail.com>
> Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
>
> 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.Prokharchyk@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 <mi...@solidfire.com>
>> Date: Friday, March 28, 2014 at 4:15 PM
>>
>> To: Alena Prokharchyk <al...@citrix.com>
>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
>> shadowsor@gmail.com" <sh...@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.Prokharchyk@citrix.com> wrote:
>>
>>> So it only affects managed storage?
>>>
>>> From: Mike Tutkowski <mi...@solidfire.com>
>>> Date: Friday, March 28, 2014 at 4:10 PM
>>> To: Alena Prokharchyk <al...@citrix.com>
>>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
>>> shadowsor@gmail.com" <sh...@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.tutkowski@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.Prokharchyk@citrix.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>>>> ><Al...@citrix.com> wrote:
>>>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>>>> >>
>>>>> >> -Alena.
>>>>> >>
>>>>> >> From: Mike Tutkowski
>>>>> >><mi...@solidfire.com>>
>>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>>>> >> To: Alena Prokharchyk
>>>>> >><al...@citrix.com>>
>>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>>> >><de...@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
>>>>> >><mi...@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
>>>>> >><Al...@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
>>>>> >><mi...@solidfire.com>>
>>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>>>> >> To: Alena Prokharchyk
>>>>> >><al...@citrix.com>>
>>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>>> >><de...@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
>>>>> >><Al...@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"
>>>>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
>>>>> ><mail
>>>>> >>>>to:
>>>>> >>>> alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
>>>>> >>>>
>>>>> >>>>dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
>>>>> ><mailto:dev@
>>>>> >>>>cloudstack.apache.org<ma...@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<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
Great, thanks, I will update the spec accordingly.
From: Mike Tutkowski <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 4:20 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, "shadowsor@gmail.com<ma...@gmail.com>" <sh...@gmail.com>>
Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
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 <Al...@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 <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 4:15 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, "shadowsor@gmail.com<ma...@gmail.com>" <sh...@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 <Al...@citrix.com>> wrote:
So it only affects managed storage?
From: Mike Tutkowski <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 4:10 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, "shadowsor@gmail.com<ma...@gmail.com>" <sh...@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 <mi...@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 <Al...@citrix.com>> wrote:
On 3/28/14, 3:50 PM, "Marcus" <sh...@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
><Al...@citrix.com>> wrote:
>> I will look into it more, Mike. vmWare indeed can be different.
>>
>> -Alena.
>>
>> From: Mike Tutkowski
>><mi...@solidfire.com>>>
>> Date: Friday, March 28, 2014 at 11:39 AM
>> To: Alena Prokharchyk
>><al...@citrix.com>>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>"
>><de...@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
>><mi...@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
>><Al...@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
>><mi...@solidfire.com>>>
>> Date: Thursday, March 27, 2014 at 9:40 PM
>> To: Alena Prokharchyk
>><al...@citrix.com>>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>"
>><de...@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
>><Al...@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"
>><mi...@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.Prokharchyk@citrix.com<ma...@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
>>>><al...@citrix.com>><mail
>>>>to:
>>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>>
>>>> Date: Monday, March 24, 2014 at 11:37 AM
>>>> To:
>>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org>><mailto:dev<mailto:dev>
>>>>@cloudstack.apache.org<ht...@cloudstack.apache.org>>>" <
>>>>
>>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org>><mailto:dev@<mailto:dev@>
>>>>cloudstack.apache.org<ht...@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<ma...@solidfire.com>>
>>>o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@solidfire.com>>
>> o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@solidfire.com>>
>> o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.Prokharchyk@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 <mi...@solidfire.com>
> Date: Friday, March 28, 2014 at 4:15 PM
>
> To: Alena Prokharchyk <al...@citrix.com>
> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
> shadowsor@gmail.com" <sh...@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.Prokharchyk@citrix.com> wrote:
>
>> So it only affects managed storage?
>>
>> From: Mike Tutkowski <mi...@solidfire.com>
>> Date: Friday, March 28, 2014 at 4:10 PM
>> To: Alena Prokharchyk <al...@citrix.com>
>> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
>> shadowsor@gmail.com" <sh...@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.tutkowski@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.Prokharchyk@citrix.com> wrote:
>>>
>>>>
>>>>
>>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>>> ><Al...@citrix.com> wrote:
>>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>>> >>
>>>> >> -Alena.
>>>> >>
>>>> >> From: Mike Tutkowski
>>>> >><mi...@solidfire.com>>
>>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>>> >> To: Alena Prokharchyk
>>>> >><al...@citrix.com>>
>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>> >><de...@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
>>>> >><mi...@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
>>>> >><Al...@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
>>>> >><mi...@solidfire.com>>
>>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>>> >> To: Alena Prokharchyk
>>>> >><al...@citrix.com>>
>>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>>> >><de...@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
>>>> >><Al...@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"
>>>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
>>>> ><mail
>>>> >>>>to:
>>>> >>>> alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
>>>> >>>>
>>>> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>>>> dev@
>>>> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
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 <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 4:15 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, "shadowsor@gmail.com<ma...@gmail.com>" <sh...@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 <Al...@citrix.com>> wrote:
So it only affects managed storage?
From: Mike Tutkowski <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 4:10 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, "shadowsor@gmail.com<ma...@gmail.com>" <sh...@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 <mi...@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 <Al...@citrix.com>> wrote:
On 3/28/14, 3:50 PM, "Marcus" <sh...@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
><Al...@citrix.com>> wrote:
>> I will look into it more, Mike. vmWare indeed can be different.
>>
>> -Alena.
>>
>> From: Mike Tutkowski
>><mi...@solidfire.com>>>
>> Date: Friday, March 28, 2014 at 11:39 AM
>> To: Alena Prokharchyk
>><al...@citrix.com>>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>"
>><de...@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
>><mi...@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
>><Al...@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
>><mi...@solidfire.com>>>
>> Date: Thursday, March 27, 2014 at 9:40 PM
>> To: Alena Prokharchyk
>><al...@citrix.com>>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>"
>><de...@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
>><Al...@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"
>><mi...@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.Prokharchyk@citrix.com<ma...@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
>>>><al...@citrix.com>><mail
>>>>to:
>>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>>
>>>> Date: Monday, March 24, 2014 at 11:37 AM
>>>> To:
>>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org>><mailto:dev<mailto:dev>
>>>>@cloudstack.apache.org<ht...@cloudstack.apache.org>>>" <
>>>>
>>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org>><mailto:dev@<mailto:dev@>
>>>>cloudstack.apache.org<ht...@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<ma...@solidfire.com>>
>>>o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@solidfire.com>>
>> o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@solidfire.com>>
>> o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.Prokharchyk@citrix.com> wrote:
> So it only affects managed storage?
>
> From: Mike Tutkowski <mi...@solidfire.com>
> Date: Friday, March 28, 2014 at 4:10 PM
> To: Alena Prokharchyk <al...@citrix.com>
> Cc: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>, "
> shadowsor@gmail.com" <sh...@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.tutkowski@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.Prokharchyk@citrix.com> wrote:
>>
>>>
>>>
>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>> ><Al...@citrix.com> wrote:
>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>> >>
>>> >> -Alena.
>>> >>
>>> >> From: Mike Tutkowski
>>> >><mi...@solidfire.com>>
>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>> >> To: Alena Prokharchyk
>>> >><al...@citrix.com>>
>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>> >><de...@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
>>> >><mi...@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
>>> >><Al...@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
>>> >><mi...@solidfire.com>>
>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>> >> To: Alena Prokharchyk
>>> >><al...@citrix.com>>
>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>> >><de...@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
>>> >><Al...@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"
>>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
>>> ><mail
>>> >>>>to:
>>> >>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>>> >>>> Date: Monday, March 24, 2014 at 11:37 AM
>>> >>>> To:
>>> >>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>>> dev
>>> >>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>>> >>>>
>>> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>>> dev@
>>> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
So it only affects managed storage?
From: Mike Tutkowski <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 4:10 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, "shadowsor@gmail.com<ma...@gmail.com>" <sh...@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 <mi...@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 <Al...@citrix.com>> wrote:
On 3/28/14, 3:50 PM, "Marcus" <sh...@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
><Al...@citrix.com>> wrote:
>> I will look into it more, Mike. vmWare indeed can be different.
>>
>> -Alena.
>>
>> From: Mike Tutkowski
>><mi...@solidfire.com>>>
>> Date: Friday, March 28, 2014 at 11:39 AM
>> To: Alena Prokharchyk
>><al...@citrix.com>>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>"
>><de...@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
>><mi...@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
>><Al...@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
>><mi...@solidfire.com>>>
>> Date: Thursday, March 27, 2014 at 9:40 PM
>> To: Alena Prokharchyk
>><al...@citrix.com>>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>"
>><de...@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
>><Al...@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"
>><mi...@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.Prokharchyk@citrix.com<ma...@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
>>>><al...@citrix.com>><mail
>>>>to:
>>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>>
>>>> Date: Monday, March 24, 2014 at 11:37 AM
>>>> To:
>>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org>><mailto:dev<mailto:dev>
>>>>@cloudstack.apache.org<ht...@cloudstack.apache.org>>>" <
>>>>
>>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org>><mailto:dev@<mailto:dev@>
>>>>cloudstack.apache.org<ht...@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<ma...@solidfire.com>>
>>>o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@solidfire.com>>
>> o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@solidfire.com>>
>> o: 303.746.7302<tel:303.746.7302><tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
Yeah, that's why I started the conversation saying we might just want to
prohibit this operation for managed storage in 4.5 until we can think it
through and make it work for all supported hypervisors. :)
As I say, I think it will be fine for XenServer and KVM as they do not
store VM config files the way VMware does.
On Fri, Mar 28, 2014 at 5:15 PM, Marcus <sh...@gmail.com> wrote:
> Yes, perhaps. I'm not sure it's specific to storage provider type
> though, but VMware vs Xen or KVM. There are plenty of features that
> aren't cross-hypervisor, so perhaps if it's a hangup then the feature
> can be only implemented on supported hypervisors.
>
> On Fri, Mar 28, 2014 at 5:10 PM, Mike Tutkowski
> <mi...@solidfire.com> wrote:
> > 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
> > <mi...@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
> >> <Al...@citrix.com> wrote:
> >>>
> >>>
> >>>
> >>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
> >>> ><Al...@citrix.com> wrote:
> >>> >> I will look into it more, Mike. vmWare indeed can be different.
> >>> >>
> >>> >> -Alena.
> >>> >>
> >>> >> From: Mike Tutkowski
> >>> >><mi...@solidfire.com>>
> >>> >> Date: Friday, March 28, 2014 at 11:39 AM
> >>> >> To: Alena Prokharchyk
> >>> >><al...@citrix.com>>
> >>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> >>> >><de...@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
> >>> >><mi...@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
> >>> >><Al...@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
> >>> >><mi...@solidfire.com>>
> >>> >> Date: Thursday, March 27, 2014 at 9:40 PM
> >>> >> To: Alena Prokharchyk
> >>> >><al...@citrix.com>>
> >>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> >>> >><de...@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
> >>> >><Al...@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"
> >>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:
> alena.prokharchyk@citrix.com><mail
> >>> >>>>to:
> >>> >>>> alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@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<ma...@cloudstack.apache.org>>" <
> >>> >>>>
> >>>
> >>> >>>> >>>>dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
> ><mailto:dev@
> >>> >>>>cloudstack.apache.org<ma...@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<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:mike.tutkowski@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.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(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Marcus <sh...@gmail.com>.
Yes, perhaps. I'm not sure it's specific to storage provider type
though, but VMware vs Xen or KVM. There are plenty of features that
aren't cross-hypervisor, so perhaps if it's a hangup then the feature
can be only implemented on supported hypervisors.
On Fri, Mar 28, 2014 at 5:10 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> 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
> <mi...@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
>> <Al...@citrix.com> wrote:
>>>
>>>
>>>
>>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>>> ><Al...@citrix.com> wrote:
>>> >> I will look into it more, Mike. vmWare indeed can be different.
>>> >>
>>> >> -Alena.
>>> >>
>>> >> From: Mike Tutkowski
>>> >><mi...@solidfire.com>>
>>> >> Date: Friday, March 28, 2014 at 11:39 AM
>>> >> To: Alena Prokharchyk
>>> >><al...@citrix.com>>
>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>> >><de...@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
>>> >><mi...@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
>>> >><Al...@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
>>> >><mi...@solidfire.com>>
>>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>>> >> To: Alena Prokharchyk
>>> >><al...@citrix.com>>
>>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>> >><de...@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
>>> >><Al...@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"
>>> >><mi...@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.Prokharchyk@citrix.com<ma...@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
>>>
>>> >>>> >>>><al...@citrix.com><mail
>>> >>>>to:
>>> >>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>>> >>>> Date: Monday, March 24, 2014 at 11:37 AM
>>> >>>> To:
>>>
>>> >>>> >>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:dev
>>> >>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>>> >>>>
>>>
>>> >>>> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:dev@
>>> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.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(tm)
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.Prokharchyk@citrix.com> wrote:
>
>>
>>
>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>> ><Al...@citrix.com> wrote:
>> >> I will look into it more, Mike. vmWare indeed can be different.
>> >>
>> >> -Alena.
>> >>
>> >> From: Mike Tutkowski
>> >><mi...@solidfire.com>>
>> >> Date: Friday, March 28, 2014 at 11:39 AM
>> >> To: Alena Prokharchyk
>> >><al...@citrix.com>>
>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>> >><de...@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
>> >><mi...@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
>> >><Al...@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
>> >><mi...@solidfire.com>>
>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>> >> To: Alena Prokharchyk
>> >><al...@citrix.com>>
>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>> >><de...@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
>> >><Al...@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"
>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
>> ><mail
>> >>>>to:
>> >>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>> >>>> Date: Monday, March 24, 2014 at 11:37 AM
>> >>>> To:
>> >>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>> dev
>> >>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>> >>>>
>> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>> dev@
>> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 3/28/14, 4:05 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:
>So, do you guys see my concern with VMware, though?
Yes, Mike, I’ve already sent a lab request to get vmWare setup to test
this out. Not a thing will be checked in unless its tested there ;)
>
>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.Prokharchyk@citrix.com> wrote:
>
>>
>>
>> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
>> ><Al...@citrix.com> wrote:
>> >> I will look into it more, Mike. vmWare indeed can be different.
>> >>
>> >> -Alena.
>> >>
>> >> From: Mike Tutkowski
>> >><mi...@solidfire.com>>
>> >> Date: Friday, March 28, 2014 at 11:39 AM
>> >> To: Alena Prokharchyk
>> >><al...@citrix.com>>
>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>> >><de...@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
>> >><mi...@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
>> >><Al...@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
>> >><mi...@solidfire.com>>
>> >> Date: Thursday, March 27, 2014 at 9:40 PM
>> >> To: Alena Prokharchyk
>> >><al...@citrix.com>>
>> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>> >><de...@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
>> >><Al...@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"
>> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
>> ><mail
>> >>>>to:
>> >>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>> >>>> Date: Monday, March 24, 2014 at 11:37 AM
>> >>>> To:
>> >>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>> dev
>> >>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>> >>>>
>> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
>> dev@
>> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.Prokharchyk@citrix.com> wrote:
>
>
> On 3/28/14, 3:50 PM, "Marcus" <sh...@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
> ><Al...@citrix.com> wrote:
> >> I will look into it more, Mike. vmWare indeed can be different.
> >>
> >> -Alena.
> >>
> >> From: Mike Tutkowski
> >><mi...@solidfire.com>>
> >> Date: Friday, March 28, 2014 at 11:39 AM
> >> To: Alena Prokharchyk
> >><al...@citrix.com>>
> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> >><de...@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
> >><mi...@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
> >><Al...@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
> >><mi...@solidfire.com>>
> >> Date: Thursday, March 27, 2014 at 9:40 PM
> >> To: Alena Prokharchyk
> >><al...@citrix.com>>
> >> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> >><de...@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
> >><Al...@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"
> >><mi...@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.Prokharchyk@citrix.com<ma...@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.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com
> ><mail
> >>>>to:
> >>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
> >>>> Date: Monday, March 24, 2014 at 11:37 AM
> >>>> To:
> >>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
> dev
> >>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
> >>>>
> >>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
> dev@
> >>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 3/28/14, 3:50 PM, "Marcus" <sh...@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
><Al...@citrix.com> wrote:
>> I will look into it more, Mike. vmWare indeed can be different.
>>
>> -Alena.
>>
>> From: Mike Tutkowski
>><mi...@solidfire.com>>
>> Date: Friday, March 28, 2014 at 11:39 AM
>> To: Alena Prokharchyk
>><al...@citrix.com>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>><de...@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
>><mi...@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
>><Al...@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
>><mi...@solidfire.com>>
>> Date: Thursday, March 27, 2014 at 9:40 PM
>> To: Alena Prokharchyk
>><al...@citrix.com>>
>> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>><de...@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
>><Al...@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"
>><mi...@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.Prokharchyk@citrix.com<ma...@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
>>>><al...@citrix.com><mail
>>>>to:
>>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>>>> Date: Monday, March 24, 2014 at 11:37 AM
>>>> To:
>>>>"dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:dev
>>>>@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>>>>
>>>>dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:dev@
>>>>cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@solidfire.com>
>> o: 303.746.7302
>> Advancing the way the world uses the
>>cloud<http://solidfire.com/solution/overview/?video=play>(tm)
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Marcus <sh...@gmail.com>.
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
<Al...@citrix.com> wrote:
> I will look into it more, Mike. vmWare indeed can be different.
>
> -Alena.
>
> From: Mike Tutkowski <mi...@solidfire.com>>
> Date: Friday, March 28, 2014 at 11:39 AM
> To: Alena Prokharchyk <al...@citrix.com>>
> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <mi...@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 <Al...@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 <mi...@solidfire.com>>
> Date: Thursday, March 27, 2014 at 9:40 PM
> To: Alena Prokharchyk <al...@citrix.com>>
> Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <Al...@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" <mi...@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.Prokharchyk@citrix.com<ma...@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 <al...@citrix.com><mailto:
>>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>>> Date: Monday, March 24, 2014 at 11:37 AM
>>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>>> dev@cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@solidfire.com>
> o: 303.746.7302
> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
I will look into it more, Mike. vmWare indeed can be different.
-Alena.
From: Mike Tutkowski <mi...@solidfire.com>>
Date: Friday, March 28, 2014 at 11:39 AM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <mi...@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 <Al...@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 <mi...@solidfire.com>>
Date: Thursday, March 27, 2014 at 9:40 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <Al...@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" <mi...@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.Prokharchyk@citrix.com<ma...@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 <al...@citrix.com><mailto:
>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>> Date: Monday, March 24, 2014 at 11:37 AM
>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>> dev@cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@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>™
--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.Prokharchyk@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 <mi...@solidfire.com>
>> Date: Thursday, March 27, 2014 at 9:40 PM
>> To: Alena Prokharchyk <al...@citrix.com>
>> Cc: "dev@cloudstack.apache.org" <de...@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.Prokharchyk@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" <mi...@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.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<mailto:
>>> >> alena.prokharchyk@citrix.com>>
>>> >> Date: Monday, March 24, 2014 at 11:37 AM
>>> >> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
>>> >> dev@cloudstack.apache.org<ma...@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<http://solidfire.com/solution/overview/?video=play>
>>> >*(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<http://solidfire.com/solution/overview/?video=play>
>> *(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<http://solidfire.com/solution/overview/?video=play>
> *(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.Prokharchyk@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 <mi...@solidfire.com>
> Date: Thursday, March 27, 2014 at 9:40 PM
> To: Alena Prokharchyk <al...@citrix.com>
> Cc: "dev@cloudstack.apache.org" <de...@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.Prokharchyk@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" <mi...@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.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<mailto:
>> >> alena.prokharchyk@citrix.com>>
>> >> Date: Monday, March 24, 2014 at 11:37 AM
>> >> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
>> >> dev@cloudstack.apache.org<ma...@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<http://solidfire.com/solution/overview/?video=play>
>> >*(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<http://solidfire.com/solution/overview/?video=play>
> *(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
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 <mi...@solidfire.com>>
Date: Thursday, March 27, 2014 at 9:40 PM
To: Alena Prokharchyk <al...@citrix.com>>
Cc: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <Al...@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" <mi...@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.Prokharchyk@citrix.com<ma...@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 <al...@citrix.com><mailto:
>> alena.prokharchyk@citrix.com<ma...@citrix.com>>>
>> Date: Monday, March 24, 2014 at 11:37 AM
>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>" <
>> dev@cloudstack.apache.org<ma...@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<ma...@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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.Prokharchyk@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" <mi...@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.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<mailto:
> >> alena.prokharchyk@citrix.com>>
> >> Date: Monday, March 24, 2014 at 11:37 AM
> >> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> >> dev@cloudstack.apache.org<ma...@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<http://solidfire.com/solution/overview/?video=play>
> >*(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
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" <mi...@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.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<mailto:
>> alena.prokharchyk@citrix.com>>
>> Date: Monday, March 24, 2014 at 11:37 AM
>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
>> dev@cloudstack.apache.org<ma...@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<http://solidfire.com/solution/overview/?video=play>
>*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
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<mailto:
> alena.prokharchyk@citrix.com>>
> Date: Monday, March 24, 2014 at 11:37 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
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 <al...@citrix.com>>
Date: Monday, March 24, 2014 at 11:37 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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.
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 3/24/14, 2:22 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:
>Ideally we would just have bootable and non-bootable disks. You could
>decide if you want to attach them as data disks or as a root disk. This is
>kind of how OpenStack handles this situation.
In the initial implementation I will derive this information - ³bootable²
from the corresponding template/iso object. But you are right, on the API
level I have to return this info to the user. I will do so by introducing
³bootable² param in VolumeResponse.
>
>
>On Mon, Mar 24, 2014 at 3:21 PM, Mike Tutkowski <
>mike.tutkowski@solidfire.com> wrote:
>
>> The trick will be to make sure somehow visually that users understand
>>they
>> can attach a data disk as the root disk of a VM (and that they
>>understand
>> this means its type will change from data disk to root disk).
That would be more of a UI presentation work. I see it being something
like: if UI knows that the Stopped vm has a spare device 0, and the
disk-to-attach is bootable, it should always give user an option first to
attach this disk to the root disk device.
>>
>>
>> On Mon, Mar 24, 2014 at 3:13 PM, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com> wrote:
>>
>>> What is not quite right in CS at the moment - instead of relying on the
>>> device id=0 for determining if the volume is ROOT, we mark the volume
>>>with
>>> type datadisk/root in the DB. Ideally we should be more flexible, and
>>> volume should have no type tight to it as it can be DataDisk or Root
>>>disk
>>> depending on its placement.
>>>
>>> Considering the above, I was planning to implement feature the
>>>following
>>> way:
>>>
>>> 1) Once volume is detached, its type is changed to DataDisk.
>>> 2) Once volume gets attached to the device 0 of the vm, it becomes a
>>>ROOT
>>> disk. If volume gets attached to any other device, its type remains to
>>>be
>>> DataDisk.
>>>
>>>
>>>
>>> On 3/24/14, 11:55 AM, "Marcus" <sh...@gmail.com> wrote:
>>>
>>> >Yes, I think we need a call to change disk type between data and root
>>> >
>>> >On Mon, Mar 24, 2014 at 12:37 PM, Alena Prokharchyk
>>> ><Al...@citrix.com> wrote:
>>> >> 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<http://solidfire.com/solution/overview/?video=play>
>> *(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<http://solidfire.com/solution/overview/?video=play>
>*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
Ideally we would just have bootable and non-bootable disks. You could
decide if you want to attach them as data disks or as a root disk. This is
kind of how OpenStack handles this situation.
On Mon, Mar 24, 2014 at 3:21 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> The trick will be to make sure somehow visually that users understand they
> can attach a data disk as the root disk of a VM (and that they understand
> this means its type will change from data disk to root disk).
>
>
> On Mon, Mar 24, 2014 at 3:13 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
>> What is not quite right in CS at the moment - instead of relying on the
>> device id=0 for determining if the volume is ROOT, we mark the volume with
>> type datadisk/root in the DB. Ideally we should be more flexible, and
>> volume should have no type tight to it as it can be DataDisk or Root disk
>> depending on its placement.
>>
>> Considering the above, I was planning to implement feature the following
>> way:
>>
>> 1) Once volume is detached, its type is changed to DataDisk.
>> 2) Once volume gets attached to the device 0 of the vm, it becomes a ROOT
>> disk. If volume gets attached to any other device, its type remains to be
>> DataDisk.
>>
>>
>>
>> On 3/24/14, 11:55 AM, "Marcus" <sh...@gmail.com> wrote:
>>
>> >Yes, I think we need a call to change disk type between data and root
>> >
>> >On Mon, Mar 24, 2014 at 12:37 PM, Alena Prokharchyk
>> ><Al...@citrix.com> wrote:
>> >> 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<http://solidfire.com/solution/overview/?video=play>
> *(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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
The trick will be to make sure somehow visually that users understand they
can attach a data disk as the root disk of a VM (and that they understand
this means its type will change from data disk to root disk).
On Mon, Mar 24, 2014 at 3:13 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:
> What is not quite right in CS at the moment - instead of relying on the
> device id=0 for determining if the volume is ROOT, we mark the volume with
> type datadisk/root in the DB. Ideally we should be more flexible, and
> volume should have no type tight to it as it can be DataDisk or Root disk
> depending on its placement.
>
> Considering the above, I was planning to implement feature the following
> way:
>
> 1) Once volume is detached, its type is changed to DataDisk.
> 2) Once volume gets attached to the device 0 of the vm, it becomes a ROOT
> disk. If volume gets attached to any other device, its type remains to be
> DataDisk.
>
>
>
> On 3/24/14, 11:55 AM, "Marcus" <sh...@gmail.com> wrote:
>
> >Yes, I think we need a call to change disk type between data and root
> >
> >On Mon, Mar 24, 2014 at 12:37 PM, Alena Prokharchyk
> ><Al...@citrix.com> wrote:
> >> 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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
What is not quite right in CS at the moment - instead of relying on the
device id=0 for determining if the volume is ROOT, we mark the volume with
type datadisk/root in the DB. Ideally we should be more flexible, and
volume should have no type tight to it as it can be DataDisk or Root disk
depending on its placement.
Considering the above, I was planning to implement feature the following
way:
1) Once volume is detached, its type is changed to DataDisk.
2) Once volume gets attached to the device 0 of the vm, it becomes a ROOT
disk. If volume gets attached to any other device, its type remains to be
DataDisk.
On 3/24/14, 11:55 AM, "Marcus" <sh...@gmail.com> wrote:
>Yes, I think we need a call to change disk type between data and root
>
>On Mon, Mar 24, 2014 at 12:37 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>> 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.
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
I would be interested in keeping current with this proposal as it moves
forward as I'll need to make sure whatever we implement here works with
CloudStack-managed storage.
On Mon, Mar 24, 2014 at 12:55 PM, Marcus <sh...@gmail.com> wrote:
> Yes, I think we need a call to change disk type between data and root
>
> On Mon, Mar 24, 2014 at 12:37 PM, Alena Prokharchyk
> <Al...@citrix.com> wrote:
> > 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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Marcus <sh...@gmail.com>.
Yes, I think we need a call to change disk type between data and root
On Mon, Mar 24, 2014 at 12:37 PM, Alena Prokharchyk
<Al...@citrix.com> wrote:
> 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.
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Alena Prokharchyk <Al...@citrix.com>.
Restore vm doesn’t give you the option to pick up the volume you want to
attach. It creates a fresh volume (but from the new template if you wish)
for the existing vm. So its not exactly the same.
On 3/24/14, 12:52 PM, "Nitin Mehta" <Ni...@citrix.com> wrote:
>Hi Alena,
>
>I guess the part 1) can already be taken care of by restoreVirtualMachine
>api - don¹t you think ?
>
>Thanks,
>-Nitin
>
>On 24/03/14 11:37 AM, "Alena Prokharchyk" <Al...@citrix.com>
>wrote:
>
>>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.
>
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Mike Tutkowski <mi...@solidfire.com>.
The part that might be cool to augment for part 1, though, would be to not
delete the old root disk. Then maybe allow it to be turned into a data
disk. That way you could attach it to a VM and maybe investigate what got
corrupted (if anything) to make you want to restore your VM (of course
nothing might have been corrupted and you were just treating this recycle
option as sort of a snapshot).
On Mon, Mar 24, 2014 at 1:52 PM, Nitin Mehta <Ni...@citrix.com> wrote:
> Hi Alena,
>
> I guess the part 1) can already be taken care of by restoreVirtualMachine
> api - don¹t you think ?
>
> Thanks,
> -Nitin
>
> On 24/03/14 11:37 AM, "Alena Prokharchyk" <Al...@citrix.com>
> wrote:
>
> >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<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5
Posted by Nitin Mehta <Ni...@citrix.com>.
Hi Alena,
I guess the part 1) can already be taken care of by restoreVirtualMachine
api - don¹t you think ?
Thanks,
-Nitin
On 24/03/14 11:37 AM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>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.