Issue
New OVA appliance deployment fails with the following error message:
Failed to deploy OVF package. ThrowableProxy.cause A general system error occurred: Transfer failed: Invalid response code: 407, note that HTTP/s proxy is configured for the transfer.
Solution
Check if the vCenter side proxy is set.
That's it.
Issue
Recently I had to create a script that periodically take a snapshot of the current situation regarding the list of Virtual Machines and the associated NSX Security Tags, via rest API calls.
To do this, I had to create some lines of code. Let's see below, the call to get the list of VMs and how it works....
Solution
The script must run on an Ubuntu machine, so I decided to make a bash script and use cURL.
Information regarding api call, can be found at the following link https://developer.vmware.com/apis
More specific information regarding NSX, can be found here.
Our call to retrieve informations, looks like this:
curl -sk -u username:password -X GET 'https://{nsx_manager}/policy/api/v1/infra/realized-state/virtual-machines' > vms-all.json
... and from terminal using the "jq" command (with the options "-r '.results[]' ") ...
jq -r ' .results[]' vms-all.json... the output is as below ...
jq -r ' .results[] | select(.display_name=="db-01a") ' vms-all.json
jq -r ' .results[] | select(.display_name=="db-01a") | .tags' vms-all.json
jq -c ' .results[] | [.display_name, .tags]" vms-all.json | wc -l
jq -c ' .results[] | [.display_name, .tags]' vms-all.json
That's it.
Issue
One month ago, I came across this. After a disaster recovery test performed via SRM, we encountered the following error "Reduced availability without rebuild" for 27 objects, we tried to click "repair object immediately" without success.
There are no resync objects in progress.
The source and target infrastructure consists of two VCF 5.X environment based on vSAN file system, where Site Recovery Manager is used to replicate VMs.
This issue reduce the Health score rate to 60%.
Solution
We have been able to solved the issue performing the following steps:
Short Answer
That's it.
Issue
After updating my macOS to Sonoma 14.4.1 (23E224) I can no longer connect to Windows machines via "Microsoft Remote Desktop" version 10.9.6 (2188).
I click on the remote connection, and then "Continue" as usual....
Solution
Open the connection, then click "Show certificate" and expand "Trust"
That's it.
Issue
Recently I had to create a script that grab some information from vCenter Server via Rest API calls. To do so, I had to create a few lines of code to authenticate on the vCenter, obtain a sessions and the c. Let's see bellow how does it works ....
Solution
The script must run on an Ubuntu machine, so I decided to make a bash script and use cURL.
Information regarding api call, can be found at the following link https://developer.vmware.com/apis
More specific information regarding, for example, how to list the VMs already present on the inventory, can be found here.
First of all we have to create a session with the API. This is the equivalent of login. This operation exchanges user credentials supplied in the security context for a session token that is to be used for authenticating subsequent calls. To authenticate subsequent calls clients are expected to include the session token. For REST API calls the HTTP vmware-api-session-id header field should be used for this.
The call looks like this:
curl -sk -u username:password -X POST https://{vCenter}/api/session
The authentication, can be also be passed in a Base64 encoded value of username:password as header parameter, like this:
echo -n 'username:password' | base64in a single line of code:
curl -ks -H "Authorization: Basic `echo -n 'username:password' | base64`" -X POST https://{vCenter}/api/session
#!/bin/bash
VC=192.168.1.90
ADMIN=administrator@vsphere.local
PASSWORD=VMware1!
Session_ID=`curl -sk -u ${ADMIN}:${PASSWORD} -X POST https://${VC}/api/session`
# Request sent through session ID
curl -ks -H "vmware-api-session-id: ${Session_ID:1:-1}" https://${VC}/api/vcenter/vm
That's it.
Issue
Working within a LAB and/or in a nested environment often requires the deployment a Windows Server Machines (for instance, for a local services such as Active Directory, DNS, NTP and so on).
It may happen that the tests have not been completed, but the Windows trial period has expired.
Below I'm reporting few steps to extend the Windows Trial Period for other 180 days.
Solution
It is possible to "rearm" MS Windows (in my case Server 2022), extending the Trial Period of 180 days for 6 times each time. Let's see how to do that ...
Taking a look at the desktop, we can see the countdown in the corner down right. In my case, the period is expired.
That's it.