Also just to review, clocksource=acpi_pm should be used in conjunction
with the tools.synctime = "true" flag in your vmx file. The combination
of the two settings prevents time from going into the future from too
many ticks, and synctime corrects slow clocks, which leads to a much,
much better
clocksource=pit is confirmed not working in VMware ESX.
You should be using clocksource=acpi_pm in addition to divider=10 to
reduce idle load.
Binding to a single CPU is hardly a fix. Always engineer *real*
solutions, not poor workarounds! ;)
Kai Schaetzl wrote:
Akemi Yagi wrote on Sat,
Waldirio Manhães Pinheiro wrote on Sat, 3 May 2008 14:24:06 -0300:
> There are any lists like Hardware Compatible List to Xen
Most NICs that are compatible with CentOS will also be compatible with
Xen. I doubt your problem really is the card by itself. I'd rather think
it's a driver or the way
Hello friends
I was installed the yum group Virtualization to start tests about it, but
when my machine was restarted, hung up in same time of start xend daemon ..,
I'm stoped the daemon with chkconfig and the OS work's fine (without xen),
but when I started the daemon, my NIC/Switch led turn
Akemi Yagi wrote on Sat, 3 May 2008 06:06:31 -0700:
> I
> tried it but it seems to have the same problem as before - when used
> with clocksource=pit, it hangs on bootup.
For the record, this can also happen in other situations with VMWare. For
instance, I have seen that happen with a Suse 9.0 g
Hi all,
If you are using the kernel divider= option in your vmware quest, you
are probably aware of the bugs reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=315471
Someone @redhat "confirmed" the fix is in the test kernel -92. I
tried it but it seems to have the same problem as before
