Centos Host/Guest SMP imbalance and slow performance

[Jonathan Deitch]

Host is Centos 5.3 (dual quad core Xeon, IBM x3650) Guest is Centos 4.8 configured for dual core SMP

Both Centos systems are stock, with updates from the centos and rpmforge repositories.

Guest runs very slow, performance is noticeably affected. /proc/cpuinfo in the guest shows a massive imbalance between the detected smp cores provided to the guest OS.

The same command on the host shows different results and values.

[Jonathan Deitch]

/proc/cpuinfo on guest system

[Jonathan Deitch]

/proc/cpuinfo on host system

[Jonathan Deitch]

vbox log file

[Jonathan Deitch]

Attached are the virtualbox log file, and outputs from the cpuinfo on the host and guest Centos systems.

Note the differences in attributes detected, and the "bogomips" detection linux provides. While this is hardly a usable criteria for speed, it should be the same value (whatever the value is) for each core within a system.

Note that the two cores on the guest system are wildly inaccurate, and have a different value than the cores on the host system.

[Jonathan Deitch]

Guys ... this has been open for THREE WEEKS now.

And it still happens on 3.1.2 ... what is the status on fixing this, since it still shows NEW ...

This is a MAJOR problem for anyone using a RH or Centos guest, since it essentially makes it unusable for anything that, well, matters, in the real world ...

[Sander van Leeuwen]

Please check if 3.1.4 beta 1 solves the problem: ​http://forums.virtualbox.org/viewtopic.php?f=15&t=27300

[Jonathan Deitch]

SMP cores are better balanced.

System, however, is even LESS usable than before.

It took over FIVE MINUTES to install the guest additions.

Don't even get me started on how long it takes to run ANY database operation or an attempt at compiling a program.

This makes Vbox essentially useless as a VM host, if you can't run a guest that needs to do anything other than sit there idle.

System specs are unchanged from those in the opening ticket.

Any why is this issue still marked NEW, when it's been TWO MONTHS since it was opened?

[Sander van Leeuwen]

You of course realize that this bug tracker is maintained on a best effort basis and support is provided free of charge. Insisting on immediate help isn't the best way to get attention. Yelling doesn't help either.

[Jonathan Deitch]

I understand that ...

But please also understand the extreme frustration when an IMPORTANT issue is reported (this issue affects ALL users who are using either Centos or Redhat hosts/guests) and the general impression is it is completely ignored.

The entire world does NOT revolve around Debian and Ubuntu; in my case, neither distribution is allowed; only centos/redhat. And so far, it's pretty much unusable.

My time is running out to try and utilize Vbox; if these issues are not at least acknowledged soon (indicating work is at least underway), I will be forced to abandon this and move to the competition.

This issue is still marked NEW. It's been three months. It is not new.

Why is this?

Quite frankly, the viewpoint from the user is that this bugtracker essentially operates as a big black hole; no information gets back to us of what is going on; new releases just magically appear.

Some guidance would be nice. Then I might have something to tell people here at the office before the plug gets pulled on trying to virtualize on an open source solution.

• litz

[Sander van Leeuwen]

There is a lot of activity on the bug tracker. Easy to see if you bother to look before forming an opinion. Not to mention the frequent references to tickets in the change logs. So much for your black hole theory.

Our time is limited and I'm not aware of others reporting issues with Red Hat/CentOS. It is certainly running fine here. Just make sure you are not running a 1000 hz kernel.

[Klaus Espenlaub]

Replying to litz:

This issue is still marked NEW. It's been three months. It is not new.

Why is this?

Easy: the bug tracking system here has a very limited number of states. Those are: new, accepted, reopened, fixed (with some sub-state). No one here sees much point in "accepting" a bug - any bug not closed is a valid one.