Introduction

Purpose

The requirement is to support creation of data volumes on local storage (disks associated to hosts). Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency, cost reduction from using inexpensive local disks.

References

Document History

Glossary

Use cases

  • Creating data disk offering for local storage
  • Creating vm instance with local data volume
  • Creating/deleting local data volume
  • Attaching/detaching local data volume to/from an existing vm instance
  • Re-attaching local data volume to a different vm instance
  • Enabling/disabling local storage offering for a zone

Feature Specifications

What is already supported on local storage?
- System VMs
- User VMs (only with root volume on local storage)

Features that need to be supported
- Create/delete data volume on local storage
- Attach/detach data volume on local storage
- Disk offering leveraging local storage
- Number of local data volumes that can be attached. Currently there is a limit (13 for XS 6.0 and above, 6 for other HVs) on the number of volumes that can be attached to a VM 

Placement constraints
- Data volume on local storage should be created on on same hypervisor host as the VM instance.

Root and data disk combinations
- Local root + Local data. This is the primary scenario that needs to be enabled
- Shared root + Local data. This combination will not be blocked explicitly but I cannot think of any use case for this
- Local root + Shared data. This is already supported
- Shared root + Shared data. This is already supported 

VM deletion
- Currently shared data volumes of a VM gets detached when a VM is deleted. The same will hold for local data volumes as well.

VM migration
- Currently VMs with local root volume cannot be migrated. The same will hold for local data volumes as well i.e. migration is not allowed if a VM has either local root and/or data volumes.

Data disk migration
- Migration of local data volumes will not be supported

Snapshot
- Same as root/shared data volumes

Maintenance mode
- Currently VMs with local root volume needs to be stopped before a host can be put to maintenance. The same will hold for local data volumes as well

Zone level config for enabling local storage
- Currently local storage offering is at the cloud level. The idea is to have a zone level setting for enabling local storage offering for both compute and disk. If local storage is not enabled then VMs cannot be created using compute/disk offering leveraging local storage in that zone.

Hypervisor support
- XenServer, Vmware, KVM.

Architecture and Design description

API changes

  • Migration of VM instance is not supported if it uses local root or data volumes. migrateVirtualMachine now throws InvalidParameterValueException for local data volumes.
  • Migrate volume is not supported for local volumes. migrateVolume now throws InvalidParameterValueException for local volumes.
  • Attach/detach volume now supported for local volumes. attach/detachVolume no longer throws for local volume. Re-attach of volume is also allowed on a different vm instance similar to shared data volumes.
  • Create disk offering API now takes an extra parameter to denote storage type (local or shared). This is similar to storage type in service offering.
  • Create/update zone now takes an additional parameter for enabling local storage offering.
  • Deploy VM will now check if the compute and disk offering is as per the local storage offering that is set at zone level.

Database changes

disk_offering table already has a flag denoting if local storage needs to be used. So no changes is required for this.

data_center table needs to have an additional column (name: is_local_storage_enabled; type: tinyint; values: 0-disabled, 1-enabled) for local storage offering configuration. For new scenarios this is set to 0; for upgrade scenarios this will be set based on use.local.storage config value (see below).

ALTER TABLE `cloud`.`data_center` ADD COLUMN `is_local_storage_enabled` tinyint NOT NULL DEFAULT 0 COMMENT 'Is local storage offering enabled for this data center; 1: enabled, 0: not';
UPDATE `cloud`.`data_center` SET `is_local_storage_enabled` = IF ((SELECT `value` FROM `cloud`.`configuration` WHERE `name`='use.local.storage')='true', 1, 0) WHERE `removed` IS NULL;

Allocator changes

Local storage pool allocator is modified to take into account only local storage pools from host where vm instance is placed while allocating a local data volume. Allocation logic for shared volumes remains unchanged.

Updating local storage offering

Local storage offering will be editable. All subsequent VM deployments will take into account the updated config. Note there may be a situation where the zone had initially VMs with local storage volumes but later on the config got updated to disable local storage offering.

UI flow

  • Create disk offering with local storage option
  • Create instance with both local storage for both ROOT and DATA disks
  • Create/delete of volume with local storage offering
  • Attach for local volume should be enabled only if there is a host with VM running (host name should be displayed as label)
  • Detach of local volume needs to be allowed
  • Setting zone level config for enabling local storage

Appendix

Appendix A:

Hack for creating data disk (in existing code)
- Create a VM with local ROOT disk
- Take a snapshot of this
- Create a volume from the snapshot, this is created on the local storage

Appendix B:

Questions
- What happens when a VM with local data disk is deleted? Should the data disk gets cleaned up? In ec2 gets cleaned up. In CS for shared data disk it gets detached
- Detach/attach of local disk. Once attached to an instance should we allow re-attach to another VM instance (ec2 doesn't)?

  • No labels