The script should be pretty self explanatory. You need to have PowerCLI for vCloud Director installed and be logged in (as tenant or system admin).

$vm variable contains the VM for which you want to open the console. $vrmcPath is the path to the locally installed VMware Remote Console application. Next you need to acquire VM’s MKS ticket and with little manipulation send it to the application as a parameter.

Share this:

Like this:

Some time ago I blogged about how I automate acquisition of Let’s Encrypt Certificates for my lab (NSX + vCloud Director) with PowerShell. The old script no longer works due to some changes on Let’s Encrypt side therefore the need for part 2.

To quickly summarize my situation. My lab consists of vCloud Director with multiple cells fronted by NSX-V Load Balancer. I need public certificate for vCloud Director which is uploaded to the NSX-V Load Balancer (that does L7 SSL termination) and to vCloud Director public addresses.

Prerequisites:

Web server on the domain your are getting the certificate for. It is necessary for the DNS challenge that proves you own the domain you are requesting the certificate for. I am using IIS on the machine I trigger the script from and supply the root folder where the challenge file needs to be placed.

NSX-V API access information – needed to replace the certificate on the NSX-Edge

Details about the load balancer (on which Edge it is running and what is the LB application profile of vCloud Director)

vCloud Director API access information – needed to upload new certificate and the full chain to vCloud Director public addresses.

Share this:

Like this:

Recently one of my customers changed naming convention of vCloud Director Edge Gateways. He renamed them in vCloud Director however the names of virtual machines backing the Edge Gateways stayed the same. Also the names in vShield Manager or NSX Manager did not change. He quickly found out that there is no way to change the name in the GUI of vShield/NSX Manager. This is unfortunate especially for troubleshooting purposes.

Just today I saw the same question internally on our mailing list and the answer is that you can rename the Edge via API. Just GET the particular edge configuration and PUT it back with the changed name. As I recently wrote Powershell scripts that leveraged NSX API I quckly modified it and created two functions – RenameEdgeV5 and RenameEdgeV6.

They both rename the Edge, however only the first one works with vShield Manager. (EDIT 11 June 2015: Unfortunately vShield Manager does not allow renaming of Edges. You will get following error: Edge name cannot be updated. Specified name … does not match … Error code 15013.)

When using NSX Manager you have to use the one that matches the Edge version. The legacy Edges deployed by vCloud Director are version 5. The new NSX Edges are version 6. The API calls to retrieve the Edge info and change it are very similar one uses api 3.0 the other api 4.0.

Share this:

Like this:

NSX Edge Service Gateways are virtual machines deployed by NSX Manager that provide network services (routing, bridging, load balancing, VPNs, DNS relay, DHCP, …). This makes them quite a critical component in the infrastructure and thus there might be a need to keep a close eye on their availability.

While NSX Manager reports the status of the Edges in the GUI and logs it might take some time to register a change in the health. If you want up-to-date status of an Edge health you need to query the NSX Manager with NSX API. The NSX Manager then retrieves the current status of the Edge. The mechanism of the communication between NSX Manager and Edge appliance(s) depends on the Edge version and the vSphere cluster status:

VIX Communication

This is the legacy mode of communication. NSX Manager utilizes VIX API to query vCenter Server and the ESXi Host which runs the Edge appliance who then via VM Tools talks to the actual VM. This mode of communication is used for the legacy Edges version 5.5.x (deployed via the compatibility vShield v2 API) and as failback mode when for some reason Message Bus Communication mode is not possible.

Message Bus Communication

This is direct (and faster) communication between NSX Manager and the ESXi host (vsfwd process) running the Edge appliance. During the Edge deployment the cluster where the Edge is deployed to must be prepared for NSX and without any issues.

source: NSXvSphereDesignGuidev2.1.pdf

To query the Edge health is an expensive operation – it takes time and creates load on NSX Manager. If there is large number of Edges (for example in service provider scenario) this should be considered.

To test the viability of checking at least once in a given time the status of all Edges health I have created simple Powershell function Get-NSXEdgeHealth:

In my lab it took at least cca 2 seconds to get status of an Edge (depending on the mode of communication and its actual health). It is obvious that most time NSX Manager spends on communication with the ESXi host – so the task should and can be parallelized. While running 5 sessions at the same time the retrieval of health status of one Edge went up to 3-4 seconds (for a green Edge) while the load on NSX Manager went up 14 % (I run NSX Manager only with 2 vCPUs in my lab).

While the article mentions only NSX the scripts should work also with vShield / vCloud Networking and Security Manager.