The guest OS freezes after a while- usually during network traffic.
There were no problems till some point with the 2008 RC's, but since some kernel revision VMWare can't run properly the smp-enabled guest. Unfortunately I can't spot up to which kernel revision it worked, but I can report that this thing also happens with other guest OS'es which are using kernel 2.6.22.9 (my Archlinux being one of them).
If one of the two (virtual) CPU's is disabled, then the guest runs perfectly well. (it also runs mighty well under VirtualBox, BTW, which does not support guest SMP).
It's not a host configuration problem (Arch Linux, VMWare Workstation 6.0.1), nor something specific to the virtualization software version (the same thing happens with version 6.0.0 as well). On the same host, Windows XP pro SP2 and PCLinuxOS 2007 (obviously none of them running a 2.6.22.X kernel! ) are working fine as 2-CPU guests.
It does not seem specific to the virtual network interface either (tried both pcnet32 and vmxnet), nor to the network type (same symptoms with ipv6 on or off, NAT, host-only networking or bridged networking).
Did anyone else encounter something similar?


[moved from Installing Mandriva by spinynorman]

Try using this kernel parameter:

nohz=off

when booting the Mandriva guest. Apparently, tickless kernel timers can confuse virtualization systems.

To add kernel parameters, just hit F2 at the bootloader screen and type - so just hit F2, type:

nohz=off

and hit enter.

Thank you, Adam. Spot on!
nohz=off seems to do the trick- have been using the virtual machine for a couple of hours with both CPU's enabled without hanging.
Apparently it's a kernel bug, because at another VM which runs 32-bit ArchLinux "nohz=off" also does the trick, while when booting from a newer kernel with the -mm patchset (2.6.23.rc4.mm1) there are no issues even without that switch.
Not sure ***EXACTLY*** where the fault should be attributed, but I'm flagging it as [SOLVED]

I'm not sure tickless timer is the default even in 2.6.23, so the 2.6.23.rc4.mm1 kernel you're testing *may* not have the tickless timer enabled. You can check by looking at its config file to see what CONFIG_NO_HZ is set to. If it's Y, that means the tickless timer is enabled. If it's N, that means it's not.

As I understand it, the bug, limitation, call it what you will, is in VMware (VirtualBox has the same problem, haven't checked qemu etc yet), it just doesn't cope with a tickless timer very well.