VMware Aria Automation deployments failing on Allocation Filter error: The Storage Requirements for hosts selection are not satisfied
search cancel

VMware Aria Automation deployments failing on Allocation Filter error: The Storage Requirements for hosts selection are not satisfied

book

Article ID: 322116

calendar_today

Updated On:

Products

VMware Aria Suite

Issue/Introduction

Symptoms:

  • VMware Aria Automation is failing to deploy servers to storage profiles that are not selected as the preferred storage profile.

  • VMware Aria Automation is not able to failover between the created storage profiles.

  • Deployment error: Error Message: No placement exists that satisfies all of the request requirements. See 'Request Details' for more information. Original Task Error: 'Allocation Filter error: The Storage Requirements for hosts selection are not satisfied.'

 



Environment

VMware Aria Automation 8.10.x
VMware Aria Automation 8.11.x
VMware Aria Automation 8.x

Cause

Cloud zones or Cloud Account tags are not inherited by the storage objects as it is explained in the doc Using Capability tags in Cloud Assembly

On lower versions than Aria Automation 8.10 the storage profile inherited tags from compute objects, however, this was not intended and it was corrected on 8.10

Resolution

Add storage constraint tags in the YAML to all the storage objects, even when there is an explicit link between the elements of the deployment.

  • Constraint tags in a Cloud.vSphere.Machine element.

 Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: 'compute:production'  #compute_tags#
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
      storage:
        constraints:
          - tag: 'storage:gold'     
  • Constraint tags in a Cloud.vSphere.Disk element

 Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
      constraints:
       - tag: 'storage:gold'    
 

  Full examples are in the workaround section.


Workaround:

Example 1. Explicit links on Storage Elements.

  1. It is required to create a logic placement based on the OS of the Servers Linux and Windows. In vCenter VC1 the following configuration is present:

  • Linux Compute Cluster connected to a Linux Datastore Cluster.

  • Windows Compute Cluster connected to a Windows Datastore Cluster.

  • Linux Compute Cluster is NOT connected to a Windows Datastore Cluster.

  • Windows Compute Cluster is NOT connected to a Linux Datastore Cluster.

    image.png

  1. In VMware Aria Automation,  there are no Compute Capability Tags on the Cloud Account VC1.

 
Cloud Account NameTags
VC1 
 
  1. There are two cloud zones with the following tags.

Cloud ZoneTags
Windows Clusteros:windows
Linux Clusteros:linux



image.png
  1. There are two Storage Profiles, with the following tags. As the default Storage Profile Windows is selected.

Storage ProfileTagsDefault Storage
VC1-Windowsos: windows-
VC1-Linuxos:linuxYes

kb91411.jpg

 
  1. The capabilities tags are defined in the YAML

  • Linux Cloud Template: One Server with two external disks.

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: 'os:linux'
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
  Cloud_vSphere_Disk_2:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
  Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
  • Windows Cloud Template: One Server with two external disks.

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: 'os:windows'
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
  Cloud_vSphere_Disk_2:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
  Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1


Expected results for example 1.

Having this configuration the following are the expected results:

1. The User requests a Linux VM it will not fail because:

  • VMware Aria Automation will place the VM to the respective Linux cluster based on tags based on the constraint tags specified in the YAML for the Cloud.vSphere.Machine.

  • Since there are no constraints tag in the YAML under properties for Cloud.vSphere.Disk VMware Aria Automation will use the preferred/default storage, in this case is Linux therefore the deployment will not fail. 

image.png


2. The User requests a Windows VM it will fail because:

  • VMware Aria Automation will place the VM to the respective Windows cluster based on tags based on the constraint tags specified in the YAML for the Cloud.vSphere.Machine.

  • Since there are no constraints tag in the YAML under properties for Cloud.vSphere.Disk VMware Aria Automation will use the preferred/default storage, in this case, is Linux therefore the deployment will fail, since the Linux datastore is not connected to the Windows cluster.

image.png
 


Solution for example 1.

  1. As a best practice use different tags for the different resources (network, compute, and storage)  as it is explained in our docs Creating a Tagging Strategy. Therefore, in this example tags are updated considering:

  • Storage profile:  storage:linux      storage:windows

  • Cloud zone:       cluster:linux     cluster windows:

 
Storage ProfileTagsDefault Storage
VC1-Windowsstorage: windows-
VC1-Linuxstorage:linuxYes


image.png
 
Cloud ZoneTags
Windows Clustercluster:windows
Linux Clustercluster:linux

image.png
 
  1. As explained in this article the Storage Tags are not inherited, therefore, it is required to add them as storage constraints.

  • Linux Cloud Template: One Server with two external disks.

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: 'cluster:linux'
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
      storage:
        constraints:
          - tag: 'storage:linux'
  Cloud_vSphere_Disk_2:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
      constraints:
        - tag: 'storage:linux'
  Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
      constraints:
        - tag: 'storage:linux'
  • Windows Cloud Template: One Server with two external disks.
formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: 'cluster:windows'
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
      storage:
        constraints:
          - tag: 'storage:windows'
  Cloud_vSphere_Disk_2:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
      constraints:
        - tag: 'storage:windows'
  Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
      constraints:
        - tag: 'storage:windows'


After adding these Storage constraints tags, deployments will work for Linux and Windows.

 

Example 2. Failover between Storage Profiles  

In this example. a Cluster Production is connected to three different datastores A, B, C. The goal is to be able to use any of the datastores, if for example datastore A is unhealthy VMware Aria Automation should be able to use B or C.

image.png

The cloud zone or cluster has the following tags.
 

Cloud ZoneTags
Productionenv:production


 

As Storage Profiles are created with the following tags:

Storage ProfileTagsDefault Storage
Storage Profile Aenv:productionYes
Storage Profile Benv:production-
Storage Profile Cenv:production-


The YAML is the following:

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: env:production #compute_tags#
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
  Cloud_vSphere_Disk_2:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
  Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1


Expected results for example 2

In this case when a user requests the deployment:

  • VMware Aria Automation will place the Cloud.vSphere.Machine to the production cluster based on the tags.
  • VMware Aria Automation will always place the attached disks to the default storage, since there are no constraints tags in the Cloud.vSphere.Disks sections of the YAML. If the default storage is not available, deployments will fail. Therefore, we are not able to failover between the datastores. 


Solution for example 2.

Since the tags from the compute objects will not propagate to storage objects, we will need to add tags to the storage profile and use add soft tags to the Cloud.vSphere.Disks in the constraint tags of the YAML. 

As a best practice use different tags for the different resources (network, compute, and storage)  as it is explained in our docs Creating a Tagging Strategy. Therefore, in this example, tags are updated considering:

  • Storage profiles:  storage:A storage:B  storage:C

  • Cloud zone:       cluster:production

The cloud zone or cluster has the following tags:
 
Cloud ZoneTags
Productioncluster:production


As Storage Profiles are created with the following tags:
 
Storage ProfileTagsDefault Storage
Storage Profile Astorage:AYes
Storage Profile Bstorage:B-
Storage Profile Cstorage:C-
 

The YAML, we added the constraints tags to the Cloud.vSphere.Disk objects because compute tags are not inhereted by storage objects.

formatVersion: 1
inputs: {}
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-16_04
      cpuCount: 1
      totalMemoryMB: 1024
      constraints:
        - tag: cluster:production #compute_tags#
      attachedDisks:
        - source: ${resource.Cloud_vSphere_Disk_1.id}
        - source: ${resource.Cloud_vSphere_Disk_2.id}
  Cloud_vSphere_Disk_2:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
  Cloud_vSphere_Disk_1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: 1
      constraints:
        - tag: 'storage:A:soft'
        - tag: 'storage:B:soft'
        - tag: 'storage:C:soft'

 

 


Additional Information

Following the upgrade to version 8.18, deployment of virtual machines has encountered issues in certain cases. The error message displayed is:

"No placement exists that satisfies all of the request requirements. Original Task Error: 'Allocation filter error: The storage requirements for host selection are not satisfied.'"

Action Required:

Please verify that Storage DRS is enabled on the datastore clusters where the  VMs are being deployed. This configuration is necessary to ensure that the storage requirements are met and to resolve the placement issues.