Benchmark: Are VDIs really slower than using Raw Partitions

[TerryE]

The Background

The trigger for this post was a related topic exchange with darkmikey where he quoted Section 9.9 from the UG:

With VirtualBox, this type of access is called “raw hard disk access”; it allows a guest operating system to access its virtual hard disk much more quickly than with disk images, since data does not have to pass through two file systems (the one in the guest and the one on the host).

I made a comment that this was misleading and raised a ticket requesting a change to the documentation. Let’s just say there followed a robust dialogue between Klaus, Frank and myself where we agreed to differ on this point. The substance of these two positions is:

• VB Team: VMDK mapped partitions are recommended, as they generally give significantly better performance compared to the equivalent VDI. Whilst in ideal circumstances performance might be comparable, in general the need to pass data through two file-systems results in a materially reduced performance.
• TerryE: As long as you carry out sensible maintenance of your file-systems and VDIs, the performance of VDIs and raw VMDKs are pretty comparable. The benefits of ease of management of VDIs far outweigh the performance risks of using them compared to raw partitions.

So who has the stronger argument? Since there seemed to be little value in bandying opinions, I decided to try a real-world benchmark.

The Benchmark

Since we are discussing I/O performance, I felt it fair to choose a heavy I/O scenario, and I happen to have a good one to hand. I am a system admin for the OpenOffice.org User Forums. I have developed an automated backup process where each night the D/B is dumped and delta’ed giving a Monthly full backup + weekly and daily incrementals. Any new attachments (one of the advantages of phpBB3 is that users can post attachments) are rolled up into a tarball. The sql.bz2 and tar.bz2 files are then automatically shipped off to another site which also acts as a Disaster Recovery (DR) backup for the forums.

So much for production, but for development and maintenance I have a standard Ubuntu JeOS Appliance VM (using VirtualBox, of course), which is based on two VDIs. You install it by running a small XP command script which downloads the System Image from the DR server (the entire LAMP system is a 90Mbyte 7zip archive) and uses VBoxManage to create a test VM with this as /dev/sda and a blank dynamic VDI as /dev/sda. You bootstrap into the VM and run a second script which then interrogates the DR server and downloads all the necessary .tar.bz2 and .sql.bz2 files to do a fully automated build the Apache hierarchy and PostgreSQL database as at the last overnight backup. The data downloads are currently just under 200 Mbytes of bz2 compressed files, and the whole process takes about 45mins from no VM to a LAMP VM running a working copy of last night’s forums.

The biggest chunk of this time is due to my ADSL download bandwidth, and to mitigate this delay, I cache the files and check to see if any file is already in the cache before downloading it. Since the file naming convention embeds the MD5 digest of each bz2 file, I also validate all files against their MD5 before using them. Thus by doing a dry run I can pre-populate the cache (which is on the system partition) and run the database and apache build section against a range of HDD formats. This is heavy I/O: MD5 checking, exploding tar.bz2 archives, integrating sql.bz2 with 2 delta bz2 streams, loading up a 500 Mbyte PostgreSQL database, but due to all the decompression and caching the system does swing from being I/O bound to 100% CPU bound on occasions. Still, the VBox logs tell me that my PC is sustaining about 60 I/Os per second during this process.

The Results

I ran four tests using different configurations of VDI and VMDK. The VDIs were loaded into an NTFS partition (F:) that I use for VDIs (and conventional VMDKs). This is about 60% utilised and I routinely defragment it. The raw VMDKs were logical partitions adjacent to F:. All of these partitions where sized as 1920Mbytes.

• Run 1 — Raw VMDK. 15min 37s.
• Run 2 — Static VDI. 15min 05s.
• Run 3 — Another Raw VMDK. 16min 12s.
• Run 4 — Dynamic VDI. 15min 15s.

So what on earth is going on here? According to the VirtualBox folk, VDIs are significantly slower than the Raw partitions, but no: the run times are actually very similar, and in fact in these tests the VDIs are slightly faster. Moreover, this is doing heavy I/O — far heavier than you would sustain using a normal desktop VM. If you get negligible runtime difference doing this sort of intensive I/O, then the difference in user perception for a typical workstation VM will be imperceptible.

So What is my Explanation?

1. If you trace through the VB code paths for raw VMDKs and VDIs, these are almost same in terms of hand-offs, indirection, I/O fragmentation and mapping. Both ultimately use the standard C++ stdio read and write functions. The only material difference is that the VDI cases writes to an offset in a VDI file, but the raw VMDK writes to the underlying block device (File \\.\PhysicalDriveN in NTFS).
2. The perception that file systems add an overhead is extremely misleading. Yes of course the management of a file system increases the CPU load on this system, but what the user cares about is the responsiveness of the system and that is down to the delays whilst processing must stop when your HDD is moving. The fact that your CPU is at 15% utilisation rather than 12% is irrelevant.
3. Developing file systems is extremely complex and the people who do so go to great lengths to ensure that metadata is cached where practical (and for large file structures such as VDIs the cache hit ratio on such metadata is over 99%). You only need to go to disk for cache misses. Also most writes use elevator base delayed write-through algorithms to eliminate largely the response impact of writes.
4. When you are I/O bound, it is the pattern and frequency of physical transfers that dominate the composite delay. The VMI uses a 1Mbyte allocation tile which is significantly larger than the underlying file-system cluster size (4Kbytes in the case of both NTFS and Ext3); the double mapping therefore introduces little if any increased fragmentation. Both Ext3 and (defragged) NTFS go to some lengths to maintain local proximity of adjacent clusters. Both user elevator sequencing to further optimise I/O seeks. The net result is that these two file systems largely dovetail and do not ‘fight’. (Incidentally, I think that the main reason that the VMDK times were slower is the two VDIs were stored in the same partition but the VMDK was in an adjacent partition. This increased separation of the sda and sdb regions in the VMI+VMDK case was enough to cause a slight decrease in performance and one which dominated any small overheads of using a VDI.
5. I cheated in my allocation of my VDIs because I used the magic sizing formula (NGb – 128Mb) for my disk / partition sizes. This means that the standard VDI preamble is now a whole number of clusters so the Logical and Physical clusters are aligned. (Why the VDI isn’t packed out as standard amazes me: a trivial storage overhead to prevent a source of fragmentation the file system.)
6. I also have a consistent and routine housekeeping process for allocating and managing my VDIs which keeps them “lean and mean”. Though this whole issue of how you should manage your VDIs for optimum performance, especially in the case where you need to maintain and to distribute multiple VMs, is not well documented discussed within the VirtualBox community, and the VirtualBox tool support is unnecessarily weak here, but this is really the subject of a separate article.

OK, so let me summarise my proposition: in the case of Windows hosts if you keep your VDIs on a routinely defragmented NTFS partition, then there is minimal overhead in using VDIs over raw partitions. The management advantages of using a file based encapsulation are considerable (e.g. my backup utility is my ZIP package). I feel that this benchmark clearly supports my case quite. I also believe that the same applies if you set up a Linux system properly (e.g. use a dedicated partition for your VDI directory and follow some basic rules).

However, please don't take this strawman post as "gospel" just yet. I would welcome informed feedback and discussion. However, since I have gone to the effort of thinking about it and setting up a real benchmark to support my proposition, I would ask that any counterarguments are also informed by some hard [benchmark] evidence, rather than just opinion.

[TerryE]

I will update my top post in the light of any feedback and corrections so that anyone visiting this Topic doesn't need to read all the way to the end to get the forum's consensus view. I will use this post to audit such changes, and link to any key "minority report" posts within the thread.

So please comment as you wish.

[klaus]

You have selected a perfectly sensible benchmark which measures what you care about. So far so good.

However looking at it from a distance it's actually a rather unusual access pattern for VMs. You have a very large proportion of writes, and they are temporally very close together. As a result you end up with a fairly reasonable VDI file, with low host filesystem fragmentation and also very likely low internal VDI fragmentation.

Also you say that you frequently defragment your disk. Many people don't do that - especially on highly loaded systems running many VMs.

So it's not that unexpected that the performance values are very close together. Also don't forget that one of the advantages of VirtualBox actually comes from host side caching. However the write caching strategies for filesystems are usually different to the strategies on raw disks. So for your benchmarks which does a lot of writing you may just end up to some degree comparing those strategies.

Another factor is that you say the filesystem is just 60% full - that also favors image files as they allow better data locality on the physical disk than raw partitions.

Your argument that you don't care whether the load is 15% or 12% is another assumption which isn't always true. It's true for a small scale setup with one or maybe two VMs running.

So what you can prove with this is the universal truth that there are lies, damn lies and benchmarks. A benchmark never says anything about the general case - it only provides a number for the thing it tests. I'm not saying your results are wrong or that you're doing something wrong. All you did is measure performance and you found out that for you raw partition is worse than VDI files.

Another thing you mention: the padding to align blocks. I believe this is something which can be quite trivially fixed, so it'd be interesting to work on this. Might be interesting (or not) to compare the performance.

And just to set it straight once and for all: it's not the position of the VB Team to favor raw partition access. Otherwise we wouldn't have put it in a section few people will ever get to and put big warnings there. You're interpreting way too much into one or two sentences.

As a final note: don't assume that it's set in stone that this will go to stdio forever. Things may change.

[kentborg]

So I finally got raw access working--and it is as slow as regular disk-based access. I measured that, and it is slow.

Am I stuck?

I did some tests, Linux host, Linux guest. On the machine on which I am doing Virtualbox tests I ran "hdparm -t" on the host and the SATA disk does 77MB/s. In the guest I get 11MB/s for a file-based volume, and the same for a raw volume.

On a different machine, where I am using Qemu, I did similar tests. The host and its ATA disk does 60MB/s. I use software raid 1 on the host, so I tried an md device in the host and it drops a little to 57MB/s. In a Qemu guest a file-based volume measures 20MB/s (on top of raid 1 in the host). In the same Qemu guest a raw-based volume measures 21MB/s (also on top of raid 1 in the host).

Certainly hdparm -t is not that fancy a tool, but I did run it multiple times for each case to let it converge on a repeatable best speed.

You might say Virtualbox disks are 15% efficient.
You might say Qemu disks are 35% efficient.

In conservative round numbers, Qemu seems to be twice as fast for disk access. And I thought Qemu had a bad reputation for disk speed...

Am I stuck? Am I being fooled? I want to run real services on whole OSs on a real server all doing real work. What virtualizer should I use? How does Vmware stack up?


Thanks,

-kb, the Kent who was just getting to like Virtualbox.

[TerryE]

Klaus, some responses to your comments (kentborg, my next post talks to yours). For a vendor such as Innotek now Sun to move its product into the FLOSS domain is a fine thing to do, as it benefits the community, and therefore the community which uses it also owes a debt of support. It is also a brave thing to do, because it opens the product “warts and all” to informed public criticism, in a way that closed source products avoid. However, constructive open dialogue can also benefit a product and I wanted to use this as an example of where this can work, so please bear with me here. I also wanted to bring into this debate a comment that you made in Seamless Windows and Physical Partitions:

But sure, in a normal case the difference is only measurable - people wouldn't be able to tell the difference. In typical cases it's a difference between roughly 0 to maybe 15%. However there are also really bad cases of fragmentation - and not everyone reorganizes things for optimal performance.

and given this, I believe that our views in quantitative terms are very similar, though perhaps perceptions can shift dramatically according to the language that we use. I think that we agree on:

• The overhead of using VDIs versus VMDK raw partitions is typically 0 to perhaps 15%.
• You can keep this overhead to low end of this range by thinking about how to allocate and manage both your VDIs and the underlying file systems which host them.
• You can also go to the high end of this range and in some cases considerably exceed it if you don’t bother about how you do this.
• Having VM file systems encapsulated in host based VDI files brings a lot of management conveniences in itself.

I also feel that you alluded to what is missing here when you made comments about my defragmenting drives being untypical; that a 60% full file system helps; that the way that I created my VDI ended up with a well structured one. Of course this is the case. I am a competent system administrator, with decades of IT experience. But we could easily agree and lay out the “ten basic rules” (or 20 or whatever) in an easy-to-read knowledgebase article to help those VirtualBox users who care about their I/O performance set up their systems to get good performance out of them. Such material should be in your wiki or here in the forum. (And yes, some of these rules would be slightly different for Windows and Linux hosts.)

The VirtualBox user population is largely stratified into 5 main categories. All seam to like the product because it is a lightweight (in resource terms); it supports a wide range of host and guest platforms; it is available FLOSS / PUEL. When we develop such guides, we need to think about and address the needs of each of these communities.

• Windows users who want to experiment with a Linux workstation platform.
• Linux users who still have a few Windows app that they need to run.
• MacOS users who want to do both the above.
• Developers who need to use VMs for development and test environments.
• System admins and small businesses who want to use VB as a free / cheap alternative to VMware Server / ESX.

In terms of optimising VDI performance:

• I’ve mentioned the point that any headers should always be packed so that the following image blocks are cluster aligned in terms of host and virtual file systems.
• All data writes are done in VDI_IMAGE_DEFAULT_BLOCK_SIZE (1 Mbyte) chunks which is effectively minimises fragmentation to the host file system, though as I discuss in the next post does degrade I/O performance. However, the order in which they are laid down is creation order. Also the VBoxManage modifyvdi compact algorithm identifies zero blocks and compacts the file by copying down non-zero blocks from the end of the file overwriting the data in these zero blocks, then truncating the VDO to new length. So we could really do with is a compactreordered option which basically copies the VDI in ascending block order to a new file which is then moved over the original (of possible an equivalent clonereordered reordered option).

Kentborg, it’s getting late for me so I’ll post my reply tomorrow. I also want to check something out first.

[frank]

I agree with most of your statements. But note that the user manual is primarily written for unexperienced users. So it contained a clear statement like Dear user, if you want the maximum performance, use a dedicated partition rather than a .vdi file. This statement is very generic and on many systems a dedicated partition might not be necessary (for the reasons you already wrote) but this clear statement is sufficient for the normal Ubuntu/MacOSX/Windows user. For instance, one user asked some days ago if it is possible to run VBox on Ubuntu 8.04 which was installed using wubi.

Of course we can and probably should add more hints for more experienced users about, for example, how to improve the disk performance to the user manual. And yes, suggestions are welcome.

[klaus]

So I finally got raw access working--and it is as slow as regular disk-based access. I measured that, and it is slow.

Am I stuck?

I did some tests, Linux host, Linux guest. On the machine on which I am doing Virtualbox tests I ran "hdparm -t" on the host and the SATA disk does 77MB/s. In the guest I get 11MB/s for a file-based volume, and the same for a raw volume.

I highly suspect that your measurement is wrong. Note that you're doing guest-side timing - which is highly unreliable in the short term. I won't go in much detail here, but time seen in a VM is only equivalent to real time in a relatively long term due to host OS scheduling effects. So the 3 second measurement done by hdparm might as well create random numbers.

From my experience the actual throughput for such micro-benchmarks is mainly determined by the host OS caching efficiency, which is extremely high e.g. for Linux. You should easily reeach 80 to 100MB/sec on any current hardware, assuming that VirtualBox doesn't compete much with other processes for the CPU.

[pete_l]

There are parallels with some (rather heated) discussions that took place in the 90's regarding database implementation. On the one side was a group who said that database files should be placed on raw partitions for speed, on the other a group who said that the speed improvement was negligible and the ease of managing filesystem based databases outweighed any performance improvements.

When you look around today, you see that the overwhelming majority of databases are implemented over a filesystem. The technical arguments and benchmarking wars petered out as f/s technology improved and the performance proponents concluded that higher performance can be achieved by implementing the database over multiple disks.

Maybe what we need here is not so much a debate about which method gives the ultimate performance in their own specialised case, but a set of guidelines about how to improve performance overall. Such as using a striped RAID array, zero-copy filesystems, IDE/(e)SATA/SCSI/SoE and the like.
What we'll probably end up with is another debate over which host O/S give the best I-O performance, but that's one for another time.

[TerryE]

+1 on pete_l’s comment. Now to reply to kentborg. But before I do, I want to pick up a comment that Klaus made earlier that “this is the universal truth that there are lies, damn lies and benchmarks. A benchmark never says anything about the general case - it only provides a number for the thing it tests”. I have learnt to be an out-and-out sceptic, so I put my trust in the Scientific Method over faith or intuition any day. Yes, of course benchmarks and hard test data can mislead on occasion, but the numbers for a correctly constituted test don’t lie. However, faith and experience / assumption is sometimes just plain and dangerously wrong. That’s not to say that experience isn’t an extremely powerful tool — it’s just that you need to be sceptical until you have constructed or referenced a test which provides hard data to validate your assumptions, and sometimes you just need to be surprised.

So to kentborg’s comments like: they do seem to present an anomalous data point. Being the sceptic, I tend to feel that this may be exposing some issue worth exploring that will broaden our understanding. So I took a deeper dive into the code to see what might cause these sorts of issues, and here is what I can up with. I have discussed the general architecture for device drivers in two other topics (#7557 and #7584).

The VMware tools which include vmblock and vmxnet device drivers which bypassed the overhead of having to simulate ATA virtual hardware and the corresponding dispatch mechanisms. When you write to a HDD in a VMware VM with VMware tools installed, the guest file system in effect talks directly to the host file system with little intervening overhead. Whilst the VirtualBox architecture facilitates such device drivers (and indeed uses them in the case of mouse and display), it doesn't yet have such accelerators for HDD and network.

Most VirtualBox users probably don’t do enough I/O to notice this loss (mainly the first three VirtualBox user communities that I discussed earlier in the topic), but this is a problem for the "power user" communities. A VMware whiterpaper suggest up to a 33% performance penalty in the case of network (and somewhat less in the case of HDD) I/O due to H/W virtualisation that’s avoided by such guest VM drivers. I suspect that we have a similar overhead in VirtualBox.

I also reran some of yesterday’s tests today (a slightly different case because the download creates a new day's database), and what I got was:

Code: Select all

Duration               non-aligned VDI        Raw VMDK      aligned VDI
Start                         17:32:39        18:05:08         18:32:17
Stop                          17:49:01        18:22:10         18:48:53
Duration                         16:22           17:02            16:36

VM Stats               non-aligned VDI        Raw VMDK      aligned VDI
ATA0 Unit0 DMA                   9,143           9,862           10,967
ATA0 Unit0 PIO                     262             262              262
ATA0 Unit0 ReadBytes       306,189,824     303,040,000      302,167,552
ATA0 Unit0 WrittenBytes     45,772,800      44,548,096       44,5317,12
ATA0 Unit1 DMA                   4,602          3,4081           4,6378
ATA0 Unit1 PIO                       3               3                3
ATA0 Unit1 ReadBytes       412,418,048     405,732,352      518,568,960
ATA0 Unit1 WrittenBytes  1,853,364,224   1,854,347,264    1,852,422,144
Average Bytes/DMA              247,816         229,171          216,193

Taskman Stats                   Totals          Totals           Totals
Read Bytes                 719,330,774     706,898,777      822,093,046
Written Bytes            1,512,078,118   1,898,925,874    1,578,931,089
Reads Operations                42,523          39,105           43,866
Write Operation                 47,109          48,077           47,364 
Read Bytes / Op                 16,916          18,077           18,741
Written Bytes / Op              32,097          39,498           33,336 

As you can see this time, I also collected the corresponding stats from Task Manager for the VM process on the host. This is a crude instrument and it was very difficult to get them exact like-for-like in the three tests because Taskman and VBox can only give process total counts, and I had to do a bit of messing around each time as part of the process to mapping the correct drive. However, the timings are accurate as they come from time command at the beginning and end of a fully automated script. Again, the general pattern was that the VMI based disks were slightly faster than the raw partition. A pleasant surprise was that the total I/O volumes at the VM ATA DMA level was so close to the volumes the Taskman reported. We don’t seem to be getting a multiplier effect in I/O volumes though the average blocksize is consistently reduced. (Again the oddball seem to be total writes to the raw VMDK partition.)

When you do I/O in your guest the "supply chain" goes something like guest application -> C++ RTL -> Linux filesystem -> Linux block mode driver -> virtualised ATA hardware -> VM dispatcher -> Pluggable Device Manager -> DevATA -> DrvHostBase -> DrvXXXImage -> Host C++ RTL -> Host Filesystem -> Host block mode driver -> ATA -> Real HDD. Phew! This might seem horrible, but it is typical of the sort of call hierarchies you get in such C++ implementations (for example, some that I’ve traced in the OpenOffice.org code make this chain look mild). What this does do is to take CPU cycles, but if all goes well it shouldn't add too many extra I/O operations and these are what kills I/O throughput.

The DrvHostBase ( implemented by VBoxHDD-new.cpp) calls the appropriate format HDD handler through an abstraction interface VBOXHDDBACKEND which is declared in VBoxHDD-newInternal.h as a structure (somewhat confusingly in C++ structures are just a type of class where all methods of public). So if we take the case of right functions and look at VBoxHDD-new.cpp lines 2222-2256 we find the VDwrite routine which then calls a helper routine at lines 540-597. The reasons for doing this, is that any writes which cross a 1Mbyte allocation tile broken into two separate write (even this break could be redundant). The helper now has to write a segment of data to part of a single tile. There are two variant algorithms are doing this depending on the container types (for example there are subtle rules for handling snapshot write back which mean that you must clone the original tile). If the tile already exists in writeable format then the write maps to a stand C++ WriteFile call. For new tiles the code typically does a read-modify-writeback approach where the parts of the tile which bracket the piece to be written are first read into memory and then the whole tile is written back to disk. Thus we always write a megabyte to the filesystem for each new tile covering the write (See lines 446-449 and 535-538 of VBoxHDD-new.cpp). So apart from some avoidable fragmentation at tile boundaries, I/O is essentially a 1-1 map.

What is interesting is the difference is typical block sizes for DMA transfer vs. the Taskman numbers (200-250Kb vs 16-32K). The large block sizes for Ext3 are due to the read-ahead and delayed write algorithms in Ext3 which optimise I/O and avoid fragmentation. The small block sizes on the NT side are a little surprising and may be an artefact of the C++ stdio lib.

So having had this scan, sorry kentborg, at least as NTFS is concerned I can’t find any major issues which would cause a pathological degrading of performance of the scale that you are seeing on Linux/Ext3 hosting. However I need to think about this some more. Could you confirm that your are using Ext3? I guess it’s time to bring up my own bare metal Linux testbed and start evaluation the Linux version of VirtualBox.

[decoder_oh]

Hi,

TerryE: refering to the comment you made on my performance problem with I/O, I've read this thread

Could you confirm that your are using Ext3?

If it helps you, the tests that I did were all on Ext3. I can try with a different FS as well


Best regards,


Chris

[TerryE]

Out of interest I used bonnie++ (the package name is also bonnie++ if you need to install it) to do a standard benchmark on my LAMP appliance:

Code: Select all

$ bonnie++ -d /app/work -r 150 -s 500 -n 0 -m ub804jeos -u test
...
Version 1.03b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ub804jeos      500M 12505  33 12249   5 10019  14 20402  71 23040   9 144.0   2

This was on my XP laptop its slow 2.5" HDD also running HDD encryption. What are your results host and guest?

[decoder_oh]

Ok, here are some results. Note however that you have a whole different version of the tool:

First the host:

Code: Select all

bugfix ~ # bonnie++ -d /scratch/ -r 150 -s 500 -n 0 -m bugfix -u root
Using uid:0, gid:0.
[...]
Version 1.93c       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bugfix         500M   290  99 44188  17 45874  11  1623  99 +++++ +++  3034  22
Latency             52658us   60894us   35385us    5654us     247us     275ms

Now for the guest:

Code: Select all

Version 1.93c       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
busserver      500M    11  89  8928  48  9949  50    23  92 71710 100 901.3 195
Latency              2397ms     615ms     244ms     784ms    5600us   80454us

EDIT:

I also tried using direct I/O in the guest to write (means dd if=/dev/zero of=/some.file conv=notrunc oflag=direct bs=4M count=1000) and it is much faster (50mb/s, that is nearly host speed).

Any idea?

Cheers,


Chris

[TerryE]

Humm, kentborg and decode_oh both seem be seeing roughly a factor of 4 performance decrease of Linux VM over Linux Host. I've repeated these bonnie++ tests a few times and compared them to running defrag native on the XP Host.

I played with two XP hosts (a 1yr old Laptop running Pointsec Encryption and McAfee virus; a 3 yr old PC running Avast) (I've explicitly added VDI file type as an exclusion from Virus Scanning.) The 3 yr old PC has a disk performance that is broadly similar to my Laptop, as its M/B insists in running ATA66 even though I have upgraded drivers and BIOSes; I think its an issue with the M/B rev 1 version; that's what you get when you buy a $40 clearance M/B. So I'll just discuss the Laptop figures.

In general I get around 16-20Mb/sec red 8-10Mb/sec write in the bonnie++ reports. I also had Perfmon running to instrument I/O (read + writes)x(Bytes + Ops + bytes/op) for the Process VirtualBox#1, and I+O bytes/op from the Logical disk. Xfers were either 32Kb or 64Kb but on the bulk I/O they stayed flat as 64Kb. This supported my previous Taskman finding: that the actual I/O rates to the disk were broadly the same as those reported in the benchmark.

I also did some I/O exercises on the native NTFS file system which pretty much sustained 20Mb/sec for bulk reads and write and 10Mb/sec for bulk copy. I realised that I was doing this to a non-aligned VDI which might be why the VM write rate is broadly the same as the native read-write.

So over all we either have parity on reads, and 2:1 on writes. So we might experience say a 25% degradation on XP. I feel that this is within the bounds of acceptability. A world away from the 4X on Linux, which clearly is not.

[decoder_oh]

Yep, the linux performance degradation is indeed a problem. However, I wonder why/how direct I/O affects this issue. In my tests, the performance degradation went away (write speed greatly increased) when I used direct I/O with dd instead of using dd as usual.

The only difference in the guest between these two modes is that for direct I/O, the ram isnt used as cache (as far as I know), whereas it is for normal mode of operation. I don't know if VirtualBox somehow can threat these two things differently and what happens in detail that makes direct I/O so much faster (however only with the guest additions, without additions, direct I/O is unusable, so I suspect that VirtualBox is indeed doing something here that it isnt for normal I/O, because normal I/O does not change with or without additions).

[TerryE]

Hmmmn, I've got the OSE guest additions installed in my Linux VMs. It am going to try the PEUL guest additions to see if there are any changes in this area. It would interesting to see the comments of Frank, Klaus or Sander on this.