This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.
Cloudstack provides a mechanism to put a marker on the hosts and storage pools called a tag. The users can create disk offering and service offering which can be forced to use these tagged resources by the use of these named handles. For example you can have a premium storage pool and a regular storage pool, by use of tags you can have a premium disk offering always allocated on the premium pool and the regular one going to the regular storage pool. Similarly by using tages you can force some VMs to run on certain hosts.
When storage or host tags are added to a resource, those tags are comma-delimited without any spaces. Example: A host tag is entered on the hypervisor host or template - "tag1,tag2".
The deployment planner while creating VM with a host tagged service offering will be looking for a host with the similar tag. For creating disks, using offering with a storage tag, will be created on the appropriately tagged storage. In case the match is not found the planner will fail. The VM disks (including root) should be in the PS pool which is configured for the cluster where the VM host is ie for a successful deployment the tags for both disk and service offering should match up with resources in one cluster. No tags specified in offering act as a wildcard tag. If there is a tag the algorithm does a full match, no match or partial match results in failure. There is nothing called affinity for tags like the best partial match. A offering tags have to be subset of the resource tags for it to be considered by the planner.
If offerings are tagged, then only the host with matching tag will be chosen. But while deploying a VM with a non-tagged service offering, we consider both untagged and tagged hosts. So a VM with non-tagged offering may reside on a tagged host. Same goes with storagepools.