Skip to main content

 

IP Allocation failure during onboarding


Issue/Introduction

Symptoms:
  • When Onboarding a virtual machine, the IP Address allocation phase is skipped
  • When attempting to deploy a new VM from vRA, an IP conflict occurs with a previous onboarded VM


Environment

VMware vRealize Automation 8.x

Cause

IP conflict occurs because the onboarded VM's IP address was not allocated within vRA.

Resolution

VMware is aware of this issue.

In order to avoid IP conflicts in vRA, follow the steps below before onboarding VMs.

Important: The Prerequisites before onboarding are required even when there are no IP conflicts in the environment.


Workaround:

    Note: To query for allocated IP Addresses, run the following API query

    https://vRAFQDN/provisioning/uerp/resources/ip-addresses?expand=true&$filter=(ipAddress eq 'IPADDRESS') and (ipAddressStatus eq 'ALLOCATED')

    Where IPADDRESS is italicized and is required to be updated with the IP Address you wish to check for.

    New provisioned VMs with IP Conflicts

    In case you have new provisioned VMs with IP conflict before applying the workaround follow the next steps. 
    • Delete the newly provisioned VM
    • Release the IP
    • Ensure IP Address is in ‘Available’ status (To verify in: Infrastructure > Resources > Networks > IP Addresses)
    • Unregister the previously onboarded VM 
    • Delete the deployment whose resources were unregistered. To perform this operation only after ensuring VMs were successfully unregistered and back in ‘Discovered’ state. Discovered state can be verified under Virtual Machines tab.

    If you do not have any IP conflicts proceed with the following steps.

    Prerequisites before onboarding

    1. Ensure an address of the discovered VM is data collected: Cloud Assembly Resources > Virtual Machines Address 
    2. Create a valid subnetRange if you have not already done so: Infrastructure > Resources > Networks > IP Ranges        Note: when a vSphere cloud account is associated with an NSX instance then subnets need to be created in vRA for NSX networks for allocation to succeed during onboarding.
    3. In case of external IPAM onboarding, in addition to the above, add the below custom properties to the VM before executing the onboarding plan
      __Infoblox.IPAM.Migration.ExtensibilityKey
      
      __IPAM.Migration.ExtensibilityKey 
      whose values are the resourceIds of the VM
    Note: A ResouceId can be found and retrieved from Infoblox under the extensible attributes similar to the screenshot provided.
    Note: This step will ensure the deallocate IP to Infoblox occurs when the VM is deleted in vRA.image.png
    1. Add the discovered VM to the onboarding plan and run it. Network should be onboarded and IP should become allocated.
    2. Verify the IP is now allocated: Infrastructure > Resources > Networks > IP Addresses

    Additional Information

    Impact/Risks:
    This can lead to IP conflicts on your network when provisioning new virtual machines.

    Comments

    Popular posts from this blog

      Issue with Aria Automation Custom form Multi Value Picker and Data Grid https://knowledge.broadcom.com/external/article?articleNumber=345960 Products VMware Aria Suite Issue/Introduction Symptoms: Getting  error " Expected Type String but was Object ", w hen trying to use Complex Types in MultiValue Picker on the Aria for Automation Custom Form. Environment VMware vRealize Automation 8.x Cause This issue has been identified where the problem appears when a single column Multi Value Picker or Data Grid is used. Resolution This is a known issue. There is a workaround.  Workaround: As a workaround, try adding one empty column in the Multivalue picker without filling the options. So we can add one more column without filling the value which will be hidden(there is a button in the designer page that will hide the column). This way the end user will receive the same view.  

    57 Tips Every Admin Should Know

    Active Directory 1. To quickly list all the groups in your domain, with members, run this command: dsquery group -limit 0 | dsget group -members –expand 2. To find all users whose accounts are set to have a non-expiring password, run this command: dsquery * domainroot -filter “(&(objectcategory=person)(objectclass=user)(lockoutTime=*))” -limit 0 3. To list all the FSMO role holders in your forest, run this command: netdom query fsmo 4. To refresh group policy settings, run this command: gpupdate 5. To check Active Directory replication on a domain controller, run this command: repadmin /replsummary 6. To force replication from a domain controller without having to go through to Active Directory Sites and Services, run this command: repadmin /syncall 7. To see what server authenticated you (or if you logged on with cached credentials) you can run either of these commands: set l echo %logonserver% 8. To see what account you are logged on as, run this command: ...
      The Guardrails of Automation VMware Cloud Foundation (VCF) 9.0 has redefined private cloud automation. With full-stack automation powered by Ansible and orchestrated through vRealize Orchestrator (vRO), and version-controlled deployments driven by GitOps and CI/CD pipelines, teams can build infrastructure faster than ever. But automation without guardrails is a recipe for risk Enter RBAC and policy enforcement. This third and final installment in our automation series focuses on how to secure and govern multi-tenant environments in VCF 9.0 with role-based access control (RBAC) and layered identity management. VCF’s IAM Foundation VCF 9.x integrates tightly with enterprise identity providers, enabling organizations to define and assign roles using existing Active Directory (AD) groups. With its persona-based access model, administrators can enforce strict boundaries across compute, storage, and networking resources: Personas : Global Admin, Tenant Admin, Contributor, Viewer Projec...