VMware View 4, Certified HCL Tripples in Size

In the past month, the number of hardware Thin and Zero clients certified for VMware View 4.0 has nearly trippled. It only seemed fitting to update our list to further showcase the current state of the View “certified” HCL for “hardware” thin clients. The “ThreadX” OS variants include hardware from Teradici (TC1100) to accelerate the PCoIP protocol. 

As of January 26, 2010, the following hardware clients (average price of $526/unit) are “officially” on VMware’s HCL:

OEM	Model	OS	Supports	Unit Cost	New Since
		Variant	PcoIP	(Est. $)	Dec-09
Amulet Hotkey	DXR4-iP	ThreadX	Y (quad-head video)	TBD	Y
Astec Technology Co.	A3520	Linux Embedded for Thin Client b1106	Y	TBD	Y
Astec Technology Co.	A3580	Windows XPe SP2	Y	TBD	Y
ClearCube	C7420	ThreadX	Y	$1,160	Y
ClearCube	I9420	ThreadX	Y	TBD	Y
DELL	OptiPlex FX160	Windows XPe SP2	Y	$512	N
DevonIT	TC10	ThreadX	Y	$342	Y
DevonIT	TC5	Windows Embedded Standard 2009	Y	$299	N
HP	GT7720	Windows Embedded Standard	Y	$799	N
HP	t5545	HP ThinPro	Y	$296	Y
HP	t5630	Windows XPe SP3	Y	$632	N
HP	t5630W	Windows Embedded Standard	Y	$440	N
HP	t5720	Windows XPe SP3	Y	$410 (refurbished)	N
HP	t5730	Windows XPe SP3	Y	$349	N
HP	t5730W	Windows Embedded Standard	Y	$550	N
HP	t5740	Windows Embedded Standard	Y	$429	N
HP	vc4820t	Windows Embedded Standard	Y	N/A	Y
IGEL	UD2-420 ES	Windows Embedded Standard	N	$436	Y
IGEL	UD2-420 LX	IGEL Linux 4.02.500	N	$292	Y
IGEL	UD3-420 ES	Windows Embedded Standard	Y	$561	Y
IGEL	UD3-420 LX	IGEL Linux 4.02.500	Y	$412	Y
IGEL	UD3-720 ES	Windows Embedded Standard	Y	$561	Y
IGEL	UD3-720 LX	IGEL Linux 4.02.500	Y	$436	Y
IGEL	UD5-420 ES	Windows Embedded Standard	Y	$627	Y
IGEL	UD5-420 LX	IGEL Linux 4.02.500	Y	$579	Y
IGEL	UD5-720 ES	Windows Embedded Standard	Y	$653	Y
IGEL	UD5-720 LX	IGEL Linux 4.02.500	Y	$605	Y
IGEL	UD7-720 ES	Windows Embedded Standard	Y	$1,042	Y
IGEL	UD7-720 LX	IGEL Linux 4.02.500	Y	$925	Y
IGEL	UD9-720 ES	Windows Embedded Standard	Y	$953	Y
Leadtek Research Inc.	WinFast VP200 P	ThreadX	Y	$715	Y
Praim	XP-6700	Windows XPe SP3	Y	TBD	Y
Praim	XP940-I	Windows XPe SP3	N	TBD	Y
Praim	XP9400-U	Windows XPe SP3	Y	TBD	Y
Praim	XT900-I	ThinOX 8.01.14	N	TBD	Y
Samsung	SyncMaster NC190	ThreadX	Y	$467	Y
Samsung	SyncMaster NC240	ThreadX	Y	$524	Y
Wyse	C90LEW	Windows Embedded Standard 2009	Y	$498	N
Wyse	P20	ThreadX	Y	$585	Y
Wyse	R50L	SUSE Linux Enterprise TC 10	Y	$481	Y
Wyse	R50LE	SUSE Linux Enterprise TC 10	Y	$442	Y
Wyse	R90LEW	Windows Embedded Standard 2009	Y	$640	N
Wyse	R90LW	Windows Embedded Standard 2009	Y	$593	N
Wyse	S10	WTOS 6.5	N	$252	N
Wyse	V10L	WTOS 6.5	N	$315	N
Wyse	V10L Dual DVI	WTOS 6.5	N	$447	N
Wyse	X50L	SUSE Linux Enterprise TC 10	Y	$671	Y

 SOLORI’s NOTE: The Samsung NC190 and NC240 include integrated 19″ and 24″ monitors, respectively. This combination makes them the most cost and energy efficient PCoIP solutions on the market. If all-in-one products meet your deployment profile, the Samsung units are worth a serious look.

Devices not on this list may “work” with VMware View 4.0 but may not support all of View 4’s features. VMware addresses certified and compatible as follows:

Certified and Compatible Thin Clients:
Certified – A thin client device listed against a particular VMware View release in the Certified For column has been tested by the thin client manufacturer against that specific VMware View release and includes a minimum set of features supported in that VMware View version.

Compatible – A thin client device certified against a specific VMware View release is compatible with previous and subsequent VMware View releases according to the compatibility guarantees published as part of that specific VMware View release (typically two major releases in both directions). However, a compatible thin client may not include all of the features of the newer VMware View release. Please refer to your VMware View Client documentation to determine which features are included.

Unlisted thin clients may embed VMware’s “software client” along with a more general purpose operating system to deliver View 4 compatibility. Support for this class of device may be restricted to the device vendor only. Likewise, thin clients that are compatible with earlier versions of View may support only a subset of View 4’s features. When in doubt, contact the thin client manufacturer before deploying with View 4.

Quick-Take: It’s Time to Upgrade from ESX to ESXi

That’s right, I said upgrade from ESX to ESXi - not ESX 3.x to vSphere, but ESX (any version) to vSphere’s ESXi! Ever since VMware PartnerExchange 2009 (April), SOLORI has been advising clients and prospects to focus on ESXi and move away from ESX-based hosts – you know, the one with the “Linux” service console. Personally, I’m glad VMware has strengthened their message about the virtues of ESXi and the direction of their flagship product.

ESXi has a superior architecture and we encourage customers to deploy ESXi as part of any new vSphere deployment. Our future posts will compare ESX 4 and ESXi 4 in detail on topics like hardware compatibility list, performance, and management to demonstrate that ESXi is either on par with or superior than ESX. But for now, here are some key points you should know about ESXi vs. ESX:

1. The functionality and performance of VMware ESX and ESXi are the same; the difference between the two hypervisors resides in their packaging architecture and operational management. VMware ESXi is the latest hypervisor architecture from VMware. It has an ultra thin footprint with no reliance on a general-purpose OS, setting a new bar for security and reliability (learn more).
2. In the future, ESXi’s superior architecture will be the exclusive focus of VMware’s development efforts.
3. New and existing customers are highly encouraged to deploy ESXi. Many Fortune 100 companies have already standardized on the ESXi platform.

- VMware Blog, June, 2009

Not unfamiliar with the VI3 version of ESXi, its ease of installation, configuration and management and smaller footprint, I was one of about 10 participants in an “ESXi BoF Breakout Session” with Charu Chaubal of VMware. While discussing vSphere’s ESXi with Charu, I never heard the words “ESXi is a superior architecture,” but I did get a clear message that ESXi was the way of the future. From that point on, it seemed as though any efforts concentrated on (net new) ESX deployments was going to be “time wasted.”

However, it was clear by the whispered tone about ESXi’s virtues that the timing was not right for the real message to be spoken aloud. Remember, this was the launch of vSphere and “ESXi” was strongly associated with “ESXi Free” – not a clear marketing message when license sales and adoption curves are on the line. Perhaps that’s why the “talking points” at PEX2009 always suggested that ESX was the “flagship” hypervisor and ESXi was “targeted for embedded and OEM” deployments.

In practical terms, migration from ESX 3.x to vSphere/ESXi didn’t make a lot of sense for many large or institutional customers at the time due to the lack of third-party driver parity between ESX and ESXi in vSphere. However, for net new installations where thrid-party drivers and service console agents were not a concern, the message about ESXi’s superiority was getting lost. Thomas Paine once said “what we obtain too cheap, we esteem too lightly” and I’d attribute the slow uptake on ESXi to the perception that it was somehow inferior to ESX – a misconception owed to it being offered in a “free” version.

Price is what you pay; value is what you get.

- Warren Buffet

By Warren Buffet’s standards, ESXi is a tremendous value. For the novice entering bare-metal virtualization for the first time, the relative ease with which ESXi installs to a USB flash drive allows for a trial experience that is both quick and reassuring. I’d argue that ESXi’s tiny memory footprint and generous hardware support make it the easiest platform for testing bare-metal virtualization. As I’ve blogged about, ESXi takes about 14 minutes to install to USB flash – from initial CD-ROM boot to configuration console.

Anyone experienced with ESX will have encountered service and performance affecting IRQ sharing issues with the service console. The hours discovering, tracking and mitigating these kinds of issues after a BIOS update or hardware refresh can never be reclaimed. The fact is these problems simply do not exist for ESXi – something many ESXers will appreciate.

I’ve attended a great deal of WebEx sessions on VMware products over the last year and I’m still hearing hushed tones and uncertainty about the role of ESXi versus ESX. To be clear, ESXi is being talked about as “enterprise ready,” but much of the focus is still on ESX. These overtones were still present in an “vSphere: Install, Configure and Manage” course I recently attended to qualify for VCP410. While our instructors were very knowledgeable and experienced, there seemed to be much less confidence when discussing ESXi versus ESX. In fact, the lab guide clearly states:

If you are new to VMware vSphere and you do not have any special needs for more advanced features, use ESXi.

- Page 599, Module 13, Installing VMware ESX and ESXi

The manual – and VMware’s choice of message here – seems to indicate that ESX has “more advanced features” than ESXi. While the “advanced features” VMware is talking about are service console related, it leaves many regarding ESXi as the inferior product in sharp contrast to today’s message. If the statement “ESXi’s superior architecture will be the exclusive focus of VMware’s development efforts” isn’t writing on the wall for the rest of you, here’s a list of VMware’s new talking points on ESXi:

• Improved Reliability and Security
• Fewer Patches
• Less Disk Space
• Streamlined Deployment and Configuration
• Reduced Management Overhead
• Next Generation Hypervisor
• Superior Architecture
• Drastically Reduced Hypervisor Footprint
• Smaller Code Base, Smaller Attach Surface
• Certified on over 1,000 Server Systems – including USB keys
• New, Operating System Independent

In contrast, the ESX platform is being re-imaged. Here are some new talking points about ESX:

• The Older Architecture
• Relies on Linux OS for Resource Management
• 20x Larger on-disk Footprint
• More Complex to Configure
• Console OS Administration for Configuration and Diagnostics
• Prone to Arbitrary Code Execution (Console OS)

For many of us familiar with both ESXi and ESX, nothing here is really new. The only real change is the message: build your eco-system around ESXi…

SOLORI’s Take: It’s clear to me that VMware took inventory of its customers and chose to lead with ESX when vSphere was released. I suspect this was a practical decision due to the overwhelming numbers of ESX hosts already installed. However, the change in marketing and positioning we’re witnessing signals that we’re moving toward a time when ESX will be openly considered a dead-end variant.

When will ESX be phased-out? That’s up to market forces and VMware, but the cloud loves efficiency and ESXi is certainly more resource efficient and compartmentalized than its brother ESX. Furthermore, VMware has to maintain two development and support chains with ESX and ESXi and Darwin likes ESXi. If I had to bet, I wouldn’t put my money on seeing an ESX version of the next major release. In any case, when ESX is gone VMware can stop having to make excuses for the “linux console” and the implications that VMware is somehow “based on Linux.”

UCS and VCE vBlock Type 1 Challenge Top VMmark

VMmark "Tile" Loads

Last November we reported on the Fujitsu RX300 S5 rack server taking the top VMmark spot for 8-core systems. Yesterday (January 11, 2010) Cisco’s UCS B200-M1 using VMware ESX 4.0 (build 164009) came within 0.5% of the top spot with a score of 25.06@17 tiles. While falling only slightly short of the mark set by the brute force RX300/DX80 combo, the UCS system did so with a very different solution, unsurprisingly similar to the vBlock Type 1 architecture described by Chad Sakacc in his blog post about the VMware, Cisco and EMC alliance.

Given that VMmark is a single node test harness, the difference between rack server and blade server architectures is a non-issue. However, more than just rack vs. blade is going on in this comparison. The Cisco UCS system is being fed by a pair of 10GE converged network adapters – used both for host network access and Fiber Channel bus access – and a monolithic storage array in the guise of a CLARiiON CX4-240 complete with a complement of 20, 73GB STEC SSD’s – just to sweeten the pot.

VMmark Network Configuration for the UCS B200-M1

While it is clear from past VMmark posts that the network speed (beyond 1Gbps) has little to do with the results, it is nice to see the confidence Cisco has in the CNA approach (Cisco UCS M71KR-Q) to go with the “eggs in a basket” solution. Given the storage demands on the CNA, the VMmark result should remove any doubt about the viability (performance) of high-capacity tandems (we’ll leave the physical link security concerns for another day.)

However, where the “rubber meets the road” in this contest is storage I/O and this solution – in our opinion is just plain showing off. With just 41 disks to build from, the CX4-240 has been configured to deliver 37 LUNs – nearly one LUN per unit disk. Before any awards are given out for storage of the year, we need to consider that 36 of those LUNs are RAID0 – yielding a testing platform with no real-world analog (hence “showing off”.)

CLARiiON CX4-240 Storage Build-out for UCS B200-M1 VMmark

Given the ease at which RAID0 can be replaced by RAID1+0, it may be safe to assume that the same results could have been obtained by using 77 disks instead of 41 – at which point the CX4-240 would still be less than half the size of the top VMmark’s 172-disk solution. The reason is clear: SSD’s accelerate I/O loads incredibly well in architectures that support them. If anything, this “runner-up” proves that SSD adoption is on the verge of becoming mainstream.

But what does this test show about UCS? Firstly, it shows that Cisco’s platform can compete with the best solutions out there on CPU and I/O performance (what’s a half a percentage point across 102 virtual machines?) It’s not really a surprise given that the UCS platform was designed to do just that – and within a neatly managed framework. Secondly, it shows that the choice of EMC as a partner was an excellent one. As Martin Glassborow commented on his Storagebod’s Blog, EMC’s involvement in VMware has energized the storage vendor to take bold and innovative steps towards Cloud Computing solutions that it might not have done otherwise (like the RAID0 SSD array). Thirdly and most importantly, it underscores the importance of predictable performance in a virtualization solution. Given the UCS/vBlock approach to systems organization, it can be very difficult not to draw solid parallels between the benchmarks and expectations for net new builds based on the criterion.

Quick-Take: ESXi Patch Released

Thanks to a tweet from Duncan Epping at Yellow Bricks, we’ve installed the latest ESXi patches to combat the unexpected vCenter problems reported with Update 1 for vSphere. While we’ve not experienced the vCenter problem in the lab, enough of users out there have caught it for VMware to issue a “not recommended” warning for ESXi users.

VMware ESX & vCenter Server Alerts

ESX 4.0: If you plan to upgrade ESX 4.0 to 4.0 Update 1 (fixed in 1a), it is critical to read KB article 1016070 before proceeding with the upgrade (affecting HP Proliant Systems w/Insight Agents).

vCenter Server: vCenter Server: If you have ESXi hosts connected to vCenter Server 4.0, please do not upgrade vCenter Server to Update 1 before installing the patch (ESXi400-200912001) referenced in KB article 1016262.

- VMware Support

SOLORI’s Take: reinforces the concept of patch regression in lab or non-critical cluster… Work with your VMware professional(s) to manage VMware/vSphere patches and updates whenever possible.

Quick Take: Year-end DRAM Price Follow-up, Thoughts on 2010

Looking at memory prices one last time before the year is out and prices of our “benchmark” Kingston DDR3 server DIMMs are on the decline. While the quad rank 8G DDR3/1066 DIMMs are below the $565 target price (at $514) we predicted back in August, the dual rank equivalent (on our benchmark list) are still hovering around $670 each. Likewise, while retail price on the 8G DDR2/667 parts continue to rise, inventory and promotional pricing has managed to keep them flat at $433 each, giving large foot print DDR2 systems a $2,000 price advantage (based on 64GB systems).

Benchmark Server (Spot) Memory Pricing – Dual Rank DDR2 Only
DDR2 Reg. ECC Series (1.8V)	Price Jun ‘09	Price Sep ‘09	Price Dec ‘09
KVR800D2D4P6/4G 4GB 800MHz DDR2 ECC Reg with Parity CL6 DIMM Dual Rank, x4 (5.400W operating)	$100.00	$117.00 up 17%	$140.70 up 23% (Promo price, retail $162)
KVR667D2D4P5/4G 4GB 667MHz DDR2 ECC Reg with Parity CL5 DIMM Dual Rank, x4 (5.940W operating)	$80.00	$103.00 up 29%	$97.99 down 5% (retail $160)
KVR667D2D4P5/8G 8GB 667MHz DDR2 ECC Reg with Parity CL5 DIMM Dual Rank, x4 (7.236W operating)	$396.00	$433.00	$433.00 (Promo price, retail $515)

Benchmark Server (Spot) Memory Pricing – Dual Rank DDR3 Only
DDR3 Reg. ECC Series (1.5V)	Price Jun ‘09	Price Sep ‘09	Price Dec ‘09
KVR1333D3D4R9S/4G 4GB 1333MHz DDR3 ECC Reg w/Parity CL9 DIMM Dual Rank, x4 w/Therm Sen (3.960W operating)	$138.00	$151.00 up 10%	$135.99 down 10%
KVR1066D3D4R7S/4G 4GB 1066MHz DDR3 ECC Reg w/Parity CL7 DIMM Dual Rank, x4 w/Therm Sen (5.09W 5.085W operating)	$132.00	$151.00 up 15%	$137.59 down 9%(retail $162)
KVR1066D3D4R7S/8G 8GB 1066MHz DDR3 ECC Reg w/Parity CL7 DIMM Dual Rank, x4 w/Therm Sen (6.36W 4.110W operating)	$1035.00	$917.00 down 11.5%	$667.00 down 28% (avail. 1/10)

As the year ends, OEMs are expected to “pull up inventory,” according to DRAMeXchange, in advance of a predicted market short fall somewhere in Q2/2010. Demand for greater memory capacities are being driven by Windows 7 and 64-bit processors with 4GB as the well established minimum system foot print ending 2009. With Server 2008 systems demanding 6GB+ and increased shift towards large memory foot print virtualization servers and blades, the market price for DDR3 – just turning the corner in Q1/2010 versus DDR2 – will likely flatten based on growing demand.

SOLORI’s Take: With Samsung and Hynix doubling CAPEX spending in 2010, we’d be surprised to see anything more than a 30% drop in retail 4GB and 8GB server memory by Q3/2010 given the anticipated demand. That puts 8G DDR3/10666 at $470/stick versus $330 for 2x 4GB and on track with August 2009 estimates. The increase in compute, I/O and memory densities in 2010 will be market changing and memory demand will play a small (but significant) role in that development.

In the battle to “feed” the virtualization servers of 2H/2010, the 4-channel “behemoth” Magny-Cours system could have a serious memory/price advantage with 8 (2-DPC) or 12 (3-DPC) configurations of 64GB (2.6GB/thread) and 96GB (3.9GB/thread) DDR3/1066 using only 4GB sticks (assumes 2P configuration). Similar GB/thread loads on Nehalem-EP6 “Gulftown” (6-core/12-thread) could be had with 72GB DDR3/800 (18x 4GB, 3-DPC) or 96GB DDR3/1066 (12x 8GB, 2-DPC), providing the solution architect with a choice between either a performance (memory bandwidth) or price (about $2,900 more) crunch. This means Magny-Cours could show a $2-3K price advantage (per system) versus Nehalem-EP6 in $/VM optimized VDI implementations.

Where the rubber starts to meet the road, from a virtualization context, is with (unannounced) Nehalem-EP8 (8-core/16-thread) which would need 96GB (12x 8GB, 2-DPC) to maintain 2.6GB/thread capacity with Magny-Cours. This creates a memory-based price differential – in Magny-Cours’ favor – of about $3K per system/blade in the 2P space. At the high-end (3.9GB/thread), the EP8 system would need a full 144GB (running DDR3/800 timing) to maintain GB/thread parity with 2P Magny-Cours – this creates a $5,700 system price differential and possibly a good reason why we’ll not actually see an 8-core/16-thread variant of Nehalem-EP in 2010.

Assuming that EP8 has 30% greater thread capacity than Magny-Cours (32-threads versus 24-threads, 2P system), a $5,700 difference in system price would require a 2P Magny-Cours system to cost about $19,000 just to make it an even value proposition. We’d be shocked to see a MC processor priced above $2,600/socket, making the target system price in the $8-9K range (24-core, 2P, 96GB DDR3/1066). That said, with VDI growth on the move, a 4GB/thread baseline is not unrealistic (4 VM/thread, 1GB per virtual desktop) given current best practices. If our numbers are conservative, that’s a $100 equipment cost per virtual desktop – about 20% less than today’s 2P equivalents in the VDI space. In retrospect, this realization makes VMware’s decision to license VDI per-concurrent-user and NOT per socket a very forward-thinking one!

Of course, we’re talking about rack servers and double-size and non-standard blades here: after all, where can we put 24 DIMM slots (2P, 3-DPC, 4-channel memory) on a SFF blade? Vendors will have a hard enough time with 8-DIMM per processor (2P, 2-DPC, 4-channel memory) configurations today. Plus, all that dense compute and I/O will need to get out of the box somehow (10GE, IB, etc.) It’s easy to see that HPC and virtualization platforms demands are converging, and we think that’s good for both markets.

SOLORI’s 2nd Take: Why does 8GB of DRAM require less than 4GB at the same speed and voltage??? The 4GB stick is based on 36x 256M x 4-bit DDR3-1066 FBGA’s (60nm) and the 8GB stick is based on 36x 512M x 4-bit DDR3-1066 FBGA’s (likely 50nm). According to SAMSUNG, the smaller feature size offers nearly 40% improvement in power consumption (per FBGA). Since the sticks use the same number of FBGA components (1Gb vs 2Gb), the 20% power savings seems reasonable.

The prospect of lower power at higher memory densities will drive additional market share to modules based on 2Gb DRAM modules. The gulf between DDR2 will continue to expand as tooling shifts to majority-DDR3 production and the technology. While minority leader Hynix announced a 50nm 2Gb DDR2 part earlier this year (2009), the chip giant Samsung continues to use 60-nm for its 2Gb DDR2. Recently, Hynix announced a successful validation of its 40-nm class 2Gb DDR3 module operating at 1333MHz and saving up to 40% power from the 50nm design. Similarly, Samsung’s leading the DRAM arms race with 30nm, 4Gb DDR3 production which will show-up in 1.35V, 16GB UDIMM and RDIMM in 2010 offering additional power saving benefits over 40-50nm designs. Meanwhile, Samsung has all but abandoned advances on DDR2 feature sizes.

The writing is on the wall for DDR2 systems: unit costs are rising, demand is shrinking, research is stagnant and a new wave of DDR3-based hardware is just over the horizon (1H/2010). While these things will show the door to DDR2-based systems (which enjoyed a brief resurgence in 2009 due to DDR3 supply problems and marginal power differences) as demand and DDR3 advantages heat-up in later 2010, it’s kudos to AMD for calling the adoption curve, spot on!

vSphere, Hardware Version 7 and Hot Plug

VMware’s vSphere added hot plug features in hardware version 7 (first introduced in VMware Workstation 6.5) that were not available in the earlier version 4 virtual hardware. Virtual hardware version 7 adds the following new features to VMware virtual machines:

• LSI SAS virtual device – provides support for Windows Server 2008 fail-over cluster configurations
• Paravirtual SCSI devices – recently updated to allow booting, can allow higher-performance (greater throughput and lower CPU utilization) than the standard virtual SCSI adapter – especially in SAN environments where I/O-intensive applications are used. Currently supported in Windows Server 2003/2008 and Red Hat Linux 5 – although any version of Linux could be modified to support PVSCSI.
• IDE virtual device – useful for older OSes that don’t support SCSI drivers
• VMXNET 3 – next generation Vmxnet device with enhanced performance and enhanced networking features.
• Hot plug virtual devices, memory and CPU – supports hot add/remove of virtual devices, memory and CPU for supported OSes.

While the “upgrade” process from version 4 to version 7 is well-known, some of the side effects are not well publicised. The most obvious change after the migration from version 4 to version 7 is the affect hot plug has on the PCI bus adapters – some are now hot plug by default, including the network adapters!

Safe to remove network adapters. Really?

Note that the above example demonstrates also that the updated hardware re-enumerates the network adapters (see #3 and #4) because they have moved to a new PCI bus – one that supports hot plug. Removing the “missing” devices requires a trip to device manager (set devmgr_show_nonpresent_devices=1 in your shell environment first.) This hot plug PCI bus also allows for an administrator to mistakenly remove the device from service – potentially disconnecting tier 1 services from operations (totally by accident, of course.

Devices that can be added while the VM runs with hardware version 4

In virtual hardware version 4, only SCSI devices and hard disks were allowed to be added to a running virtual machine. Now with hardware version 7,

Devices that can be added while the VM runs with hardware version 7

additional devices (USB and Ethernet) are available for hot add. You could change memory and CPU on the fly too, if the OS supports that feature and they are enabled in the virtual machine properties prior to running the VM:

CPU and Memory Hot Plug Properties

However, the hot plug NIC issue isn’t discussed in the documentation, but Carlo Costanzo at VMwareInfo.com passes on Chris Hahn’s great tip to disable hot plug behaviour in his blog post complete with visual aids. The key is to add a new “Advanced Configuration Parameter” to the virtual machine configuration: this new parameter is called “devices.hotplug” and its value should be set to “false.” However, adding this parameter requires the virtual machine to be turned-off, so it is currently an off-line fix.

Quick Take: VirtualBox adds Live Migra… uh, Teleportation

Sun announced the 3.1.0 release of its desktop hypervisor – VirtualBox – with their own version of live virtual machine host migration called “Teleporting.” Teleporting, according to the user’s manual, is defined as:

“moving a virtual machine over a network from one VirtualBox host to another, while the virtual machine is running. This works regardless of the host operating system that is running on the hosts: you can teleport virtual machines between Solaris and Mac hosts, for example.”

Teleportation operates like an in-place replacement of a VM’s facilities, requiring that the “target” host has a virtual machine in VirtualBox with exactly the same hardware settings as the “source” VM. The source and target VM’s must also share the same storage, etc. and must use either the same VirtualBox accessible iSCSI targets or some other network storage (NFS or SMB/CIFS) – and no snapshots.

“The hosts must have fairly similar CPUs. While VirtualBox can simulate some CPU features to a degree, this does not always work. Teleporting between Intel and AMD CPUs will probably fail with an error message.”

The recipe for teleportation begins on the target and is given in an example, leveraging VirtualBox’s VBoxManage command syntax:

VBoxManage modifyvm  --teleporter on --teleporterport

On the source, the running virtual machine is modified according to the following:

VBoxManage controlvm  teleport --host  --port

For testing, same-host teleportation is allowed (source and target equal loopback). Obviously a ready and clean-up script would be involved to copy the settings to a target location, provide the teleport maintenance and clean-up the former VM configuration that is obsoleted in the teleportation. In the case of an error, the running VM stays running on the source host, and the target VM fails to initialize.

SOLORI’s Take: This represents the writing on the wall for VMware and vMotion. Perhaps the shift from VMotion to vMotion telegraphs the reduced value VMware already sees in the “now standard” feature. Adding vMotion to vSphere Essentials and Essentials Plus would garner a lot of adoption from the SMB market that is moving quickly to Hyper-V over Citrix and VMware. With VirtualBox’s obvious play in desktop virtualization – where minimalist live migration features would be less of a burden – VMware’s market could quickly become divided in 2010 with some crafty third-party integration along with open VDI. It’s a ways off, but the potential is there…

VMware View 4, Current Certified HCL

Given the recent release of VMware View 4.0, we though it would be handy to showcase the current state of the View “certified” HCL for “hardware” thin clients. As of November 30, 2009, the following hardware thin clients are “officially” on VMware’s HCL:

OEM	Model	OS Variant	Certified For	Compatible With	Supports PcoIP	Unit Cost (Est. $)
DELL	OptiPlex FX160	Windows XPe SP2	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$512
DevonIT	TC5	Windows Embedded Standard 2009	View 4.0, View 3.1	View 3.0, VDM 2.1, VDM 2.0	Y	$299
HP	GT7720	Windows Embedded Standard	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$799
HP	t5630	Windows XPe SP3	View 4.0, View 3.1	View 3.0, VDM 2.1, VDM 2.0	Y	$632
HP	t5630W	Windows Embedded Standard	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$440
HP	t5720	Windows XPe SP3	View 4.0, View 3.1	View 3.0, VDM 2.1, VDM 2.0	Y	$410 (refurbished)
HP	t5730	Windows XPe SP3	View 4.0, View 3.1	View 3.0, VDM 2.1, VDM 2.0	Y	$349
HP	t5730W	Windows Embedded Standard	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$550
HP	t5740	Windows Embedded Standard	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$429
HP	vc4820t	Windows Embedded Standard	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	N/A
Wyse	C90LEW	Windows Embedded Standard 2009	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$498
Wyse	R90LEW	Windows Embedded Standard 2009	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$640
Wyse	R90LW	Windows Embedded Standard 2009	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	Y	$593
Wyse	S10	WTOS 6.5	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	N	$252
Wyse	V10L	WTOS 6.5	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	N	$315
Wyse	V10L Dual DVI	WTOS 6.5	View 4.0	View 3.1, View 3.0, VDM 2.1, VDM 2.0	N	$447

Devices not on this list may “work” with VMware View 4.0 but may not support all of View 4’s features. VMware addresses certified and compatible as follows:

Certified and Compatible Thin Clients:
Certified – A thin client device listed against a particular VMware View release in the Certified For column has been tested by the thin client manufacturer against that specific VMware View release and includes a minimum set of features supported in that VMware View version.

Compatible – A thin client device certified against a specific VMware View release is compatible with previous and subsequent VMware View releases according to the compatibility guarantees published as part of that specific VMware View release (typically two major releases in both directions). However, a compatible thin client may not include all of the features of the newer VMware View release. Please refer to your VMware View Client documentation to determine which features are included.

Unlisted thin clients may embed VMware’s “software client” along with a more general purpose operating system to deliver View 4 compatibility. Support for this class of device may be restricted to the device vendor only. Likewise, thin clients that are compatible with earlier versions of View may support only a subset of View 4’s features. When in doubt, contact the thin client manufacturer before deploying with View 4.

Updated: 1-December-2009 -  added price reference for listed thin clients.

vSphere 4, Update 1 and ESXi

On November 19, 2009 VMware released Update 1 for vSphere 4.0 which, among other bug fixes and errata, adds the following new features:

• ESX/ESXi
  • VMware View 4.0 support (previously unsupported)
  • Windows 7 and Windows 2008 R2 support (previously “experimental”) – guest customizations now supported
  • Enhanced Clustering support for Microsoft Windows – adds support for VMware HA and DRS by allowing HA/DRS to be disabled per MSCS VM instead of per ESX host
  • Enhanced VMware Paravirtualized SCSI support (pvSCSI boot disks now supported in Windows 2003/2008)
  • Improved vNetwork Distributed Switch performance
  • Increased vCPU per Core limit (raised from 20 to 25)
  • Intel Xeon 3400 (uni-processor variant of the Nehalem)
• vCenter Server
  • Support for IBM DB2 (Enterprise, Workgroup and Express 9, Express C)
  • Windows 7 and Windows 2008 R2 support (previously “experimental”) – guest customizations now supported
• vCenter Update Manager
  • Does not support IBM DB2
  • Still no scan or remediate for Windows Server 2003 SP2/R2 64-bit, Windows Server 2008 or Windows 7
• vSphere Client
  • Windows 7 officially supported (no more workaround hacks)
• vSphere Command-Line Interface
  • allows the use of comma-separated bulletins with –bundle option in “vihostupdate”

Authorized VMware users can download the necessary updates for vSphere Update 1 directly from VMware. For ESX and ESXi, updates can be managed and installed from the vCenter Update Manager within the vSphere Client. In addition to the normal backup procedure and those steps recommend by VMware, the following observations may be helpful to you:

• DRS/HA cluster members CAN be updated auto-magically, however we observed very low end-to-end success rates in our testing lab. We recommend the following:
  • Manually enter maintenance mode for the ESXi server
  • Manually stage/remediate the patches to avoid conflicts
  • Manually re-boot ESXi servers if they do not reboot on their own
  • Re-scan patches when re-boot is complete, to check/confirm upgrade success
  • Manually recover from maintenance mode and confirm HA host configuration
• For the vSphere Client on Windows 7, completely remove the “hacked” version and clean-install the latest version (download from the updated ESX/ESXi server(s))

SOLORI’s Notes: When upgrading ESXi “auto-magically” we experienced the following failures and unwanted behavior:

• Update manager failure to stage pending updates and upgrades correctly, resulting in a “time-out” failure. However, updates are/were applied properly after manual reboot.
• DRS/DPM conflicts with upgrade process:
  • inadequate time given to servers for servers to recover from sleep mode
  • Hosts sent to sleep while updates being evaluated, causing DRS to hold maintenance mode while sleeping hosts awakened, resulting in failed/time-out update process
• Off-line VMs and templates not automatically migrated during update (maintenance mode) process causing extended unavailability of these assets during update

Additional Notes: Directed to the question of which updates/patches may or may not be “rolled-up” into this update, the release notes are very clear. However, for the sake of convenience, we repeat them here:

Patch Release ESX400-Update01 contains the following individual bulletins:

• ESX400-200911201-UG: Updates Core
• ESX400-200911205-UG: Updates lpfc820 driver to version 8.2.0.30.52vmw-2vmw
• ESX400-200911206-UG: Updates hpsa driver to version 3.6.14.27vmw-2vmw
• ESX400-200911207-UG: Updates mpt2sas driver to version 02.00.00.00.1vmw-2vmw
• ESX400-200911208-UG: Updates Service Console Kernel
• ESX400-200911209-UG: Updates forcedeth driver to version 0.61-2vmw
• ESX400-200911210-UG: Updates ixgbe driver to version 1.3.36-2vmw
• ESX400-200911211-UG: Updates megaraid2 driver to version 2.00.4-2vmw
• ESX400-200911212-UG: Updates megaraid-sas driver to version
• ESX400-200911213-UG: Updates mptsas driver to version
• ESX400-200911214-UG: Updates ahci driver to version 2.0-2vmw
• ESX400-200911215-UG: Updates ata-piix driver to version 2.00ac6-2vmw
• ESX400-200911216-UG: Updates mptspi driver to version
• ESX400-200911217-UG: Updates qla2xxx driver to version 821.k1.42vmw-2vmw
• ESX400-200911218-UG: Updates s2io driver to version 2.1.4.13427-2vmw
• ESX400-200911219-UG: Updates nx-nic driver to version 4.0.301-2vmw
• ESX400-200911220-UG: Updates cciss driver to version 3.6.14.8vmw-2vmw
• ESX400-200911221-UG: Updates Service Console glibc
• ESX400-200911222-UG: Updates enic driver to version 1.1.0.68-1vmw
• ESX400-200911223-UG: Updates Web Access
• ESX400-200911224-UG: Updates fnic driver to version 1.1.0.49.2vmw-2vmw
• ESX400-200911225-UG: Updates bnx2x driver to version 1.45.20-2vmw
• ESX400-200911226-UG: Updates the VMware ESX 4.0 e1000
• ESX400-200911227-UG: Updates the ESX 4.0 Intel igb driver
• ESX400-200911228-UG: Updates the ESX 4.0 Serverworks PATA for ATA driver
• ESX400-200911229-UG: Updates the ESX 4.0 ATA
• ESX400-200911230-UG: Updates the ESX 4.0 SCSI/iSCSI driver
• ESX400-200911231-UG: Updates the ESX 4.0 qlogic SCSI driver
• ESX400-200911232-UG: Updates the ESX 4.0 curl component
• ESX400-200911233-UG: Updates the ESX 4.0 gnutls component
• ESX400-200911234-UG: Updates the ESX 4.0 libxml2 component
• ESX400-200911235-UG: Updates the ESX 4.0 python component
• ESX400-200911236-UG: Updates ESX 4.0 SNMP component
• ESX400-200911237-UG: Updates the ESX 4.0 bind component
• ESX400-200911238-UG: Updates the ESX 4.0 ntp component
• ESX400-200911239-UG: Updates the ESX 4.0 audit component:

ESXi 4.0 Update 1 also contains all fixes in the following previously released bundles:

Patch Release ESX400-200906001
Patch Release ESX400-200907001
Patch Release ESX400-200909001

NEC Offers “Dunnington” Liposuction, Tops 64-Core VMmark

NEC’s venerable Express5800/A1160 is back at the top VMmark chart, this time establishing the brand-new 64-core category with a score of 48.23@32 tiles – surpassing its 48-core 3rd place posting by over 30%. NEC’s new 16-socket, 64-core, 256GB “Dunnington” X7460 Xeon-based score represents a big jump in performance over its predecessor with a per tile ratio of 1.507 – up 6% from the 48-core ratio of 1.419.

To put this into perspective, the highest VMmark achieved, to date, is the score of 53.73@35 tiles (tile ratio 1.535) from the 48-core HP DL785 G6 in August, 2009. If you are familiar with the “Dunnington” X7460, you know that it’s a 6-core, 130W giant with 16MB L2 cache and a 1000’s price just south of $3,000 per socket. So that raises the question: how does 6-cores X 16-sockets = 64? Well, it’s not pro-rationing from the Obama administration’s “IT fairness” czar. NEC chose to disable the 4th and 6th core of each socket to reduce the working cores from 96 to 64.

At $500/core, NEC’s gambit may represent an expensive form of “core liposuction” but it was a necessary one to meet VMware’s “logical processor per host” limitation of 64. That’s right, currently VMware’s vSphere places a limit on logical processors based on the following formula:

CPU_Sockets X Cores_Per_Socket X Threads_Per_Core =< 64

According to VMware, the other 32 cores would have been “ignored” by vSphere had they been enabled. Since “ignored” is a nebulous term (aka “undefined”), NEC did the “scientific” thing by disabling 32 cores and calling the system a 64-core server. The win here: a net 6% improvement in performance per tile over the 6-core configuration – ostensibly from the reduced core loading on the 16MB of L3 cache per socket and reduction in memory bus contention.

Moving forward to 2010, what does this mean for vSphere hardware configurations in the wake of 8-core, 16-thread Intel Nehalem-EX and 12-core, 12-thread AMD Magny-Cours processors? With a 4-socket Magny-Cours system limitation, we won’t be seeing any VMmarks from the boys in green beyond 48-cores. Likewise, the boys in blue will be trapped by a VMware limitation (albeit, a somewhat arbitrary and artificial one) into a 4-socket, 64-thread (HT) configuration or an 8-socket, 64-core (HT-disabled) configuration for their Nehalem-EX platform – even if using the six-core variant of EX. Looks like VMware will need to lift the 64-LCPU embargo by Q2/2010 just to keep up.