Virtualization has been a hot topic in tech for several years now and shows no signs of going out of style any time soon. I think there are some really great uses for it, such as server and application consolidation, but, I also think there is a lot of hype and glamour surrounding the topic as well. Will virtualizing your servers really save you money and time? That all depends, in my opinion. Only you know what applications you have and how well those currently perform. The only way you'll know how virtual machines will help or hurt you is by testing.
The department I work for currently uses Microsoft Virtual Server 2005 R2 on top of Windows Server 2003 for the majority of our virtual machines. When Microsoft introduced Hyper-V with Windows Server 2008, we discussed upgrading, but ultimately held off on the new Microsoft virtualization solution. Hyper-V had many mixed reviews upon its debut, so we wanted to wait to see what later revisions could deliver. Also, at the time, Virtual Server 2005 met our needs just fine. Since VS2005 wasn't broken ... you get the idea.
Time has passed since then and Microsoft has recently released Windows Server 2008 R2 with an updated version of Hyper-V. There have been several improvements to Hyper-V since its initial release. Virtual Server 2005 has started to show its age, compared to all the other virtualization solutions now available, so now is a great time to do some testing of Hyper-V 2008 R2.
As users of Virtual Server 2005, my co-workers and I have known using SCSI virtual disks (with Virtual Machine Additions installed) has advantages over using IDE disks in VS2005. Switching from the IDE to a SCSI interface made noticeable virtual machine performance improvements. When Hyper-V was originally released, however, booting off SCSI disks wasn't supported. "How version 1.0!" we all thought. Removing features from new products isn't new for Microsoft, after all. Well, it's not supported in Server 2008 R2, either. I was disappointed, but this time the question "Does it really matter?" came to mind.
I decided to test this using one of our newer servers that has been freshly reloaded with Windows Server 2008 R2 Standard with Hyper-V from scratch. For the test, I'd create a new Windows 7 virtual machine with two extra drives attached. One drive would be connected to the virtual IDE controller. The other would be connected to a new virtual SCSI controller. Both drives would be set to the same physical size (30GB) and both would be created as fixed-size virtual disks.
The test platform specs are as follows.
Test Server:
- HP ProLiant DL380 G5
- Dual Intel Xeon E5450 quad core 3.00GHz CPUs
- 14GB ECC memory
- HP NC373i gigabit server adaptor (1x1GBPs connection)
- Drive C is a HP Smart Array P400 controller (512 MB) with 2x HP 68GB 15k RPM SAS drives in RAID-1 (cache enabled)
- Drive E is a HP Smart Array P800 controller (512 MB) connected to an external MSA50 drive array with 10x HP 68GB 15k RPM SAS drives in RAID-10 (cache enabled)
- Windows Server 2008 R2 with Hyper-V installed on drive C
- Virtual machine VHD files on drive E
Test Virtual Machine:
- Windows 7 Enterprise RTM 32-bit
- 2GB memory
- Drive C (boot) is a 40GB fixed-size NTFS volume connected to IDE controller 0, port 0 on the virtual machine.
- Drive E (IDETest) is a 30GB fixed-size NTFS volume connected to IDE controller 1, port 0 on the virtual machine.
- Drive F (SCSITest) is a 30GB fixed-size NTFS volume connected to SCSI controller 0, ID 0 on the virtual machine.
- UAC is turned off, no updates applied (fresh installation for testing)
- No antivirus installed
- Logged in as an administrator
Below are some screenshots of the virtual machine's disk configuration, along with the Hyper-V settings for the virtual machine.
Disclaimer time. I've worked in the IT field for many years now and am knowledgeable in many areas of IT infrastructure and application development. I am relatively new to Windows Server 2008 R2 with Hyper-V, however. I'm also not a professional reviewer and benchmarker. I do my best to test, record, and interpret the results, but you may come to different conclusions. If you do, let me know (but play nice)! I also encourage you to repeat similar test steps if you have the time and resources. I'm doing this for fun and learning and didn't receive compensation from any product vendors (or their competitors!).
First round of tests: ATTO Disk Benchmark
To begin, I decided to go with good 'ol fashioned disk benchmarking. I searched for disk benchmarking software on Google and found ATTO Disk Benchmark v2.45. It's available as a free download from ATTO Technology, Inc. I've seen this software used on various hardware review sites, also.
For each test, I set ATTO to use the following parameters:
- Transfer Size: 0.5 to 8192.0 KB
- Total Length: 2GB
- Direct I/O checked
- Overlapped I/O selected
- Queue Depth 4
The tests were run three times in a row for each virtual drive. The IDE disk was tested first. The virtual machine was then rebooted before the SCSI disk was tested. Below are screenshots of each test. Look in the application title bar for the test iteration.
Do these test results look strikingly similar to you, too? It seems the trend between SCSI and IDE disks are almost identical. To get a better visual representation of this that I could compare, I decided to plot the data in Excel. The graph below compares the average of the IDE read and write runs to the average of the SCSI read and write runs.
From the graph, it's easy to see how IDE and SCSI reads/writes are right on par with each other. Sure, there are some differences here and there, but I think the margin of error in this testing method makes this too close to call. There were variances in each run of ATTO, so, for now, it's looking like these virtual disks perform virtually (pun intended) equal.
One thing I wondered about is the behavior when the tests hit the 512KB mark. Until then, reads/writes scale nicely. For both SCSI and IDE, read and write performance basically "meet" at the 512KB mark and then diverge from there, with priority clearly given to reads for data transfer sizes greater than 512KB. Write performance after that tops out at about 200 MB/sec and holds steady, with read performance topping out at 500 MB/sec. I tried ATTO on the virtual host computer with the same settings and no virtual machines running and experienced similar results. I then ran ATTO on some other computers, such as my laptop and desktop, and did not experience that behavior. Reads and writes on those machines stayed near equal after a 4KB data set size.
I believe the cause of the performance differences, in this case, is the HP array controller's cache. Transfer rates in hundreds of megabytes per second is pretty high, after all. The test is still valid, in my opinion, because you'll want to have your controller's cache enabled when running virtual machines in a production environment. In fact, the only other instance where I was able to replicate this behavior with ATTO Disk Benchmark was on a Lenovo X61 tablet with an Intel 32GB solid-state disk (SSDSA2SH032G1GN). On this drive, there was a similar separation of read and write performance, this time at the 4KB mark.
Second round of tests: Microsoft's SQLIO utility
I wasn't completely satisfied with the ATTO benchmark after reviewing the results. For one, I wasn't sure if ATTO Disk Benchmark was necessarily the correct tool to test this scenario (SAS drives in RAID10, virtual environment, etcetera). Secondly, I wanted something that could differentiate between random and sequential testing, along with giving the virtual drives a longer workout. The ability to import test results directly into Excel would be a big help, too.
A co-worker recommended a utility from Microsoft called SQLIO. The name of this utility is deceptive, because it does not depend on Microsoft SQL Server nor does it seem to have anything else to really do with it. It should not be confused with another Microsoft utility with a similar name. After some Google searches about the app, I came across a really great tutorial with examples and video by Brent Ozar.
I used Brent's sample configuration batch file to run my tests. All I changed were the drive letters on the "-d" parameter. I followed the rest of his instructions and let the testing run over the weekend on the IDE and SCSI virtual disks. When I ran the USP_Import_SQLIO_TestPass stored procedure to populate the SQLIO_TestPass table from the imported data, I specified "Hyper-V IDE" or "Hyper-V SCSI" in the sixth parameter. I then imported the data into an Excel pivot table. The entire process was pretty easy to follow. Testing each disk took about six hours.
Below is a pivot chart of the test results. The "128" values on the horizontal axis represent 128 outstanding requests and the "2, 4, 8, 32, 64" values represent the number of threads. I only included the "128" outstanding requests values because having them all in the graph made it unreadable. The numbers in the graph area are the "Max MB/sec" column.
Overall, again, the performance for Hyper-V virtual SCSI and IDE disks are close to identical. The most important values are the Max MB/s and Max IOs/sec. For the random read and write tests, IOs/sec are nearly matching evenly for both IDE and SCSI across all tests. I would attribute this to the controller's cache. On sequential reads, however, the SCSI virtual disk has a slight edge over the IDE disk. Also, on sequential reads, the Max MB/sec of the SCSI disk is about 10MB/sec higher than the IDE disk for each run. Another interesting series of data to note is the Max Latency for sequential writes (shorter is better). As the thread counts increase, the IDE disk performed best by eight threads, but then climbed back up by 128 threads. The SCSI disk, however, started low and increased almost linearly.
Conclusion
Whew, that was a lot of testing ... at least for someone who doesn't do that type of work all the time. In the end, I don't think you'll see a huge difference between virtual IDE and virtual SCSI disk performance in Hyper-V 2008 R2. It's true that the SQLIO tests revealed some slight advantages to virtual SCSI disks, but I believe you'd only experience this under very controlled situations.
What other kind of tests could I have done? I'm sure there are plenty out there that I'm not aware of. I felt this was a good start, though, considering I couldn't find much out there regarding IDE vs. SCSI performance in Hyper-V. One additional test I thought of after I finished was placing a constant load on the virtual machine's CPU during the SQLIO tests. I've run out of time with this hardware, though, so maybe I'll get to save that for another day.
I hope you found this post helpful. If you have any questions, please leave a comment and I will answer as soon as I can. Thanks for reading!