Quantcast
Channel: Tomas Fojta – Tom Fojta's Blog
Viewing all 242 articles
Browse latest View live

Organization VDC Permissions in vCloud Director

$
0
0

As of vCloud Director 8.10 it is possible for the tenant Organization Administrator to control access to Organization VDCs. This enables the following use case:

  • In one Organization there are multiple Org VDCs belonging to different business units. Each Org VDC has its own Organization VDC administrator (from the business unit) who can manage Org VDC resources (networks, Edge Gateways) in his Organization VDC but does not see VDCs of other business unit.

The capability is currently available only with vCloud API. There are also four new related user rights that system administrator can use to create new roles.

  • Allow Access to All Organization VDCs
  • Edit Access Control List of Organization VDCs
  • View Access Control List of Organization VDCs
  • Implicitly Import User/Group from IdP while Editing VDC ACL

Org VDC Admin Role

Note that I have removed most of Organization and all User rights from the custom Org VDC Admin role which follows the described use case.

In the following example I have two Org VDCs – Production and Test in Organization ACME. The Organization Administrator (acmeadmin) created two Org VDC Admin users – acmeadminprod and acmeadmintest. Now he will create access for each to his corresponding Org VDC.

Users

As was mentioned above, this is done with vCloud API PUT request. First we need to find out Org VDC and user references.

GET https://vcloud.fojta.com/api/admin/org/02b433db-0b37-4304-b07b-0717255ec297

Accept: application/*+xml;version=20.0
x-vcloud-authorization: 3e131f9e3bc240269a7758fdb6c1bf7f</pre>

<?xml version="1.0" encoding="UTF-8"?>
<AdminOrg xmlns="http://www.vmware.com/vcloud/v1.5" name="ACME" id="urn:vcloud:org:02b433db-0b37-4304-b07b-0717255ec297" href="https://vcloud.fojta.com/api/admin/org/02b433db-0b37-4304-b07b-0717255ec297" type="application/vnd.vmware.admin.organization+xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://vcloud.fojta.com/api/v1.5/schema/master.xsd">
    <Link rel="down" href="https://vcloud.fojta.com/api/tasksList/02b433db-0b37-4304-b07b-0717255ec297" type="application/vnd.vmware.vcloud.tasksList+xml"/>
    <Link rel="down" href="https://vcloud.fojta.com/api/admin/org/02b433db-0b37-4304-b07b-0717255ec297/metadata" type="application/vnd.vmware.vcloud.metadata+xml"/>
...
    <Users>
        <UserReference href="https://vcloud.fojta.com/api/admin/user/395b2a93-d5ef-4c55-a316-ab500ea4829c" name="acmeuser" type="application/vnd.vmware.admin.user+xml"/>
        <UserReference href="https://vcloud.fojta.com/api/admin/user/46f40e2c-ed07-428f-af82-e691329f3cba" name="acmeadmin" type="application/vnd.vmware.admin.user+xml"/>
        <UserReference href="https://vcloud.fojta.com/api/admin/user/8c1af691-baa9-49db-9bf4-a5ad0562f92b" name="acmeadmintest" type="application/vnd.vmware.admin.user+xml"/>
        <UserReference href="https://vcloud.fojta.com/api/admin/user/e20edd07-e426-4a72-8f49-718b37685da6" name="acmeadminprod" type="application/vnd.vmware.admin.user+xml"/>
    </Users>
...
    <Vdcs>
        <Vdc href="https://vcloud.fojta.com/api/vdc/18d1590d-e033-4618-8179-432f99e5c54a" name="Test" type="application/vnd.vmware.vcloud.vdc+xml"/>
        <Vdc href="https://vcloud.fojta.com/api/vdc/47564d52-9204-40b1-b315-a00d59945cfd" name="Production" type="application/vnd.vmware.vcloud.vdc+xml"/>
    </Vdcs>
...
</AdminOrg>

Now we can construct PUT request for each Org VDC to assign user access:

Test Org VDC

PUT https://vcloud.fojta.com/api/vdc/18d1590d-e033-4618-8179-432f99e5c54a/action/controlAccess

Accept: application/*+xml;version=20.0
x-vcloud-authorization: 3e131f9e3bc240269a7758fdb6c1bf7f
Content-type: application/vnd.vmware.vcloud.controlAccess+xml

<?xml version="1.0" encoding="UTF-8"?>
<ControlAccessParams xmlns="http://www.vmware.com/vcloud/v1.5">
	<IsSharedToEveryone>false</IsSharedToEveryone>
	<AccessSettings>
		<AccessSetting>
			<Subject href="https://vcloud.fojta.com/api/admin/user/8c1af691-baa9-49db-9bf4-a5ad0562f92b" name="acmeadmintest" type="application/vnd.vmware.admin.user+xml"/>
			<AccessLevel>ReadOnly</AccessLevel>
		</AccessSetting>
	</AccessSettings>
</ControlAccessParams>

Production Org VDC

PUT https://vcloud.fojta.com/api/vdc/47564d52-9204-40b1-b315-a00d59945cfd/action/controlAccess

Accept: application/*+xml;version=20.0
x-vcloud-authorization: 3e131f9e3bc240269a7758fdb6c1bf7f
Content-type: application/vnd.vmware.vcloud.controlAccess+xml

<?xml version="1.0" encoding="UTF-8"?>
<ControlAccessParams xmlns="http://www.vmware.com/vcloud/v1.5">
	<IsSharedToEveryone>false</IsSharedToEveryone>
	<AccessSettings>
		<AccessSetting>
			<Subject href="https://vcloud.fojta.com/api/admin/user/e20edd07-e426-4a72-8f49-718b37685da6" name="acmeadminprod" type="application/vnd.vmware.admin.user+xml"/>
			<AccessLevel>ReadOnly</AccessLevel>
		</AccessSetting>
	</AccessSettings>
</ControlAccessParams>

Now we can log in as each Org VDC Administrator and verify that we see only one Org VDC:

User acmeadminprod can see only Org VDC Production:

Prod Org VDC

User acmeadmintest can see only Org VDC Test:

Test Org VDC

As both Org VDCs were set as private the Organization Administrator will now have to explicitly enable access for regular users to each Org VDC with the same PUT request. There is maximum of 200 user/group references per Org VDC.



Limit Maximum Size of Disk in vCloud Director

$
0
0

Although cloud services are providing access to abstracted seemingly infinite physical resources, the truth is that the physical infrastructure is not limitless. Pooling and distributed resource scheduling for compute, storage and network helps but at the end there is always a physical host, LUN or network uplink which constraints the granularity of scaling.

When it comes to storage it is the datastore size that limits the maximum size of virtual disk a cloud consumer can attach to his/her VM. While thin and fast provisioning and dedupe (NFS/VSAN) can be used to fit more data and storage DRS can shuffle the data around when a particular datastore is filling up at the end the service provider should not allow creation of arbitrary size of vdisks (vSphere maximum is 62 TB) to avoid datastore out of space condition. For example letting customers provision 4 TB thin disks on 3 TB LUNs is just asking for trouble.

Before vCloud Director 8.10 service providers were leveraging blocking tasks with custom orchestration to check if provisioned VM is within provider specified limits (RAM size, vDisk size, max vCPUs). There is reference implementation published here: CPU and Memory Limit enforcement for vCloud Director.

vCloud Director 8.10 brings hidden configuration option where service provider can globally set the maximum allowed size of virtual disk.

The option can be set with cell-management-tool command on a vCloud cell with the following syntax:

$VCLOUD_HOME/bin/cell-management-tool manage-config -n vmlimits.disk.capacity.maxMb -v 1000000

which would set maximum size of disk to 1000000 MB which is 1 TB.

Note: the command is run on one vCloud cell and its impact is immediate (no need to restart anything).

If the tenant tries to provision larger vDisk he will get the following error:

Disk Limit

Note that the limit is not enforced for system administrators and existing disks are not affected.

What should be the limit is out of scope for this post as there are many considerations that should be taken into account:

  • datastore size
  • can datastore grow?
  • thin provisioning
  • fast provisioning
  • tenant snapshots
  • provider snapshots (backup software generated)
  • yellow and red datastore thresholds
  • Storage DRS
  • deduplication on the array

vCloud Director Fundamentals E-learning Course

$
0
0

VMware released free vCloud Director Fundamentals e-learning course. It is based on the latest vCloud Director v 8.10 and goes into quite a depth in about 3-4 hours.

VCD Fundamentals

Course Outline:

  1. Cloud Computing and VMware vCloud Director – OVerview
  2. VMware vCloud Director Architecture and Components
  3. VMware vCloud Director Installation and Configuration
  4. VMware vCloud Director Administration
  5. Network Administration in VMware vCloud Director
  6. VMware vCloud Director End-User Tasks

Register for the e-learning course here.


vCenter Chargeback Manager Notes

$
0
0

ChargebackThis blog post summarizes up-to-date (July 2016) information related to vCenter Chargeback Manager.

Chargeback Manager (CBM) is available only for service providers. Although in past its end of support was announced it was extended until end of 2017. The reason for extension is to provide more time to service providers to migrated to its successor – vRealize Business for Cloud Advanced (vRB)

Both CBM and vRB were removed from all but standard vCloud Service Provider Bundles (with the exception for current users) and can be licensed separately. The reason was to give partners more choice which metering tool to use.

  • The latest CBM version is 2.7.1 and is downloadable from here. Note that this version has following support limitations:
    • vSphere 6 is not supported – this is due to new storage APIs introduced in vSphere 6
    • Both vCloud Networking and Security and NSX are supported (in the vCloud Director context)
    • vCloud Director 8.10 is not supported (see the next bullet point)
  • CBM patch for vCloud Director 8.10 was released in the following KB: https://kb.vmware.com/kb/2146041. It replaces one JAR file of the vCloud Director data collector to properly identify new vCloud API versions. It is also backward compatible with older vCloud Director versions.
  • vSphere 6 support is expected in the next release of CBM later this year

In case you are upgrading from CBM 2.7.0 to 2.7.1 here are some notes and considerations:

  • CBM 2.7.0 and older was 32 bit application. CBM 2.7.1 is 64 bit application.
  • There are two ways how to upgrade CBM. You can either do in-place upgrade, or you can uninstall CBM and install fresh binaries while using the same Chargeback database
    • In-place upgrade:
      • Make sure you shut down all services before running the installer (vCenter-CB.exe)
      • Always run the installer with the Run as administrator option.
      • Even though CBM 2.7.1 is 64 bit application it will still be located in the default 32bit Program Files (x86) folder.
    • Fresh install:
      • Uninstall CBM by running Uninstall.bat located in the …\VMware vCenter Chargeback\Uninstall_VMware vCenter Chargeback folder. If non-embedded collectors were used, uninstall them in similar way as well.
      • Reboot and install new binaries while pointing to the same CBM database. Remember to use Run ad administrator option when executing the installer (vCenter-CB.exe)
      • The installer does not remove old collectors from the database. Wait a few minutes until they will be identified as failed (red X in CBM System Health, Data Collectors UI), note their IDs and then manually remove them from CBM database – CB_DC_STATUS table. You can locate them by their ID in the DC_ID column.
      • CBM 2.7.1 will be located by default in the 64 bit Program Files folder.

vCloud Networking and Security Upgrade to NSX in vCloud Director Environments – Update

$
0
0

vCNS to NSXIn April I wrote whitepaper describing all considerations that need to be taken when upgrading vCloud Networking And Security to NSX in vCloud Director Environments. I have updated the whitepaper to include additional information related to new releases:

  • updates related to vCloud Director 8.10 release
  • update related to VMware NSX 6.2.3 release
  • updates related to vCenter Chargeback Manager 2.7.1 release
  • NSX Edge Gateway upgrade script example
  • extended upgrade scenario to include vCloud Director 8.10

The whitepaper will be posted later this month on vCloud Architecture Toolkit for Service Providers website, until then it can be downloaded from the link below.

VMware vCloud Networking and Security to VMware NSX Upgrade v2.1.pdf … link


Edge Gateway Deployment Speed in vCloud Director 8.10

$
0
0

Edge GatewayIn vCloud Director 8.10 there is massive improvement in deployment (and configuration) speed of Edge Gateways. This is especially noticeable in use cases where large number of routed vApps are provisioned in as short time as possible – for example nightly builds for testing, or labs for training purposes. But this is also important for customer onboarding – time to login to cloud VM from the swipe of the credit card SLA.

Theory

How is the speed improvement achieved? It is actually not really vCloud Director accomplishment. The deployment and configuration of Edge Gateways were always done by vShield or NSX Manager. However, there is a big difference how vShield Manager and NSX Manager communicate with the Edge Gateway to push its configuration (IP addresses, NAT, firewall and other network services configurations).

As the Edge Gateway can be deployed to any network which can be completely isolated from any external traffic, its configuration cannot be done over the network and instead out-of-band communication channel must be used. vShield Manager always used VIX API (Guest Operations API) which involves communication with vCenter Server, hostd process on ESXi host hosting the Edge Gateway VM and finally VMware Tools running in the Edge Gateway VM (see this older post for more detail).

NSX Manager uses different mechanism. As long as the ESXi host is properly prepared for NSX, message bus communication between the NSX Manager and vsfwd user space process on the ESXi host is established. Additionally the configuration to the Edge Gateway VM is done via VMCI channel.

Prerequisites

There are necessary prerequisites to use the faster message bus communication as opposed to VIX API. If any of these is not fulfilled the communication mechanism fails back to VIX API.

  • The host running the Edge Gateway must be prepared for NSX. So if you are in vCloud Director using solely VLAN (or even VCDNI) backed network pools and you skipped the NSX preparation of underlying clusters, message bus communication cannot be used as the host is missing the NSX VIBs and vsfwd process.
  • The Edge Gateway must be version 6.x. It cannot be the legacy Edge version 5.5 deployed by older vCloud Director releases (8.0, 5.6, etc.). vCloud Director 8.10 deploys Edge Gateway version 6.x however existing Edges deployed before upgrade to 8.10 must be redeployed in vCloud Director or upgraded in NSX (read this whitepaper for a script to do it at once).
  • Obviously NSX Manager must be used (as opposed to vShield Manager) – anyway vCloud Networking and Security is not supported with vCloud Director 8.10 anymore.

Performance Testing

I have done quick proof of concept testing to see what is the relative improvement between the older and newer deployment mechanism.

I used 3 different combinations of the same environment (I was upgrading from one combination to the other).

  • vCloud Director 5.6.5 + vCloud Networking and Security 5.5.4
  • vCloud Director 8.0.1 + NSX 6.2.3 (uses legacy Edges)
  • vCloud Director 8.10 + NSX 6.2.3 (uses NSX Edges)

All 3 combinations used the same hardware and the same vSphere environment (5.5) with nested ESXi hosts. So the point is to look at the relative differences as opposed to absolute deployment times.

I measured in PowerCLI sequential deployment speed of 10 vApps with one isolated network and 10 vApps with one routed network with multiple runs to calculate average per one vApp. The first scenario was to measure differences in provisioning speeds of VXLAN logical switches to see impact of controller based control plane mode. The second includes provisioning of an Edge Gateway and logical switch. The vApps were otherwise empty (no VMs).

Note; If you want to do similar test in your environment, I captured the two empty vApps with only the routed or isolated networks to a catalog with vCloud API (PowerCLI) as it cannot be done from vCloud UI.

Here are the average deployment times of each vApp.

vCloud Director 5.6.5 + vCloud Networking and Security 5.5.4

  • Isolated 5-5.5 seconds
  • Routed 2:17 min

vCloud Director 8.0.1 + NSX 6.2.3

  • Isolated cca 6.8 seconds (Multicast), 7.5 seconds (Unicast)
  • Routed 2:20 min

vCloud Director 8.10 + NSX 6.2.3

  • Isolated 7.7 s (Multicast), 8.1 s (Unicast)
  • Routed 1:35 min

While the speed of logical switch provisioning goes little bit down with NSX and with Unicast control plane mode, the Edge Gateway deployment gets massive boost with NSX and VCD 8.10. While the OVF deployment of NSX Edge takes little bit longer (from 20 to 30 s) it is the configuration that makes up for it (from way over a minute down to about 30 s).

Just for comparison here are the tasks done during deployment of each routed vApp as reported by vSphere Client Recent Task window.

vCloud Director 5.6.5 + vCloud Networking and Security

vCloud Director 5.6.5 + vCloud Networking and Security

vCloud Director 8.10 + NSX 6.2.3

vCloud Director 8.10 + NSX 6.2.3


Automate Let’s Encrypt Certificate for NSX Edge Load Balancer

$
0
0

NSX LBI needed public certificate for my lab to avoid issues while testing certain libraries that did not allow untrusted connections or importing private Certificate Authority.

Fortunately, there is possibility to issue free public certificates with Let’s Encrypt certificate authority. These certificates are domain validated, which means you need to own the domain for which you issue the certificate. There are three methods how the validation is done but only one can be used in fully automated mode. Why the need for automation? The issued certificates are valid only for 90 days.

To validate the domain ownership you need to publish on publicly accessible web server under the certificate FQDN a specific generated verification string. You do not actually need to publish the service (and the NSX Edge load balancer) to the internet if you do not want to – I just set up a simple webserver with a sole purposed to complete the validation challenge.

So what is the high level process?

  1. Own a domain for which you want to have the certificate.
  2. Set up publicly accessible web server and point to it a DNS record with the certificate FQDN.
  3. Generate challenge string and place it on the web server.
  4. Validate the domain and obtain the certificates.
  5. Upload the certificates to your NSX Edge Load Balancer.
  6. In 60 days repeat from #3.

There are various ways how to automate steps 3-5. I have chosen to do this on Windows with PowerShell but the same could be accomplished on Linux as there are many Let’s Encrypt clients available to chose from.

On a Windows 2012 R2 Server I installed latest Powershell 5, IIS and ACMESharp with PowerShell gallery:

save-module -name ACMESharp
install-module -name ACMESharp

Then I wrote PowerShell script that first goes through the certificate generation and then using NSX API replaces certificate of a specific load balancer.

Note that you need to supply NSX Manager credentials, Edge ID which is running the load balancer, application profile ID which the web server uses (can be easily looked up in NSX UI) and email and domain for the Let’s Encrypt generation process.

Also be aware that Let’s Encrypt has rate limit on how many times a particular certificate can be issued within 7 day period (currently 20).

$Username = "admin"
$Password = "default"
$NSXManager = "nsx01.fojta.com"
$LBEdge = 'edge-1'
$ApplicationProfile = 'applicationProfile-1'
$Email = "mailto:user@example.com"
$Domain = "domain.example.com"


## Generate random alias
$IdentAlias = 'Ident_'+([guid]::NewGuid()).ToString()
$CertAlias = 'Cert_'+([guid]::NewGuid()).ToString()

## Remove and rename old files
If (Test-Path D:\LetsEncrypt\issuer.crt.old) {Remove-Item D:\LetsEncrypt\issuer.crt.old}
If (Test-Path D:\LetsEncrypt\cert.key.old) {Remove-Item D:\LetsEncrypt\cert.key.old}
If (Test-Path D:\LetsEncrypt\cert.crt.old) {Remove-Item D:\LetsEncrypt\cert.crt.old}

If (Test-Path D:\LetsEncrypt\issuer.crt) {Rename-Item D:\LetsEncrypt\issuer.crt D:\LetsEncrypt\issuer.crt.old}
If (Test-Path D:\LetsEncrypt\cert.key) {Rename-Item D:\LetsEncrypt\cert.key D:\LetsEncrypt\cert.key.old}
If (Test-Path D:\LetsEncrypt\cert.crt) {Rename-Item D:\LetsEncrypt\cert.crt D:\LetsEncrypt\cert.crt.old}

## Let's Encrypt specific code from https://github.com/ebekker/ACMESharp/wiki/Quick-Start
Import-Module ACMESharp
Initialize-ACMEVault -ErrorAction SilentlyContinue
New-ACMERegistration -Contacts $Email -AcceptTos
New-ACMEIdentifier -Dns $Domain -alias $IdentAlias
Complete-ACMEChallenge $IdentAlias -ChallengeType http-01 -Handler iis -HandlerParameters @{ WebSiteRef = 'Default Web Site' }
Submit-ACMEChallenge $IdentAlias -ChallengeType http-01

$Status = "pending"
Do {
	Start-Sleep -s 5
	$Status = ((Update-ACMEIdentifier $Alias -ChallengeType http-01).Challenges | Where-Object {$_.Type -eq "http-01"}).Status
	}
Until ($Status = "valid")


New-ACMECertificate $IdentAlias -Generate -Alias $CertAlias
Submit-ACMECertificate $CertAlias
Get-ACMECertificate $CertAlias -ExportCertificatePEM D:\LetsEncrypt\cert.crt
Get-ACMECertificate $CertAlias -ExportKeyPEM D:\LetsEncrypt\cert.key
Update-ACMECertificate $CertAlias
Get-ACMECertificate $CertAlias -ExportIssuerPEM D:\LetsEncrypt\issuer.crt


$IssuerCert = [IO.File]::ReadAllText("D:\LetsEncrypt\issuer.crt")
$PrivateKey = [IO.File]::ReadAllText("D:\LetsEncrypt\cert.key")
$LBCertificate = [IO.File]::ReadAllText("D:\LetsEncrypt\cert.crt")

## Calculate Issuer Cert Thumbprint
$IssuerCertThumbprint = (Get-PfxCertificate -filepath D:\LetsEncrypt\issuer.crt).Thumbprint.ToLower()

## Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}

## Get all Edge certificates
$Uri = "https://$NSXManager/api/2.0/services/truststore/certificate/scope/" + $LBEdge
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $r.Content

## Find if Issuer Certificate already exists
$exists = $false
foreach ($Certificate in $sxml.certificates.certificate) {
	$Thumbprint = $Certificate.x509Certificate.sha1Hash -replace '[:]'
	if ($Thumbprint -eq $IssuerCertThumbprint) { $exists = $true }
	}

##Upload issuer certificate if it does not exist
if (-Not $exists) {
	$Uri = "https://$NSXManager/api/2.0/services/truststore/certificate/" + $LBEdge
	$Body = "
<trustObject>
 <pemEncoding>" +$IssuerCert+ "</pemEncoding>
 <description>Issuer Certificate</description>
</trustObject>"
	$r = Invoke-WebRequest -URI $Uri -Method Post -Headers $head -ContentType "application/xml" -Body $Body -ErrorAction:Stop
	$IssuerId = ([xml]$r).certificates.certificate.objectId
	}

##Upload certificate
$Uri = "https://$NSXManager/api/2.0/services/truststore/certificate/" + $LBEdge
$Body = "
<trustObject>
 <pemEncoding>" + $LBCertificate + "</pemEncoding>
 <privateKey>" + $PrivateKey + "</privateKey>
 <description>vCloud Certificate</description>
</trustObject>"
$r = Invoke-WebRequest -URI $Uri -Method Post -Headers $head -ContentType "application/xml" -Body $Body -ErrorAction:Stop
$NewCertificateId = ([xml]$r).certificates.certificate.objectId

##Replace certificate in the application profile
$Uri = "https://$NSXManager/api/4.0/edges/" + $LBEdge + "/loadbalancer/config/applicationprofiles/" + $ApplicationProfile
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $r.Content
$OldCertificateId = $sxml.applicationProfile.clientSsl.serviceCertificate
$sxml.applicationProfile.clientSsl.serviceCertificate = $NewCertificateId
$r = Invoke-WebRequest -Uri $Uri -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

##Delete old certificate from the Edge
$Uri = "https://$NSXManager/api/2.0/services/truststore/certificate/" + $OldCertificateId
$r = Invoke-WebRequest -URI $Uri -Method Delete -Headers $head -ContentType "application/xml" -ErrorAction:Stop



Gathering Health Status of vCloud Director Edge Gateways

$
0
0

Some time ago I wrote about how to monitor health of NSX Edge Gateways. In this blog post I will show how to get health and other info about vCloud Director Edge Gateways with PowerCLI.

PowerCLI already includes vCloud Director related cmdlets, unforunatelly there is none related to Edge Gateways. This can be easily remediated by using vCloud API however to get detailed information about Edge health we must use NSX API. As of vCloud Director 8.0 the service provider can easily get NSX Edge ID which is backing up particular vCloud Director Edge as a new type GatewayBacking was added.

What follows is an example of function that collects as much information as possible (interfaces, network services, size, syslog, default gateway, health of all services, Org, Org VDC and Provider VDC) about all Edge Gateways from PowerCLI, vCloud API and NSX API.

Note: there is dependency on the Get-NSXEdgeHealth function.

function Get-CIEdgeGateways {
<# .SYNOPSIS Gathers Edge Gateways from vCloud Director and all info through PowerCLI, vCloud API and NSX API .DESCRIPTION Will inventory all of your vCloud Director Edge Gateways .NOTES Author: Tomas Fojta #>
	[CmdletBinding()]
	param(
	[Parameter(Mandatory=$true,Position=0)]
	[String]$NSXManager,
	[Parameter(Mandatory=$false,Position=1)]
	[String]$NSXUsername = "admin",
	[Parameter(Mandatory=$true)]
	[String]$NSXPassword
	)

	$output = @();
	$EdgeGWs = Search-Cloud -QueryType EdgeGateway

	Foreach ($Edge in $EdgeGWs) {
		$Edgeview = $Edge | get-ciview
		$Vdc = get-OrgVdc -Id ($Edge.PropertyList.Vdc) -ErrorAction SilentlyContinue
		$webclient = New-Object system.net.webclient
		$webclient.Headers.Add("x-vcloud-authorization",$Edgeview.Client.SessionKey)
		$webclient.Headers.Add("accept",$EdgeView.Type + ";version=9.0")
		[xml]$EGWConfXML = $webclient.DownloadString($EdgeView.href)
		$n = "" | Select Name,Description,EdgeBacking,Interfaces,Firewall,NAT,LoadBalancer,DHCP,VPN,Routing,Syslog,Size,HA,DNSRelay,DefaultGateway,AdvancedNetworking, Org, TenantId, OrgVDC, OrgVDCId, ProviderVDC, ProviderVDCId, Health
		$n.Name = $EGWConfXML.EdgeGateway.Name
		$n.Description = $EGWConfXML.EdgeGateway.Description
		$n.EdgeBacking = $EGWConfXML.EdgeGateway.GatewayBackingRef.gatewayId
		$n.Interfaces = $EGWConfXML.EdgeGateway.Configuration.GatewayInterfaces.GatewayInterface
		$n.Firewall = $EGWConfXML.EdgeGateway.Configuration.EdgegatewayServiceConfiguration.FirewallService.FirewallRule
		$n.NAT = $EGWConfXML.EdgeGateway.Configuration.EdgegatewayServiceConfiguration.NatService.NatRule
		$n.LoadBalancer = $EGWConfXML.EdgeGateway.Configuration.EdgegatewayServiceConfiguration.LoadBalancerService.VirtualServer
		$n.DHCP = $EGWConfXML.EdgeGateway.Configuration.EdgegatewayServiceConfiguration.GatewayDHCPService.Pool
		$n.VPN = $EGWConfXML.EdgeGateway.Configuration.EdgegatewayServiceConfiguration.GatewayIpsecVpnService
		$n.Routing = $EGWConfXML.EdgeGateway.Configuration.EdgeGatewayServiceConfiguration.StaticRoutingService
		$n.Syslog = $EGWConfXML.EdgeGateway.Configuration.SyslogServerSettings.TenantSyslogServerSettings.SyslogServerIp
		$n.Size = $EGWConfXML.EdgeGateway.Configuration.GatewayBackingConfig
		$n.HA = $EGWConfXML.EdgeGateway.Configuration.HaEnabled
		$n.DNSRelay = $EGWConfXML.EdgeGateway.Configuration.UseDefaultRouteForDnsRelay
		Foreach ($Interface in $n.Interfaces) {
			if ($Interface.UseForDefaultRoute -eq 'true') {$n.DefaultGateway = $Interface.SubnetParticipation.Gateway}
			}
		$n.AdvancedNetworking= $EGWConfXML.EdgeGateway.Configuration.HaEnabled = $EGWConfXML.EdgeGateway.Configuration.AdvancedNetworkingEnabled
		$n.Org = $Vdc.Org.Name
		$n.TenantId = $Vdc.Org.Id.Split(':')[3]
		$n.OrgVDC = $Vdc.Name
		$n.OrgVDCId = $Vdc.Id.Split(':')[3]
		$n.ProviderVDC = $Vdc.ProviderVDC.Name
		$n.ProviderVDCId = $Vdc.ProviderVDC.Id.Split(':')[3]
		$n.Health = Get-NSXEdgeHealth -NSXManager $NSXManager -Username $NSXUsername -Password $NSXPassword -EdgeID ($n.EdgeBacking)
		$Output += $n
		}
	return $Output
}


PowerCLI Stops Working After NSX 6.2.4 Upgrade

$
0
0

NSX LBAs of NSX 6.2.3 TLS 1.0 support is deprecated on Edge Service Gateways. So if you are using load balancer with SSL offload, TLS 1.0 ciphers are no longer being supported and those clients that rely on them will not work anymore.

The supported ciphers can be easily checked with nmap. Here is nmap output to website behind NSX Edge 6.2.2 and 6.2.4 load balancer:

NSX 6.2.2 with TLS 1.0

NSX 6.2.2 with TLS 1.0

NSX 6.2.4 without TLS 1.0

NSX 6.2.4 without TLS 1.0

In my case PowerCLI stopped working and could not connect anymore to vCloud Director endpoint behind the Edge load balancer. The error was not very descriptive: The underlying connection was closed: An unexpected error occurred on a send.

PowerCLI Error

PowerCLI Error

Fortunately, it is possible to force PowerCLI to use TLS 1.1/1.2 by editing Windows Registry as described in the KB article: Enabling the TLSv1.1 and TLSv1.2 protocols for PowerCLI (2137109).

 

 

 


Collect vCloud Director Cell Logs with Log Insight Agent

$
0
0

vcenter-log-insight-logoWhile it is possible to redirect vCloud Director cell logs by editing log4j.properties file to remote syslog server (see KB 2004564) there is an alternative agent based method utilizing vRealize Log Insight.

Log Insight agent is installed on each cell and then remotely managed from Log Insight server. Here are some advantages of this approach:

  • no manual edits of log4j file which gets overwritten with each upgrade
  • as we do not rely log4j logger we are able to collect also API request log files which are generated by Jetty
  • agent uses reliable TCP communication as opposed to unreliable UDP
  • we no longer rely on source IP to identify sender; cells can use source NAT (with single IP) to communicate with Log Insight server and we can still distinguish them
  • we can remotely change which logs we want to monitor (info vs debug)
  • and much more

Here is quick configuration how to:

  1. Download Log Insight Agent from Log Insight Server. It is already customized installation for your vRLI server. Administration > Agents > scroll down > Download Log Insight Agent Version 3.6.0 > pick rpm package
  2. Upload rpm file to each cell and install it with rpm -i VMware-Log-Insight-Agent-3.6.0-4148343.noarch_XXX.rpm
  3. Back in Agents configuration create active agent group from vCloud Director Cell Server template (copy template icon)
  4. Create hostname filter (use ? for any character substitution, you can add multiple entries in one line for ‘logical or’ or multiple lines for ‘logical and’
  5. Optionally edit agent configuration to include additional files or directories

agent-config


How to Enable TLS1.0 on NSX Edge

$
0
0

In one of my previous articles I wrote how NSX upgrade to 6.2.4 impacts PowerCLI as it disables TLS 1.0 ciphers on Edge Load Balancer. The fix for PowerCLI was easy but what if there are other applications still using TLS1.0 that cannot be fixed/updated?

An example is vSphere Replication 6.1.1 which does not support TLS 1.2.

There is workaround. It is possible to create application rule that specifically enables TLS 1.0. The rule syntax is:

tlsv1 enable

application-rule

 

Once the rule is created it can be added in the Advanced Configuration of the virtual Server.

virtual-server


Query ESXi Hosts Serial Numbers

$
0
0

I was asked by our IT department to provide serial numbers of our lab servers. Fortunately this can be done remotely with esxcfg-info CLI command and can be automated with William Lam (@lamw) PowerCLI function Get-Esxcfginfo. I just had to find the right entry in the xml file returned by the function.

Here is the script I used:

<#
.SYNOPSIS Remoting collecting esxcfg-info from an ESXi host using vCenter Server
.NOTES Author: William Lam
.NOTES Site: www.virtuallyghetto.com
.NOTES Reference: http://www.virtuallyghetto.com/2016/06/using-the-vsphere-api-to-remotely-collect-esxi-esxcfg-info.html
.PARAMETER Vmhost
 ESXi host
.EXAMPLE
 PS> Get-VMHost -Name "esxi-1" | Get-Esxcfginfo
#>

Function Get-Esxcfginfo {
 param(
 [Parameter(
 Position=0,
 Mandatory=$true,
 ValueFromPipeline=$true,
 ValueFromPipelineByPropertyName=$true)
 ]
 [VMware.VimAutomation.ViCore.Impl.V1.Inventory.InventoryItemImpl[]]$VMHost
 )

 $sessionManager = Get-View ($global:DefaultVIServer.ExtensionData.Content.sessionManager)

 # URL to the ESXi esxcfg-info info
 $url = "https://" + $vmhost.Name + "/cgi-bin/esxcfg-info.cgi?xml"

 $spec = New-Object VMware.Vim.SessionManagerHttpServiceRequestSpec
 $spec.Method = "httpGet"
 $spec.Url = $url
 $ticket = $sessionManager.AcquireGenericServiceTicket($spec)

 # Append the cookie generated from VC
 $websession = New-Object Microsoft.PowerShell.Commands.WebRequestSession
 $cookie = New-Object System.Net.Cookie
 $cookie.Name = "vmware_cgi_ticket"
 $cookie.Value = $ticket.id
 $cookie.Domain = $vmhost.name
 $websession.Cookies.Add($cookie)

 # Retrieve file
 $result = Invoke-WebRequest -Uri $url -WebSession $websession -ContentType "application/xml"

 # cast output as an XML object
 return [ xml]$result.content
}

Connect-VIServer -Server xxx.gcp.local -User administrator@vsphere.local -password VMware1! | Out-Null

$hosts = Get-VMHost

foreach ($ESXhost in $hosts)
{
$xmlResult = $ESXhost | Get-Esxcfginfo
Write-Host $ESXhost.name ($xmlResult.host.'hardware-info'.value[3].'#text')
}

Disconnect-VIServer * -Confirm:$false

host-serials


vCloud Availability PowerCLI Monitoring Cmdlets

$
0
0


vCloud Availability for vCloud Director
is a new product for vCAN service providers released in July 2016 that enables disaster recovery to and from the cloud. It allows any vSphere customer who installes vSphere Replication to protect her on-prem workloads into the multitenant service provider cloud environment.

vCloud Availability

vCloud Availability adds additional vCloud APIs thanks to its vCloud Extensibility Framework. I have created a few simple PowerCLI cmdlets that demonstrate how easy is to use the new APIs. The cmdlets allow service provider to monitor state of vCloud Availability components as well as state of tenant replications.

Get-VRCells

Discovers all vCloud Director cells (including Cloud Proxies) and reports their status.

Get-VRCells

Get-VRCSNodes

Discovers all vSphere Replication Cloud Service nodes, their version and amount of seconds since last successful heartbeat.

Get-VRCSNodes

Get-VRMServers

Discovers all vSphere Replication Manager Servers and reports their status and paired vCenter Server

Get-VRMServers

Get-VRServers

Discovers all vSphere Replication Servers, their status and statistics about utilization.

Get-VRServers

Get-VRReplications

Collects all replications in particular organization, their compliance status and other information (RPO, storage used, number of snapshots, etc.). This cmdlet can be used also with tenant credentials.

Get-VRReplications

Function Get-VRCells {
<#
.SYNOPSIS
Discovers all vCloud Director cells
.DESCRIPTION
Discovers all vCloud Director cells including Cloud Proxies and report their status and version and if they ran VC proxy .EXAMPLE PS C:\> Get-VRCells
.NOTES
Author: Tomas Fojta
#>

if (-not $global:DefaultCIServers) {Connect-CIServer}

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + "query?type=cell"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=3.0"}
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content
$VRCells = $sxml.QueryResultRecords.CellRecord


$VRCells
}

Function Get-VRCSNodes {
<#
.SYNOPSIS
Discovers all vSphere Replication Cloud Service nodes
.DESCRIPTION
Discovers all vSphere Replication Cloud Service nodes, their version and last heartbeat
.EXAMPLE
PS C:\> Get-VRCSNodes
.NOTES
Author: Tomas Fojta
#>
if (-not $global:DefaultCIServers) {Connect-CIServer}

$VRCSNodes = @()
$CurrentTime = (New-TimeSpan -Start (Get-Date -Date "01/01/1970") -End (Get-Date).ToUniversalTime()).TotalMilliseconds

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + "admin/vr/nodes"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=3.0"}
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

foreach ($VRCS in $sxml.VrcsNodes.Node) {
$n = @{} | select VRCS,MaxSupportedAPiVersion,LastHeartbeatTimestamp,LastHeartbeatAgoInSeconds
$n.VRCS = $VRCS.Id
$n.MaxSupportedAPiVersion = $VRCS.MaxSupportedAPiVersion
$n.LastHeartbeatTimestamp = $VRCS.LastHeartbeatTimestamp
$n.LastHeartbeatAgoInSeconds = [math]::Truncate(($CurrentTime - [convert]::ToInt64($VRCS.LastHeartbeatTimestamp))/1000)

$VRCSNodes += $n
}

$VRCSNodes
}

Function Get-VRMServers {
<#
.SYNOPSIS
Discovers all vSphere Replication Manager Servers and reports their status
.DESCRIPTION
Discovers all vSphere Replication Manager Servers, reports their status and paired vCenter Server
.EXAMPLE
PS C:\> Get-VRMServers
.NOTES
Author: Tomas Fojta
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$false,Position=1)]
[String]$Org
)
if (-not $global:DefaultCIServers) {Connect-CIServer}

$VRMServers = @()

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + "admin/extension/vimServerReferences"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=3.0"}
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

foreach ($VimServer in $sxml.VMWVimServerReferences.VimServerReference) {
$n = @{} | select VRMS,IsConnected,VIMName,VIMhref
$n.VIMname = $VimServer.name
$n.VIMhref = $VimServer.href

$r = Invoke-WebRequest -URI ($VimServer.href + "/vrmServer") -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content
$n.VRMS = $sxml.AdminVrmServer.Uuid
$n.IsConnected = $sxml.AdminVrmServer.IsConnected

$VRMServers += $n
}

$VRMServers
}

Function Get-VRServers {
<#
.SYNOPSIS
Collects all vSphere Replication Servers
.DESCRIPTION
Collects all vSphere Replication Servers and basic statistics
.EXAMPLE
PS C:\> Get-VRServers
.NOTES
Author: Tomas Fojta
#>

if (-not $global:DefaultCIServers) {Connect-CIServer}

$VRServers = @()

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + "admin/extension/vr/vrServers"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=3.0"}
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

foreach ($vRS in $sxml.References.Reference) {
$n = @{} | select Name,href,IsConnected,ReplicationsCount,DisksCount
$n.href = $vRS.href

$r = Invoke-WebRequest -URI $vRS.href -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

$n.Name = $sxml.AdminVrServer.ReplicationTrafficAddress
$n.IsConnected = $sxml.AdminVrServer.IsConnected

$r = Invoke-WebRequest -URI ($vRS.href+"/statistics") -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content
$n.ReplicationsCount = $sxml.VrServerStatistics.ReplicationsCount
$n.DisksCount = $sxml.VrServerStatistics.DisksCount

$VRServers += $n
}

$VRServers

}

Function Get-VRReplications {
<#
.SYNOPSIS
Collects all replications in particular organization
.DESCRIPTION
Collects all replications in particular organization, their compliance status and other information
.EXAMPLE
PS C:\> Connect-CIServer -Org ACME
PS C:\> Get-VRReplications
.EXAMPLE
PS C:\> Get-VRReplications -Org ACME
.NOTES
Author: Tomas Fojta
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$false,Position=1)]
[String]$Org
)
if (-not $global:DefaultCIServers) {Connect-CIServer}
If ($Org -eq "") {$Org = $global:DefaultCIServers[0].Org}

$VRReplications = @()

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + ((get-org $org).id).Replace("urn:vcloud:org:","org/") + "/replications"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=3.0"}
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

foreach ($Replication in $sxml.References.Reference) {
$n = @{} | select Name,href,Rpo,ReplicationState,CurrentRpoViolation,TestRecoveryState,RecoveryState,VappId,VrServerInfo,ReplicaSpaceRequirements, Instance
$n.href = $Replication.href

$r = Invoke-WebRequest -URI $Replication.href -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

$n.Rpo = $sxml.ReplicationGroup.Rpo
$n.ReplicationState = $sxml.ReplicationGroup.ReplicationState
$n.CurrentRpoViolation = $sxml.ReplicationGroup.CurrentRpoViolation
$n.TestRecoveryState = $sxml.ReplicationGroup.TestRecoveryState
$n.RecoveryState = $sxml.ReplicationGroup.RecoveryState
$n.VappId = $sxml.ReplicationGroup.PlaceholderVappId.Replace("urn:vcloud:vapp:","")
$n.VrServerInfo = $sxml.ReplicationGroup.VrServerInfo.Uuid

$r = Invoke-WebRequest -URI ($Replication.href + "/instances") -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

$n.ReplicaSpaceRequirements = $sxml.ReplicationGroupInstanceList.ReplicaSpaceRequirements
$n.Instance = $sxml.ReplicationGroupInstanceList.Instance

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + "vApp/vapp-" + $n.VappId
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

$n.Name = $sxml.VApp.Children.Vm.name

$VRReplications += $n
}

$VRReplications

}

 


vCloud Availability – Orchestration with PowerCLI

$
0
0

In my last post I have introduced vCloud Availability – a Disaster Recovery extension for vCloud Director and also have shown how service providers can monitor the key components of the solution.

Today I will show how tenants can orchestrate failover of their VMs to the cloud with PowerCLI without the need to have access to their on-prem vCenter Server which in case of disaster might be down.

vCloud Availability is extending vCloud APIs with new API calls that can be used to gather information about ongoing replications and provide fail over, test failover and cleanup test failover actions.

I have created the following PowerCLI cmdlets that demonstrate usage of the new APIs.

Get-VRReplication

The function returns one (based on its name) or all tenant configured replications, displays their status and also vCloud vApp identifier which is important for additional orchestration as I will show later below.

FailOver-VRReplication

This function needs an Replication object (which can be obtain with the previous command) as an input and performs real replication to the cloud. Additional parameters specifie if the recovered VM should be powered on or if the task should run asynchronously.

TestFailover-VRReplication

This is identical function to the previous one, however it performs only Test Failover to the cloud. This means replication still goes on and the recovered VM is connected to a test network in the cloud instead of the production one. Input parameters are identical.

TestCleanup-VRRreplication

This command cleans up replication that is in Test Recovery State.

Orchestration

As I hinted above, these new cmdlets can be combined with existing vCloud PowerCLI cmdlets to orchestrate complex workflows that require changes on the recovered VMs. As an example I am showing simple script that recovers one VM and changes its IP address. The code is heavily commented to explain each step.

#Replication name matches the protected VM name
$Name = "VM1"
#New IP addresses(s) - can be array of multiple entries, if VM has multiple NICs
[array] $IPAddress = '192.168.1.150'

#First we need to get the replication object
$Replication = Get-VRReplication $Name

#Now we can perform the failover however we will not power-on the VM yet.
FailOver-VRReplication -Replication $Replication -PowerOn $false

#Now we need to find the recovered VM within the vApp. There is always 1:1 relationship between vApp and recovery VM.
$VM = Get-CIVApp -Id $Replication.VappId | Get-CIVM

#We will go through all VM NICs and change their IP allocation mode from DHCP to manual and set new IP address
$i = 0
foreach ($NetworkAdapter in $VM|Get-CINetworkAdapter) {
 Set-CINetworkAdapter $NetworkAdapter -IPAddressAllocationMode Manual -IPAddress $IPAddress[$i]
 $i++
 }

#Guest customization must be enabled so new IP addresses are assigned within the Guest OS upon first boot
$GuestCustomization = $VM.ExtensionData.Section | Where {$_.GetType() -like "*GuestCustomizationSection"}
$GuestCustomization.Enabled = $True
$Result = $GuestCustomization.UpdateServerData()

#We can finaly start the VM
Start-CIVM $VM -RunAsync:$true

And here are the PowerShell functions:

Function Get-VRReplication {
<#
.SYNOPSIS
Collects specific or all replications in particular organization
.DESCRIPTION
Collects specific or all replications in particular organization, their compliance status and other information
.EXAMPLE
PS C:\> Connect-CIServer -Org ACME
PS C:\> Get-VRReplication
PS C:\> Get-VRReplication VM1
.EXAMPLE
PS C:\> Get-VRReplication -Org ACME -Name VM1
.NOTES
Author: Tomas Fojta
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$false,Position=1)]
[String]$Name,
[Parameter(Mandatory=$false,Position=2)]
[String]$Org
)
if (-not $global:DefaultCIServers) {Connect-CIServer}
If ($Org -eq "") {$Org = $global:DefaultCIServers[0].Org}

$VRReplications = @()

$Uri = $global:DefaultCIServers[0].ServiceUri.AbsoluteUri + ((get-org $org).id).Replace("urn:vcloud:org:","org/") + "/replications"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=3.0"}
$r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

foreach ($Replication in $sxml.References.Reference) {
$n = @{} | select Name,href,Rpo,ReplicationState,CurrentRpoViolation,TestRecoveryState,RecoveryState,VappId,VrServerInfo,ReplicaSpaceRequirements, Instance
$n.href = $Replication.href

$r = Invoke-WebRequest -URI $Replication.href -Method Get -Headers $head -ErrorAction:Stop
[xml]$sxml = $r.Content

$n.name = $sxml.ReplicationGroup.name
$n.Rpo = $sxml.ReplicationGroup.Rpo
$n.ReplicationState = $sxml.ReplicationGroup.ReplicationState
$n.CurrentRpoViolation = $sxml.ReplicationGroup.CurrentRpoViolation
$n.TestRecoveryState = $sxml.ReplicationGroup.TestRecoveryState
$n.RecoveryState = $sxml.ReplicationGroup.RecoveryState
$n.VappId = $sxml.ReplicationGroup.PlaceholderVappId
$n.VrServerInfo = $sxml.ReplicationGroup.VrServerInfo.Uuid

$VRReplications += $n
}
if ( $name ) {
 $VRReplications | ? { $_.name -eq $name }
 } else {
 $VRReplications}

}


Function FailOver-VRReplication {
<#
.SYNOPSIS
Fails over replicated VM in the cloud
.DESCRIPTION
Fails over replicated VM in the cloud. The input must be replication object, power-on (default = true) and RunAsync (default false) booleans
.EXAMPLE
PS C:\> Connect-CIServer -Org ACME
PS C:\> FailOver-VRReplication (Get-VRReplication VM1)
.EXAMPLE
PS C:\> FailOver-VRReplication -Replication (Get-VRReplication -Org ACME -Name VM1) -PowerOn:$False -RunAsync:$True
.NOTES
Author: Tomas Fojta
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=1)]
$Replication,
[Parameter(Mandatory=$false,Position=2)]
[boolean]$PowerOn=$true,
[Parameter(Mandatory=$false,Position=3)]
[boolean]$RunAsync=$false
)

if (-not $global:DefaultCIServers) {Connect-CIServer}
If ($Org -eq "") {$Org = $global:DefaultCIServers[0].Org}



$Uri = $Replication.href + "/action/failover"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=4.0"} + @{"Content-Type"="application/vnd.vmware.hcs.failoverParams+xml"}

if ($PowerOn -eq $False) {$body =
'<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:FailoverParams xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:ns2="http://www.vmware.com/vr/v6.0" xmlns:ns3="http://schemas.dmtf.org/ovf/envelope/1" xmlns:ns4="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData"
xmlns:ns5="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ns6="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"
xmlns:ns7="http://schemas.dmtf.org/ovf/environment/1">
<ns2:PowerOn>false</ns2:PowerOn>
</ns2:FailoverParams>'} else
{$body =
'<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:FailoverParams xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:ns2="http://www.vmware.com/vr/v6.0" xmlns:ns3="http://schemas.dmtf.org/ovf/envelope/1" xmlns:ns4="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData"
xmlns:ns5="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ns6="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"
xmlns:ns7="http://schemas.dmtf.org/ovf/environment/1">
<ns2:PowerOn>true</ns2:PowerOn>
</ns2:FailoverParams>'}

$r = Invoke-WebRequest -URI $Uri -Method Post -Headers $head -Body $Body -ErrorAction:Stop
[xml]$sxml = $r.Content

$Uri = $sxml.Task.href
if ($RunAsync -eq $false) {
 Do
 {
 $r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
 [xml]$sxml = $r.Content
 $Progress = $sxml.Task.Progress
 Write-Progress -Activity FailOver -Status 'Progress->' -PercentComplete $Progress
 Start-Sleep -s 5
 } until ($Progress -eq 100)
 }
}

Function TestFailOver-VRReplication {
<#
.SYNOPSIS
Performs test failover of replicated VM in the cloud
.DESCRIPTION
Performs test failover replicated VM in the cloud. The input must be replication object, power-on (default = true) and RunAsync (default false) booleans
.EXAMPLE
PS C:\> Connect-CIServer -Org ACME
PS C:\> TestFailOver-VRReplication (Get-VRReplication VM1) -PowerOn:$False
.EXAMPLE
PS C:\> TestFailOver-VRReplication -Replication (Get-VRReplication -Org ACME -Name VM1) -RunAsync:$True
.NOTES
Author: Tomas Fojta
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=1)]
$Replication,
[Parameter(Mandatory=$false,Position=2)]
[boolean]$PowerOn=$true,
[Parameter(Mandatory=$false,Position=3)]
[boolean]$RunAsync=$false
)

if (-not $global:DefaultCIServers) {Connect-CIServer}
If ($Org -eq "") {$Org = $global:DefaultCIServers[0].Org}



$Uri = $Replication.href + "/action/testFailover"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=4.0"} + @{"Content-Type"="application/vnd.vmware.hcs.failoverParams+xml"}

if ($PowerOn -eq $False) {$body =
'<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TestFailoverParams
xmlns="http://www.vmware.com/vcloud/v1.5"
xmlns:ns2="http://www.vmware.com/vr/v6.0"
xmlns:ns3="http://schemas.dmtf.org/ovf/envelope/1"
xmlns:ns4="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData"
xmlns:ns5="http://schemas.dmtf.org/wbem/wscim/1/common"
xmlns:ns6="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"
xmlns:ns7="http://schemas.dmtf.org/ovf/environment/1">
<ns2:PowerOn>false</ns2:PowerOn>
<ns2:Synchronize>false</ns2:Synchronize>
</ns2:TestFailoverParams>'} else
{$body =
'<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TestFailoverParams
xmlns="http://www.vmware.com/vcloud/v1.5"
xmlns:ns2="http://www.vmware.com/vr/v6.0"
xmlns:ns3="http://schemas.dmtf.org/ovf/envelope/1"
xmlns:ns4="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData"
xmlns:ns5="http://schemas.dmtf.org/wbem/wscim/1/common"
xmlns:ns6="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"
xmlns:ns7="http://schemas.dmtf.org/ovf/environment/1">
<ns2:PowerOn>true</ns2:PowerOn>
<ns2:Synchronize>false</ns2:Synchronize>
</ns2:TestFailoverParams>'}

$r = Invoke-WebRequest -URI $Uri -Method Post -Headers $head -Body $Body -ErrorAction:Stop
[xml]$sxml = $r.Content

$Uri = $sxml.Task.href
if ($RunAsync -eq $false) {
 Do
 {
 $r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
 [xml]$sxml = $r.Content
 $Progress = $sxml.Task.Progress
 Write-Progress -Activity 'Test FailOver' -Status 'Progress->' -PercentComplete $Progress
 Start-Sleep -s 5
 } until ($Progress -eq 100)
 }
}

Function TestCleanup-VRReplication {
<#
.SYNOPSIS
Performs test replication cleanup in the cloud.
.DESCRIPTION
Performs test replication cleanup in the cloud. The input must be replication object and optional RunAsync (default false) boolean.
.EXAMPLE
PS C:\> Connect-CIServer -Org ACME
PS C:\> TeastCleanup-VRReplication (Get-VRReplication VM1)
.EXAMPLE
PS C:\> TestCleanup-VRReplication -Replication (Get-VRReplication -Org ACME -Name VM1) -RunAsync:$True
.NOTES
Author: Tomas Fojta
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=1)]
$Replication,
[Parameter(Mandatory=$false,Position=2)]
[boolean]$RunAsync=$false
)

if (-not $global:DefaultCIServers) {Connect-CIServer}
If ($Org -eq "") {$Org = $global:DefaultCIServers[0].Org}



$Uri = $Replication.href + "/action/testCleanup"
$head = @{"x-vcloud-authorization"=$global:DefaultCIServers[0].SessionSecret} + @{"Accept"="application/*+xml;version=20.0;vr-version=4.0"} + @{"Content-Type"="application/vnd.vmware.hcs.failoverParams+xml"}

$body =
'<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:SyncParams
xmlns="http://www.vmware.com/vcloud/v1.5"
xmlns:ns2="http://www.vmware.com/vr/v6.0"
xmlns:ns3="http://schemas.dmtf.org/ovf/envelope/1"
xmlns:ns4="http://schemas.dmtf.org/wbem/wscim/1/cimschema/
2/CIM_VirtualSystemSettingData"
xmlns:ns5="http://schemas.dmtf.org/wbem/wscim/1/common"
xmlns:ns6="http://schemas.dmtf.org/wbem/wscim/1/cimschema/
2/CIM_ResourceAllocationSettingData"
xmlns:ns7="http://schemas.dmtf.org/ovf/environment/1">
<ns2:RepeatOngoingOnlineSync>false</ns2:RepeatOngoingOnlineSync>
</ns2:SyncParams>'

$r = Invoke-WebRequest -URI $Uri -Method Post -Headers $head -Body $Body -ErrorAction:Stop
[xml]$sxml = $r.Content

$Uri = $sxml.Task.href
if ($RunAsync -eq $false) {
 Do
 {
 $r = Invoke-WebRequest -URI $Uri -Method Get -Headers $head -ErrorAction:Stop
 [xml]$sxml = $r.Content
 $Progress = $sxml.Task.Progress
 Write-Progress -Activity 'Test Cleanup' -Status 'Progress->' -PercentComplete $Progress
 Start-Sleep -s 5
 } until ($Progress -eq 100)
 }
}

Configure Active Directory Federation for vCloud Director Organization

$
0
0

vCloud Director tenants can federate their on-premises identity source with vCloud Director to simplify user management in their vCloud organization. I have already wrote blog post about this topic in the past; this time I will provide step by step instructions how to federate Active Directory with Active Directory Federation Services (AD FS).

Installation and configuration of AD FS is out of scope for this article as there are already very good and detailed guides on the internet.

  1. Download AD FS SAML2 metadata from your AD FS server (https://adfs.acme.com/FederationMetadata/2007-06/FederationMetadata.xml)
  2. As Org Administrator log into vCloud Director and in Administration > Settings > Federation check Use SAML Identity Provider checkbox and upload FederationMetadata file from #1.
  3. Still on the same page fill in Entity ID (must be unique for given IdP) and regenerate certificate. It will be valid for 1 year after which it must be regenerated again.
    Note: Entity ID is available only in vCloud Director 8.10 and newer.
  4. Click Apply.
  5. Download SAML metadata file from https://<vcd_url>/cloud/org/<org-name>/saml/medatadata/alias/vcd.
    Note: vCloud Director 8.10 provides link to the file just above the Certificate Expiration button.
    vcd-config-saml
  6. In Administration > Memebers > Users import SSO users from the SAML source. As user name use email address. Assign a vCloud role.
  7. It is also possible to import SSO groups from the SAML source. However, Groups menu might be missing under Users until you refresh the page (Groups menu got enabled by the step #2). For group import simply use AD group name (without domain).
    Note: If you get log out before setting up AD FS you can always go back to native authentication dialog by entering the following URL: https://<vcd_url>/cloud/org/<org-name>/login.jsp
    groups
  8. That’s all for vCloud Director configuration. The rest must be done in AD FS. Open AD FS Management Console and in Actions menu cling on Add Relying Party Trust. Go through the wizzard and import the SAML metadata file from step #5.
  9. Next we need to Edit claim rules. Under Issuance Transform Rules, using Send LDAP Atributes as Claims template create LDAP claim rule that uses Active Directory as Attribute Store and maps E-Mail-Addresses to E-Mail Address and Token-Groups – Unqualified Names to Groups.
    claim1
  10. Add another transform rule from Transform an Incoming Claim template that transforms E-Mail Address to Name ID.claim2
  11. Last thing that needs to be done is changing Relying Party Trust hashing algorithm from SHA-256 to SHA-1 (can be found in Properties > Advanced).

That’s all, now depending how your browser is configured, when you enter vCloud Director Organization URL you will be redirected to authentication dialog (either native browser or at the AD FS website). Enter AD credentials and if the user had been properly imported into vCloud Director (as individual user or member of a group) you should be logged into vCloud Director UI.

 

Edit 11/24/2016: My faithful readers (thank you Julius) have provided additional links for federations with other IdP solutions:

SafeNet Authentication Service: Integration Guide

RSA SecureID: blog post



Setup Site-to-Site VPN between AWS and vCloud Director

$
0
0

In today’s reality of multi cloud world customers are asking how to set up connection between them. In this article I am going to demonstrate how to set up IPsec VPN tunnel between AWS VPC and vCloud Director Org VDC.

IPSec is standard protocol suite which works at OSI Layer 3 and allows encrypting IP packet communication. It is supported by many software, hardware and cloud vendor implementations, however it is also quite complex to set up due to large sets of different settings which both tunnel endpoints must support. Additionally as it does not rely on TCP L4 protocol NAT traversal can be a challenge.

In my example I am using my home lab vCloud Director instance running behind NATed internet connection. So what could go wrong 🙂

The diagram below shows the set up.

 

AWS Virtual Private Cloud on the left is created with large subnet 172.31.0.0/16, a few instances, and Internet and VPN gateways.

On the right is vCloud Director Org VDC with a network 192.168.100.0/24 behind an Org VDC Edge Gateway which is connected to the Internet via my home ADSL router.

    1. We start by taking care of IPSec NAT traversal over the ADSL router. As I have dd-wrt OS on the router, I am showing how I enabled port forwarding of UDP ports 500 and 4500 to the Edge GW IP 10.0.2.121 and added DNAT for protocols 50 (AH) and 51 (ESP) to the router startup script.
      udp-port-forwardingiptables -t nat -A PREROUTING -p 50 -j DNAT –to 10.0.2.121
      iptables -t nat -A PREROUTING -p 51 -j DNAT –to 10.0.2.121
    2. Now we can proceed with the AWS VPN configuration. In AWS console, we go to VPC, VPN Connections – Customer Gateways and create Customer Gateway – the definition of the vCloud Director Org VDC Edge Gateway endpoint. We give it a name, set it to static routing and provide its public IP address (in my case the public address of the ADSL router).customer-gateway
    3. Next we define the other end of the tunnel – Virtual Private Gatway – in menu below. We give it a name and right after it is created, associate it with the VPC by right clicking on it.virtual-private-gateway
    4. Now we can create VPN Connection in the next menu below (VPN Connections). We give it a descriptive name and associate Virtual Private Gateway from step #3 with Customer Gateway from step #2. We select static routing and provide the subnet at the other end of the tunnel, which is in our case 192.168.100.0/24. This step might take some time to finish.
    5. When the VPN Connection is created we need to download its configuration. AWS will provide the configuration in various formats customized for the appliance on the other side of the tunnel. Generic format will do for our purposes. Needless to say, AWS does not allow custom setting of any of the given parameters – it is take it or leave it. download-configuration
    6. Before leaving AWS console we need to make sure that the subnet at the other side of the tunnel is propagated to the VPC routing table. This can be done in the Route Table menu, select the existing Route Table, in the Route Propagation tab find the Virtual Private Gateway from step #3 and check Propagate check box.route-table
    7. To configure the other side of the VPN endpoint – the Org VDC Edge Gateway we need to collect the following information from the configuration file obtained in the step #5.
      Virtual Private Gateway IP: 52.x.y.z
      Encryption Algorithm: AES-128
      Perfect Forward Secrecy: Diffie-Hellman Group 2
      Pre-Shared Key (PSK): 32 random characters
      MTU: 1436.Note: As was said before, none of these parameters can be changed on AWS side. So the router on the other side must support all of them. And here we hit a little issue. AWS pre-shared key is generated with number and letter (upper and lower case) characters and a special character – like dot, underscore, etc. Unfortunately vShield Edge does not support PSK with special character. NSX Edge does, but the legacy vCloud Director UI/API will not allow us to create IPsec VPN configuration with PSK containing special character. There are various ways how to solve it. One is not to use the native AWS VPN Gateway and instead use software VPN option, another is to create/edit the VPN configuration directly in NSX Manager (only Service Provider can do this) and lastly convert the Edge Gateway to Advanced Gateway and take advantage of the new networking UI and API that does not have this limitation (this functionality is currently available only on vCloud Air, but will soon be available to all vCloud Air Network providers).
    8. In vCloud Director UI go to Administration, select your Virtual Datacenter, Edge Gateways tab and right click on the correct Edge GW to select its Edge Gateway Services.edge-gw-services
    9. In The VPN tab Enable VPN by clicking the checkbox. In my NATed example I also had to configure public IP for the Edge GW (which is the address of the ADSL router).enable-vpn
    10. Finally we can create the VPN tunnel by clicking the Add button and selecting Establish VPN to a remote network pulldown option. Select local network(s) (192.168.110.0/24), in peer networks enter AWS VPC subnet (172.31.0.0/24), select internet interface of the Edge in the Local Endpoint, enter its IP address (10.0.2.121). For Peer ID and Peer IP use public address of Virtual Private Gateway from step #7. Change Encryption algorithm to AES and paste Shared Key (see the note in #7). Finally modify MTU size (1436).

If everything was set correctly then back in AWS console, under VPN Connections, Tunnel details we should see the tunnel status change to UP.

AWS offers two tunnel endpoints for redundancy, however in our case we are using only Tunnel 1.

tunnel-status-in-aws

If the firewall in Org VDC and Security Groups in AWS are properly set, we should be able to prove tunnel communication with pings from AWS instance to the Org VDC VM.

ping-test


Setup Site-to-Site VPN between Azure and vCloud Director

$
0
0

My previous blog post was about setting up IPSec VPN tunnel between AWS VPC and vCloud Director Org VDC. This time I will describe how to achieve the same with Microsoft Azure.

vCloud Director is not among Azure list of supported IPSec VPN endpoints however it is possible to set up such VPN although it is not straightforward.

I will describe the setup of both Azure and VCD endpoints very briefly as it is very similar to the one I described in my previous article.

Azure Configuration

  • Resource Group (logical container object) – in my example RG UK
  • Virtual network (large address space similar to AWS VPN subnet) – 172.30.0.0/16
  • Subnets – at least one for VMs (172.30.0.0/24) and one for Gateway (172.30.255.0/29)
  • Virtual Network Gateway – Azure VPN endpoint with public IP address associated with the Gateway subnet above. Gateway type is VPN, VPN type is Policy-based (this is because Route-based type uses IKE2 which is not supported by NSX platform used by vCloud Director).
  • Local Network Gateway – vCloud VPN endpoint definition with its public IP address and subnets that should be reachable behind the vCloud VPN endpoint (81.x.x.x, 192.168.100.0/24)
  • Connection – definition of the tunnel:
    • Connection type: Site-to-site (IPSec)
    • Virtual network gateway and local network gateway are straightforward (those created previously)
    • Connection name: whatever
    • Shared Key (PSK): create your own 32+ character key using upper and lower case characters and numbers
  • Test VM connected to the VM subnet (IP 172.30.0.4)

azure-resources

vCloud Configuration

As explained above we created Policy Based VPN endpoint in Azure. Policy Based VPN uses IKE version 1, Diffie-Hellman Group 2 and no Perfect Forward Secrecy.

However selection of DH group and PFS is not available to tenant in vCloud Director on the legacy Org VDC Edge Gateway. Therefore the following workaround is proposed:

Tenant configures VPN on his Org VDC Edge Gateway with the following:

  • Name: Azure
  • Enable this VPN configuration
  • Establisth VPN to: a remote network
  • Local Networks: 192.168.100.0/24 (Org VDC network(s))
  • Peer Networks: 172.30.0.0/24
  • Local Endpoint: Internet (interface facing internet)
  • Local ID: 10.0.2.121 (Org VDC Edge GW internet interface)
  • Peer ID: 51.x.x.x (public IP of the Azure Virtual network gateway)
  • Peer IP: 51.x.x.x (same as previous)
  • Encryption protocol: AES256
  • Shared Key: the same as in Azure Connection definition

Now we need to ask the service provider to directly in NSX in the Edge VPN configuration disable PFS and change DH Group to DH2.

nsx-vpn

Note that this workaround is not necessary on Org VDC Edge Gateway that has been enabled with Advanced Networking services. This feature is at the moment only in vCloud Air, however soon will be available to all vCloud Air Network service providers.

If all firewall rules are properly set up we should be able to ping between Azure and vCloud VMs.

ping


vCloud Availability: Replication Traffic Deep Dive

$
0
0

VMware this week released vCloud Availability 1.0.1. It is a disaster recovery as a service solution that extends vCloud Director and enables VM replications between vSphere environments and a multitenant public cloud.

One of the unique features it offers is that there is no need for private networks for replication traffic between the tenant on-prem environment and the public cloud. The bi-directional replication can securely traverse the Internet and in this post I will dive deeper into how this is technically achieved.

On-Premises Components

The tenant on-prem environment can run almost any version of vSphere together with vSphere Replication (VR) appliance. The appliance must have access to the internet but does not need to have an external internet routable IP address. It can be behind a firewall with Source NATing and only one port open – TCP 443.

The appliance runs various services:

  • vSphere Replication Manager Service (vRMS) – the brain of the on-prem VR solution with an internal or optionally external database. It also provides the vSphere Web Client plugin extension for managing the replication.
  • vSphere Replication Server (vRS) – staging point for incoming (from-the-cloud) replications before they are de-staged via ESXi hosts to target datastores. This component can scale-out if needed by deploying additional appliances (cca 200 incoming replications for each vRS). It is not in the path for outgoing (to-the-cloud) replications.
  • vCloud Tunneling Agent (vCTA) – component that provides secure tunnel connections to the cloud. It also keeps control connection open so reverse replication can be initiated as well. More on that later.

That is it. There is nothing else needed to be installed by the tenant. This is because the actual replication engine (the vSphere Replication agent and vSCSI filter) is already present in the hypervisor – ESXi VMkernel. This also means no dependency what so ever on the storage hardware.

To-the-cloud replication flow:

ESXi host (VR Agent) > vSphere Replication Appliance (vCTA) > Internet > vCloud Availability public endpoint (Cloud Proxy load balanced VIP)

From-the-cloud replication flow:

vCloud Availability public endpoint (Cloud Proxy) > Internet > vSphere Replication Appliance (vCTA) > vSphere Replication Server (either embedded on VR appliance or standalone) > ESXi host

Public Cloud Components

In the cloud we need to have supported version of vCloud Director. It consists of multiple load balanced vCloud Director cells, database and resource vSphere environments.

For vCloud Availability we need vSphere Replication components – vRMS appliances for each resource vCenter Server and vRS appliances for replication staging that scale-out based on number of replications.

Additionally we need:

  • vSphere Replication Cloud Service (vRCS) – highly available appliances. The brain of the solution with extended vCloud VR APIs. It needs external Cassandra database and RabbitMQ to communicate with vCloud Director.
  • Cloud Proxies – load balanced vCloud Director cell like components with all vCloud services disabled with only the Cloud Proxy service running (multitenanted vCTA)
  • vCloud Availability Portal appliances – load balanced stateless components that provide portal to manage replications in the cloud when the on-prem vSphere Replication UI is not available (in disaster situations).

The provider can serve hundreds of customers with thousands of concurrent tunnels. To achieve such level of scalability, the Cloud Proxies are deployed in scale-out fashion with load balancer in front. The load balancer provides single endpoint for the on-prem vCTA control connection as well as for the to-the-cloud replication traffic.

To-the-cloud replication flow:

Tenant on-prem VR Appliance > Internet > Load balancer > Cloud Proxy (tunnel termination and decryption) > vRS > ESXi host.

From-the-cloud replication flow:

In order not to require public visibility of the on-prem tenant VR Appliance, the from-the-cloud replication is set up in a quite clever way. There are two options of doing this – one with load balancer with L7 application rules and the other without. The seconds approach is more scalable and recommended so let me describe it.

The following diagram shows the workflow:

from-the-cloud-replication

As was said before the connection is always initiated by the on-prem environment. That’s why we have the control connection (1) that is load balanced to one of the Cloud Proxies (in our example Cloud Proxy 2). The replicated traffic is coming from in the cloud resource ESXi host that sends it (2) via internal load balancer to one of the Cloud Proxies – in our case Cloud Proxy 1 (3). Through the control connection the on-prem vCTA endpoint is notified which Cloud Proxy is used for the particular replication (4-7). Now the on-prem vCTA can establish new connection to the correct Cloud Proxy 1 – it does not use its load balanced address, but instead a direct IP/FQDN that is DNATed 1:1 to the Cloud Proxy (9). Finally the two connections (3) and (9) can be stitched together (10) and we can start sending from-the-cloud replication traffic all the way to the on-prem environment.

To summarize, we need:

  • Cloud Proxy load balancer with CloudProxyBase VIP that is used for the Control connection and to-the-cloud replications.
  • Internal load balancer for resource ESXi to Cloud Proxy (from-the-cloud) traffic.
  • Additional public IP/FQDN for each Cloud Proxy for from-the-cloud traffic. This FQDN is configured on the Cloud Proxy cell in global.properties file (cloudproxy.reverseconnection.fqdn=FQDN:443).
  • As a consequence of using the same Cloud Proxy under different FQDNs (CloudProxyBase VIP and Cloud Proxy reverse connection) we need to take care that Cloud Proxy cell http certificate is set for both FQDNs. Probably the easiest way to achieve this is to use wild card certificate on cloud proxies (CN *.cloudproxy.example.com).

Monitoring vSphere Replication RPO Compliance

$
0
0

Just a quick post to show how you can monitor Recovery Point Objective (RPO) compliance of a virtual machines protected with vSphere Replication.

Option 1: vCenter Server Alarm

When vSphere Replication Appliance is registered to vCenter Server multiple new vSphere Replication Event Types become available and can be used for creation of custom alarms.

List of all these event types can be queried with the following one-line PowerCLI command:

(get-view eventManager).get_Description()| select -expand Eventinfo |where FullFormat -like “*Hms*”

The following example will show how to set alarm for event “RPO violated”

Key:ExtendedEvent
Description: RPO violated
Category: error
FullFormat: com.vmware.vcHms.rpoViolatedEvent|Virtual machine vSphere Replication RPO is violated by [data.currentRpoViolation] minute(s)

  1. In vCenter Server go to Manager, Alarm Definitions and add new alarm
  2. Set alarm name, monitor VMs and specific events.
    new-alarm
  3. Enter the trigger (com.vmware.vcHms.rpoViolatedEvent)
    alarm-trigger
  4. Add Alarm actions (email, SNMP trap, run command etc.) as necessary.

Triggered alarm:

triggered-alarm

Note that this alarm applies only to VMs replicated from the particular vCenter Server. So it will not be triggered on VMs replicated to this vCenter Server.

Option 2: vCloud API

This options applies only for VM replications to or from a cloud provider who uses vCloud Availability add-on. The vCloud Director tenant APIs are extended with replication APIs. The state of each replication can be retrieved with:

GET /api/vr/replications/<replication-id>

and

GET /api/vr/failbackreplications/<replication-id>

Where list of all replications and their replication-ids is retrieved at org level with these two API calls:

GET /api/org/<org-id>/replications

and

GET /api/org/<org-id>/failbackreplications

An example of VM1 replication state (RPO 15 mins, not active with 16 min RPO violation):

replication-api

The following tables describes all the elements of the API response:

replication-details


vCloud Director 8.20: VM Auto-import

$
0
0

While the biggest new feature of vCloud Director 8.20 is the access for tenants to NSX advanced services on Edge Gateways and distributed firewall, service providers will love automatic import of vCenter virtual machines.

Import of vCenter VMs under vCloud Director management was around for long time, but the VM had to be in powered off state. In vCloud Director 8.10, the possibility of running VM import was introduced (vCloud API only feature). However, vCloud Director 8.20 simplifies this even more:

The system administrator can just drag any vCenter VM into Org VDC resource pool and vCloud Director will automatically discover such VM and import it. The VM can be even in running state. This enables migration use cases, or allows service providers to easily offer self service access to their fully managed vSphere only environments by simply connecting them to vCloud Director.

In the picture below you can see Org VDC Resource Pool (ACME_PAYG) in vCenter hierarchy with two regular vCenter VMs that were dragged there. VM_C1 was running, while VM_P2 was powered-off.

resource-pool

The next picture shows automatically created vApps for these two imported VMs with the prefix Discovered.

vapps

While these vApps resemble regular vApps they are not real vCloud Director vApps until they are adopted. The adoption happens when the VM inside the vApp is somehow reconfigured.

By default VM discovery is enabled for every Organization in vCloud Director. It can be disabled in General Settings (UI or API)

general-settings

or with CMT command on VCD cell:

cell-management-tool manage-config -n managed-vapp.discovery.activated -v false

This behavior can be overridden at Org VDC level with API element <VmDiscoveryEnabled>.

Here are the differences between Discovered and Adopted vApp:

Discovered vApp

  • Looks like a regular vApp
  • Can have only one VM per discovered vApp
  • vApp contains API element <autoNature>true</autoNature>
  • When imported VM is deleted in VC or VCD, its vApp object will get automatically purged
  • Is owned by system
  • Is not subject to Org lease settings

Adopted vApp

  • Regular vCloud Director vApp
  • Can contain multiple VMs, vApp networks, etc.
  • Discovered vApp will get adopted when it is reconfigured (other than changing its name or description)

Other Considerations

  • Discovery process runs in the background every 3 mins
  • Failed VM import is retried after 60 mins. This can be changed with CMT command (example for 25 seconds):
    cell-management-tool manage-config -n managed-vapp.discovery.retry-delay-sec -v 25
  • The following VMs cannot be imported: Fault Tolerant VMs, VMs with creation/upload process in VC, templates, VCD shell VMs
  • VM must be connected to Org VDC network.
  • VM can be running or powered off.
  • VM does not need to use Org VDC storage policy. If it resides on unknown storage policy, it is automatically relocated to the default Org VDC storage policy during the adoption however the VM must be in powered off state.
  • VM with IDE controller must be in powered off state.
  • VM CPU/RAM resources are changed based on Org VDC allocation type.
  • VM resources are not subject to Org VDC allocation restrictions, but are charged against it.
  • VM name in VC remains intact until it is adopted and renamed
  • New vSphere 6.5 guest operating systems are not recognized and are imported as Other (32-bit) OS.

Viewing all 242 articles
Browse latest View live