Today VMware announced a new service aimed at the SMB market making it easier for these companies to adopt and move to a virtualized server environment.  This new offering is called "VMware Go™" and although currently in beta is predicted to go live in Q4 2009.

“VMware Go™ is the latest innovation we’ve brought to market as part of our ongoing commitment to helping SMB customers run their applications with more agility, profitability, and resilience,” said Dan Chu, vice president, emerging products and markets at VMware.  “Nearly every SMB stands to benefit tremendously from virtualization.  VMware Go™ will simplify virtualization for SMBs to a few easy online steps and was designed with SMBs in mind.  We want SMBs who may be sitting on the fence to realize all the benefits of virtualization without burdening their limited IT resources.” 

VMware Go™ is a free web-based service that will enable SMB customers to fly through the ESXi setup process with just a few mouse clicks.  The award-winning VMware ESXi is the industry’s most widely deployed hypervisor, with hundreds of thousands of users worldwide.  VMware ESXi, also available for free, allows companies to reduce overhead and simplify business operations by running multiple operating systems and applications on a single server, spending less money on hardware, power and cooling, and server administration. VMware ESXi together with VMware Go is an on-ramp for companies new to virtualization, especially small businesses who may not think they have the time or budget to get started.

This post brought to you by VMwarewolf

VMware Go™: free web management for ESXi

A new bunch of patches for ESX 3.5 and 3.0.x were posted this week from VMware. If you’re still in the old Virtual Infrastructure 3 world, you might want to look in to the latest patches as they contain security and critical updates.

Patch Download and Installation

See the VMware Update Manager Administration Guide for instructions on using Update Manager to download and install patches to automatically update ESX Server 3.5 hosts.

To update ESX Server 3.5 hosts when not using Update Manager, download the most recent patch bundle from http://www.vmware.com/download/vi/vi3_patches_35.html and install the bundle using esxupdate from the command line of the host. For more information, see the ESX Server 3 Patch Management Guide.

This post brought to you by VMwarewolf

ESX Patches

The new Knowledgebase blog has just posted a table of brand new (or recently updated) timekeeping articles for VMware products.  A nice one-stop shop for all the time related KB articles. Worth a visit.

This post brought to you by VMwarewolf

All about Time in VMware

Just a quick post-

Multiple symptoms, one solution>>

Symptoms:
1. Unable to ssh into your ESX host
2. Unable to login to the ESX console
3. ESX shows not responding in VirtualCenter
4. HA error (but esx host responding)
5. Unable to VMotion (but esx host responding)

Check ps output and if you see

# ps -ef
root 6232 0.0 0.0 0 0 ? Z Sep24 0:00 [cimservera <defunct>]
root 6377 0.0 0.0 0 0 ? Z Sep24 0:00 [cimservera <defunct>]
root 6496 0.0 0.0 0 0 ? Z Sep24 0:00 [cimservera <defunct>]

Solution:
http://kb.vmware.com/kb/1007887

This post brought to you by VMwarewolf

Defunct cimservera processes causing havoc

There’s a new problem a few customers have reported whereby-

• ESX disconnects randomly from VirtualCenter
• ESX disconnects when performing VI Client tasks from VirtualCenter.
• Tasks randomly timeout after a long idle time
• “An error occurred communicating to the remote host” pops up.

This only refers to Update 3. This issue seem to be affecting customers with firewalls using state-ful inspection, such as a Juniper ISG 2000, Software Revision 6.1.0R3.

The problem occurs because of SOAP timeouts, and this behavior did not exist in VC 2.0.x or 2.5 GA, as they used a different mechanism to communicate with ESX.

A knowledgebase article is in the works, but Engineering is still actively investigating this problem. One work-around that I have seen mentioned (not verified to work!) is as follows:

• Create a dummy VM on each host (e.g. 16 MB RAM, no disk, no network).
• Set CPU affinity to the last core to prevent VMotion.
• Create a new Scheduled Task that performs:
  • Change power state: Power-on dummy VM. Every hour, on the hour.
• Create another Scheduled Task that performs:
  • Change power state: Power-off dummy VM. Every hour, 30 minutes after the hour.

Like I said, Engineering is aware of this issue and actively investigating it.

This post brought to you by VMwarewolf

ESX disconnects randomly or when doing VI client tasks from VC, task randomly timeout after a long idle time

I have heard that we are getting a few calls into support on this one, so I am rushing this new Knowledgebase article ( http://kb.vmware.com/kb/1007755 to be publicly available. It’s not quite out yet, so here’s the scoop.

• Deployed VM’s base disk will point to the original template’s vmdk if Edit Virtual Hardware is used to modify it.

• A cloned VM’s base disk will point to the original VM’s vmdk if Edit Virtual Hardware is used to modify it.

The problem is caused by a bug in hostd. When reconfiguring of the vmdk happens, hostd sets the vmdk path in the vmx to the backing disk in the config specification.

VMware is aware of the problem and expects a future release to address it. The current recommendation is to not use this (currently experimental) feature.

In the case that you already used the feature:

1. After deploying the VM, review the VM properties, specifically the virtual disk location.

2. Change the virtual disk settings manually to point to the correct file by right-clicking the VM and selecting Edit Settings…

3. In the Hardware tab, select Hard Disk 1

4. Verify the Disk File box points to the intended vmdk file.  If it does not remove the Hard Disk.

5. Click Add… and use the Hardware Wizard to select the correct vmdk file.

This post brought to you by VMwarewolf

Deployed or cloned VM base disk will point to template’s or original VM’s vmdk if "Edit Virtual Hardware" is used to modify it

Now that I have been working for a few weeks in the knowledge management team at VMware I have a better handle about how our online knowledgebase is organized.

One of the things I am currently in charge of in my area of expertise are what we call Resolution Paths. Resolution Paths are collections of modular steps that can be used to solved tech support issues.  Being modular, they can be re-used in other paths. A good example is using the ping command to test network connectivity.  This step is used in all kinds of troubleshooting procedures. Put a number of these steps together, and you have a method.

What I have for you today is an index of sorts, of the top issues we see in the System Management team, along with all of the steps used in resolving these issues.  You might want to download this file and keep it handy somewhere.  All of the titles are linked to the public Knowledgebase articles for quick access.

Download this file, unzip it, and open in a browser.  That’s it!!

The main problems are shown in yellow.  The steps to resolve these issues are listed on the same line, in order of operation.  Each line represents a different problem and set steps to resolve it.  Make sense?

Feel free to share with all!

This post brought to you by VMwarewolf

Common system management issues in VMware Infrastructure