Again this year VMware topped the Goldman Sachs IT Spending Survey. Released yesterday, this survey lists which vendors are gaining and losing share of IT spending dollars based upon interviews of IT executives.
Gaining Top 3:
Losing Top 3:
Technology of Business & Business of Technology
Again this year VMware topped the Goldman Sachs IT Spending Survey. Released yesterday, this survey lists which vendors are gaining and losing share of IT spending dollars based upon interviews of IT executives.
Gaining Top 3:
Losing Top 3:
On Friday, VMware release the first version of VMware Studio. As described on the Studio page:
VMware Studio 1.0 enables software developers and hardware appliance vendors to build customized virtual appliances that can be shipped in industry standard Open Virtualization Format (OVF).
While VMware Studio is designed for ISVs to author their own virtual appliances, I have a number of enterprise customers who are interested in this as well. Either for creationo of internal virtual appliances as official versions of a software stack or as building blocks for creating a virtual machine library. Studio is more suited to the former versus the later, other VMware tools like Lab Manager and Stage Manager have library functionality built into them which are better suited for hosting an enterprise VM library.
VMware Studio is available as a free download from the above link.
Today I had an interesting issue arise with one of my customers that I’m sure might be experienced by other VMware customers in the future. It has to do with support for the version of VMware software you are running and the VMware version numbering system.
The issue was some confusion around the maintenance releases and the duration a maintenance release is expected to be running in production. As detailed on the VMware Upgrade and Update Policies page, the versioning system for VMware products is a typical X.Y.Z numbering scheme. The Z number indicates a maintenance release. It is expected that maintenance releases are upgraded to the next Minor or Major release as soon a reasonable.
The issue arises when you run a maintenance release for long term in production. VMware’s Support Terms and Conditions states (see Section 2.3.a) that:
VMware will provide Services with respect to (i) the most current release of the Software for the Contract Term (ii) the immediately preceding release of the Software, but only for a period of eighteen (18) months following the next Major Release of the Software within the Contract Term…
Meaning that users are expected to upgrade their maintenance releases within 18 months of the next Major release. When a subsequent maintenance release comes out, it may also shorten the window of support for a maintenance release. The VMware VI Support Life Cycle Maintenance Information page details each maintenance release and when support for that release ends.
Because of the confusion that the Maintenance release number created, VMware has changed the labeling mechanism for updates. As of 3.5, there are no longer a Z number for releases. Maintenance or Update releases are now numbered X.Y Ux, where x is the Update Version (i.e., 3.5 U1, 3.5 U2).
So, if you’re running a release of ESX older than 3.5, check your version numbers to make sure your release is still supported. And keep the release update version in mind when planning your upgrade and deployment schedules as well as when deploying update release. It’s best practice to be running the latest Minor or Major release.
Don’t loose sight of your maintenance releases running in production.
(Disclosure: I currently work at VMware as a Solutions Consultant)