So we’ve just wrapped up day 2 at VMworld. I certainly have to say that day 2 went much better than day 1. I met so many great people down on the show floor. Since I’ve been to the last four VMworlds (US and Europe), I’m not surprised that so many at the show don’t know that much about Microsoft Virtualization. It’s great to just talk with people, no demos, no slides, just techies talking shop so to speak.
I was able to attend two sessions today. First, I went to EA3605 - Virtualizing Tier 1 Applications. Overall, the session was okay. It might have been expected but the session was a lot more about VMware features than really how to virtualize Tier 1 apps, or what are key issues, concerns, or even best practices on how to virtualize Tier 1 apps. It was much more of a product promo than an informational discussion.
Still, there were some interesting facts posted in the session. One slide showed that 73% of customers are using x86 virtualization for critical apps. That wasn’t that surprising. What was surprising was a later slide, showing specific applications and what percentage of customers were virtualizing those applications in production. The numbers surprised me. While some apps (SQL Server for example) were above 50%, many were below that, some well below. Those applications included (Exchange, DB2, and SAP). Is that what people are seeing in their deployments?
Another interesting note in that sessions was how virtualization was helping the application lifecycle, speeding deployment. To me, deployment is the easy part of the application lifecycle. Application deployment is one area that has a lot of technology. It’s the monitoring, updates, and retirement of applications that is difficult. That’s where systems management and even application virtualization can really play a part. I know I keep harping on it but without in-guest knowledge of the application, how can you say you manage the entire application lifecycle?
The other session I went to was VM3103 - How VMware Reduces Cost per Application and OpEx Costs. I was hoping to hear some details on the testing methodology of the Taneja paper, one I’ve written about before, or possible new results. Unfortunately, I got a lot of slides with graphs with little details, of which half the time they were covered by a big text box saying how much the ratios are.
Sure I can see how the methodology might works but there are some weird assumptions:
- Here’s the big one. The methodology assumes that if you run out of memory for Hyper-V, you buy a whole new server. Huh? I would buy more memory. And please don’t say you can’t add more memory. Even the test bed used BL460c G6s that support 64GB of RAM.
- Dual Quad Core 32GB server – $8,000??? Dual Quad Core 16GB - $4,000? I thought that might include the OS cost but then the actual scenarios charts break out the OS cost separate
- The methodology also said to include all the management costs. What about the 3rd party SW costs? The Microsoft suite includes Operations Manager, Configuration Manager, and Data Protection Manager. Where are the equivalent costs on the VMware side? What about OS monitoring? Application Management? Most of those charge a per agent, per VM cost.
- Where are the details on the test? The fact that the “real world" SQL servers were 1GB VMs with 512MB SQL loads?
- Why would you continue to add more SpecJBB VMs to the server, even though SpecJBB throughput was reached? To prove that you can overload the server? Okay, maybe, but why then test for overload dropoff in the performance? That doesn’t tell you VM density. It just shows that you can keep added VMs for no reason other than to drive performance down, not add it. Who does that in the production?
If you want more details on the study, you can read this whitepaper on the whole subject.
I’ll write more in the morning, especially about some of the neat technologies I saw on the expo hall. Don’t forget to keep following my tweets (@edwinyuen) for information about the show and a chance to win a ZuneHD! If you are at the show, stop by both and say hi. See everyone tomorrow.