I will look into it more, Mike. vmWare indeed can be different.

-Alena.

From: Mike Tutkowski 
<mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>>
Date: Friday, March 28, 2014 at 11:39 AM
To: Alena Prokharchyk 
<alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
<dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5

VMware is also different because when you shut a VMware VM down from 
CloudStack, the VM still exists in vCenter Server (whereas for XenServer and 
KVM, the VM is gone).

Since the life of a datastore that was created for managed storage is tied to 
the life of the CloudStack volume it stores, when the CloudStack volume is 
deleted, the datastore goes away, as well.

If the datastore in question was automatically created to store a root disk 
(alongside VM config files) and you switch the VM to another root disk (which 
has to necessarily be in another datastore), you won't see a problem until the 
original root volume is expunged by CloudStack. At this point, its datastore 
will go away along with your VM config files.


On Fri, Mar 28, 2014 at 12:31 PM, Mike Tutkowski 
<mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote:
Well, the reason I brought it up was mainly due to VMware.

Let's use that as an example:

I initiate the process of spinning up a VM based on managed storage.
A volume is dynamically created on a SAN.
VmwareStorageProcessor dynamically creates a datastore to consume the newly 
created SAN volume.
All VMware VM files (ex. VMX, NVRAM) are placed in the datastore alongside the 
VMDK file that represents the root volume.

Now, let's say we want to detach this root volume and give the VM a new root 
volume.

The new root volume will necessarily be on a different datastore than the 
datastore of the previous root volume (because a datastore created to consume 
managed storage will have at most one VMDK file*).

Is it going to be a problem that the VM's files (ex. VMX, NVRAM) are on one 
datastore, but its root disk is on another?

I don't think it's really a problem until you go to delete the original root 
volume from CloudStack. At that point, its datastore will be removed 
(including, of course, your VM's VMX, NVRAM, etc. files).

This is not really a problem on XenServer because XenServer does not store VM 
config files in the SR, so I think we're OK there.

We should also be OK for KVM.

* Technically it can have many if those other VMDK files are delta snapshots, 
but they still - together - represent a single disk.


On Fri, Mar 28, 2014 at 10:36 AM, Alena Prokharchyk 
<alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> wrote:
Mike, thank you for the explanation on managed storage.. As far as I understand 
from your email, the main difference is instead of creating an SR on the PS, 
CloudStack will recognize pre-existing volume created outside of the CS. Am I 
correct?

If so, I don’t think there would be any difference. When root volume detach 
happens, no storage attributes – path, clusterId – are being changed. And we 
would apply the same set of checks to the root volume attach, as for a dataDisk 
attach.

-Alena.

From: Mike Tutkowski 
<mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>>
Date: Thursday, March 27, 2014 at 9:40 PM
To: Alena Prokharchyk 
<alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
<dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Subject: Re: [PROPOSAL] ROOT volume detach - feature for CS 4.5

Hi Alena,

I was wondering if you've taken "managed" storage into consideration for this?

If you're unfamiliar with it, managed storage is named as such because 
CloudStack manages it on behalf of the admin (ex. dynamically creating SRs as 
needed).

For example, when I add primary storage to CloudStack that is based on the 
SolidFire SAN, I use the SolidFire plug-in, which is an example of managed 
storage.

In this case, the primary storage represents a SAN as opposed to a preallocated 
volume.

When the time comes to, say, attach a data disk to a VM for the first time, the 
SolidFire plug-in goes off to its SAN and dynamically creates a new volume on 
it (with the appropriate size and IOPS requirements).

CloudStack has logic that recognizes managed storage.

For example, for XenServer, its logic has been augmented to automatically 
create an SR based on the iSCSI target that was created on the SAN and to 
create a VDI within it that is attached to the VM in question.

The big takeaway is that each CloudStack volume here will be associated with a 
unique volume on a SAN and consumed as an SR (XenServer) or datastore (ESX) 
(KVM handles this differently). In this situation, there is a 1:1 mapping 
between a SAN volume and an SR. No other VDIs are stored on the SR except for 
the one representing this one CloudStack volume.

That being the case, I was wondering what you thought of this with regards to 
your root-volume-detach feature?

If we don't want to look into this for 4.5, it might be best to simply fail to 
detach a root volume from a VM if the volume is based on managed storage or to 
fail to attach a bootable volume to a VM if it is based on managed storage.

Talk to you later,
Mike


On Tue, Mar 25, 2014 at 1:24 PM, Alena Prokharchyk 
<alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> wrote:
Mike,

Volume has a template_id referencing vm_template table. Vm_template has
bootable flag, so we will derive information from there.
And sure, this information will not change if the root disk is detached.

On 3/25/14, 12:18 PM, "Mike Tutkowski" 
<mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>>
wrote:

>Hi Alena,
>
>I was wondering how we plan to keep track of the new "bootable" property?
>When we create a VM, would we just mark its root disk as bootable and then
>that property becomes immutable (for the upgrade case, all root disks
>would
>be marked as bootable)?
>
>I'm thinking we'd want to keep track of bootable disks even when there are
>detached and turned into data disks. Is that what you had in mind?
>
>Thanks!
>Mike
>
>
>On Tue, Mar 25, 2014 at 12:20 PM, Alena Prokharchyk <
>alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> wrote:
>
>> Here is the link to the corresponding FS (placed in "4.5 Design
>>documents"
>> section)
>>
>>
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/ROOT+volume+detach
>>
>> -Alena.
>>
>> From: Alena Prokharchyk 
>> <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com><mailto:
>> alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>>>
>> Date: Monday, March 24, 2014 at 11:37 AM
>> To: 
>> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>"
>>  <
>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>>
>> Subject: [PROPOSAL] ROOT volume detach - feature for CS 4.5
>>
>> I would like to propose a new feature for CS 4.5 - "ROOT volume detach"
>>-
>> that enables support for following use cases:
>>
>> 1) Replace current ROOT volume with the new one for  existing vm.
>> 2) Case when ROOT volume of vm1 gets corrupted, and you want to attach
>>it
>> to vm2 to run the recovery utils on it. With current CS implemntation,
>>you
>> have to perform several steps - create snapshot of vm1's volume, create
>> volume from snapshot, attach volume to the vm2. New implementation will
>> merge it all to one step.
>>
>>
>> With the planned implementation, once the ROOT volume is detached, it
>>can
>> be attached to any existing vm (with respect to Admin/Domain/Physical
>> resources limitations), either as a DataDisk or a Root disk.
>>
>> Amazon EC2 already has this functionality in place, so I think CS would
>> only benefit from having it. Storage experts (Edison, others) please
>>raise
>> your concerns if you have any, or if you see any potential problems with
>> the planned implementation. And if anyone can think of other use cases
>>this
>> feature can possible solve, I would appreciate this input as well.
>>
>>
>> Feature limitations:
>>
>> * ROOT volume can be detached only when vm is in Stopped state
>> * CS will fail to start the vm not having a ROOT volume
>>
>> I will send out the link to the FS once I start getting feedback on the
>> proposal.
>>
>> -Alena.
>>
>
>
>
>--
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>
>o: 303.746.7302<tel:303.746.7302>
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*




--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>
o: 303.746.7302<tel:303.746.7302>
Advancing the way the world uses the 
cloud<http://solidfire.com/solution/overview/?video=play>™



--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>
o: 303.746.7302<tel:303.746.7302>
Advancing the way the world uses the 
cloud<http://solidfire.com/solution/overview/?video=play>™



--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the 
cloud<http://solidfire.com/solution/overview/?video=play>™

Reply via email to