vCloud Connector and Offline Data Transfer

Offline Data Transfer (ODT) is a feature of vCloud Connector that allows migration of VMs from customer own datacenter to vCloud Air with NAS appliance which is shipped via regular mail. The point is to avoid slow wide area network connectivity and leverage awesome bandwidth but slow latency of sneakernet.

Have you ever wondered why it is supported only with vCloud Air and not with any public or private cloud based on vCloud Director? Well I am going to lay down the whole process here in this blog post so nothing is stopping anyone testing this feature on your own.

Let me first paste picture from the manual which describes in high level how the process works:

Offline Data Transfer ProcessvCloud Connector (vCC) is leveraged to manage the whole process. The customer (on left) deploys his own vCloud Connector Server and Node which he attaches to his on premises infrastructure (vSphere based). He then requests the ODT service. The provider will deploy ODT node in the public cloud (on right) and also its own vCC Server to manage it. Regular NAS appliance is prepared – its only purpose is to provide storage capacity which is fast and reliable enough via NFS protocol and can be easily packaged and shipped.

Customer mounts it to his vCC Node (to a directory via NFS mount). Both the ODT and vCC Nodes are registered in his vCC Server. Then via the traditional vSphere Client and vCC Plugin only the local vSphere environment (here it differs from the traditional vCC transfer).

vSphere in vCC

The actual export is done by selecting the objects to export (templates, vApps or VMs) and clicking the small Offline Data Transfer icon: ODT IconMount path is entered and links and credentials to the target Cloud and ODT node. There is also option to select if a particular VM should be deployed and connected to a network. These steps above are all described in the manual here.

But what about the provider side of the whole process?

ODT Node

ODT Node is actually regular vCloud Connector Node tweaked by running configureSneakernetNode.sh script which can be found in /opt/vmware/hcagent/scripts folder on the Node VM itself.

The ODT needs to have network access to the vCenter Server (and ESXi hosts) of the target vCloud VDC environment.

Import

The actual import is done via provider vCloud Connector server which is again the regular vCloud Connector server with no tweaks this time. The ODT Node is registered there which enables import menu in the vCC plugin GUi in vSphere Client. The shipped NAS appliance must be mounted to the ODT Node and the ODT URL and mount path is entered in the Import Wizzard. The actual physical connection of the NAS appliance can be done using dedicated VLAN with point to point connection of the second ODT network interface.

ImportNext we need to pick the target vCenter Server and a credentials for it. ODT Node will import offline VMs which are stored as encrypted OVFs on the NAS appliance into the target vCenter Server. To do that it needs a big enough datastore and a dummy network in order to connect the imported VMs temporarily to it. Once that is done VMs are imported by vCloud Director to the target VDCs, catalogs and networks. The provider needs to have big enough datastore and create dummy standard switch port group on every host with name ‘VM Network’. This network does not need to have external access.

As you can see contrary to the regular internet vCloud Connector transfer where the VM is transfer from the original environment via on-prem node to public node to vCloud Director (through its API and transfer storage – see here for more detail) the transfer does not go through the vCloud Director cells and its transfer storage at all. This is possible thanks to handling the final step of the process by the provider himself (he has vCenter Server access) and makes also the transfer faster (potentially one less step). On the other hand this brings some security and operational process challenges (physical access to management network, vCenter credentials) which must be properly addressed.

VCD Cell Management Tool without Administrator Credentials

I just learned from engineering neat trick related to how cell management tool can be invoked without specifying administrator credentials.

The issue is that currently you cannot use LDAP account to trigger cell management tool commands which are mostly used for quiescing and shutting down cells for maintenance. Using vCloud Director local administrator account is discouraged as it poses a security issue. However what is possible is to trigger the cell management tool as root (or with sudo) and supply via hidden flag -i the process ID of the java process.

Here is an example:

PID

First I query the java PID with ps aux command. Then I use the standard cell-management-tool command without specifying the user with the -i flag at the end.

So you can force the administrator to log in to the cell guest OS via a LDAP account and then run the command with sudo.

Thank you Zachary Shepherd for the tip.

Custom vCenter Server Event and Alarm

Related to my previous post about monitoring Edge Gateways my customer asked me if he could leverage vCenter Server alarms as they are integrated with their monitoring and alerting infrastructure.

So basically is there a way to create vCenter alarm via scripted action (for example with PowerCLI)?

The answer is yes and it is not that difficult. There are two types of vCenter alarms: based on condition/state or an event. And it is possible to create custom user event via Loguserevent method of entity manager via vSphere API.

This is example of PowerCLI code the creates user event “Edge Gateway event” at the root datacenter folder.

$DCFolderEntity = Get-Folder -Name datacenters
$eventMgr = Get-View EventManager
$eventMgr.LogUserEvent($entity.ExtensionData.MoRef,"Edge Gateway event")

User logged event

Now it is easy to create custom alarm based on the user logged event. Create the alarm at the vCenter Server root level, as alarm type pick monitor vCenter Server and as triggers manually enter (type):

Event; vim.event.GeneralUserEvent 

That’s it.

Alarm

Renaming Edge Gateway

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. 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.

Here are the scripts:

function RenameEdgeV5 {
<#
.SYNOPSIS Renames vShield Edge
.DESCRIPTION Renames vShield or NSX legacy v5 Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your vShield or NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
.EXAMPLE
PS> RenameEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId -Name newname
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId,
[Parameter(Mandatory=$true)]
[String]$Name
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/3.0/edges"+"/"+$EdgeId
$s = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $s.Content
$sxml.edge.name = $Name
$r = Invoke-WebRequest -Uri $HealthRequest -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

return $r.StatusCode
function RenameEdgeV6 {
<#
.SYNOPSIS Renames NSX Edge
.DESCRIPTION Renames NSX Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
.EXAMPLE
PS> RenameEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId -Name newname
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId,
[Parameter(Mandatory=$true)]
[String]$Name
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/4.0/edges"+"/"+$EdgeId
$s = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $s.Content
$sxml.edge.name = $Name
$r = Invoke-WebRequest -Uri $HealthRequest -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

return $r.StatusCode

} # End of process

} # End of function

Usage example:Usage

vSphere Client recent task activity:
Recent Tasks

 

And NSX Manager Edge Gateway view.RenamedEdges

My New Role at VMware

After almost 4 years working for professional services at VMware I am transferring to new Architect role in Global Cloud Practice – vCloud Air Network. I am taking up the challenge to work in a global team of cloud architects with half of them VCDX certified which will support the largest vCloud Air Network Service Provider partners.

During my PSO days as Consulting Architect I was consulting, designing and implementing private and public clouds for global, large and also smaller customers all over Europe with most of them in German-speaking countries. Whenever I encountered an interesting problem I blogged about it on this blog and recently the most often topics blogged about were about vCloud Director and NSX.

So I feel it is a perfect fit for me that In the new role I will specialize on public cloud only for handful of large SPs which means you can expect more articles about vCloud Director and NSX :-).

Stay tuned…