Wednesday, November 16, 2011

vCenter Orchestrator - You Own It, Use It!

At lunch this week with a customer when the subject of automation came up, as it seems to more and more frequently these days.  They were looking for a way to automate provisioning of servers so that they could reduce time to market.  What product would help them with that, they asked.

You already own it, was my answer.

If you're a VMware administrator you're probably aware of vCenter Orchestrator at least in passing.  If you're like me, you may have even played with it a little and moved on to other things because you couldn't really figure out how it all works.

On the other hand, you may have never even heard of vCenter Orchestrator and you don't know why you'd want to learn about it, much less use it.

What is it?

vCenter Orchestrator, or vCO, is a workflow engine that can help administrators automate tasks.  Simple, yet powerful statement, right?

In fact, vCO comes out of the box with lots of pre-built workflows for vSphere administration as well as plugins for things like Active Directory, SOAP, REST ... there's even a plugin by Cisco for UCS.  Naturually, VMware also provides plugins for other products like vCloud Director and Update Manager.  The community also provides a source of plugins such as Joerg Lew's PowerSSHell pluginVMware Labs also provides some unsupported/experimental plugins.


With vCO, a VMware administrator can create, using a drag and drop interface, a workflow to provision new servers including deploying a template, customizing and installing applications.

Did I say it was drag and drop?  That's the best part for salty old infrastructure folks like me - you know, the kind of guy who does his scripting through the Google search interface.  vCO doesn't require that you be a hacker, but it also doesn't limit you from creating some pretty complex workflows that include custom scripts.  The good news is, you can do a lot of powerful things, pretty easily, with the built in workflows.

What can it do?

Here's a list of examples from the vCO community --




How do I get it?

As the title of this post indicates, if you own vCenter Server you already have vCO.  Recently, VMware released a vCO virtual appliance so installation is super easy.

Burke has a good guide for installing vCO on a Windows server if you like to do things the hard way.


How do I get started with vCO?

There's actually a pretty good community out there already with example workflows, step-by-step guides and video demonstrations...


VMware vCenter Orchestrator Blog
VMware Orchestrator Community
vCO Portal
VCO Team
Mighty Virtualization
Cody Bunch - you can pre-order his book "Automating vSphere"

Tuesday, November 15, 2011

Setting the Citrix CLIENTNAME to match the View client host name

Often, applications will use the Citrix client name to assign location based resources (printers, for example).  In the case of a Citrix XenApp session running from a Windows based View session, location awareness is lost because Citrix client name assumes the Windows host name of the VM, not the endpoint (a thin client or View running on a physical desktop).

There are two ways that I have seen to address this - and personally I have a preference for one of those methods, but you can decide which works best for you.

First, it's important to understand a couple of things.

The View agent on the VM will capture information about the client and store that data in the hive "HKCU\Volatile Environment\" and one of the keys in that hive is "ViewClient_Machine_Name".

Citrix clients store the CLIENTNAME attribute in "HKLM\Software\Citrix\ICAClient\CLIENTNAME".

By default, the Citrix plugin installs with dynamic client name enabled.  This means that the CLIENTNAME reg is populated with the host name of the host running the client.  In other words, by default CLIENTNAME will be the VM's OS host name.

One method of changing the CLIENTNAME to the endpoint host name is to grab the reg key "ViewClient_Machine_Name" and replace the "CLIENTNAME" key with that string.  A script to do just that may look like this:

Option Explicit
Dim SysVarReg, Value
Set SysVarReg = WScript.CreateObject("WScript.Shell")
value = SysVarReg.RegRead("HKCU\Volatile Environment\ViewClient_Machine_Name")
SysVarReg.RegWrite "HKLM\Software\Citrix\ICAClient\CLIENTNAME", value

You would want this script to run on connection and reconnection, so when a roaming desktop user changes endpoints you are updating the CLIENTNAME to match for location awareness.

To use this method, you would need to reinstall the Citrix plugin on the VM to disable dynamic client name.

I like this approach because it's elegant and simple to troubleshoot.  I would recommend using BGinfo to add three bits of info to the VM desktop wallpaper to help validate that the CLIENTNAME is correct and to aid in any troubleshooting.  For example, I would have the following appear in the lower left corner in small font on the desktop:

  View VM -
  View Client -
  Citrix Client Name -

The other method would be to leave Citrix dynamic client name enabled and change the host name of the VM on connect/reconnect to match the endpoint host name (or include the endpoint host name in the VM host name).  I'm not a huge fan of this approach because it involves constantly changing the host name of the VM which could impact other applications as well as complicate troubleshooting.  You also need to make sure that the TCPIP name is changed as well, resulting in a DNS update if you're running dynamic DNS.

I do have access to a script to perform a VM host name change, but since I didn't write it I don't want to post it here.  I will check with the author to see if I can add it to this post later, but the script above should give you a start on creating that script.

Thursday, January 27, 2011

Changes

Tomorrow I will make my last sales call for Compellent.  It's been a great, albeit short, ride with an up and coming storage company and I appreciate every thing about the past 13 months.  There are so many great people at Compellent who I will miss and I wish them the very best in whatever the future holds - this year will be very exciting at Compellent.  Good speed to the entire team and thanks for the memories.

I will continue this blog (with hopefully more frequency - but we'll see).  Although most postings were related to Compellent's products and value I don't have any regrets about anything I've posted and still stand behind each and every post.  My new role will afford me the opportunity to champion not only Compellent but also other storage technologies - particularly as they relate to virtualization and cloud infrastructure.

Beginning next week I will join VMware as a Systems Engineer - doing pretty much the same thing I was doing with Compellent but with a much broader canvas, more brushes and a large palette of colors.

Stay tuned!

As always, my opinions are my own and not those of my employer.

Tuesday, January 25, 2011

A Pool of Storage

I saw a question pop up on Twitter regarding the difference between "free allocated vs unallocated disk space" on a Compellent Storage Center.  I believe the question arises out of this screen from the System Manager GUI:

The bar graph shows the storage utilization for disks in the default "Assigned" disk folder (which is typically the way a system is deployed).

The blue shaded area shows disk used by volumes - easy enough.  This is allocated pages with user data on them.

The light blue (or clear, I haven't ever figured that out since the background is the same color!) area represents something called "Free allocated space"...

Huh? 

In a Compellent storage system (and by the way in pretty much all virtualized storage systems as I'm aware) disk blocks are carved up into pages or extents - terminology differs but it's essentially the same concept and Compellent refers to them as pages and the aggregation of all pages in the system is referred to as the page pool.  The default page size for Compellent is 2MB (4096 blocks) although 4MB and 512KB pages can be used in specific cases.

You may be aware that Storage Center uses variable RAID protection based on pages being writeable or part of a read-only replay (snapshot).  In general writeable pages are RAID 10 protected and replay pages are RAID 5 (dual parity schemes may also be configured as in the graphic below).  Storage Center prepares pages for user data ahead of time for use by volumes - some will be prepared at each RAID protection level on each disk tier.  The graphic below from the Data Progression Pressure Reports shows this.


Here again we see the dark blue/light blue bar graph.  Note the RAID 10-DM (dual mirrored) fast track allocation.  1.39GB of space is in use by volumes - but another 48GB of disk space has been prepared at this protection scheme (using the outermost tracks all Tier 1 disks).  This is actually from the Storage Center 5.3 manual, so I'm not sure what was going on with this system but your typical real world system would likely have more "disk used" of course.

But hopefully you get the point.  The "free allocated" or light blue shaded section of the bar on the first graph is the amount of disk space consumed by all of these prepared pages, across all tiers.

So what's unallocated?  That's simply disk space that hasn't been turned into pages and assigned to a RAID level - or hasn't been "formatted for use" if you will.  No worries, as you consume "free allocated" pages you'll begin to see the "unallocated" space decrease to back fill the "free allocated" pages.  By the way, expired replays and deleted volumes return pages to "free allocated" status.