vRealize Orchestrator – Resolving the ${message} blue screen issue

Here’s an issue that frustrated me for a while until I was able to finally resolve it. If you’re here reading this too, I feel your pain… Hopefully this helps you out as well!

I’m deploying vRealize Orchestrator (vRO) 7.3 in our lab for testing as I continue to build our cloud environment. To help detail the issue we have been having, I’ll provide a quick overview of our environment.

For our cloud, we have three separate environments:

  • Core
    • Management nodes (NSX mgr, AD, DNS, SQL, PSCs for vCenter, and vCenter)
  • Automation
    • vRealize suite (vRO, vRA, IaaS, SQL, PSC for Auto environment)
  • Networking
    • NSX load balancer, ESGs, DLRs

During the initial vRO configuration, you configure it as standalone and then choose your authentication method. We are using vSphere authentication which will authenticate via the PSC (Platform Services Controller) in the Auto environment. We have a single SSO domain with relationships setup between the Core PSC and the Auto PSC.

Now that I’ve set the premise, let’s talk about the issue at hand. During the vRO standalone config, if you are using a load balancer you have to change the hostname to the your LB VIP for vRO. Then on the next screen you configure your authentication source. We’re using vSphere authentication and set it to our Automation PSC. Once complete, you’re taken right into control center using the root account. If you logout at any point, you may encounter the following issue when trying to browse back to control center (https://vro1.domain.local:8283/vco-controlcenter)


Here’s what I realized after seeing this issue and attempting various failed fixes… we had missed a step during our NSX load balancer configuration. Since the hostname was set to the vRO VIP and the authentication source now set to our PSC, SSO was looking to authenticate via our VIP rather than the local node. This lead us back to NSX where we had to configure another virtual server for port 8283 and a pool for our two vRO nodes as well.

Here’s what we ended up configuring on the NSX end:

NSX Virtual Server on the Load Balancer


NSX Pool on the Load Balancer


Once that was in place, I was able to get to the vRO control center using the VIP address. I also was able to join the second node to the cluster and verify all was good on that end after applying our needed SSL certificate!


VMware, XtremIO, and Native Multipathing


So, you have your XtremIO installed, configured, and ready for use. Now what? If you’re like most I’ve worked with, you have probably already started creating volumes, presented them to your ESXi hosts, and have created datastores. Often times, I am finding myself working with customers who express some performance concerns post-migration to XtremIO and it is usually due to a commonly overlooked item in the EMC Host Configuration Guide.

The most overlooked item is in regards to VMware Native Multipathing. If you’re familiar with the EMC VNX arrays, you probably noticed that the VNX devices presented in vCenter defaulted to a Round Robin path policy. This is because VMware had a rule in place that identified CX/VNX arrays to accommodate for ALUA (active/active) and would assign that policy (VMW_SATP_ALUA_CX) to those devices which set them to Round Robin instead of Fixed Path.

With the XtremIO, there is no such in rule in place. By default, the XtremIO devices will identify with policy VMW_SATP_DEFAULT_AA and I have noticed that the path selection policy is set to Fixed (Default).

To overcome this, it is recommended to create a new Storage Array Type policy per the EMC XtremIO Host Configuration Guide.

esxcli storage nmp satp rule add -c tpgs_off -e “XtremIO
Active/Active” -M XtremApp -P VMW_PSP_RR -O iops=1 -s
VMW_SATP_DEFAULT_AA -t vendor -V XtremIO

This creates a custom rule for XtremIO devices, sets the path selection policy to Round Robin, and then sets the path switching frequency from a default of 1000 I/O packets to 1. This ensures optimal distribution and availability of load between I/O paths to the XtremIO storage.

As you may see in the Host Configuration Guide, it is noted below:

Note: With NMP in vSphere versions below 5.5, clustering is not supported when the
path policy is set to Round Robin. For details, see vSphere MSCS Setup Limitations in
the Setup for Failover Clustering and Microsoft Cluster Service guide for ESXi
5.0 or ESXi/ESX 4.x. In vSphere 5.5, Round Robin PSP (PSP_RR) support is introduced.
For details, see MSCS support enhancements in vSphere 5.5 (VMware KB 2052238).

Note: Use this method when no XtremIO volume is presented to the host. XtremIO volumes already presented to the host are not affected by this procedure (unless they are unmapped from the host).

If you find yourself in the situation above with volumes already mapped and datastores created, you can simply storage vMotion your VMs over to new XtremIO volume datastores with this new rule in place.


To continue with part 3 of this series, I will quickly recap where we left off.

  • We have a source VNX and a target XtremIO that we need to migrate boot LUNs and VMware RDMs to
  • SANcopy enabler installed on source VNX
  • VNX SP ports are zoned to XtremIO target brick (in my case, I am using brick 4 of a 4-brick cluster)
  • We have identified our source LUNs and created our target XtremIO volumes

For our BOOT from SAN LUNs, we do not need these to be incremental SANcopy sessions as they are only 30GB in size each. To cutover the boot LUN, we will do the following:

  1. Place the host maintenance mode to evacuate any/all VMs on the host
  2. Shutdown the host
  3. Start the SANcopy session
  4. Once complete, remove the source volume from the VNX host storage group
  5. Map the boot volume to the VMware host as HLU 0 on the XtremIO
  6. Adjust host boot from SAN policy (in my case, I am working with UCS hosts)
  7. Boot host and verify successful boot
  8. Exit maintenance mode

The SANcopy session can be created in either the VNX GUI or CLI using naviseccli. You will need to know the following: source LUN name (or ID), source LUN GUID (wwn), target XtremIO FC ports, target volume mapped HLU # to the VNX initiator group.


As you see here, I mapped host 1’s target boot volume as HLU 1 to the VNX initiator group. (Host 2 mapped as HLU 2, etc.) I decided to create my SANcopy sessions in the CLI as I have about 40 host boot LUN sessions to create.

naviseccli -h -User sysadmin -Password sysadmin -Scope 0 sancopy -create -name “LUN 47_BOOT LUN_ESXP10” -srcwwn 60:06:01:60:BB:B4:30:00:61:28:DD:1D:82:F0:E1:11 -fibre -destportwwn 51:4f:0c:50:62:07:af:30 10 -throttle 8 -verify -o

This syntax breaks down like this:

naviseccli -h (SP IP) -User <username> -Password <password> -Scope 0 sancopy -create <session name> -srcwwn <source LUN GUID / WWN> -fibre -destportwwn <XtremIO target FC WWN> <destination LUN number (HLU)> -throttle <0 – 10> -verify -o

While scripting out my session create commands, I am alternating between SCs and ports on the XtremIO to balance the load out.


As for our incremental sessions, we need to create a Reserved LUN Pool that the incremental sessions will use. For that we will follow EMC best practices and create our incremental sessions accordingly. More to come on that soon!

VMware Migration of VMs and RDMs from VNX to XtremIO – Part 2


In continuing with part 2 of this series, I’m going to discuss zoning requirements for SANcopy on the XtremIO. To recap before we begin, I have a VMware environment that I am migrating from VNX to XtremIO. Most of this environment can be migrated via storage vMotion to the XtremIO. However, there are quite a few of VMs that have physical mode RDMs that need to be migrated via SANcopy. We chose SANcopy over Open Migrator because these following reasons:

  • SANcopy enabler is installed on the source VNX
  • SANcopy will require one outage to shutdown the server on time of cutover
  • SANcopy is array-based and would not impact the host CPU
  • Open Migrator is only supported for Microsoft Windows Server
  • Open Migrator requires three reboots to migrate (one to attach filter driver to source and target drives, two to actually cutover one drives are in sync, and three to uninstall the software)

First things first; we need to zone our target XtremIO to the source VNX. With following EMC Best Practices, we will create 1-to-1 zones on each Fabric for SP A and SP B ports to two controllers.

Fabric A

Zones Source VNX Target XtremIO
Zone 1 SP A-port 5 X1-SC1-FC1
Zone 2 SP A-port 5 X1-SC2-FC1
Zone 3 SP B-port 5 X1-SC1-FC1
Zone 4 SP B-port 5 X1-SC2-FC1
* SP A-port 5 and SP B-port 5 are connected to Fabric A in my environment*

Fabric B

Zones Source VNX Target XtremIO
Zone 1 SP A-port 4 X1-SC1-FC2
Zone 2 SP A-port 4 X1-SC2-FC2
Zone 3 SP B-port 4 X1-SC1-FC2
Zone 4 SP B-port 4 X1-SC2-FC2
* SP A-port 4 and SP B-port 4 are connected to Fabric B in my environment*

You should end up with zones that look something like this:

zone name XIO3136_X1_SC1_FC2_VNX5500_SPA_P4 vsan 200
member fcalias XIO3136_X1_SC1_FC2
member fcalias VNX_SPA_P4
zone name XIO3136_X1_SC2_FC2_VNX5500_SPA_P4 vsan 200
member fcalias XIO3136_X1_SC2_FC2
member fcalias VNX_SPA_P4
zone name XIO3136_X1_SC1_FC2_VNX5500_SPB_P4 vsan 200
member fcalias XIO3136_X1_SC1_FC2
member fcalias VNX_SPB_P4
zone name XIO3136_X1_SC2_FC2_VNX5500_SPB_P4 vsan 200
member fcalias XIO3136_X1_SC2_FC2
member fcalias VNX_SPB_P4

Yes… yes… I know I used the acronym XIO (XIO is not XtremIO) for my fcalias and zone names. Sorry! 🙂

You can choose to split this across multiple bricks if you have more than one brick in your XtremIO cluster. Even though, you really only need to zone one storage controller at a minimum, we are choosing to zone two controllers and will split the SANcopy sessions across the two controllers to balance out the load.

Once we have our zoning in place, we should now see the VNX visible from the XtremIO. You can view this in the CLI by issuing the show-discovered-initiators-connectivity command or in the GUI by creating a new initiator group for the VNX and selecting the drop down to show the SP A and SP B WWPNs. Create a new initiator group on the XtremIO for the VNX and map the target volumes for the SANcopy session to this initiator group. Take note of the HLU you assigned to the volume mapping and also the target FC ports on the XtremIO you zoned to the VNX.

xmcli (admin)> show-discovered-initiators-connectivity
Discovered Initiator List:
Cluster-Name Index Port-Type Port-Address Num-Of-Conn-Targets
ATLNNASPXTREMIO01 1 fc 50:06:01:61:08:60:10:60 2
ATLNNASPXTREMIO01 1 fc 50:06:01:62:08:60:10:60 2
ATLNNASPXTREMIO01 1 fc 50:06:01:64:3e:a0:5a:ed 2
ATLNNASPXTREMIO01 1 fc 50:06:01:65:3e:a0:5a:ed 2
ATLNNASPXTREMIO01 1 fc 50:06:01:69:08:60:10:60 2
ATLNNASPXTREMIO01 1 fc 50:06:01:6a:08:60:10:60 2
ATLNNASPXTREMIO01 1 fc 50:06:01:6c:3e:a0:5a:ed 2
ATLNNASPXTREMIO01 1 fc 50:06:01:6d:3e:a0:5a:ed 2


The next part of this guide will discuss what is needed on the VNX source before SANcopy sessions can be created. We are going to talk about reserved LUN pool, requirements around that, and creating the SANcopy session itself. Stay tuned!


VMware Migration of VMs and RDMs From VNX to XtremIO – Part 1

In today’s digital age with virtualization leading the way, you will often find yourself in a situation dealing with VMs and RDMs. RDMs are Raw Device Mappings and it is a way to present a physical LUN to a VM directly as if it was accessing direct-attached storage. Often what proves to be a daunting task is the ability to migration these RDMs that are attached to VMs. I’m going to discuss how to identify which VMs have RDMs, which storage array they belong to, and map it back to the physical LUN on that storage array.

  • The first thing you will want to do is to scan vCenter for VMs with RDMs
    • You will need read access to vCenter and you should have VMware powerCLI installed on your desktop
    • Connect to vCenter through powerCLI
      • Connect-VIServer yourvcenterhostname.domain.local
    • Run a get-VM script selecting the VM hostname, raw device, NAA ID, and hard disk number
      • Get-VM | Get-HardDisk -DiskType “RawPhysical”,”RawVirtual” | Select Parent,Name,DiskType,ScsiCanonicalName,DeviceName | format-table | Out-File –FilePath “out-file-location-on-your-terminal”
  • Once the script completes, you should have a text file that can be imported into excel as text data delimted or fixed width
  • Use the data filter and sort by NAA or SCSIcanonicalname
  • Use this and the source array collects or logs to compare and identify which pertain to your migration
    • In my example, I am migrating from a VNX to XtremIO. I will be using the SCSI Canonical Name and comparing that to the LUN UID/WWN from the SP collect



Once you have identified the VMs in the list that pertain to your migration, you are now ready to begin planning next steps. In my scenario, I am migrating VMs residing on a VNX to a XtremIO. There is a mixture of Virtual and Physical RDMs which means that along with Storage vMotion, I will be using SANcopy to create incremental sessions and pushing the physical RDMs to the XtremIO.

Other tools such as Open Migrator and PPME (if PowerPath is present) can be used as an alternative host-based migration approach, but each tool as its caveats and may still require a reboot to cut over. I will discuss SANcopy from VNX to XtremIO in a future post.

Mounting a NFS share from Exagrid to a VMware host

After endlessly searching through Google (by endlessly I mean various searches with only scanning the first or second page and spending roughly about 2 – 3 minutes on each page), we bit the bullet and called Exagrid support to assist us with mounting a NFS share in VMware. This is what I learned from that experience.

  • By default, Exagrid uses NFSv4 when using the directory path serverIPaddress:/NFSshare
  • To mount this in VMware you need to force it to use NFSv3
  • When trying to mount the share using simply /Backup we were receiving the following error:
    • NFS mount ip-address:mountpoint failed: The mount request was denied by the NFS server. Check that the export exists and that the client is permitted to mount it.

To mount the NFS share in VMware use the following path pre-fix in front of your share:

  • /home1/shares/
    • Example: my NFS share in Exagrid is Backup, so in VMware my path will be: /home1/shares/Backup

You should see that VMware is able to successfully add the NFS share as a datastore.


VMware ESXi 5 Whitebox

I just recently purchased a new PC which I have turned into my VMware ESXi 5.0 Whitebox. More posts to come soon as I prepare my virtual environment!

Gateway DX4860
Intel i5 processor

This screen shows the ESXi host management console. It’s a custom version of Linux designed by VMware to be a baremetal hypervisor and leave a minimal footprint on the host.

With the ESXi host prepared, we are now ready to navigate to the IP address of the host to install VMware Virtual Infrastructure Client on my laptop. This will be used to remotely manage the host and virtual machines.

This the welcome screen you receive when navigating the host’s IP address. On this page, vmWare provides you tools needed to remotely manage the ESXi host.

Using VMware Virtual Infrastructure client to access the host. I logged into the host using the root credentials, but once my servers are configured access will be delegated through Active Directory user accounts with the required security group privilege.

Preparing for Windows Server 2008 to be installed as a virtual machine. This will be my Primary Domain Controller on my network.

Installing Windows Server 2003. This will just be a member server on the domain and will have VMware virtual infrastructure client installed on it. That way, if I don’t have my primary Windows laptop I can still VPN back to that server and access the ESXi host using that virtual machine. This machine will also run automated tasks, scripts, and handle backups.

A quick view of the usage statistics with both virtual machines running.