From time to time a host may be unmanageable from vCenter / web client or you may only have console access. In my case I was bringing up a Dell EMC VxRail. During initial bringup the ESXi hosts do not get a mgmt IP if you do not have DHCP available so management with the web client is not possible. I do have iDRAC access though so can access the console. I needed to see where the VxRail manager VM was running as it comes up during an election process between the hosts. With console access it is still possible to manage VMs using esxcli.
To discover all VMs on a host run the following
Once you have the output you can use the Vmid to manipulate the powerstate of a VM
- vim-cmd vmsvc/power.get 2
In my case the VM i wanted was powered off. You can run the following to power it on
And there you have it. Simple VM management using vim-cmd. Explore what else you can leverage it for here
We’ve all been there…attempt to open an RDP session to a VM you haven’t connected to in a while and you see the message above! Traditionally the fix for this was to log on as a local admin user, remove the VM from the AD domain (add to workgroup), reboot, log in again, add to AD domain, reboot….well here is a quicker way of resolving the issue with PowerShell.
Modify the username, password and domain controller FQDN and save the following as ResetDomainMembership.ps1 and run on the affected VM as a local administrator
$password = "Password123!" | ConvertTo-SecureString -asPlainText -Force
$username = "domain\administrator"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Reset-ComputerMachinePassword -Server dc01.domain.local -credential $credential
shutdown -r -t 0
Tip: If you dont want to include the password in the script as this is a security concern you can use a Read-Host command to prompt the user for the password
$password = Read-Host -asSecureString "Please enter the password"
From time to time a request in vRA will fail for whatever reason. When this happens you will see the request status as failed on the requests tab. There is a greyed out delete button that for whatever reason cannot be used to delete the failed request even when logged in as a full tenant/iaas/cloud admin.
There are several reasons you may want to remove failed requests…maybe you may need to deliver a demo to the CIO on some new functionality and failures in the UI never look good…or maybe you just have mild OCD like me and like to cleanup any failures to restore the illusion of all being good with the world! 🙂 Whatever your reasons here is a procedure that you can use.
Disclaimer: I dont believe this procedure if fully supported by VMware so please proceed with caution.
- SSH to your primary vRA appliance
- Run the following to view the contents of /etc/vcac/server.xml
- less /etc/vcac/server.xml
- Look for the line with password= and copy everything between the “”. This password will allow you to connect to the vRA PostGres DB
- Run the following command with the password from the above step
- vcac-config prop-util -d –p “s2enc~K6RsAv5WGpoAt+qsnZPrKErxZ0kU1npeK/G5iMzyaWI=”
- Next change to the postgres user
- Change to the postgres directory
- cd /opt/vmware/vpostgres/current/bin
- Connect to the vcac database
- Enter the password from server.xml
- vRA requests are store in the cat_request table. To enable us to delete a request we first need the request id. Query the cat_request table for your request ID using the requestnumber (In my case the offending failed requestnumber is 63, as seen in the first column in the screenshot above. replace with your requestnumber)
- SELECT id,requestnumber FROM cat_request where requestnumber = ’63’;
vRA XaaS blueprint requests are referenced in 1 further table, cat_requestevent. This entriy must be deleted before you can delete the request.
- Run the following commands to delete the request.
- delete from cat_requestevent where request_id =’4dc74fc2-f855-4eb1-94d6-65481b702acd’;
- delete from cat_request where id =’4dc74fc2-f855-4eb1-94d6-65481b702acd’;
The offending failed request should now be gone from the requests list in vRA!
I’ve been playing around with Dell EMC RP4VM & vRA and needed to setup cross vCenter NSX in my lab. I’m not going to go into that setup as there are many blogs on the subject. What i will cover is an error i hit when trying to do Network and Security Inventory data collections on one of my NSX endpoints. The error from the Dem logs in vRA (Infrastructure > Monitoring > Log ) was as follows:
Workflow 'vSphereVCNSInventory' failed with the following exception:
'object' does not contain a definition for 'clusters'
After digging around for VMware KBs and blogs on the subject and coming up empty handed i went back to review my entire setup and discovered i had missed adding a vCenter cluster to the universal transport zone on the offending NSX endpoint, which is my DR site.
Once i rectified this the Network and Security Inventory Data Collection worked as expected.