One way to update a vSphere 5 host from CLI

Every time a new version comes out, I have to dig up this procedure, so I figured I’d post it for quicker reference next time.

If you have a vSphere Update Manager in your environment, use it, if not, here is one method to update a host: (using ESXi-5.0.0-20120302001-standard.zip in this case)

1. Locate the Offline Bundle with the desired version or create an image profile from it that includes additional vibs you may need.
2. Copy that zip file to a datastore that the host to be upgraded has access to.
3. Use the vSphere CLI on a local machine and vMA to run this command to determine the profiles contained in the bundle
   

   esxcli --server=<host IP> --username=root --password=<password> software sources profile list --depot="[DATASTORE]ESXi-5.0.0-20120302001-standard.zip"

   Returns “ESXi-5.0.0-20120302001-standard”, “ESXi-5.0.0-20120302001-no-tools”; we’re going to use “standard” in this case.

4. Put the host in maintenance mode
   

   vicfg-hostops.pl --server=<host IP> --username=root --password=<password> --operation enter

5. Apply update to host using profile
   

   esxcli --server=<host IP> --username=root --password=<password>software profile update --depot="[DATASTORE] update-from-esxi5.0-5.0_update01.zip" --profile="ESXi-5.0.0-20120302001-standard"

6. Reboot the host
   

   vicfg-hostops.pl --server=<host IP> --username=root --password=<password> --operation reboot

Advertisement

Three features I want to see added to VMware View

This week was VMware Partner Exchange 2012, there was a lot of focus on End User Computing.  I attended several breakout sessions on the delivery and optimization of virtual desktops and came away with not only a greater appreciation of the technology we have, but also a need for some missing features.

Stand-alone View Composer

The supported and recommended implementation of secure multi-tenant VDI-as-a-Service is extremely cumbersome.  There’s a great deal of isolation and complexity as a result of the inter-dependencies on Microsoft Active Directory.  As you know, View Composer is installed on your vCenter Server and must be a member of- or have a 2-way trust with- the domain in which the desktops will be deployed.  As a result, a separate vCenter Server with View Composer is needed for each Forest that must be isolated.  This drives up the management and administration challenges as well as the license cost.  Some, by no means all, of the complexity could be alleviated by not requiring View Composer run on the actual vCenter Server.   If a stand-alone View Composer virtual appliance were available, it would perform all of the Active Directory actions itself and submit appropriate requests to the vCenter Server for its provisioning and to execute vSphere SDK Guest Operations for customization.  This would help with multi-tenant solutions requiring separate Active Directory Forests.

Support for Linux Desktops

A significant portion of the total CapEx for VDI is the Microsoft licenses.  The VDA is not the ideal solution for a number of organizations and sometimes a full Windows Desktop is overkill.  It was discussed at length this week that delivering Windows to a user is irrelevant, the user is concerned with the applications they need to get their job done effectively, not the platform.  As more and more business applications are migrated to web apps, having  full Windows O/S seems unnecessary.  Imagine kiosk-mode virtual desktops running Firefox on Ubuntu.  Navigate to your web app, do what you need to and move on.  In addition, we may be able to deliver ThinApps to Linux desktops running Wine.  This seems like it would be rather more difficult for VMware to support than it sounds like.  For example, if we continue to depend on Active Directory for authentication and so on, the Linux client will obviously require SAMBA and various other components.  During provisioning, the desktop is customized by assigning a unique name, joining the domain and so on.  These steps are possible by way of the vSphere or VIX API and the VMware Tools, but may require that the prerequisites are in specific locations.

Support for Seamless Windows (Unity)

There is no VMware equivalent to Citrix XenApp.  I’m okay with that; XenApp requires a rather large commitment with farms of Terminal Servers, Web Servers, Database Servers and more to deliver a robust experience.  For me and a lot of customers, there is a need to consume an application remotely without the appearance of a remote environment.  In a number of ways this may be as simple as enabling the “Unity” feature (found in Fusion and Workstation) in the View Client.  This would allow us to create desktop pools (for example) where the application in question is configured as the “shell” and delivered in a seamless window to the end-user.  The benefit here is that the end-user experience feels like a native application but is still controlled by internal IT and never actually leaves the secure data center.  In my opinion, this would be preferential to Microsoft Terminal Services, because we could continue to utilize the existing Desktop solution as well as applications that have been delivered as ThinApps.  I also prefer the user-isolation of VDI over multiple concurrent sessions on a single Terminal Services Server.  Subsequent application launches would have to be detected and handled by the View components so that a new application is launched in the already-open session rather than attempting to connect to a new desktop.

 

These are just a few of the items that occurred to me this week.  I’d love to hear your suggestions, whether you agree/disagree or think that there are more important features than these that are missing.

 

Use a Post-Synchronization script to set the Windows 7 key and activate

I had a situation today where the parent desktop image had Kaspersky Anti-Virus installed and I could not modify it.  This product is known for breaking sysprep, so I had to use QuickPrep instead.  The problem I had was that without sysprep, the system was not getting its correct Multi-Access Key nor activating.  To work around this, I put together a tiny batch file that uses slmgr.vbs to set the key and activate.  I was pleasantly surprised to see that the script/batch file was successfully executed from a UNC path, so I did not have to make changes to the parent desktop image.

The batch file contents:

cscript C:\Windows\System32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
cscript C:\Windows\System32\slmgr.vbs /ato

Replace XXXXX-XXXXX-XXXXX-XXXXX-XXXXX with your MAK.

Please be aware that the procedure is different when there is a Key Management Server in place with the appropriate Windows 7 Keys ready.

Configure Wyse Windows Embedded Standard thin client to load VMware View Client automatically

Objectives:

• Faster time from power on to View logon prompt
• User cannot access any other applications on the Windows Embedded O/S
• Exiting the View Client automatically relaunches it
• Administrator account is not affected

Procedure:

1. Disable PXE boot
   1. As the thin client is booting, hit <delete> to enter the BIOS
   2. At the BIOS password prompt, enter “Fireport” (unless the BIOS password has been changed)
   3. Update the device boot order so Hard Drive is first
2. Get “User” SID
   1. Reboot thin client, load Windows as default “user”
   2. Click “Start|Shutdown|Log off” while holding <shift>, continue holding <shift>
   3. At the logon prompt, logon as administrator using the password “Wyse#123”
   4. Launch Regedit, navigate to HKEY_USERS
   5. Examine the USERNAME value under each “HKEY_USERS\<SID>\Volatile Environment” to find which SID belongs to the default “user”.  A SID begins with “S-1-5-“.
   6. Double-click “Disable FBWF”, wait for system to reboot
3. Create scripts
   1. Click “Start|Shutdown|Log off” while holding <shift>, continue holding <shift>
   2. At the logon prompt, logon as administrator using the password “Wyse#123”
   3. Launch Windows Explorer
   4. Create a folder named” bat” in the root of C:\
   5. Launch Notepad; paste in the following:
      

      @echo off
      :View
      “C:\Program Files\VMware\VMware View\Client\bin\wswc.exe”
      goto View

   6. Save the file as C:\bat\View.cmd
   7. Launch Notepad; paste in the following:
      

      Set WshShell = CreateObject(“WScript.Shell”)
      WshShell.Run chr(34) & “C:\bat\view.cmd” & Chr(34), 0
      Set WshShell = Nothing

   8. Save the file as C:\bat\View.vbs
4. Update Shell for “User”
   1. Launch Regedit
   2. Navigate to “HKEY_USERS\<SID>\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon”
   3. If the “Shell” values does not exist, create it as a new String Value
   4. Update the “Shell” value to “wscript c:\bat\view.vbs”
   5. Close Regedit
   6. Double-click “Enable FBWF”
   7. Reboot thin client

Credits to Sparko Design, Free Wyse Monkeys and MidWest Wyse Guys.

VMware I/O Analyzer 1.0.0 Review

Since I’m in the middle of replacing one storage array (EMC Celerra NS-120) with another (EMC VNX 5500), I’m interested in comparisons of I/O performance between the arrays and between the various LUN configurations.  VMware made the I/O Analyzer Fling available on December 5, 2011.  Hopefully, you know how to deploy the OVA, so I won’t bore you with those details and will simply start with “okay, I’ve got it installed per the instructions, now what?”

• Using your vSphere Client, open a console on the IOAnalyzer VM you imported.  Logon as “root”, using “vmware” as the password.  This will take you to an ordinary gray screen.

  

  IO Analyzer Grey Screen

• Back on the vSphere Client, make a note of the IP Address of the IO Analyzer VM and the host on which it’s running.
• Launch Firefox or Chrome and point it to the IP address of the IO Analyzer.  It should come up with the “Home” screen.

  

  I/O Analyzer Home Screen

• Click “|| Setup & Run ||” at the top to go to that area.
• On the Setup & Run page, we’ll set the host to gather ESXtop statistics on and the parameters to pass to IOMeter running in the IO Analyzer VM.
• Under “Host Credentials”, enter the host name or IP address of the host where the IO Analyzer VM is running, provide the root password and click “Add Host” to save the details.
• Under “Guest/Worker to Workload Binding”, select the host under the Host Name dropdown.  Supposedly, the “Select VM” dropdown will enumerate the VMs on the selected host, but I never saw it behave like this.  Just choose one of the VM names listed – the name is just used in the formatting report and has no bearing on the results.
• The “Workload Spec” dropdown lists the access pattern you want to use with IOMeter.  There are some that represent a Workstation, SQL or Exchange Server in addition to the percent read/percent random ones – pick one.
• In the VM IP Address, provide the IP address of the IO Analyzer VM (same IP address your browser is pointed to) and click “Add Worker”
• You may add additional workers/access patterns, but when I tried, these additional workers were not spawned on the VM and only used the last workload defined.
• Enter a duration for the test to run in seconds – usually 120 and click “Run”.
• Flip over to the console on the IO Analyzer VM and watch IOMeter launch

  

  IOMeter running on the VM

• In IOMeter, you can choose the “Results Display” tab, set the Results since to “Last Update” and the Update Frequency to 2 to see the results while the test is progressing.  This is great for those of us with little to no patience.
• When finished, IOMeter will close and the “Setup & Run” page of the Web UI will state “Run complete.  Goto results tab.”
• Click the “|| Results ||” link at the top, select the most recent item from the Result Summary drop down and click “View Summary” to load the details.

  

  IO Analyser Results View

• The IOMeter Results summary is obtained from the IOMetere running within the VM and provides Read & Write IOPS and MBPS.
• The Host Results Summary is obtained from ESXtop against the specified host

You can compare the IOPS and MBPS from IOMeter and ESXtop to see what additional load the host is enduring.

To measure the performance of another LUN, simply use Storage vMotion to migrate the IO Analyzer VM elsewhere and rerun it.

My Observations

The VM dropdown thing is annoying, but not really crucial.  The tool will let you select a host unrelated to the VM and confound yourself.  You must logon to the VM on the console in order for it to fire off IOMeter and obtain the results.  It’s a little clunky; multiple workers are not spawned on the VM when selected in the Web GUI.  But, you can simply run IOMeter yourself in the VM and set your own params.

Coming Up

I’ll post my performance statistics for various LUNs and later compare them to the storage on the VNX5500  with and without- FAST cache.

VMware View 4.6 incompatible with VM v8 – correction

I’ve got an environment running vSphere 5.0 and VMware View 4.6 (because View 5.0 isn’t GA yet).  I found that when I upgrade the VM version and VMware Tools of my “Parent” Windows 7 VM, then recompose the Pool, the View client can no longer connect to the Desktop over PCoIP!

Here’s some more details, I’m using a security server in a separate VLAN from the Connection Server, but even if I connect the View client directly to the Connection Server, the behavior is the same.  It acts just like the PCoIP port is blocked (it’s not BTW); first the black screen, then the session dies.

If I choose the snapshot made before the HW version and Tools version upgrade, and re-recompose the pool,  the client connects as expected.  There are no other apparent differences between the “working” snapshot and the “not-working” snapshot, so I must conclude that VMware View 4.6 is incompatible with VM v8.

If this is, or is not the case, or you have a workaround, please let me know!

 

Edit: thanks to the very first comment, I reinstalled the View Agent on the parent VM an viola’, it worked like a charm.

 

vSphere Licensing Update!

Thank you VMware!  It’s refreshing when a company with VMware’s magnitude in the market actually listens to partners and customers.

These changes to the vSphere 5 licensing model mean that we can continue to use loads of pRAM in our hosts.  It also intelligently does not penalize users for transient VMs.  I’m happy to see these changes and think that it’ll make the transition much easier for our customers.

vSphere 5 Licensing impact on VDI

Very quietly, VMware released some information about vSphere for Desktop. This is the licensing model you’re going to want… especially for VDI.

Here’s a link to the details:vSphere Desktop FAQ

There are a number of caveats explained in this FAQ, but the licensing strategy is beginning to make sense.

In short, if you run VMware View, you can get an unlimited vRAM entitlement.  You cannot upgrade to vSphere 5 for Desktop and if you’re running a third-party VDI solution on vSphere, you will have to use the “non-Desktop” editions and be subjected to vRAM license limits.

This is just my humble opinion and does not necessarily reflect the opinion of my employer or partners or anyone else for that matter

vSphere 5 Licensing Change Ramifications

Until now, vSphere licenses have focused on populated physical processor sockets.  To maximize the bang-for-the-buck, we sought few processors with as many cores as our vSphere license would permit and load ’em up with RAM.  Picture a 6-host cluster where each host has two 10-core processors and 192GB RAM running vSphere Enterprise Plus.

In this case, we buy twelve Enterprise Plus licenses, entitling us to 576GB vRAM.  This is a N+1 HA cluster, so we can consume up to 5 hosts-worth of pRAM, or 960GB.  This leaves us having to purchase an additional EIGHT licenses of Enterprise Plus to cover processors we don’t actually own.  Sure, we could configure the cluster as N+2, reducing my effective capacity from 83.3% to 66% and still have to buy four more licenses just to use all the pRAM in the cluster.

Compounding the frustration is that we’ve been encouraged to make use of great features like transparent page sharing which make memory over-subscription easy and efficient.  Now, if I apply a 1.5:1 memory over-subscription rate to my cluster above, I may have to come up with EIGHTEEN Enterprise Plus licenses for processors we don’t actually own.

I am aware that the vRAM entitlement is pooled by license type across the entire vCenter-managed VMs, so if you have a couple of 2-host clusters, you might be able to apply some of that entitlement to the bigger clusters…

With this license change, I think VMware is driving people to use smaller, less efficient clusters.  Customers are effectively penalized for having more than (Number of Hosts-1) * vRAM entitlement per CPU in their hosts.

This is just my humble opinion and does not necessarily reflect the opinion of my employer or partners or anyone else for that matter

Best features in vSphere 5

Of the myriad of new features announced as part of vSphere 5 yesterday, I’ve narrowed it down to a few of my favorites; these are the game-changers.  I really hope they live up to the expectations!

In no particular order…

Swap to Local SSD

This is a neat feature to take advantage of those fast SSD drives in your hosts that you’re not really using much.  (The UCS B230 comes to mind).  With this feature, vSphere can move the swapfile to the host’s local SSDs for fast response time.  Of course, if you’re using the swap file, you probably want to add RAM.
VMFS 5 – 64TB Volumes

This is a much-needed feature.  The 2TB limit on VMFS extents has been making for environments that are more complicated than necessary.  Now users can have fewer, larger data stores.  You’ll want to make sure your array supports the Atomic Test & Set (ATS) function in VAAI before you put a lot of VMs on a single LUN.

Monster VMs

vSphere 5 now provides support for VMs with 32 vCPU and 1TB of vRAM.  (no wonder considering the new pricing structure… grumble grumble)

vStorage DRS

This is a cool feature I’m looking forward to working with.  You’ll create a new object called a “Datastore Cluster” and assign several Datastores to it.  I’m pretty sure you’re going to want the datastores that are clustered to have similar performance characteristics.  vStorage DRS will measure the storage I/O per VM and per datastore and make suggestions or actually move the VMDKs to another datastore in the cluster if it will help balance the storage I/O load.  This is really neat technology!  Imagine that you’re NOT sitting on top of your performance statistics and don’t notice that the LUNs housing your Exchange mailboxes are getting slammed, affecting performance of other VMDKs on those LUNs.  Much like DRS lets you set-it-and-forget-it when it comes to balancing the memory and CPU load, vStorage DRS will do the same for storage I/O.  In addition, it allows you to set affinity and anti-affinity rules all the way down to the individual VMDKs.

Multi-NIC enablement for vMotion

Honestly, this is one of those features I thought vSphere already had.  When you assign multiple uplinks to your vmkernel and make them both active, it will now actually take advantage of them, increasing the bandwidth and speed of vMotion actions.

VAAI for NFS, full file clone, thick disks on nfs

Before now, when you created a VMDK on an NFS datastore, you got a thin-provisioned disk.  Now, you can explicitly create thick disks and let the array (assuming its compatible) handle the work of zeroing it out.  In addition, VAAI for NAS will offload the work of cloning a VM to the array and off of the host, greatly reducing the work and network traffic involved.
HA rewrite

Halleluiah! I’m thrilled to see this!  HA is no longer dependent on DNS.  It is supposed to be faster to enable, more descriptive when it fails and have less funky networking requirements.  I’m eager to work with this and see if its all true.

Live Storage vMotion

Until now, when you needed to move a running VM from shared storage to storage only one of the hosts can see, it was a two-step process. First vMotion the VM to the host that can see the new storage, then storage vMotion it to the right datastore.  Now, you’re able t0 do that move in a single step.  Not sure how often this will get used, but it’s nice.

vCenter Appliance

I’m happy to see a VMware appliance for vCenter Server.  This will eliminate a Windows license for non-Microsoft shops and give the service a smaller footprint with less resource consumption.  The downside I see is that not all plug-ins will work with the Linux-based appliance and it cannot currently be used with VMware View Composer.  I expect this to mature rapidly and become a more robust solution.
vSphere Storage Appliance

This is another great feature that will make the resiliency of vSphere accessible to smaller shops that don’t have the budget to buy an enterprise-class storage array.  It works by maintaining a primary and a replica of each datastore on each of up-to three hosts.  Each host in the VSA cluster runs an NFS server and exports the primary datastores residing there.  In this way, should any one host in the VSA cluster fail, the datastores will remain online via the running replica.  This should not be seen as an alternative to enterprise-class storage, but a good entry point for low-cost deployments needing some resiliency.