How to crash Solaris host with Windows 7 guest

[martyscholes]

Ramshankar,

Would you be interested in sharing an early binary of the fixed vboxdrv module?

I'm not sure the change only ended up in vboxdrv. It was also the Runtime. I'll try to put out a test build if the 4.2.18 release might take a while.

Many thanks. In the meantime, we are limiting VMs to a single core. Do you think that will mitigate the issue?

[Ramshankar]

Ramshankar,

Would you be interested in sharing an early binary of the fixed vboxdrv module?

I'm not sure the change only ended up in vboxdrv. It was also the Runtime. I'll try to put out a test build if the 4.2.18 release might take a while.

Many thanks. In the meantime, we are limiting VMs to a single core. Do you think that will mitigate the issue?

No, I don't think that will help. It might make the problem less frequent but not fix it.

[martyscholes]

No, I don't think that will help. It might make the problem less frequent but not fix it.

I'll take anything right now. So far, we have been up for 2 hours without an issue. That is a new high-water mark in the past few days. Thanks again.

[martyscholes]

I have a fix in trunk (4.3.x) to avoid logging this, i'll see if I've backported it to 4.2.x and if so that should be available in the next maintenance release.

Does that mean that the fix is in the 4.3 beta?

[Ramshankar]

I have a fix in trunk (4.3.x) to avoid logging this, i'll see if I've backported it to 4.2.x and if so that should be available in the next maintenance release.

Does that mean that the fix is in the 4.3 beta?

Yes. Sorry, I didn't have any time to check or upload an interim 4.2.x build yet.

[martyscholes]

No worries and thanks for the help. The 4.3 beta caused every Windows instance I tried to blue-screen. I am back to 4.2.16 waiting for the .18 release. Thanks again.

[Ramshankar]

4.2.18 is up.

[martyscholes]

4.2.18 is up.

Nice! Many thanks! Downloading now...

[martyscholes]

4.2.18 is up.

Ramshankar,

So that it's said, there is a bug when installing under Sun Ray services (SRSS). I know, Sun Ray is EOL. When installing the extension packs, the installation always fails because SRSS does not support RANDR. It looks like the whole install failed, but every time I see that message it appears that everything is fine.

The actual error:

Failed to install the Extension Pack /home/marty/.VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-4.2.18.vbox-extpack.
The installer failed with exit code 255: Xlib: extension "RANDR" missing on display ":13.0".

The Details:

Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
ExtPackManager
Interface:
IExtPackManager {3295e6ce-b051-47b2-9514-2c588bfe7554}

[Ramshankar]

The extpack by itself has nothing to do with Xlib/RANDR. It could be that our sudo/su wrapper invocation that drags this in.

How exactly are you installing the ext-pack? Could you try installing it as root from the command-line using VBoxManage?

[martyscholes]

The extpack by itself has nothing to do with Xlib/RANDR. It could be that our sudo/su wrapper invocation that drags this in.

How exactly are you installing the ext-pack? Could you try installing it as root from the command-line using VBoxManage?

It installs fine from the command line, so it probably is the wrapper. When I see the message it is when I start up VirtualBox (because I forgot about the extensions) and it pops up a message prompting me to download and install the extensions.

I did want to take a moment and thank you for the update. We have been rock-solid for several days. The server is a four-socket, dual-core (4x Opteron 8216) machine. Some time ago (March 2012?) when we installed the server, we tried to allocate > 2 CPUs to a guest and the server locked up. I am guessing that was related to the bug/feature/nuance at hand. After the 4.2.18 update, we tried again to allocate > 2 CPUs to a guest and noticed that the guests were painfully slow, but did not lock up the server. It doesn't really impact me, but I am wondering if there is some strange limit with the Opterons and the current VirtualBox to where guests do not scale well when the guest is allocated CPUs that must span sockets.

Thanks again.

[Ramshankar]

Unless you really need SMP for a guest, I would advise using single CPU VMs. Many people assume SMP VMs = better performance, but that's not always the case. Even on real hardware there are certain situations that are more expensive with SMP but with virtualization it gets magnified a lot and leads to significantly worse performance (e.g. ping-pong IPIs).

We're also aware that we have some performance issues with our SMP implementation in 4.2.x and we're working to improve the situation going forward with 4.3.x. As for your 4 socket system, VirtualBox isn't optimized for NUMA systems yet and I don't know the exact NUMA topology on your particular 4-socket system, but if I assume every socket has a QPI/HyperT to every other one (which I'm 99.9% is the case), it's at most a 1 hop penalty for non-local accesses. It would, depending on the memory access patterns and scheduling, get worse with 8 sockets with at most with a 2 hop penalty.

[martyscholes]

Unless you really need SMP for a guest, I would advise using single CPU VMs. Many people assume SMP VMs = better performance, but that's not always the case. Even on real hardware there are certain situations that are more expensive with SMP but with virtualization it gets magnified a lot and leads to significantly worse performance (e.g. ping-pong IPIs).

We're also aware that we have some performance issues with our SMP implementation in 4.2.x and we're working to improve the situation going forward with 4.3.x. As for your 4 socket system, VirtualBox isn't optimized for NUMA systems yet and I don't know the exact NUMA topology on your particular 4-socket system, but if I assume every socket has a QPI/HyperT to every other one (which I'm 99.9% is the case), it's at most a 1 hop penalty for non-local accesses. It would, depending on the memory access patterns and scheduling, get worse with 8 sockets with at most with a 2 hop penalty.

Ramhsankar, That makes sense. The machine is NUMA. I wondered here viewtopic.php?f=1&t=54189&sid=734cd88a8 ... d0#p265026 whether or not VirtualBox or the guest OS is NUMA aware. I am fairly confident that Solaris is NUMA aware, but if VirtualBox is not and the guest is not, then I would expect a LOT of Hypertransport traffic, slowing down the guest. For what it's worth, Windows 7 benefits quite a bit from dual CPUs, probably because Windows 7 itself does a lot of housekeeping. The second CPU is basically available for applications. Thinking about it, multiple CPUs are probably presented to the guest as SMP and the guest probably uses them as SMP, suggesting that keeping the guest CPU count to that of a single socket is a good idea.

Now I am curious how a NUMA aware OS would behave as a guest on a NUMA system.

[Ramshankar]

It won't help much, sooner or later guest memory access will have to go through NUMA hops if both VirtualBox and the host scheduler isn't extremely smart about it. Currently, full NUMA support requires co-operating from too many different components and while it does bring performance improvements, VirtualBox has bigger SMP bottlenecks than the NUMA performance hit (for instance, some of the overly cautious locking in our APIC device). We are of course, working on this first before fine tuning things for NUMA. It *is* a known performance tuning opportunity and again, if we could clone ourselves we would be working on all this stuff simultaneously! Till then, unfortunately it's very resource bound.