Swimming Upstream is hard, I guess

I’m a regular reader of Scott Lowe’s blog, and I hope you all get a chance to see his latest comment as he takes his Cisco UCS training.

The summary: a Cisco UCS system cannot connect upstream to a FCoE storage device – the UCS 6100 Fabric Interconnect doesn’t support upstream or “Northbound” FCoE connectivity.

Now this in itself I guess isn’t a deal-breaker, as one of the posters says, this is just because the FCoE and FIP standards weren’t ratified yet. And that’s fine.

But do you want to be running your business on a standard whose ink hasn’t dried yet?

I don’t want to turn this into a rant against Cisco – but I will say that I think the UCS is a lot more hype than substance today. Perhaps Scott’s followup articles will change my mind, however.

VMware Plea Part Deux: ESXi Boot from SAN

As some of you are aware, ESXi can officially boot from all the following sources:
USB Flash Device
SD Card
Local Hard Drive
PXE Boot (experimental)

There’s one big missing piece here: Boot from SAN. Why is this a big deal? It means customers who want to BFS (like HP VirtualConnect customers, or in the future Cisco UCS customers) in order to get the most out of their dynamic datacenter cannot use the next generation hypervisor architecture; they must stick to ESX “Classic.” We have been going back and forth with VMware support on this, but still even in ESXi 4.0 Boot from SAN is not officially supported.

This is despite the fact that on the ESXi Features Page, one of the features listed is Boot from SAN! Instead, you need to dig into the Install and Setup guide to find this gem:

You use the ESXi 4.0 CD to install the ESXi 4.0 software onto a SAS, SATA, or SCSI hard drive.
Installing on a Fibre Channel SAN is supported experimentally. Do not attempt to install ESXi with a SAN attached, unless you want to try this experimental feature.

That said, it works fine. I haven’t had any problems. But we can’t deploy it for customers that way if it’s not supported.

VMWare: Why is your next-generation hypervisor crippled in this way?

VMware View 3.1.1 Released

Just a quick bug-fix release, View 3.1.1 fixes the following issues. From the Release Notes:

View Administrator

• When using View Web Portal to launch a virtual desktop with a user, the User field in the View Administrator Console does not display the name of the desktop user although the desktop is assigned to the user persistently.
  This issue is resolved in this release.
• The list of desktop pools in the left-hand pane of the Web Administrator window’s Inventory tab is sometimes not populated. This issue prevents the administrators from managing the desktops.
  This issue is resolved in this release.

View Client

View Clients might unexpectedly disconnect from the desktops when tunneled (KB 1012388)

Miscellaneous

When you perform some functions on a virtual desktop that is running View agent and certain third-party GINAs that do not completely support WLX version 1.4, the guest operating system fails and displays a blue screen. This issue is resolved in this release.

You can download it here. Note that there is no new View Composer version.

Using the HP t5545 Thin Client with VMware View

This is my first in a series of articles outlining how to setup various Thin Clients with VMware View.

One of my favorite thin clients as of late is the HP t5545. It’s a very inexpensive thin client with a lot of great features – local web browser, full VMware View support, Multimedia redirection, USB redirection, and more. Up until recently, however, getting all that to work was a bit of a challenge.

Using HP RGS with VMware View 3.1

So as I’m sure many people are aware, VMware will be shipping a protocol in the near future (with View 4, most likely) called PC-over-IP. In the meantime, however, VMware View 3.1 has included support for HP Remote Graphics Software, which provides a similar experience today (albeit not for free). VMware hasn’t come out with tiering or pricing for View 4 yet, and since customers today may require this kind of functionality, I think it’s wise for people to test out how well it works.

First, a disclaimer. In the release notes for View 3.1, VMware states the following policy:

View Client can now use HP Remote Graphics Software (RGS) as the display protocol when connecting to HP Blade PCs, HP Workstations, and HP Blade Workstations. The connection is brokered by View Manager. HP RGS is a display protocol from HP that allows a user to access the desktop of a remote computer over a standard network. VMware View 3.1 supports HP RGS Version 5.2.5. VMware does not bundle or license HP RGS with View 3.1. Please contact HP to license a copy of HP RGS software version 5.2.5 to use with View 3.1. This release does not support HP RGS connections to virtual machines.

So be aware that VMware does not support running RGS Senders in Virtual Machines. That said, HP does support it, and the plan was prior to View 3.1’s launch to have this fully supported by both parties. From what I heard, issues at the last minute caused them to push this off. As a result, if you try to create a pool using VirtualCenter VMs (i.e. an Individual Desktop with VirtualCenter VM selected, any kind of Automated Desktop Pool, or a Manual Desktop Pool with VirtualCenter VM selected) RGS does not show as an available default protocol.