A cloud account region contains storage profiles that let the cloud administrator define storage for the region in vRealize Automation.
What does a storage profile do
Storage profiles include disk customizations, and a means to identify the type of storage by capability tags. Tags are then matched against provisioning service request constraints to create the desired storage at deployment time.
Storage profiles are organized under cloud-specific regions. One cloud account might have multiple regions, with multiple storage profiles under each.
Vendor-independent placement is possible. For example, you might have three different vendor accounts and a region in each. Each region includes a storage profile that is capability tagged as fast. At provisioning time, a request containing a fast hard constraint tag looks for a matching fast capability, regardless of which vendor cloud is supplying the resources. A match then applies the settings from the associated storage profile during creation of the deployed storage item.
Capability tags that you add to storage profiles should not identify actual resource targets. Instead, they describe types of storage. For more about actual resources, see Storage resources in vRealize Automation.
Default provisioning type
The storage profile provisioning type only establishes a default behavior. The setting doesn't necessarily affect placement and might be overridden by a property in the cloud template.
For example, you might set the storage profile for thin provisioning. In most cases, requests would create thin provisioning storage by default. However, if the cloud template has the provisioningType
property set to eager-zero, the cloud template overrides the default of thin.
For the provisioning type default, a cloud template property overrides a storage profile default, and a storage profile default overrides a default from a vCenter storage policy.
Disk allocation with machines
In a project with multiple cloud zones that belong to different cloud accounts, a disk follows the machine even if the disk isn't attached to the machine. This behavior keeps the resources together to prevent failure when you decide to attach the disk later.
For example, the following design won't work. The cloud template attempts to use location constraints to separate the disk, but the deployment returns a No matching placement
error instead.
If you need to place a disk in a different cloud account, use a separate deployment to deploy the disk.
resources: Machine1: type: Cloud.vSphere.Machine properties: image: ubuntu flavor: small constraints: - tag: 'location:siteA' Disk1: type: Cloud.vSphere.Disk properties: capacityGb: 1 constraints: - tag: 'location:siteB'
First class and standard disks
By using the Disk type option on the storage profile page, or by using the vRealize Automation API, you can create a storage profile to support first class disk (FCD) or standard disk storage. In effect, the first class disk option creates a vSphere storage profile.
- First class disk
First class disks can exist independent from a vSphere virtual machine. A first class disk also has life-cycle management capabilities that can operate independently of a virtual machine. First class disks are available for vSphere 6.7 Update 2 and later, and are currently implemented in vRealize Automation as an API-only feature.
For information about FCD storage, including the capabilities that are available from the vRealize Automation API, and links to the API documentation itself, see What can I do with first class disk storage in vRealize Automation.
- Standard disk
Standard disk storage is created and managed as an integrated component of a virtual machine.
For information about standard disk storage, see What can I do with standard disk storage in vRealize Automation and What can I do with persistent disk storage in vRealize Automation.
Azure server-side disk encryption
For Azure resources, if you elect to support encryption in a managed disk storage profile, you also select disk encryption that has an associated key. Available encryption and keys correspond to the disk encryption sets configured in Azure for the location.