VMware

Virtual Performance

May 2009

Previous Next
0

Its been about 10 days since I posted the YouTube video showing Hyper-V's stability problems in consolidated environments. I immediately received a lot of questions about the configuration that I answered to the best of my ability in my "Video on Hyper-V Crashes" blog entry. Many respondents were not surprised by stability problems with a first-generation product and some people requested more detail on this issue for further discussion. But there were too many comments to address in all.

One of the more interesting emails I received pointed out that it unreasonable to blame Hyper-V for the collapse of these very large and very busy websites. Hyper-V's stability issues would bring down individual VMs or small groups when the parent partition blue screened. I think that this is a reasonable observation, so its worth including here. I can't say that Hyper-V was responsible for the MSDN and TechNet crashes. That would be for Microsoft to say, when and if they choose to expose the issue behind the outage.

Lastly, all comments come from people that fall into one of two categories: one camp thinks the video captures are bogus and the other believes they're based on a real, reasonable, repeatable workload. I'm not going to try and move you from one camp to the other.

It is clear that a small, vocal, and surprisingly profane number of you think that I made this whole thing up. The premise of this latter group appears to be that Microsoft wouldn't make a product that a customer could crash under normal conditions. If this is your reasoning then no video, discussion or demonstration is going to change your mind. I'll let everyone else make their decisions based on Microsoft's track record and his or her experience with Microsoft products.

Update: 5/15/09

The team responsible for the research has deciced to post details: Setting the Record Straight on the Hyper-V Video

0 Comments Permalink
0

Video on Hyper-V Crashes

Posted by drummonds VMware May 15, 2009

Since I posted the YouTube video showing Hyper-V blue screens last Friday I've received a lot of comments, questions, compliments and complaints. The video and descriptive text have raised more questions than answers, so here are a few details to help fill out the story.

  • The workload was not technically VMmark. There are two reasons for this:
    • VMmark's run rules specify that the VMs must be configured with a single virtual disk. Because this configuration can't make use of Hyper-V's paravirtualized SCSI driver, which requires a second virtual disk, the run rules were violated to make Hyper-V produce its best results.
    • The vendors that provided requirements for VMmark included use of SMP Linux guests. Hyper-V's lack of support for these configurations means that it is unable to run VMmark according to the rules. Those rules were ignored by the test team and the ESX and Hyper-V tests were run with uniprocessor Linux guests so that Hyper-V was able to produce some number.
  • The server ran 15 tiles* when ESX was installed. So, the hardware is good.
  • The server successfully ran 10 tiles* when Hyper-V was installed, although at a much higher CPU utilization and lower throughput than ESX. The server seems to run Hyper-V correctly.
  • The 11-tile* run was tried many, many times. Hyper-V was unable to run 11 tiles without guest blue screens or the parent partition crashing and bringing down the server.

(*) As detailed in the first bullet, these aren't real "tiles". They have been dumbed down (Linux SMP) and reconfigured (extra virtual disk) to work around Hyper-V limitations.

I'm hoping to convince the people responsible for the test to shed their anonymity and come out with an official paper. I'll provide those details as soon as I can get them.

Update: 5/15/09

The team reasonable for the research has posted details of the experiment. Read more at Setting the Record Straight on the Hyper-V Video.

0 Comments Permalink
0

At VMworld Europe 2009 my engineering colleague Chethan Kumar and I presented the results of a six-month investigation into the performance of SQL Server on ESX. Tomorrow (May 12 at 09:00 PDT) we're going to offer an updated version of this session to the general public. If you have any interest in virtualized SQL Server deployments, please register and attend the presentation to discover what we learned in our investigation.

I provided some notes on that presentation in a blog entry (SQL Server Performance Problems Not Due to VMware) right after the show. But the large numbers of attendees and exceptionally high ratings encouraged me to setup this encore session. And since Chethan's research on SQL Server performance tuning has continued, we have some updates to the experimental results.

In tomorrow's webinar we will tell the story of our exploration into persistent rumors of SQL Server performance problems. The search began after VMworld 2008 when I decided to engage every customer with a complaint on SQL Server performance. At the same time Chethan investigated every possible application, operating system, and hypervisor parameter that could impact SQL performance. I talked to dozens of customers and Chethan spent hundreds of hours on this work.

This presentation will detail the results of our investigation and leave its attendees with a clear understanding SQL performance on VMware. Our conclusions are surprisingly simple and certain to help you get the most out of your virtual infrastructure.

0 Comments Permalink

Virtual Performance

Scott Drummonds works in a variety of performance areas at VMware: VDI, application best practices, competitive analysis, customer performance investigations, and outward bound communications. This blog will detail some of my musings on these subjects.

Communities