Skip to end of metadata
Go to start of metadata

Introduction

"ROOT volume detach" feature 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. 

References

JIRA ticket: 

JIRA Issues Macro: Unable to locate JIRA server for this macro. It may be due to Application Link configuration.

 

Architecture and design description

Changes has to be done on the Services layer to attach/detach methods.

  1. Volume Detach changes

VolumeApiServiceImpl class, orchestrateDetachVolumeFromVM method:

  • should be changed to allow Root volume detach, but only for vm is in Stopped state

VolumeDaoImpl class, detachVolume method:

  • should change the volume type from Root to DataDisk if the Root volume gets detached

 

2. Volume attach changes

VolumeApiServiceImpl class, attachVolumeToVM method:

  • allow deviceId=0 to be passed in for vm in Stopped state not having any ROOT volume attached

 

VolumeDaoImpl class, attachVolume method:

  • change type from DataDisk to Root if the volume gets attached with deviceId=0

Web API changes

  • No new Apis are added
  • New parameter "bootable" is added to VolumeResponse
  • AttachVolume - allow deviceId to be 0

UI changes

  • UI should be changed so it allows Root volume detach for the vm in Stopped state, and Root volume attach to the vm in Stopped state.
  • For a Stopped vm, UI should always check if there is a root volume attached to the vm. If not, it should always propose to attach volume as a root first

 

Feature limitations for 4.5 release

  • Feature is not supported for Managed data stores
  • Feature is supported only for primary storage created in the cluster of type KVM/VmWare/Xen
  • If vm was originally created with hypervisor type KVM, new Root volume that you attach to the vm, should have hypervisor type KVM as well.
  • No labels