Virtual machine
Matthew Gillen
me-5yx05kfkO/aqeI1yJSURBw at public.gmane.org
Thu Dec 2 08:58:02 EST 2010
On 12/02/2010 08:36 AM, Rich Braun wrote:
> As for performance, I don't see the issue. One tip that I have to maximize
> VirtualBox performance is this:
>
> Put your virtual disk drives in raw Logical Volumes (LVM)!
>
> When you do this, you get remarkably high disk I/O performance. On a small
> 2-disk RAID1 setup, in October I ran benchmarks comparing the host systems
> with two client installations (both OpenSuSE 11.3), one installed under the
> host's ext4 volume and the other installed on a raw LVM. The numbers were:
>
> Random I/O: host 1.619 MB/s; cl-1(fs) 1.521 MB/s; cl-2(lvm) 2.274 MB/s
> Sequential: host 64.675 MB/s; cl-1 35.93 MB/s; cl-2 88.819 MB/s
>
> That's right, the client installed under LVM is *faster* than the host. I'll
> leave it up to the group to repeat my observations and explain why, but this
> is my reality on a Core-i5 server with 16GB of RAM and about 8 virtual
> machines so far.
I'm interpreting what you're saying as
- with ext4, the VM disk image was a file on the ext4 filesystem
- with LVM, you created an LV that was entirely used by the VM (ie no
'host' filesystem was on the VM's LV)
Assuming those two statements are true, it might be explainable from the
point of view that LVM is doing a lot less work, since all it has to do
is simulate a block device, versus ext4, which as a higher level
filesystem has to generally do more housekeeping. How much extra work
is dependent on several factors. A couple off the top of my head:
- in the ext4 case, was the whole image pre-allocated? Or was it of
the "growable" variety? (I have no idea if virtualbox images support
this, I mostly use qemu/kvm and they do)
- was ext4 formatted in ext3-compatibility mode? If so, it wasn't
using the more LVM-like block allocation technique that makes ext4 much
better at handling very large files
(http://kernelnewbies.org/Ext4#head-7c5fd53118e8b888345b95cc11756346be4268f4)
I'm curious what others have to say as well...
Matt
More information about the Discuss
mailing list