Maritz apologises to VMware customers again
Sorry isn't always the hardest word
Magic Quadrant for Enterprise Backup/Recovery
Days before VMware's virtualization-fest at the virtual Venice of Las Vegas' Venetian Hotel, CEO has issued a second letter of apology to customers affected by the ESX update last month that crashed their virtual servers.
VMware has found that this foot-shooting episode's effects have been exacerbated by Microsoft's price-cutting of Hyper-V and whispers that VMware isn't really suitable to be mission-critical software if simple updates crash the hypervisor. Sun has also announced its xVM virtualization products and Red Hat is busy crowing about its Qumranet acquisition's KVM hypervisor which, it claims, can host many more virtual machines (VMs) than ESX.
Venetian Hotel's lagoon and gondola.
VMware recently lost its R&D director, Richard Sarwal, who had been recruited when founder Diane Greene ran VMware inside the Joe Tucci-controlled EMC big tent. Greene was fired in July and ex-Microsoft executive Paul Maritz, recently recruited by EMC to run its cloud computing initiatives, was given VMware to run. His update engineers screwed up big time by issuing an ESX update in August that contained destructive time out code. This caused many VMware users' licenses to abruptly expire and their virtualized server worlds came crashing down to Earth.
VMware quickly developed workarounds and fixes and Maritz issued a mea culpa letter. But then Sarwal went nine months after joining VMware, to be quickly followed by Greene's husband and co-founder, Mendel Rosenblum, VMware's chief scientist. This was an expected departure but the timing is not good and sours things for Maritz.
He's decided it's necessary to issue a second apology to customers and to emphasise VMware's credentials as a mission-critical software supplier. The letter states: "we have initiated a major examination and evaluation of our product release and quality assurance processes. This effort has yielded a number of areas for improvement, and we have already begun making needed changes. "
"We have removed any instances of the type of “time-out” code from all major, minor and maintenance code releases for VMware enterprise products and will not incorporate this type of code in our licensed products going forward."
He's not explicitly blaming the previous administration but there's a hint there of sloppy update practices having to be fixed. Maritz also says: "we will improve and better align our efforts around supporting and communicating to customers in response to product issues."
Hopefully VMware existing and potential customers will be reassured by this and not feel tempted to take a gondolier across the Venetian's lagoon to the alternate virtual worlds offered by Citrix, Microsoft, Red Hat, Sun and virtual Iron. ®
COMMENTS
Ponder this
If a virtual server crashes does anyone know?
I'm still waiting for the virtual computer room.
Oh, and the new web design blows. Took a lesson from XP and Crayola Bill eh?
of course they should remove time out code and replace with VMGA
The better solution would be a Windows Genuine Advantage type code. Well, maybe VMWare Genuine Advantage. VMGA.
vmware apologists have facts wrong
With reply to Goat Jam: The release was not a Beta. VMware has a completely different release mechanism for betas.
An accurate description of the problem is that VMware forgot to take out the expiration date lockout from a prior beta when they released a general update for all customers, and which all customers of their production software were pushed to upgrade to if they were using the automated update manager. VMware then didn't realize their mistake for several weeks until the timeout occurred. And even worse, gave completely unrealistic fix estimates when informed of the issue (36hrs for a critical patch to an enterprise product is not acceptable).
As for Danial Gold's comments, you are leaving out some other aspects:
- Impacted customers were unable to vmotion across clusters until patches were applied (for any reasonably sized cluster, this is a significant impact).
- There was significant confusion about the production impact of changing the date of the ESX hosts
- Given that VMware was not aware of what was going on until many of their customers were impacted and had expanded significant effort tracking down the cause of vm's being unable to restart, to state that customers should have applied workarounds is completely wrong. VMware didn't publish the workarounds until after many clients had already spent hours trying to figure out what was happening.
In brief, VMware completely screwed up, and their new CEO is exactly right to apologize again.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
