Once it powers on, you will need to configure your iPad by going into Settings, the vSphere client (usually bottom left corner of screen, in the Apps section), then you enter the IP address of your mobile appliance.

Finally, you can access your environment from the vSphere iPadapp by entering your vCenter server info or ESX server info, with appropriate username and password.

vSphere Client for iPad

Having a heads-up from the vExpert team briefing by Srinivas Krishnamurti, Sr. Director for Mobile Solutions and Marketing at VMware, plus earlier press coverage from VMworld 2010 (see below), I knew what this “information leak” was hailing. Fortunately, the offending section (text above) was quickly redacted and VMware managed to avoid spoiling the surprise pending today’s [press release].

However, that was not the only source of “information leakage” prior to today’s announcement: you just had to know where to look. For instance, while looking deeper into the virtual appliance for our vCMA how-to, I found bread-crumbs pointing to more “curious” iPad wanderings. The following “Easter egg” was discovered in the “action-config.xml” file (which we held back under the spirit of the information embargo):

This grouping of action/command definitions identify 17 of 23 vCMA action classes. These classes meant four things to me: (1) the actions are tuned specifically for a non-HTML-only client; (2) the limitations of vCMA’s web interface do not bind the iPad client; (3) there is significant potential for “capabilities drift” between the iPad client the “generic” mobile access client (i.e. HTML) as time goes by (read: richer feature set, user options); and (4) other “tablet” or “mobile” clients can’t be too far behind.

Since it is not feasible to have iPad software previews for vExperts (i.e. via iTunes) for pre-release products, this “pre-view” is based on exposure to product briefing and other pre-launch sources (direct and indirect). We’ll be following-up within the week with actual hands-on experience… That said, here’s what’s going on with VMware and iPad:

vSphere Client for iPad

Today, VMware CIO Steve Herrod announced the launch of version 1.0 of the vSphere Client for iPad (vCiP). The aptly named utility runs on Apple’s current generations of iPad and provides access to many of the basic administrative functions available to vCenter and the standard vSphere Client. This release must be seen as a quick, 1-2-3 punch of mobile and management-centric releases for VMware in the span of two weeks: vCenter Ops, View Client for iPad and now vSphere Client for iPad.

This iPad application is not truly a “native” or “fat” client for vSphere in the “conventional Windows sense.” Instead, VMware’s new app deploys as a web service reliant application (typical of its iPad ilk), and it is accordingly “small, light and elegant.” As you might guess from the [leading] introduction, the “heavy lifting” is actually performed by VMware’s vCenter Mobile Access (vCMA) appliance through the set of new classes (conveniently listed above).

VMware diagram showing (optional) placement of firewall, vCMA, vCenter and vSphere clusters. The use of a VPN connection to your firewall is strongly recommended as vCMA deploys with its web service without SSL enabled.

This illustration depicts the “best practice” recommended deployment for the iPad client by way of a trusted VPN connection. Again, this information was provided to us from Srinivas and his team “pre-launch” and hence was also prior to the recently released enhancements in vCMA (see below). In either case, the connection from iPad to vCenter is always translated through vCMA.

Unlike the Windows variant, the following must be configured into the iPad’s “Settings” for the vSphere app prior to initial connection:

The IP address or DNS host name for your vCMA appliance (displayed as “Web Server” in “Settings”).

vCMA’s web service is not SSL encrypted, and these credentials could be passed “in the clear.” (see updated post, SSL added to vCMA this Tuesday.) Given this client is targeted for mobile use, the risk of exposure to insecure networks (Internet, public WiFi, etc) without SSL would have created “special” opportunities for man-in-the-middle attacks. However, the use of a mobile VPN connection for the iPad client is strongly recommended, but no longer strictly necessary.

I think “launched” is a good description of a product that represents a company’s first release from a product acquisition that was already somewhat mature. No surprising new features, no trend-setting advanced in interface or integration – just a solid, usable “pane of glass” to improve “visibility” into an existing product set. That’s how I’d describe VMware’s “new” vCenter Operations appliance for vSphere.

The product launches initially as a virtual appliance (similar to VMDR, vMA, vCMA, etc.) that enhances vCenter’s ability to track performance, capacity and changes in the vSphere environment. This initial offering is called VMware vCenter Operations Standard and is priced per-VM (I’ll get to those details later.) vCOPS Standard will be available for download and trial beginning March 14, 2011. Here’s how VMware describes it:

Proactively ensure service levels, optimum resource usage and configuration compliance in dynamic virtual and cloud environments with VMware vCenter Operations. Through automated operations management and patented analytics, you benefit from an integrated approach to performance, capacity and configuration management. You’ll gain the intelligence and visibility needed to

Get actionable intelligence to automate manual operations processes

Gain visibility across infrastructure and applications for rapid problem resolution

Get ‘at-a-glance’ views of operational and regulatory compliance across physical and virtual infrastructure.

If you’re like me, that description won’t make you find a place in your strained IT budget for VMware’s new plug-in. Eventually, VMware will find the right messaging to sell this add-on, but let’s see if it can sell itself, shall we? Located deep within a “related whitepaper” there is an indication of how vCOPS differentiates itself from the crowd of “pretty statistics loggers” and delivers some real tasty goodness. I believe this is the real reason why VMware shelled-out $100M for the technology.

Dynamic Thresholds

Yeah, I thought that too. What the heck is a “dynamic threshold” and why do I care? For one thing, it takes VMware two pages of white paper just to describe what a “dynamic threshold” is, let alone describe how it adds value to vCenter. In short, VMware’s statistics logger applies eight proprietary algorithms to live and historical data to “predict” what “normal” operating parameters are for a specific VM, host, cluster, etc. and then make decisions as to whether or not anomalous conditions exist in the present operating state.

Effectively, VMware’s dynamic threshold takes a sophisticated look at the current trend data just like a seasoned IT admin would – except it does it across your entire virtual enterprise every 12 hours and predicts what the next 12 hours should look like. This “prediction” becomes the performance envelope, hour by hour, for the next 12 hours of operation. So long as your virtual object’s performance stays within the envelope, the likelihood of anomalous behaviour is low; however, when it is operating outside the envelope, outliers are likely to trigger performance alarms.

The following transforms are applied to statistical data every 12 hours:

• An algorithm that can detect linear behaviour patterns (e.g., disk utilization, etc.).
• An algorithm that can detect metrics that have only two states (e.g., availability measurements).
• An algorithm that can detect metrics that have a discrete set of values, not a “range” of values, (e.g., “Number of DB User Connections,” “Number of Active JMVs,” etc.).
• Two different algorithms that can detect cyclical behaviour patterns that are tied to calendar cycles (e.g., weekly, monthly, etc.)
• Two different algorithms that can detect general non-calendar patterns (e.g., multi-modal)
• An algorithm that works, not with time-series or frequently measured values, but with sparse data (e.g., daily, weekly, monthly batch data)

VMware claims this approach – to borrow a recently over-used term – “wins” versus typical bell-shape algorithm approaches many times over. In statistical analysis against real-world VM metrics, VMware says typical bell-shape analysis “barely shows up” and, in the few cases where it “wins” the bell-shape approach does so only slightly. In enterprise applications, being able to present “anomalous behaviour” of related systems in opposition can more quickly lead to root-cause identity. Here, VMware demonstrates how anomaly counts for separate, related application tiers can be compared and correlated visually:

Do Fries Come with That?

From some of the back-peddling overheard in the vExpert pre-launch conference, VMware’s testing the waters on where the product fits at the low-end. Essentially, this is an enterprise class product offering that’s been paired-down to fit into a smaller IT budget. Like most VMware products, a generous “free” trial period will be granted to allow you to try before you buy. However, the introductory price (i.e. official pricing is not posted on VMware’s site) is set at $50/VM (hence Kendrick’s quandary) for up to 500 VMs (about $25K).

Since VMware intends to offer an inclusive pricing scheme, all registered VMs will need to be licensed into the Standard Edition’s footprint. In the vExpert call, there was “talk” about extending analysis only to specific VMs (and allowing for a paired-down licensing footprint) but that is conjecture today. In a typical enterprise where 70-80% of workloads are non-mission critical, the cost and license model for vCOPS could be an obstacle for some – or at least force the use of a separate vCenter and cluster arrangement. Let’s hope VMware comes-up with a mission-critical license model quickly.

It’s just a short, 270MB download separating you from managing your vCenter or licensed vSphere host from your mobile phone, Internet tablet or PC’s web browser. This simple virtual appliance performs all of the client API calls to vCenter and presents a web-based user interface that requires only basic HTML – perfect for mobile devices. It’s a bit quirky with DPM (as you’ll see later in the post) but it has a compelling feature list as well in this v1.0 fling from VMware.

The vCenter Mobile Access appliance is quick and easy to install. VMware provides these curt instructions to get you started:

Extract the zip file to a temporary directory, for example c:\temp. The files contained in the zip file include :
* vCenterMobileAccess-1.x.y.z.ovf
* system.vmdk

Select the option “Import from file” and browse to the OVF file, for example: c:\temp\vCenterMobileAccess-ovf\vCenterMobileAccess-1.0.0.10.ovf and follow the wizard next steps.

In the “End User License Agreement” page, read the license agreement completely, click on the “Accept all license agreements”, and continue the steps.

In the “Name and Location” page, provide the name for your virtual machine.

Once the wizard completes, a virtual machine will be created. Select the virtual machine and power it on.

Once it powers on, you can access the web application from your mobile device browser using the URL http:///vim.
Once connected, you will see the login screen where you can provide the vCenter or ESX IP address or name as well as username and password.

Installation of the virtual appliance is fairly straight forward, but there are a few “gotchas” to be encountered depending on your environment. For instance, if you do not run DHCP in your management or test network, you’re going to need to drop to the console for setup. Also, the default password is extremely weak, so changing it before testing or deployment is imperative. Also, there is an incompatibility in the latest version between the appliance management console (web) and Firefox, although this issue DOES NOT extend to the vCenter Mobile Access application proper.

Detailed vCMA Installation

Here’s a more expansive how-to that addresses some of these issues in deeper detail. To install VMware’s vCMA from the OVF package, I did the following:

Extracted the zip file to a network share reachable from my workstation;

Logged into vCenter with the VI Client;

Selected the menu File -> Deploy OVF Template…

Selected “Deploy from file:” and browsed to the “.ovf” file, selecting it (i.e. vCenterMobileAccess-1.0.0.41.ovf), then clicked “Next >”;

Selected the default VM name, vCenter Mobile Access, and selected a datacenter and folder to place the VM into, then clicked “Next >”;

Selected a cluster (or host) to house the VM, then clicked “Next >”;

Selected a resource pool (optional), then clicked “Next >”;

Selected a datastore to store the VM files, then clicked “Next >”;

Selected the vNetwork to connect the VM’s “Network 1” interface to, then clicked “Next >”;
(note: this network must have access to vCenter which may require adjustments to a firewall setting depending on your environment.)

Reviewed the deployment task summary and then clicked “Finish” to deploy.
(note: wall-clock deployment time was under 3 minutes.)

Finally, the deployment requester changed to “Completed Successfully” and I clicked ‘Close” to complete the process.

Before powering-on the appliance, I disabled logging from the “Options” tab of the Virtual Machine Properties page by right-clicking on the VM, selecting “Edit settings…”, clicking the “Options” tab and selecting “General” from the “Advanced” section, then uncheck the “Enable logging” box.

Once the appliance has booted, you’ll need its IP address. The vCMA appliance is setup for DHCP: if no DHCP is found, it will self-assign an IP address until one is manually configured. To manually change the vCMA address, I did this:

Opened the vCMA virtual console;

Using down-arrow, selected “Configure Network” and hit the “enter” key;

Selected “n” to disable DHCP;

Entered the vCMA’s intended IP address (i.e. 192.168.100.100);

Entered the vCMA’s netmask (i.e. 255.255.255.0);

Entered the vCMA’s network gateway (i.e. 192.168.100.254);

Entered the primary DNS server for the network (i.e. 192.168.100.15);

Entered the secondary DNS server for the network (i.e. 192.168.200.15);

This is a somewhat “mix to taste” step. We use ISO images and encourage their use. The size of the OS volume will end-up being somewhere around 8GB of actual space-on-disk after this step, making 40GB sound like overkill. However, the OS volume will bloat-up to 18-20GB pretty quick after updates, roles and feature additions. Adding application(s) will quickly chew-up the rest.

Edit Settings… ->

Options -> Advanced -> General -> Uncheck “Enable logging”

Hardware -> CD/DVD Drive 1 ->

Click “Datastore ISO File”

Browse to Windows 2008 R2 ISO image

Check “Connect at power on”

Options -> Advanced -> Boot Options -> Force BIOS Setup

Check “The next time the virtual machine boots, force entry into the BIOS setup screen”

It is important that VMware Tools be installed next, if for no other reason than to make the rest of the process quicker and easier. The additional step of disabling “Shared Folders” is for ESX/vSphere environments where shared folders are not supported. Since this option is installed by default, it can/should be removed in vSphere installations.

VM -> Guest -> Install VMware Tools ->

Custom -> VMware Device Drivers -> Disable “Shared Folder” feature

Retstart

Complete Initial Configuration Tasks:

Once the initial installation is complete, we need to complete the 2008 R2 basic configuration. If you are working in an AD environment, this is not the time to join the template to the domain as GPO conflicts may hinder manual template defaults. We’ve chosen a minimal package installation based on our typical deployment profile. Some features/roles may differ in your organization’s template (mix to taste).

Set time zone -> Date and Time ->

Internet Time -> Change Settings… -> Set to local time source

Date and Time -> Change time zone… -> Set to local time zone

Provide computer name and domain -> Computer name ->

Enterprise Edition: W2K8R2ENT-TMPL

Standard Edition: W2K8R2STD-TMPL

Foundation Edition: W2K8R2FND-TMPL

Note: Don’t join to a domain just yet…

Restart Later

Configure Networking

Disable QoS Packet Scheduler

Enable automatic updating and feedback

Manually configure settings

Windows automatic updating -> Change Setting… ->

Important updates -> “check for updates but let me choose whether to download and install them”

Recommended updates -> Check “Give me recommended updates the same way I receive important updates”

Who can install updates -> Uncheck “Allow all users to install updates on this computer”

Modify and Silence Server Manager

(Optional) Parts of this step may violate your local security policies, however, it’s more than likely that a GPO will ultimately override this configuration. We find it useful to have this disabled for “general purpose” templates – especially in a testing/lab environment where the security measures will be defeated as a matter of practice.

Security Information -> Configure IE ESC

Select Administrators Off

Select Users Off

Select “Do not show me this console at logon” and close

Modify Taskbar Properties

Making the taskbar usable for your organization is another matter of taste. We like smaller icons and maximizing desktop utility. We also hate being nagged by the notification area…

Right-click Taskbar -> Taskbar and Start Menu Properties ->

Taskbar -> Check “Use small icons”

Taskbar -> Customize… ->

Set all icons to “Only show notifications”

Click “Turn system icons on or off”

Turn off “Volume”

Start Menu -> Customize…

Uncheck “Use large icons”

Modify default settings in Control Panel

Some Control Panel changes will help “optimize” the performance of the VM by disabling unnecessary features like screen saver and power management. We like to see our corporate logo on server desktops (regardless of performance implications) so now’s the time to make that change as well.

Disable Swap File

Disabling swap will allow the defragment step to be more efficient and will disable VMware’s advanced memory management functions. This is only temporary and we’ll be enabling swap right before committing the VM to template.

Computer Properties -> Visual Effects -> Adjust for best performance

Computer Properties -> Advanced System Settings ->

System Properties -> Advanced -> Performance -> Settings… ->

Performance Options -> Advanced -> Change…

Uncheck “Automatically manage paging file size for all drives”

Select “No paging file”

Click “Set” to disable swap file

Remove hibernation file and set boot timeout

It has been pointed out that the hibernation and timeout settings will get re-enabled by the sysprep operation. Removing the hibernation files will help in defragment now. We’ll reinforce these steps in the customization wizard later.

cmd: powercfg -h off

cmd: bcdedit /timeout 5

Disable indexing on C:

Indexing the OS disk can suck performance and increase disk I/O unnecessarily. Chances are, this template (when cloned) will be heavily cached on your disk array so indexing in the OS will not likely benefit the template. We prefer to disable this feature as a matter of practice.

C: -> Properties -> General ->

Uncheck “Allow files on this drive to have contents indexed in addition to file properties”

Apply -> Apply changes to C:\ only (or files and folders, to taste)

Housekeeping

Time to clean-up and prepare for a streamlined template. The first step is intended to aid the copying of “administrator defaults” to “user defaults.” If this does not apply, just defragment.

Copy Administrator settings to “Default” user

The “formal” way of handling this step requires a third-party utility. We’re giving credit to Jason Samuel for consolidating other bloggers methods because he was the first to point out the importance of the “unattend.xml” file and it really saved us some time. His blog post also includes a link to an example “unattend.xml” file that can be modified for your specific use, as we have.

Convert VM Template to Clone

Use the VMware Customization Wizard to create a re-usable script for cloning the template. Now’s a good time to test that your template will create a usable clone. If it fails, go check the “red letter” items and make sure your setup is correct. The following hints will help improve your results.

Remember that the ISO is still mounted by default. Once VM’s are deployed from the template, it should be removed after the customization process is complete and additional roles/features are added.

That’s the process we have working at SOLORI. It’s not rocket science, but if you miss an important step you’re likely to be visited by an error in “pass [specialize]” that will have you starting over. Note: this also happens when your AD credentials are bad, your license key is incorrect (version/edition mismatch, typo, etc.) or other nondescript issues – too bad the error code is unhelpful…

VMware’s current version of its vSphere Management Assistant – also known as vMA (pronounced “vee mah”) – will crash when run on an ESX host using AMD Magny Cours processors. This behavior was discovered recently when installing the vMA on an AMD Opteron 6100 system (aka. Magny Cours) causing a “kernel panic” on boot after deploying the OVF template. Something of note is the crash also results in 100% vCPU utilization until the VM is either powered-off or reset:

vMA Kernel Panic on Import

As it turns out, no manner of tweaks to the virtual machine’s virtualization settings nor OS boot/grub settings (i.e. noapic, etc.) seem to cure the ills for vMA. However, we did discover that the OVF deployed appliance was configured as a VMware Virtual Machine Hardware Version 4 machine:

vMA 4.1 defaults to Virtual Machine Hardware Version 4

Since our lab vMA deployments have all been upgraded to Virtual Machine Harware Version 7 for some time (and for functional benefits as well), we tried to update the vMA to Version 7 and try again:

Upgrade vMA Virtual Machine Version...

This time, with Virtual Hardware Version 7 (and no other changes to the VM), the vMA boots as it should:

vMA Booting after Upgrade to Virtual Hardware Version 7

Since the Magny Cours CPU is essentially a pair of tweaked 6-core Opteron CPUs in a single package, we took the vMA into the lab and deployed it to an ESX server running on AMD 2435 6-core CPUs: the vMA booted as expected, even with Virtual Hardware Version 4. A quick check of the community and support boards show a few issues with older RedHat/Centos kernels (like vMA’s) but no reports of kernel panic with Magny Cours. Perhaps there are just not that many AMD Opteron 6100 deployments out there with vMA yet…

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:

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).

In the future, ESXi’s superior architecture will be the exclusive focus of VMware’s development efforts.

New and existing customers are highly encouraged to deploy ESXi. Many Fortune 100 companies have already standardized on the ESXi platform.

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.

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.”

Popular Posts

In Medio Stat Veritas

SOLORI's Take and Quick Take posts express my personal opinion unless explicitly attributed to other sources. Where possible, supporting facts are presented to properly frame and ground these opinions, however they are presented "AS-IS" without regard to warranty or promise: expressed or implied.

Comments are open to all registered users and may be edited for decorum. Spam is deleted with prejudice.