Search Results for: vmc

Automated deployment and setup of vRealize Network Insight (vRNI)

12.20.2016 by William Lam // 8 Comments

Earlier last week I had deployed the latest version of vRealize Network Insight (vRNI) 3.2 in my home lab to learn more about the product and its capabilities. The vRNI setup involves involves deploying two Virtual Machines, the first being the main vRNI Platform OVA. Once the vRNI Platform VM has been deployed, you will need to activate it with a license key and then generate a shared secret which is then used to deploy the vRNI Proxy OVA. Using the share secret, the vRNI Platform VM will be able to automatically detect when the vRNI Proxy VM is on the network and associate it with the deployment.

The workflow is pretty straight forward but as many of you know me, if I need to manually do something once, it means I should probably automate it for the future 🙂 I had looked around the documentation and did not see any published APIs for the initial setup and configuration. Although a CLI exists, it was only available post-deployment and it required SSH which I did not want to have to rely upon. I ended up reverse engineering the UI to replicate the workflow from an automation standpoint. I created a small PowerCLI script called vRNI-Deploy.ps1 and below are the instructions on using the script.

Step 0 - Obtain a vRNI License Key, which is required to setup vRNI. You may need to work with your VMware Account team or contact VMware Sales to get an evaluation license key.

Step 1 - Download both the vRNI 3.2 Platform and Proxy OVA from here.

Step 2 - Download the vRNI-Deploy.ps1 script to a system that has the latest release of PowerCLI 6.5 R1 installed.

Step 3 - Edit the following sections of the script which you can find more details below:

The full path to both the vRNI Platform and Proxy OVAs:

$vRNIPlatformOVA
$vRNIProxyOVA

The vRNI License Key:

$vRNILicenseKey

The configuration of the vRNI Platform VM:

$vRNIPlatformVMName
$vRNIPlatformIPAddress
$vRNIPlatformNetmask
$vRNIPlatformGateway

The configuration of the vRNI Proxy VM:

$vRNIProxyVMName
$vRNIProxyIPAddress
$vRNIProxyNetmask
$vRNIProxyGateway

General deployment configuration for both VMs:

$DeploymentSize
$DNS
$DNSDomain
$NTPServer
$VMCluster
$VMDatastore
$VMNetwork

Note: The medium (smallest) deployment requires at least 42GB of memory (32GB reserved for Platform VM and 10GB reserved for the Proxy VM). Please ensure you have sufficient resources before deploying into your environment.

[Read more...]

Using the vSphere API to remotely collect ESXi configuration file (esx.conf)

06.23.2016 by William Lam // 9 Comments

Last week we took a look at two new Automated solutions here and here that allows us to leverage vCenter Server and the vSphere APIs to remotely extract information that historically required logging in directly into an ESXi host. While working on the two scripts, I was reminded of another use that could also be really useful which builds on top of some information that I had shared back in 2012. ESXi provides a very basic file manipulation capability that is exposed as a simple HTTPS-based interface.

Here is a quick recap of the three URLs which can be accessed by opening a browser and logging into the ESXi host:

https://esxi-1.primp-industries.com/host
https://esxi-1.primp-industries.com/folder
https://esxi-1.primp-industries.com/tmp

For the purpose of this article, we will be focusing on the first url endpoint /host and below is an example screenshot on some of the configuration files (46 in total) that you would be able to access using this interface.

One of the available ESXi configuration files that you access is the esx.conf file directly where it might be useful to periodically capture the state of this file for either auditing or troubleshooting purposes.

Note: Although esx.conf does contain some amount of the ESXi configurations, it does not represent the full state of the ESXi host. If you wish to perform periodic full backups of your ESXi host (which includes esx.conf by default among other files), there is a vSphere API for this by using the HostFirmwareSystem and the BackupFirmwareConfiguration() method.

Applying the same technique as I have described here, we can easily retrieve the esx.conf for a specific ESXi host being managed by vCenter Server without needing directly login to the ESXi host or worse connecting via SSH. I have created a PowerCLI script called Get-Esxconf.ps1 which just accepts a VMHost object.

Here is an example of how you would use the function and screenshot below of the output:

$esxConf = Get-VMHost -Name "esxi-1" | Get-Esxconf

If you are interested in a specific key within the esx.conf configuration file, we further process the output. The following snippet below searches for the following key /system/uuid and will return the value as it iterates through the esx.conf output.

$esxConf = Get-VMHost -Name "esxi-1" | Get-Esxconf

$keyToSearchFor = "/system/uuid"

foreach ($line in $esxConf.Split("`n")) {
    $data = $line.split("=").trim().replace('"',"")
    if($data[0] -eq $keyToSearchFor) {
        Write-Host "Key:" $keyToSearchFor 
        write-Host "Value:" $data[1]
    }
}

Hopefully this gave you an idea of just one of the many use cases that can now be enabled through the use of the vSphere API and this ESXi interface. Here are just a few other use cases that I can think of on the top of my mind that could come in handy:

Managing ESXi SSH public/private keys, we have mostly been using httpGet, but you can also use an httpPut to upload these files without needing to go to each and every ESXi host
Replacing Custom SSL Certificates if you are not using VMCA, you can also use an httpPut request to upload these files (you will need to restart hostd or reboot the host for the new SSL Certificates to go into effect)
Quickly access the vpxa.cfg (vCenter Server agent) configuration file for troubleshooting purposes

Automating Cross vCenter vMotion (xVC-vMotion) between the same & different SSO Domain

05.26.2016 by William Lam // 79 Comments

In the last couple of months, I have noticed an increase in customer interests in using the Cross vCenter vMotion (xVC-vMotion) capability that was introduced back in vSphere 6.0. In my opinion, I still think this is probably one of the coolest features of that release. There is no longer the limitation of restricting your Virtual Machine mobility from within a single vCenter Server, but you can now live migrate a running VM across different vCenter Servers.

The primary method to start a xVC-vMotion is by using the vSphere Web Client which requires your vCenter Servers Servers to be part of the same SSO Domain and will automatically enable the new Enhanced Linked Mode (ELM) feature. ELM allows you to easily manage and view all of your vCenter Servers from within the vSphere Web Client as shown in the example screenshot below.

However, the vSphere Web Client is not the only way to start a xVC-vMotion, you can also automate it through the use of the vSphere API. In fact, there is even an "Extended" capability of xVC-vMotion that is not very well known which I have written about here which allows to live migrate a running VM across two different vCenter Servers that are NOT part of the same SSO Domain. This Extended xVC-vMotion (unofficially I am calling it ExVC-vMotion) is only available when using the vSphere API as the vSphere Web Client is unable to display vCenter Servers that are part of another SSO Domain. Below is a quick diagram to help illustrate the point in which VM1 can be seamlessly migrated between different vCenter Servers from within the same SSO Domain as well as between different vCenter Servers that are not part of the same SSO Domain.

Note: For additional details and requirements for Cross vCenter vMotion, please have a look at this VMware KB 210695 and this blog post here for more information.

UPDATE (06/15/17) - I have added a few minor enhancements to the script to support migrating a VM given a vSphere Resource Pool which enables the ability to migrate to and from VMware's upcoming VMware Cloud on AWS (VMC). There is also an additional UppercaseUUID parameter which seems to be required for some xVC-vMotions where the vCenter Server's InstanceUUID must be provided as all upper case or the operation will fail. I have still not identified why this is needed for some migrations, but for now there is a nice flag that can be used to enable this if you are hitting this problem.

UPDATE (04/08/17) - In vSphere 6.0 Update 2, there is a known limitation which prevents a VM that has multiple VMDKs stored across different datastores to be xVC-vMotion (compute only) using the vSphere Web Client. This limitation no longer exists in vSphere 6.0 Update 3 but does require customers to upgrade. If you need to perform a compute-only xVC-vMotion where the VM has multiple VMDKs across different datastores, the vSphere APIs does not have this limitation and you do not necessary need to upgrade to be able to perform this operation. Huge thanks to Askar Kopayev who discovered this and also submitted an enhancement to my xMove-VM PowerCLI script to support this functionality.

Given the amount of interest recently and some of the feedback on my original ExVC-vMotion script which I had written about here, I figured it was time to refactor my code so that it could easily support both ExVC-vMotion as well as standard xVC-vMotion. In addition, I have also added support for migrating to and from a Distributed Virtual Switch (VDS), where as previously the example only supported Virtual Standard Switch (VSS). Lastly, the script now also supports migrating a VM that is configured with multiple vNICs.

The new script is now called xMove-VM.ps1 and is even more simpler than my original script. You will need to edit the script and update the following variables:

Variable	Description
vmname	Name of the VM to migrate
sourceVC	The hostname or IP Address of the source vCenter Server in which the VM currently resides in
sourceVCUsername	Username to the Source vCenter Server
sourceVCPassword	Password to the Source vCenter Server
destVC	The hostname or IP Address of the Destination vCenter Server in which to migrate the VM to
destVCUsername	Username to the Destination vCenter Server
destVCpassword	Password to the Destination vCenter server
datastore	Name of the vSphere Datastore to migrate the VM to
cluster	Name of the vSphere Cluster to migrate the VM to
resourcepool	Name of the vSphere Resource Pool to migrate the VM to
vmhost	Name of the ESXi host to migrate the VM to
vmnetworks	Name of the vSphere Network(s). in the order in of the vNIC interfaces to migrate the VM to
switch	Name of the vSphere Switch to migrate the VM to that is comma separated and ordered by vNIC
switchtype	The type of vSphere Switch (vss or vds)
xvctype	Whether this is a Compute-only Cross VC-vMotion (1=true or 0 = false)
UppercaseUUID	There cases where the vCenter Server InstanceUUID must be all caps ($true or $false)

Here is a screenshot of running the script:

Note: When changing the type of vSphere Switch, the following combinations will are supported by the script as well as using the vSphere Web Client: VDS to VDS, VSS to VSS and VSS to VDS. VDS to VSS is not supported using the UI or API and neither are 3rd party switches supported.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of: