Slowness issue after upgrade

[XavierR]

I have been using virtualbox on several Mac OSX computers and on one of them the guest became very slow after an upgrade.

It is running Mac OSX 10.6.8. The guest OS is a Linux Gentoo. Former Virtualbox version was a 3.x (not sure which one, as I unfortunately did not keep the dmg of that version), and I upgraded to 4.1.12 today; the guest became slow to the point it was unusable. I tried to downgrade Virtualbox to other 4.x.y and 3.x.y versions to no avail, and that did not help. I notice that turning the nested paging option makes the machine halfway usable but with a 3x slowdown compared to before (it is painful to use).

Another OSX machine is running a fork of the same guest OS under the last version of Virtualbox with no issue.

I am not sure how to troubleshoot this issue. What should I do ? I would really need to get rid of that 3x slowdown.

[XavierR]

Just noticed that I forgot to upload a Vbox.log. Here it is, but I do not see anything that helps.
In order to make the VM halfway usable, I need to have both nested paging and VT-x/AMD-V disabled. Then, slowdown is about 3 to 4. Otherwise, it will just crawl forever and it is hardly possible to make an assessment of the slow down (more than 10x in any case).

[rpmurray]

The log says that the Extensions Pack is Version 4.1.6 r74713 and that the Guest Additions is Version 4.1.8 r75467 and you say you're running VirtualBox 4.1.12. Have you considered updating everything so that they're all at the same version number?

[XavierR]

Indeed, while I was caught in these upgrade/downgrade attempts, I ended up breaking the synchronization of everything.

I did put everything up to date to 4.1.8, and the VM is still very slow. Here is a log of that session... I am not sure what I should look for next. I checked that it becomes unusably slow when activating VT-x/AMD-V. Nested paging will not make it noticeably worse. Disabling both returns it to a halfway usable state, but still slow (3x slowdown compared to usual performance).

[rpmurray]

Maybe there's something in the settings that's causing this. I remember reading another post where someone was updating from an earlier version of VB and somehow had switched the guest from being 64-bit to 32-bit, which slowed his guest to a crawl.

[XavierR]

Maybe there's something in the settings that's causing this. I remember reading another post where someone was updating from an earlier version of VB and somehow had switched the guest from being 64-bit to 32-bit, which slowed his guest to a crawl.

I have also seen this. That person ended up deleting the VM (while keeping the .vdi file, of course) and recreated it. I did try that too, and that did not work.
My guest was supposed to be 32 bit anyway. I am not sure where to check that this setting has not been corrupted (but I would assume it would just not work to make a 32 bit VM 64 bit).
Is there a way to check directly in the settings ? (I do not see this setting in the panel).

[rpmurray]

Start the VirtualBox application, highlight your VM in the list, click Settings and choose the General tab. Your Operating System should say Linux and Version should be Gentoo. If the version says "Gentoo (64 bit)" then you have the 64-bit version. I guess you could try changing it to 64 bit and trying it to see if it works.

You said you have another OS X computer running a fork of the same guest so you could try seeing if there are any differences in the settings when you check the panel on the right of the VB app when you have the VM selected on the left. Or you could compare the XML settings files.

[XavierR]

Ok, then the guest os version is coherent with the VM, they are both 32 bits, which is what I want.

Comparing the XML files, I notice a lot of differences, mostly due to MAC address numbers timestamps dates and such.
I was intrigued the working VM had "HardwareVirtExtraLargePages" true while it was set to false in the crawling one. Changing this did not help.
Another intriguing difference is that the working VM has one Harddisk entry in the MediaRegistry section, but I do not see the problem (the crawling VM does find its drive, it is just painfully slow, even more so when the acceleration settings are enabled, so I am definetely looking for a virtualization issue).

I wonder whether I should report a bug. Before I do, I will probably attempt to copy the vdi file of the working VM on the other computer, make another VM and see if I can get it to work that way...