Bug Reference

The Jira issue associated with this design spec

Branch

What branch is this work being done in

Introduction

Currently CS exposes the ability to select storage type (shared or local) for deploying system VMs as a global configuration. This is fine for a single zone deployment. But once additional zones are added, it is not possible to configure it individually for each zone. This is a major limitation as system VMs across all zones always have to run either on shared storage or local storage based on the global configuration. System VMs are associated with a zone in CS and it would be useful to have the ability to configure storage type for system VMs for each zone.

Purpose

Purpose of this document is present the functional requirements and design aspects of how the functionality will be achieved. 

References

1. Adding a global config - configurable at different scopes
2. Configuration

Document History

Glossary

CS - Cloudstack

MS - Management server

System VMs - Refer to the set of VMs that are auto-deployed by CS to provide various services. These include SSVM, CPVM, virtual router, internal LB VM and elastic LB VM.

Administrator - CS root administrator

HV - Hypervisor host

Use cases

1. Ability to configure storage type (shared or local) for deploying system VMs on a per zone basis by administrator.

Functional Requirements

1. Change the scope of configuration parameter 'system.vm.use.local.storage' from global to zone.
2. Auto-discover local storage associated with HV host based on the above configuration during 'add host' operation by administrator.
3. Create default system compute offerings for each system VM type - one with shared storage and another with local storage - during MS startup if not already present.
4. Deploy system VMs using default system offering (selected based on the above configuration) if none specified explicitly.
5. Changing configuration won't have any impact on existing system VMs, only newly created VMs will be impacted.

Changes

1. The scope of existing global configuration 'system.vm.use.local.storage' will be changed to 'zone' based on references [ 1 ] & [ 2 ]. With this change the configuration will be available both at zone and global level.
2. There will be 2 default system service offerings - using shared and local storage - created for each system VM type. The unique name and description of these settings will be appropriately set based on the storage type. The local offering will have "-Local" appended to its unique name (for e.g. the unique name for SSVM shared and local compute offerings will be "Cloud.com-SecondaryStorage" and "Cloud.com-SecondaryStorage-Local" respectively). The appropriate offering will be selected based on unique name during system VM deployment.
   1. These offerings will be automatically created in CS DB at the time of MS startup if not already present.
   2. For new setup both shared and local will be created.
   3. For upgraded setup, existing offering will be checked and updated with the correct unique name based on the storage type (shared or local). Based on the existing offering, the other offering (shared or local) will be created.
3. For some system VMs, offering can be explicitly specified using global configuration. The following precedence rule will be followed for selecting system offering
   1. Explicitly specified offering if any through global configuration. For SSVM there is a global configuration 'secstorage.service.offering' to explicitly specify offering, for CPVM it is 'consoleproxy.service.offering', for internal LB VM it is 'internallbvm.service.offering'. These offerings can use either shared or local storage irrespective of the storage type specified for the zone (using system.vm.use.local.storage). For remaining system VMs there is no explicit configuration.
   2. If the above settings are not specified then system offering is picked based on zone level configuration 'system.vm.use.local.storage'.
   3. Otherwise fallback on global configuration 'system.vm.use.local.storage'.
4. During any system VM deployment, appropriate offering will be picked up based on #3.
5. Existing system VMs will continue to use old offering unless explicitly re-created after changing the configuration.
6. If either 'system.vm.use.local.storage' or zone property "use local storage for user VMs" is set to true then local storage associated with HV host gets discovered and added as a primary storage. For newly added host this happens at the time of "add host" operation. For existing hosts MS restart is required for local storage to get discovered and added.

API changes

None

DB changes

None

Upgrade

None

UI changes

1. Zone configuration wizard (creating a zone for the first time) needs to be updated to allow specifying this setting.
2. Current UI already has the ability to display and edit configuration parameters with zone scope, so no change required.