full CPU usage when raw disk is attached

[privateer]

I've started experimenting with the new feature of using raw disk with vbox. I'm stuck with virtual machine using 50% CPU (one core) right on boot - i.e. in GRUB, any OS booted from mentioned drive, CD or whatever. It is stable but slow. It just takes one CPU core for it's own - no matter what. At the same time disk image-files performs excellent with low load.

I know that using raw disks is somehow experimental yet. I did RTFM though and I found nothing about such performance drop. Manual even says: "it allows a guest operating system to access its virtual hard disk much more quickly than with disk images" - which is to be expected.

Therefore I guess it deserves a ticket to support you on your great work.

Some details: I'm using VirtualBox 1.5.2r25433 (closed source version as open src doesn't have mentioned feature :| )

The vmdk file has been created with following command: VBoxManage internalcommands createrawvmdk -filename /media/hda5/virt/raw.vmdk -partitions 1 -rawdisk /dev/sda (I experimented with other partitions too - no change)

My OS is Ubuntu Gutsy # uname -a Linux privateer 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

The drive is a regular SATA HDD, nothing fancy.

I have experimented with all ACPI settings combinations of my virtual machine - no change.

Changing the amount of memory from 128 to 512MB doesn't change the thing either.

I found nothing in syslog or vbox log (attached).

[privateer]

VBox.log

[privateer]

With lot of patience I have managed to boot into Windows XP in my virtualbox. The load inside of VM is low - near zero. At the same time load of the host is high - as described.

[Klaus Espenlaub]

Whether you use raw disk or a disk image shouldn't make a big difference in CPU usage. At least we have no verified data indicating otherwise. High load on host with little load in guest can have a number of reasons. One is trouble with keeping guest time in sync, which should only happen if the load on the host approaches the limits of the CPU. Which isn't the case if you just get one core loaded and the other idle. The most likely reason is that some software is running inside the guest which (from the guest's point of view) isn't taking up much CPU time, but is horribly inefficient to virtualize. Some virus scanners are in this category.

All in all the problem has most likely something to do with the software installed in the guest. And the only true verification that the bug is really in the raw disk code would be installing a fresh Windows XP in that raw disk (without further software) and see if it still takes too much CPU.

[privateer]

Replying to klaus:

All in all the problem has most likely something to do with the software installed in the guest. And the only true verification that the bug is really in the raw disk code would be installing a fresh Windows XP in that raw disk (without further software) and see if it still takes too much CPU.

I see you point. It doesn't seem the case though. I experience exactly the same results in fresh installation of windows XP with _nothing_ more than SP2 installed. The same happens in GRUB menu which is not run under any OS, same for partedMagic bootable CD even with the win XP installer booted from CD. It always puts high load on my host CPU whenever I use raw disk. As for the virtual machine: in some cases I cannot determine (like with the installer) but on all other load of the virtual machine is near zero.

I'm open to any suggestion. If you want me to provide more data or make more tests - just tell what exactly should I do.

I really don't know what piece of information could be relevant and useful. I have a single HDD. I monitor the number of reads/writes - it's low and unrelated to CPU load.

[privateer]

I just did one more test. I have attached troublesome raw disk as a slave on primary IDE. As a master - bootable - drive I've used HD file-image (with some windows XP). The load wasn't high at all. It booted just normal. The raw drive was usable and it performed efficiently.

The same configuration but with CD image installed again resulted in high load. It's confusing to me.

[Klaus Espenlaub]

I hope you don't just look at the CPU load while some boot loader suc as GRUB is active. GRUB simply uses busy waiting, and burns as many CPU cycles on the virtual CPU it can get hold of. So that's totally normal behavior. The WinXP installer booted from CD waiting for some user input normally takes almost no CPU. If it's copying it's a different story. Generally CD accesses in Windows XP are slow, as by default it doesn't turn on DMA. PIO chews up more CPU cycles. For disks this is normally no issue, it should automatically enable DMA there.

It's very difficult to suggest what to monitor. If the host disk load (usually can be estimated quite accurately by the noise produced when the heads are moving) on the hot is low, it must be some other virtualization issue. Could you provide the VBox.log from a substantially longer run? The statistics for a 10 seconds run isn't all that informational.

[privateer]

a log and strace of WinXP doing nothing and causing heavy load on host

[privateer]

OK.

Some successes.

At first - straightening up things I've said wrong:

1. Using much/all CPU power is a common thing to GRUB, windows installer and possibly many other small standalone bootable things. It doesn't mean problems with VirtualBox.
2. In my previous description I missed one important detail - the CPU has been used by different things on GRUB stage and on win XP stage. GRUB floods with user calls - (possibly a busy wait - as mentioned) while XP flooded with syscalls (select). It means that there is no simple reason like - bad raw HDD implementation. GRUB has different problem and XP had different problem.

I have managed to reinstall XP @ raw HD and now the CPU usage is low again. I don't know the reason of the previous problems so far but it's apparently not the raw disk itself. If I'll spot that high load again and if I manage to figure out some more - I'll post it here.

Until then:

Sorry for misleading info but the symptoms were confusing. You can mark this ticket closed as far as I'm concerned. Thanks again for this cool app ;)