Quick-Take: vCMA Updated, SSL now Default

vCMA Login Screen

In February, we detailed the installation and first use of the VMware vCenter Mobile Access appliance (version 1.0.41). In that write up, we pointed out that vCMA had some security issues and said the following:

Being HTTP-only, vCMA doesn’t lend itself to secure computing over the public Internet or untrusted intranet. Instead, it is designed to work with security layer(s) in front of it. While it IS possible to add HTTPS to the Apache/Tomcat server delivering its web application, vCMA is meant to be deployed as-is and updated as-is – it’s an appliance.

– SOLORI’s blog, 28-Feb-2011

Seems VMware is listening. Yesterday, VMware announced the release and immediate availability of vCMA v1.0.42 with HTTPS/SSL enabled by default. We got this from the “vSphere MicroClient Functional Specification Guide:”

SSL Connections
By default “https” (or SSL certificate) is enabled in the appliance for the vCMA for enhanced security. You can replace the out-of-the-box certificate with your own, if needed. However, http->https redirection is currently not supported.

Other deployment considerations

1. The vCMA server comes with a default userid/password. For security reasons, we strongly recommended that you change root password.
2. If you prefer, you can set a hostname or IP address for the appliance.
3. Using standard Linux utilities, you can change the date and time in the appliance.
4. You can also upgrade the hardware version and VMware Tools in the vCMA appliance following standard procedures.

SOLORI’s Take: This welcomed change circumvents any additional kludge work necessary to secure the appliance. Using an HTTPS proxy was cumbersome and kludgey in its own right and “hacking” the appliance was tricky and doomed to be reversed by the next appliance update. VMware’s move opens the door for more widespread use vCMA and (hopefully) more interesting applications of its use in the future.

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: AMD Istanbul Update

AMD was gracious enough to invite us to their Reviewer’s Day on May 20th to have a final look at “Istanbul” and discuss their plans for the product’s upcoming release. While much of the information we received is embargoed until the June, 2009 release date, we can tell you that we’ve have received a couple of AMD’s new 6-core “Istanbul” Opterons for testing and review. We’ll look forward to seeing “Istanbul” in action inside our lab over the next couple of weeks. Our verdict will be available at launch.

Instead of typical benchmarks, we’ll be focusing on Istanbul’s implications for vSphere before the new Opteron hits the streets (remember 6-core is the limit for “free” and “reduced capability” vSphere license). If what we saw from AMD’s internal testing at Reviewer’s Day is accurate , then our AMD/VMware Eco-System partners are going to be very happy with the results. What we can confirm today is that AGESA 3.3.0.3+ 3.5.0.0+ is required to run Istanbul, so start looking for BIOS updates from your vendors as the launch date approaches. The systems we reported on from Tyan back in April will be good-to-go at launch (our GT28 test systems are already running it require a beta BIOS).

SOLORI’s take: We made a somewhat bold prediction on April 30, 2009 that “Shanghai-Istanbul Eco-System looks like an economic stimulus all its own” when comparing the AMD upgrade path to Intel’s (rip and replace) where VMware infrastructures are concerned. That article, Shanghai Economics 101, was one of our most popular AMD-related postings yet, and – judging from what we’ve seen already – it looks like we may have been correct!

While we’re impressed with the ability to flawlessly vMotion from socket 940 to socket-F, we were more impressed with the ability to insert an Istanbul into a Barcelona or Shanghai system and immediately realize the benefits. We’re going to look at our review samples, revisit our price-performance data and Watt/VM calculations before making sweeping recommendation. However, we expect to find Istanbul to be a very good match to on-premise cloud/virtualization initiatives.

SOLORI’s 2nd take: VDI and databased consolidation systems running on 4P AMD boxes are about to take a giant leap forward. We can’t wait to see 24-core and 48-core VMmark scores updated over the next two months. Start asking your system vendor for updated BIOS supporting AGESA 3.5.0.0+ (Tyan are you listening? Supermicro’s AS2041M is already there), and get your 4P test mule updated and prepare to be amazed…

VMware ESXi Update: Build 158874

VMware has released a series of critical patches for ESXi and VMware tools discussed in knowledge base articles 1010135 and 1010136. These are the highlights:

Patch for ESXi:

• Fixes an issue in the VMkernel TCP/IP stack where adding a system to an HA (High Availability) cluster results in a timeout error.
• Fixes an issue where a virtual machine might fail if a reserved register is accessed within the guest operating system.
• Fixes an issue where a virtual machine might stop responding or the progress bar in the graphical user interface might appear to be stuck at 95% when you consolidate a snapshot of a powered on virtual machine.

Update: ESXi on GT28

Just an updated post to confirm that the GT28 (with KVMoIP SMDC module) has proven to be an excellent platform both in manageability and performance. At a $150/node premium over Supermicro’s AS-1021 dual-node, the quad-gigabit interface appointed Tyan GT28 is great for clustered consolidation and the “roomy” memory allowance gives it scalability. The only thing keeping the GT28 from being “perfect” is its lack of a redundant power option.

Our test systems have been running continuously in the lab for over 3 months without a single failure. We’d like to see an updated BIOS for the SMDC module that gives us a bit more control, but the current platform beats Supermicro’s BIOS stability with their current AGESA 3.3.0+ and KVMoIP offering (AS-1021, AS-2021, etc.).

However, Supermicro has taken it’s 1U/2-node platform to the redundant power stage by offering a 2U/4-node platform with redundant supply built-in. Perfect? Nope – still only twin-gigabit, requiring the single slot be dedicated to additional Ethernet capacity. But then there’s the issue with NO knock-out for its KVMoIP-SMDC module, requiring either ugly hack-it-in wiring or the loss of the expansion slot. A serious mistake? Time will tell…