Cross vCenter NSX failover and failback

So what does NSX cross vCenter failover look like in a real world scenario?

In this setup, we have 2 NSX managers across two sites, with Site A hosting the primary and DR Site hosting the secondary NSX manager. Simulating a DR scenario, the primary NSX manager, all 3 controllers and all the universal DLR control-VMs are shutdown in Site A

 

PowerCLI: Listing VMs from a bunch of vCenters

I need to grab all the VMs in a list of vCenters, but for each line of VM, I need to know which cluster and ESXi host they sit in. The original script was this;

Get-content .\vc.txt |
% {$vc=$_ ; connect-viserver $vc ; Get-VM |
Select Name, Vmhost, @{Name="Cluster";
Expression={ ((get-vmhost $_.vmhost).parent)}}, Folder,
@{Name="vCenter"; Expression= {$vc}} |
export-csv .\$vc.txt -NoTypeInformation ;
disconnect-viserver $vc –force –confirm:$false }

Even thought the code was straight forward with just a single get-VM execution, it was very slow. The reason was the Cluster field code block, which executes get-vmhost to get the cluster name for each VM, took time to execute.

@{Name="Cluster"; Expression={ ((get-vmhost $_.vmhost).parent)}}

A faster one-line calls each cluster first, then calls each VM in turn.

Get-content .\vc.txt |
% {$vc=$_ ; connect-viserver $vc ; Get-Cluster |
% { $clus=$_.name; Get-VM -Location $Clus |
% { "$($_.name)`t$($_.id)`t$($_.folder)`t$($_.vmhost)`t$Clus`t$vc" |
out-file .\$vc.txt -append }} ;
disconnect-viserver $vc –force –confirm:$false }

 

RP4VM failover testing network

Updated this article after Peter’s comments and my own testing

During failover of an RP4VM consistency group (CG), you have a few choices of selecting the test network to failover your VMs in. Why is this necessary?

 

RP4VM + vRA: caveats that DELL/VMware may not want to tell you

RecoverPoint for Virtual Machine (RP4VM) allows you to create disaster recovery per Virtual Machine in your vSphere environment. By itself, the application is great because you can pick and choose what VMs to protect, test failover and even restore your production VM at various points in time. However, if you have vRealize Automation (vRA) and the vendor is trying to sell you the miracle of self-service DRaaS that RP4VM+vRA can bring, you may want think harder about it.

Note: this is a review of 4.3, but I didn’t think much changed for 5.0

1. Very limited set of services from vRA blueprint, not true DRaaS

A very limited set of services are exposed to the automation blueprint. As far as I am aware, there are no other means of creating customized workflow if the standard blueprint does not satisfy you requirements for DRaaS. There are no blueprints to perform production failover, test failover nor to manage CGs or protected VMs. The current blueprint only allows a user to create protected VMs. All other administration has to be done from vSphere.

 

NSX: Edge high availability dead time value

Well studying for my NSX 6.2 exams, I found that there were some confusing over dead time value and polling interval for NSX edge HA. While doing my NSX class I asked my instructor about it and he clarified the following:

In NSX Edge HA configuration (as of 6.3) :-

• Default Declare dead time is 15 seconds
• The minimum acceptable value 9 seconds, anything below 9 seconds will not work
• The polling interval is 1 seconds

You can see the polling interval by running “debug packet” commands in the edge.

How does the dead time value impact connectivity? As a quick test, I have a machine pinging another machine behind the Edge HA.

Dead time = 15 seconds –> 11 ping time out

Dead time = 9 seconds –> 4 pings time out

 

PowerCLI: Getting VMHosts, PortGroups and switches info

I needed to extract a list of hosts in vCenter and with them, get all the portgroups and switch info. Unfortunately, there is no one one-liner script that can do this. Mainly because you have standard and distributed switches and their properties are different. In order to do this you need to separate one-liner, both feeding into the same output file.

The first script output the hosts against their VDSwitches. The script creates a tab-delimited text file that you can easy copy and paste onto a spreadsheet. Both scripts output the following:
– Clustername
– Hostname
– virtual network adapter name
– IP
– subnet mask
– port group name
– switch name
– VLAN ID

Get-VMHostNetworkAdapter -vmkernel | 
% { $vnet=$_ ; get-vdportgroup -vmhostnetworkadapter $vnet | 
%{"$($vnet.vmhost.parent)`t$($vnet.vmhost)`t
$($vnet.name)`t$($vnet.ip)`t$($vnet.subnetmask)`t
$($_.name)`t$($_.vdswitch)`t$($_.vlanconfiguration)" | 
out-file .\temp\output.txt -append } }

The second script output the hosts against their standard switch, as you can see the order of the function is very different. The main reason is that VMHostNetworkAdapter object cannot be pipped into the VirtualPortGroup but it works the other way around.

You can also see from the second script the the names for virtualswitch and vlanID different from the above. Actually .vdswitch and .vlanconfiguration are objects themselves, but they are nice enough to output the values I want without needing to specify the actual object, i.e. switch name and VLAN ID.

Get-VirtualPortgroup -standard | 
% { $pg=$_ ; get-vmhostnetworkadapter -portgroup $pg | 
% { "$($_.vmhost.parent)`t$($_.vmhost)`t$($_.name)`t
$($_.ip)`t$($_.subnetmask)`t$($pg.name)`t
$($pg.virtualswitch.name)`t$($pg.vlanid)" |
 out-file .\temp\output.txt -append }}

 

ESXi host performance issues and the importance of thermal paste

A totally interesting read on how the team in VMware resolved an issue with a non performing HP blade. The final take away from this is:

• Thermal paste really can impact performance!
• HP Active Health System logs should (but don’t) include when CPU’s clock down to prevent overheating.
• CPU clock throttled error message don’t appear in ESXi logs.

http://www.vmspot.com/esxi-host-performance-issues-and-the-importance-of-thermal-paste/