vCloud Director 5.6.4 Remote consoleproxy issues

June 12th, 2015 by jason No comments »

vCloud Director is a wonderful IaaS addition to any lab, development, or production environment. When it’s working properly, it is a very satisfying experience wielding the power of agility, consistency, and efficiency vCD provides. However, like many things tech with upstream and human dependencies, it can and does break. Particularly in lab or lesser maintained environments that don’t get all the care and feeding production environments benefit from. When it breaks, it’s not nearly as much fun.

This week I ran into what seemed like a convergence of issues with vCD 5.6.4 relating to the Remote Console functionality in conjunction with SSL certificates, various browser types, networking, and 32-bit Java. As is the case often, what I’m documenting here is really more for my future benefit as there were a number of sparse areas I covered which I won’t necessarily retain in memory long but as it goes with blogs and information sharing, sharing is caring.

The starting point was a functional vCD 5.6.4-2496071 environment on vSphere 5.5. Everything historically and to date working normally with the exception of the vCD console which had stopped working recently in Firefox and Google Chrome browsers. Opening the console in either browser from seemingly any client workstation yielded the pop out console window with toolbar buttons along the top, but there was no guest OS console painted in the main window area. It was blank. The status of the console would almost immediately change to Disconnected. I’ve dealt with permutations of this in the past and I verified all of the usual suspects: NTP, DNS, LDAP, storage capacity, 32-bit Java version, blocked browser plug-ins, etc. No dice here.

In Firefox, the vCD console status shows Disconnected while the Inspect Element console shows repeated failed attempts to connect to the consoleproxy address.

10:11:30.195 "10:11:30 AM [TRACE] mks-connection: Connecting to wss://;cst-t3A6SwOSPRuUqIz18QAM1Wrz6jDGlWrrTlaxH8k6aYuBKilv/1mc7ap50x3sPiHiSJYoVhyjlaVuf6vKfvDPAlq2yukO7qzHdfUTsWvgiZISK56Q4r/4ZkD7xWBltn15s5AvTSSHKsVbByMshNd9ABjBBzJMcqrVa8M02psr2muBmfro4ZySvRqn/kKRgBZhhQEjg6uAHaqwvz7VSX3MhnR6MCWbfO4KhxhImpQVFYVkGJ7panbjxSlXrAjEUif7roGPRfhESBGLpiiGe8cjfjb7TzqtMGCcKPO7NBxhgqU=-R5RVy5hiyYhV3Y4j4GZWSL+AiRyf/GoW7TkaQg==--tp-B5:85:69:FF:C3:0A:39:36:77:F0:4F:7C:CA:5F:FE:B1:67:21:61:53--"1 debug.js:18:12

10:11:30.263 Firefox can't establish a connection to the server at wss://;cst-t3A6SwOSPRuUqIz18QAM1Wrz6jDGlWrrTlaxH8k6aYuBKilv/1mc7ap50x3sPiHiSJYoVhyjlaVuf6vKfvDPAlq2yukO7qzHdfUTsWvgiZISK56Q4r/4ZkD7xWBltn15s5AvTSSHKsVbByMshNd9ABjBBzJMcqrVa8M02psr2muBmfro4ZySvRqn/kKRgBZhhQEjg6uAHaqwvz7VSX3MhnR6MCWbfO4KhxhImpQVFYVkGJ7panbjxSlXrAjEUif7roGPRfhESBGLpiiGe8cjfjb7TzqtMGCcKPO7NBxhgqU=-R5RVy5hiyYhV3Y4j4GZWSL+AiRyf/GoW7TkaQg==--tp-B5:85:69:FF:C3:0A:39:36:77:F0:4F:7C:CA:5F:FE:B1:67:21:61:53--.1 wmks.js:321:0

tail -f /opt/vmware/vcloud-director/logs/vcloud-container-debug.log |grep consoleproxy revealed:
2015-06-12 10:50:54,808 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0x22c9c990 [java.nio.channels.SocketChannel[connected local=/ remote=/]] |
2015-06-12 10:50:54,854 | DEBUG    | consoleproxy              | ReadOperation                  | IOException while reading data: Broken pipe |
2015-06-12 10:50:54,855 | DEBUG    | consoleproxy              | ChannelContext                 | Closing channel java.nio.channels.SocketChannel[connected local=/ remote=/] |
2015-06-12 10:50:55,595 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0xd191a58 [java.nio.channels.SocketChannel[connected local=/ remote=/]] |
2015-06-12 10:50:55,648 | DEBUG    | pool-consoleproxy-4-thread-289 | SSLHandshakeTask               | Exception during handshake: Broken pipe |
2015-06-12 10:50:56,949 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0x3f0c025b [java.nio.channels.SocketChannel[connected local=/ remote=/]] |
2015-06-12 10:50:57,003 | DEBUG    | pool-consoleproxy-4-thread-301 | SSLHandshakeTask               | Exception during handshake: Broken pipe |
2015-06-12 10:50:59,902 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0x1bda3590 [java.nio.channels.SocketChannel[connected local=/ remote=/]] |
2015-06-12 10:50:59,959 | DEBUG    | pool-consoleproxy-4-thread-295 | SSLHandshakeTask               | Exception during handshake: Broken pipe |

In Google Chrome, the vCD console status shows Disconnected while the Inspect element console (F12) shows repeated failed attempts to connect to the consoleproxy address.

10:26:43 AM [TRACE] init: attempting ticket acquisition for vm vcdclient
10:26:44 AM [TRACE] plugin: Connecting vm
10:26:44 AM [TRACE] mks-connection: Connecting to wss://;cst-f2eeAr8lNU6BTmeVelt9L8VKoe92kJJMxZCC2watauBV6/x…fmI8Xg==--tp-B5:85:69:FF:C3:0A:39:36:77:F0:4F:7C:CA:5F:FE:B1:67:21:61:53--
WebSocket connection to 'wss://;cst-f2eeAr8lNU6BTmeVelt9L8VKoe92kJJMxZCC2watauBV6/x…fmI8Xg==--tp-B5:85:69:FF:C3:0A:39:36:77:F0:4F:7C:CA:5F:FE:B1:67:21:61:53--' failed: WebSocket opening handshake was canceled
10:26:46 AM [ERROR] mks-console: Error occurred: [object Event]
10:26:46 AM [TRACE] mks-connection: Disconnected [object Object]

tail -f /opt/vmware/vcloud-director/logs/vcloud-container-debug.log |grep consoleproxy revealed:
2015-06-12 10:48:35,760 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0x55efffb3 [java.nio.channels.SocketChannel[connected local=/ remote=/]] |
2015-06-12 10:48:39,754 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0x3f123a13 [java.nio.channels.SocketChannel[connected local=/ remote=/]] |
2015-06-12 10:48:42,658 | DEBUG    | consoleproxy              | SimpleProxyConnectionHandler   | Initiated handling for channel 0x7793f0a [java.nio.channels.SocketChannel[connected local=/ remote=/]] |

If you have acute attention to detail, you’ll notice the time stamps from the cell logs don’t correlate closely with the time stamps from the browser Inspect element console. Normally this would indicate time skew or an NTP issue which does cause major headaches with functionality but that’s by design here for my various screen captures and log examples aren’t from the exact same point in time. So it’s safe to move on.

Looking at the most recent vCD installation documentation, I noticed a few things.

  1. Although I did upgrade vCD a few months ago to the most current build at the time, there’s a newer build available: 5.6.4-2619597
  2. Through repetition, I’ve gotten quite comfortable with the use of Java keytool and its parameters. However, additional parameters have been added to the recommended use of the tool. Noted going forward.
  3. VMware self signed certificates expire within three (3) months. Self signed certificates were in use in this environment. I haven’t noticed this behavior in the past nor has it presented itself as an issue but after a quick review, the self signed certificates generated a few months ago with the vCD upgrade had indeed expired recently.

At this point I was quite sure the expired certificates was the problem although it seemed strange the vCD portal was still usable while only the consoleproxy was giving me fits.  So I went through the two minute process of regenerating and installing new self signed certificates for both http and the consoleproxy.  The vCD installation guide more or less outlines this process as it is the same for a new cell installation as it is for replacing certificates. VMware also has a few KB articles which address it as well (1026309, 2014237). For those going through this process, you should really note the keytool parameter changes/additions in the vCD installation guide.

While I was at it, I also built a new replacement cell on a newer version of RHEL 6.5, performed the database upgrades, extended the self signed certificate default expiration from three months to three years, and I retired the older RHEL 6.4 cell. Fresh new cell. New certs. Ready to rock and roll.

Not so much. I still had the same problem with the console showing Disconnected. However, the Inspection element console for each browser are now indicating some new error message which I don’t have handy at the moment but basically it can’t talk to the consoleproxy adddress at all. I tried to ping the address and it was dead from a remote station point of view although it was quite alive at a RHEL 6.5 command prompt. Peters Virtual Notes had this one covered thankfully. According to, a small change is needed for the file /etc/sysctl.conf.

net.ipv4.conf.default.rp_filter = 1

must be changed to

net.ipv4.conf.default.rp_filter = 2

Success. Surely consoleproxy will work now. Unfortunately it still does not want to work. Back to the Broken pipe SSL handshake issues although the new certificate for vCD’s http address is registered and working fine (remembering again each vCD cell has two IP addresses, one for http access and one for consoleproxy functionality – each requires a trusted SSL certificate or an exception).

The last piece of the puzzle was something I have never had to do in the past and that is to manually add an exception (Firefox) for the consoleproxy self signed certificate and install it (Google Chrome). For each browser, this is a slightly different process.

For Firefox, browse to the https:// address of the consoleproxy, don’t worry, nothing visible should be displayed when it does not receive a properly formatted request. The key here is to add an exception for the certificate associated specifically to the consoleproxy address.

Once this certificate exception is added, the consoleproxy certificate is essentially trusted and so is the IP address for the host and the console service it is supposed to provide.

To resolve the consoleproxy issue for Google Chrome, the process is slightly different. Ironically I found it easiest to use Internet Explorer for this. Open Internet Explorer and when you do so, be sure to right click on the IE shortcut and Run as administrator (this is key in a moment). Browse to the https:// address of the consoleproxy, don’t worry, nothing visible should be displayed when it does not receive a properly formatted request. Continue to this website and then use the Certificate Error status message in the address bar to view the certificate being presented. The self signed consoleproxy certificate needs to be installed. Start this task using the Install Certificate button. This button is typically missing when launching IE normally but it is revealed when launching IE with Run as administrator rights.

Browse for the location to install the self signed certificate. Tick the box Show physical stores. Drill down under Third-Party Root Certification Authorities. Install the certificate in the Local Computer folder. This folder is typically missing when launching IE normally but it is revealed when launching IE with Run as administrator rights.

Once this certificate is installed, the consoleproxy certificate is essentially trusted in Google Chrome. Just as with the Firefox remedy, the Java SSL handshake with the consoleproxy succeeds and the vCD remote console is rendered.

Note that for Google Chrome, there is another quick method to temporarily gain functional console access without installing the consoleproxy certificate via Internet Explorer.

  1. Open a Google Chrome browser and browse to the https:// address of the consoleproxy.
  2. When prompted with Your connection is not private, click the Advanced link.
  3. Click the Proceed to (unsafe) link.
  4. Nothing will visibly happen except Google Chrome will now temporarily trust the consoleproxy certificate and the vCD remote console will function for as long as a Google Chrome tab remains open.
  5. Without closing Google Chrome, now continue into the vCD organization portal and resume business as usual with functional remote consoles.

On the topic of Google Chrome, internet searches will quickly reveal vCloud Director console issues with Google Chrome and NPAPI. VMware discusses this in the vCloud Director Release Notes:

Attempts to open a virtual machine console on Google Chrome fail
When you attempt to open a virtual machine console on a Google Chrome browser, the operation fails. The occurs due to the deprication of NPAPI in Google Chrome. vCloud Director uses WebMKS instead of the VMware Remote Console to open virtual machine consoles in Google Chrome, which resolves this issue.

I was working with vCD 5.6.x which leverages WebKMS in lieu of NPAPI so the NPAPI issue was not relevant in this case but if you are running into an NPAPI issue, Google offers How to temporarily enable NPAPI plugins here.

Veeam Backup & Replication 8.0 Update 2 Has Arrived

April 29th, 2015 by jason No comments »

Veeam Backup & Replication 8.0 Update 2 has arrived and with it comes compatibility with VMware vSphere 6.  The announcement (here’s another) from Veeam came yesterday following the vSphere 6 launch by about six weeks.  I was personally notified in a DM via Twitter as promised.  Talk about red carpet treatment from an organization which values community – it’s hard to find a better example than Veeam.

Not only is Update 2 vSphere 6 hypervisor aware, but it also supports many of the features baked into vSphere 6 such as VVOLs, VSAN, Cross-vCenter vMotion, tags, FT virtual machines, and Storage Policy-Based Management (SPBM) backup and restore.  This is just the short list.  Improvements were made other areas such as Microsoft Hyper-V, SQL Server, file level recovery, and Veeam Cloud Connect.  For a long and detailed list of enhancements, take a look at the Release Notes for Veeam Backup & Replication 8.0 Update 2 found in Veeam KB 2024.

As with past upgrades, I found the process quick, painless, and no-nonsense.  Granted, my lab installation is pretty straightforward.  However, be sure to read the release notes if you’re utilizing vSphere tags.

Veeam customers can download Update 2 by visiting Veeam KB 2024.

Dell Enterprise Manager Client Gets Linux Makeover

April 24th, 2015 by jason 1 comment »

Dell storage customers who have been watching the evolution of Enterprise Manager may be interested in the latest release which was just made available.  Aside from adding support for the brand new SCv2000 Series Storage Centers and bundling Java Platform SE 7 Update 67 with the installation (a separate Java installation is no longer required), a Linux client has been introduced for the first time and runs on several Linux operating systems.  The Linux client is Java based and has the same look and feel as the Windows based client.  Some of the details about this release below.

Enterprise Manager 2015 R1 Data Collector and Client management compatibility:

  • Dell Storage Center OS versions 5.5-6.6
  • Dell FS8600 versions 3.0-4.0
  • Dell Fluid Cache for SAN version 2.0.0
  • Microsoft System Center Virtual Machine Manager (SCVMM) versions 2012, 2012 SP1, and 2012 R2
  • VMware vSphere Site Recovery Manager versions 5.x (HCL), 6.0 (compatible)

Enterprise Manager 2015 R1 Client for Linux operating system requirements:

  • RHEL 6
  • RHEL 7
  • SUSE Linux Enterprise 12
  • Oracle Linux 6.5
  • Oracle Linux 7.0
  • 32-bit (x86) or 64-bit (x64) CPU
  • No support for RHEL 5 but I’ve tried it and it seems to work

Although the Enterprise Manager Client for Linux can be installed without a graphical environment, launching and using the client requires the graphical environment.  As an example, neither RHEL 6 or RHEL 7 install a graphical environment by default.  Overall, installing a graphical environment for both RHEL 6 and RHEL 7 is similar in that it requires a yum repository. However, the procedure is slightly different for each version.  There are several resources available on the internet which walk through the process.  I’ll highlight a few below.

Log in with root access.

To install a graphical environment for RHEL 6, create a yum repository and install GNOME or KDE by following the procedure here.

To install a graphical environment for RHEL 7, create a yum repository by following this procedure and install GNOME by following the procedure here.

Installing the Enterprise Manager Client is pretty straightforward.  Copy the RPM to a temporary directory on the Linux host and use rpm -U to install:

rpm -U dell-emclient-15.1.2-45.x86_64.rpm

Alternatively, download the client from the Enterprise Manager Data Collector using the following syntax as an example:

wget em1.boche.lab:3033 –no-check-certificate https://em1.boche.lab:3033/em/EnterpriseManager/web/apps/client/EmClient.rpm

rpm -U EmClient.rpm

Once installed, launch the Enterprise Manager Client from the /var/lib/dell/bin/ directory:

cd /var/lib/dell/bin/




We’re rewarded with the Enterprise Manager 2015 R1 Client splash screen.  New features are found here to immediately manage SCv2000 Series Storage Centers (the SCv2000 Series is the first Storage Center whereby the web based management console has been retired).

Once logged in, it’s business as usual in a familiar UI.

Dell, and before it Compellent, has long since offered a variety of options and integrations to manage Storage Center as well as popular platforms and applications.  The new Enterprise Manager Client for Linux extends that list of management methods available.

vCloud Director Database Migration

March 20th, 2015 by jason No comments »

This week I’ve been working on getting some lab infrastructure fitted with much needed updates. One of those components was an aging Microsoft SQL Server 2008 R2 server on Windows Server 2008 R2 which I had been using to host databases for various projects.  Since I had chosen to build the new SQL server in parallel, I’m benefiting with fresh and problem free builds of Microsoft SQL Server 2012 on Windows Server 2012 R2.  The downside is that I’m responsible for dealing with all of the SQL databases and logins and potentially scheduled jobs that must be migrated to the new SQL server.

vCloud Director is one of the last databases left to migrate and fortunately VMware has a KB article published which covers the step required to migrate a back end SQL database for vCloud Director.  The VMware KB article is 2092706 Migrating the VMware vCloud Director SQL database to another server.

Looking at the steps, the migration looks like it will be fairly simple.  VMware even provides the SQL queries to automate many of the tasks.  I’ll migrate my vCloud Director database using these steps in the following video.  I did run into a few issues which mostly boil down to copy/paste problems with the SQL queries as published in the KB article but I’ve provided the necessary corrections and workarounds in the video.

As shown in the video, I ran into a syntax issue with step four.

The SQL query provided by the KB article was:

USE master;
EXEC sp_attach_db @dbname = N’vCD_DB_Name‘,
c:\Program Files\Microsoft SQL Server\MSSQL\Backup\vCD_DB_Name.mdf
c:\Program Files\Microsoft SQL Server\MSSQL\Backup\vCD_DB_Name.ldf

The corrected SQL query syntax according to the Microsoft SQL Server Management Stuido appears to be:

USE [master]
( FILENAME = N'c:\Program Files\Microsoft SQL Server\MSSQL\Backup\vCD_DB_Name.mdf' ),
( FILENAME = N'c:\Program Files\Microsoft SQL Server\MSSQL\Backup\vCD_DB_Name.ldf' )

Another issue I’ll note that wasn’t captured in the video deals with step seven where the vCloud Director cell server is reconfigured to point to the new database.  The first time I ran that step, the process failed because the cell attempted to locate the SQL database in its original location which it actually found. When this occurred, the cell configuration script doesn’t prompt me to point to a new SQL instance.  In order for step seven to work correctly, I had to drop or delete the database on the SQL 2008 R2 server and rerun the vCloud Director configuration script.  What happens then is that the cell doesn’t automatically ‘find’ the old instance and so it correctly prompts for the new back end database details.  VMware’s KB article provides most of the steps required to migrate the database but it does need a step inserted prior to step seven which calls for the deletion of the original database instance.  Step two places the vCloud database in READ_ONLY mode but the vCloud cell configuration was still able to ‘see’ which causes step seven to fail.

Blake Garner (@trodemaster on Twitter) provided a helpful tip which will also work with step seven in lieu of dropping or deleting the database on the original SQL server:

You could also clear DB config from the /opt/vmware/vcloud-director/etc/ and run configure again.

Overall the process was still fairly simple and painless thanks to VMware’s published documentation.

VMware Horizon View Agent 6.1.0 Installation Rollback

March 16th, 2015 by jason 1 comment »

With the release of vSphere 6 last week, I decided it was time to update some of the infrastructure in the home lab over the weekend. I got an early start Friday as I had my three remaining wisdom teeth pulled in the AM and took the rest of the day off work.  Now I’m not talking about jumping straight to vSphere 6, not just yet.  I’ve got some constraints that prevent me from going to vSphere 6 at the current time but I expect I’ll be ready within a month or two.  For the time being, the agenda involved migrating some guest operating systems from Windows Server 2008 R2 to Windows Server 2012 R2, migrating MS SQL Server 2008 R2 to MS SQL Server 2012, and updating templates with current VMware Tools, and tackling VMware Horizon View getting Composer and the Connection Server migrated from version 5.3 to 6.1.0 including the pool guests and related tools and agents.

I won’t bore anyone with the details on the OS and SQL migrations, that all went as planned. Rather, this writing focuses on an issue I encountered while upgrading VMware Horizon View Agents in Windows 7 guest virtual machines. For the most part, the upgrades went fine as they always have in the past. However I did run into one annoying Windows 7 guest VM which I could not upgrade from View agent 5.1 to View agent 6.1.0. About two thirds of the way through the 6.1.0 agent upgrade/installation when the installation wizard is installing services, a ‘Rolling back action‘ process would occur and the upgrade/installation failed.

The View agent installation generates two fairly large log files located in C:\Users\\AppData\Local\Temp\.  I narrowed down the point in time the problem was occurring in the smaller of the two log files.

svm: 03/16/15 10:54:52 — CA exec: VMEditServiceDependencies
svm: 03/16/15 10:54:52 Getting Property CustomActionData = +;vmware-viewcomposer-ga;BFE;Tcpip;Netlogon
svm: 03/16/15 10:54:52 INFO: about to copy final string
svm: 03/16/15 10:54:52 INFO: *copyIter = RpcSs
svm: 03/16/15 10:54:52 INFO: newDependencyString = RpcSs
svm: 03/16/15 10:54:52 INFO: *copyIter = vmware-viewcomposer-ga
svm: 03/16/15 10:54:52 INFO: newDependencyString = RpcSs vmware-viewcomposer-ga
svm: 03/16/15 10:54:52 ERROR: ChangeServiceConfig failed with error: 5
svm: 03/16/15 10:54:52 End Logging
svm: 03/16/15 10:54:53 Begin Logging
svm: 03/16/15 10:54:53 — CA exec: VMEditServiceDependencies
svm: 03/16/15 10:54:53 Getting Property CustomActionData = -;vmware-viewcomposer-ga;BFE;Tcpip;Netlogon
svm: 03/16/15 10:54:53 Cannot query key value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\DependOnService for size: 2
svm: 03/16/15 10:54:53 Cannot query key value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\DependOnService for size: 2
svm: 03/16/15 10:54:53 End Logging

In addition, the Windows event log reflected Event ID: 7006 “The ScRegSetValueExW call failed for DependOnService with the following error: Access is denied.

I had made a few different attempts to install the 6.1.0 agent, each time trying a different approach. Checked registry permissions and dependencies, relaxed registry permissions, enabled auditing, temporarily disabled Avast Antivirus, etc.  The VMware Horizon View Agent installs a handful of components. Although I didn’t know yet what the issue was on the OS, I had the problem narrowed down to the VMware Horizon View Composer Agent portion of the installation which installs VMware Horizon View Composer Guest Agent Server service (vmware-viewcomposer-ga is the name of the service if you’re looking in the registry).

After doing some more digging, I found out that some antivirus applications like Panda have a a self-preservation mechanism built in which can cause unexpected application problems. Avast has one as well and it’s called the avast! self-defense module. This defense mechanism works independently of normal real time antivirus scans which I had disabled previously.  I had never run into a problem with Avast in the past but in this particular instance, Avast was blocking the modification of Windows services and dependencies. The easy solution, and I wish I had known this from the start but I don’t invest much time in antivirus or malware unless I absolutely have to, was to disable the avast! self-defense module which can be found in the Troubleshooting area of the Avast settings.

Once the avast! self-defense module was disabled, the installation of the VMware Horizon View Agent 6.1.0 agent, including the VMware Horizon View Composer Agent portion, completed successfully. After the agent installation completed, a reboot was performed and I re-enabled the avast! self-defense module.

Thus far I’m impressed with VMware Horizon 6.1. Not much has changed from UI/management perspective but stability and cleanup within Composer operations has improved. I built up and tore down a 28 Windows 7 guest VDI pool and whereas this has lead to precarious pool states and manual cleanup steps in the past, it has worked flawlessly so far.  I’m definitely looking forward to the jump to vSphere 6 infrastructure in the coming weeks. All but one of the other lab infrastructure components have been upgraded and are ready at this point so it shouldn’t be much longer until I have vSphere 5.x in my rear view mirror.

VMware vRealize Operations Manager 6.0.1 & Dell Storage Speed Run

March 11th, 2015 by jason No comments »

For the most part – 12:38 was my time.

There are a few spots where I could improve but what you see here is what you get – a quick video I threw together outlining a simple VMware vRealize Operations Manager 6.0.1 appliance deployment, including:

  • vCenter adapter configuration
  • Active Directory role integration
  • Dell Storage Solutions Pack installation and configuration
  • Dashboard sharing

Obviously I trimmed some of the “wait” intervals but the goal here was to cover the quick and easy steps to get vR Ops 6.x up and running from ovf download to collecting in a very short amount of time.

In case you are unaware, VMware vRealize Operations Manager 6.0.1 was released a little under two weeks ago and it includes some improvements over the December 6.0.0 release:

Updates cover all major areas of the product including installation, migration, configuration, licensing, alerting, dashboards, reports, and policies. To take advantage of the following significant enhancements, upgrade to version 6.0.1.

Improved scaling numbers

  • The number of objects that a single large node supports has been increased to 12,000. Also, in multi-node configurations, a four large-node configuration can manage up to 40,000 objects and an eight large-node configuration can manage up to 75,000 objects. For details on scaling numbers and a link to a Sizing Guideline Worksheet, see KB 2093783.

vSphere v6.0 interoperability support

  • With this release, vSphere v6.0 can function both as a platform for vRealize Operations Manager installation, and as an environment to which vRealize Operations Manager can connect for operational assurance.

User interface improvements

  • Corrections in the Views and Reports content for vSphere Hosts and Clusters.
  • Addition of Hierarchical View in the Topology widget.
  • Enhancement to the Geo widget displays objects on a world map.

Licensing improvements

  • New functionality provides a way to use the REST API to add a license key.

Metrics switched to Collection OFF to improve performance

  • Extraneous metrics are switched to Collection OFF in the default Policy. An option to enable Collection is available. However, maintaining metrics in the OFF state saves disk space, improves CPU performance, and has no negative impact on the vRealize Operations Manager functionality to collect and analyze data. For a list of metrics with Collection switched to OFF, see KB 2109869.

Alert Definition Updates

  • Improved alert definitions for vSphere clusters, hosts, and virtual machines, to better detect CPU and memory problems.
  • Improved alert definitions for hosts and virtual machines in the vSphere 5.5 Hardening Guide, to identify and report more non-compliance issues.
  • Additional alert definitions to detect duplicate object names in vCenter and vSphere Storage Management Service errors. Note: To identify duplicate object names in the vCenter Server system, the name-based identification feature must be enabled for the vSphere adapter.

I spent a fair amount of time with vC Ops 5.x and I’ll be the first in line to say vR Ops 6.x has a much more polished look and feel which generally makes consumption of this datacenter management tool much more of a pleasure to work with in terms of installation, configuration, and daily use. But don’t take my word for it, see for yourself:

Dell Compellent Storage Center Command Set Shell cmdlets

January 9th, 2015 by jason 3 comments »

If you manage Dell Compellent storage, you may or may not be aware that Windows PowerShell cmdlets are available to ease management pain by way of automation and consistency. While I am able to recognize when scripting is the right tool for the job, I do not author PowerShell scripts on a regular basis. For that reason, I’m not as deeply familiar with all of the cmdlets available within the Dell Compellent Storage Center Command Set Shell as I would like to be.

So how do I get started – what are the cmdlets? There are a few different ways to retrieve a list of cmdlets made available by a PowerShell snapin or module.

VMware vSphere PowerCLI simplifies the process by providing a cmdlet called Get-VICommand. When executed, it returns a list of all the cmdlets provided by the VMware.VimAutomation.Core snapin used to manage a vSphere environment via PowerShell. As of this writing in the 5.5.x generation of vSphere, there are a few other vSphere specific snapins installed with PowerCLI but the cmdlets provided by those aren’t returned by Get-VICommand. Those snapins are:

  • VMware.VimAutomation.Vds – This Windows PowerShell snap-in contains cmdlets that let you manage vSphere Distributed Switches.
  • VMware.VimAutomation.License – This Windows Powershell snap-in contains cmdlets for managing License components.
  • VMware.DeployAutomation – Cmdlets for Rule-Based-Deployment
  • VMware.ImageBuilder – This Windows PowerShell snap-in contains VMware ESXi Image Builder cmdlets used to generate custom images.
  • VMware.VimAutomation.Cloud – This Windows Powershell snap-in contains cmdlets used to manage VMware vCloud Director.

However, not all PowerShell snapins ship with a native shortcut to retrieve a list of their respective cmdlets. In these cases, use Get-Command. Now Get-Command by itself returns cmdlets for all snapins. For a snapin specific list, either of the following will work:

Get-Command -Module “snapin_name”
Get-Command | Where-Object{$_.PSSnapin.Name -eq “snapin_name”}

In the case of Dell Compellent Storage Center Command Set Shell, the snapin is named Compellent.StorageCenter.PSSnapin. To retrieve a list of Dell Compellent cmdlets, use one of the following:

Get-Command -Module “Compellent.StorageCenter.PSSnapin”
Get-Command | Where-Object{$_.PSSnapin.Name -eq “Compellent.StorageCenter.PSSnapin”}

At the time of this writing, there are 105 cmdlets:

Get-Command -Module Compellent.StorageCenter.PSSnapin | Measure-Object

Count    : 105
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Those who don’t use PowerShell on a regular basis may find the above difficult to easily recall from memory. I had a discussion with Justin Braun (author of The Braun Blog – check out his Dell Compellent articles here) and Mike Matthews (a peer in my office who specialize in Microsoft SQL Server, PowerShell, and is an all around good guy). Is there an easier and persistent method to retrieve cmdlets from a given snapin? What resulted was a function that can be added to a PowerShell profile which performs just like VMware’s Get-VICommand (I’ll be original and call this one Get-SCCommand to get the list of Storage Center cmdlets).

Edit the PowerShell profile (%profile). It’s default location is:


If the path and profile doesn’t already exist, it can be created in PowerShell using the following cmdlet:

new-item -itemtype file -path $profile -force

If using PowerShell ISE, the default profile location is:


Add the following to verify the Dell Compellent snapin is loaded. If not, load it.

If ( !( Get-PSSnapin | Where-Object { $_.Name -eq “Compellent.StorageCenter.PSSnapin” } ) )
Add-PSSnapin Compellent.StorageCenter.PSSnapin | Out-Null

Add the Get-SCCommand shortcut function:

Function Get-SCCommand { Get-Command -Module “Compellent.StorageCenter.PSSnapin” }

Save the profile.

Now open any PowerShell environment and use Get-SCCommand which shows a list of 105 Dell Compellent cmdlets (There are 49 additional cmdlets in the compellent.replaymanager.scripting snapin for Replay Manager):

It works with PowerShell ISE as well when the Microsoft.PowerShellISE_profile.ps1 profile is modified:

How about PowerGUI? Yes…

Of course the shortcut function provided in the example above is specific to the Dell Compellent snapin but it should work for for any PowerShell snapin including the list of VMware snapins not included in Get-VICommand discussed at the top of the article.

For more on scripting Storage Center, visit the Dell Storage PowerShell Community. Rick Gouin also has a nice collection of scripts that he has authored.

Have a great weekend!