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.prokharc...@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" <shadow...@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 > ><alena.prokharc...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
