Following scenarios are not allowed in case local storage is disabled on zone:
-Creation of volume (new or from snapshot) with local disk offering.
-Attach/reattach of volume with local disk offering.
Reviewed-by: Nitin
Using migrateVolumes method which does not perform input validation. Some input validation in the migrateVolume method prevented migration of volume in READY state. Also using volume disk offering to check if it is a local or shared one.
Reviewed-by: Nitin
- Zone level config to enable/disable local storage usage for service and disk offerings.
- Local storage gets discovered when a host is added/reconnected if zone level config is enabled. When disabled existing local storages are not removed but any new local storage is not added.
- Deploy VM command validates service and disk offerings based on local storage config.
- Upgrade uses the global config 'use.local.storage' to set the zone level config for local storage.
Reviewed-by: Abhi, Nitin
Following changes are made:
- 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/delete of data volume on local storage
- Attach/detach for local data volumes. Re-attach is allowed as long as vm host and data volume storage pool host is same.
- Migration of VM instance is not supported if it uses local root or data volumes.
- Migrate is not supported for local volumes.
Reviewed-by: Abhi
Issue happens when ROOT volume gets created and there is subsequent failure in starting the VM. During retry if allocator assigns a different storage pool the scenario was not handled. Now in case of local storage the volume get recreated on the newly assigned pool and old one gets cleaned up. In case of shared storage the existing volume is migrated to new storage pool.
Reviewed-by: Prachi, Edison, Nitin
2) added "tags" request parameter to the banch of list* Api commands (listVirtualMachines, listSnapshots - all commands are listed in the resource tags functional spec)
UploadVolume API is async now with the guidance for all the new apis added in 3.0.x need to be async. Though the success/failure wont be available through the queryAsync job which will report only the initial validation success or failure. The success or failure and the progress will all be available through listVolumes api.
Admin can either configure system.vm.default.hypervisor which is a global configuration for all zones, or call updatezone add defaultSystemVMHypervisorType
status 12139: resolved fixed
Edison Su
Koushik Das
kishan
Alena Prokharchyk
Nitin Mehta
Vijayendra Bhamidipati
anthony
frank
Sheng Yang
Jessica Wang
Kelven Yang
Edison Su
Abhinandan Prateek