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 - when used with clocksource=pit, it hangs on bootup. Wonder if some of you can test this kernel and see how it goes. The test kernel is available from: http://people.redhat.com/dzickus/el5 Akemi
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 guest on VMWare Server that is running on Win2k3. I was trying clocksource=pit because the clock was jumping ahead of time like nothing. I figured that it is actually a problem with the Suse kernel not liking that specific option (it didn't hang with other clock options). I fixed the time problem by binding the virtual machine to one CPU core. I didn't even have to shut off the power saving features of the CPU. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
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, 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 guest on VMWare Server > that is running on Win2k3. I was trying clocksource=pit because the clock > was jumping ahead of time like nothing. I figured that it is actually a > problem with the Suse kernel not liking that specific option (it didn't > hang with other clock options). I fixed the time problem by binding the > virtual machine to one CPU core. I didn't even have to shut off the power > saving features of the CPU. > > Kai > >
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 clock sync. We'll have to wait until someone figures out a clever way to tie VM clock ticks to a multiplexed physical clock source; until then, clocksync will always be a problem without a complete solution (read up on it). This is as close as it gets! Allen Tsang wrote:> 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, 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 guest on VMWare >> Server that is running on Win2k3. I was trying clocksource=pit >> because the clock was jumping ahead of time like nothing. I figured >> that it is actually a problem with the Suse kernel not liking that >> specific option (it didn't hang with other clock options). I fixed >> the time problem by binding the virtual machine to one CPU core. I >> didn't even have to shut off the power saving features of the CPU. >> >> Kai >> >> > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt
(looks at the name of the list "centos-virt"). Well, if you're using the standard rhel centos 5.1 kernel, yes, it should work. and if you can't use tools.... well, you shouldn't even try running your OS in a production virtualized environment because well that's just silly, isn't it? Speaking of which, I was talking to some friends about building a fully paravirtualized rhel/centos that works with xen, vmware, virtualbox, etc. Do you guys feel like that's a product you would consider using? - Allen Kai Schaetzl wrote:> Allen Tsang wrote on Sat, 3 May 2008 15:57:57 -0400: > > >> Also just to review, clocksource=acpi_pm should be used in conjunction >> with the tools.synctime = "true" flag in your vmx file. >> > > And you have verified that that kernel I was talking of even knows > "clocksource=acpi_pm" and that I am able to run VMWare Tools? ;-) > > Kai > >
Right, you started talking about SUSE. Last time I checked, this was a CentOS mailing list. A fully VMware-aware OS would have testing and configuration tweaks beforehand to make damn sure that clock drift isn't a problem so that my databases don't get h0rked date. How is that an unrelated topic? Don't let your hurt ego get in the way of the facts. - Allen Kai Schaetzl wrote:> It might help to read what I actually wrote. You are making a lot of > presumptions that are all not true and which you would know if you had > really read what I wrote. > > >> Speaking of which, I was talking to some friends about building a fully >> paravirtualized rhel/centos that works with xen, vmware, virtualbox, >> etc. Do you guys feel like that's a product you would consider using? >> > > Would you please consider not hijacking threads with completely unrelated > topics? > > Kai > >-------------- next part -------------- A non-text attachment was scrubbed... Name: atsang.vcf Type: text/x-vcard Size: 294 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20080505/1ca60585/attachment-0004.vcf>
Right, blog posts from 2006 always trump facts from running the latest supported kernel with totally different flags, amirite? I could show you a bunch of documentation from ESX 2.5 too, but that stuff is outdated and wrong. Try harder. FYI: """ kernel /vmlinuz-2.6.18-53.1.14.el5 ro root=/dev/RootDisk/root divider=10 notsc clocksource=acpi_pm """ I do the above in conjunction with tools.synctime="true". I've tried almost everything else under the sun with a number of test VMs on our ESX setup, and the best combination of low idle load and accurate timekeeping was achieved using that combination of settings. Yes, ntpd is off. Feel free to give it a shot; I don't take credit for it, I found notes about this on the CentOS bug tracker (http://bugs.centos.org/view.php?id=2189). Like other fine folks have mentioned on this list (much to their amusement likely, now), clocksource=pit is nice, but it doesn't work with divider=10 and hangs on boot. I know this is a confusing topic; a lot of things are changing on a monthly basis. But everyone is ganging up on me with all these weak arguments and... wow: http://xkcd.com/386/ Maybe you guys should run your own tests and present your findings instead?.. "Science!" Thanks for the heads up about the realtime kernel; looking forward to researching it, I hope performance isn't impacted. It is a classic CS/physics problem you know? "Updating things in N places at once using a single source with inherent scheduling conflicts with asymetrical loads..." - Allen Tsang Johnny Hughes wrote:> Allen Tsang wrote: >> 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 clock sync. > > That (clocksource=acpi_pm) is ONLY the best method if your clock is > running SLOWER than normal .. and in fact, a "clocksource=pit" is > probably the best solution for a clock that is running FASTER than > normal. If the clock is running FASTER than normal, also getting the > max frequency (host.cpukHz) set per these instructions is important: > > http://blog.autoedification.com/2006/11/vmware-guest-clock-runs-fast.html > > The /proc/ location in that article is not correct for centos4 or > centos5, but you can probably get the correct info for frequency most > of the time from /proc/cpuinfo, dmesg, or dmidecode. > >> >> We'll have to wait until someone figures out a clever way to tie VM >> clock ticks to a multiplexed physical clock source; >> until then, clocksync will always be a problem without a complete >> solution (read up on it). This is as close as it gets! > > There is a potential fix in the Real Time Kernel () that Red Hat has > released as part of their beta MRG release in that it might the > support tickless option. I have not had time to look at this solution > yet, but the kernel SRPM is here if someone wants to: > > ftp://ftp.redhat.com/pub/redhat/linux/beta/MRG/RHEL-5/src/ > > <snip> > > Thanks, > Johnny Hughes > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt >-------------- next part -------------- A non-text attachment was scrubbed... Name: atsang.vcf Type: text/x-vcard Size: 294 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20080505/ed33ad38/attachment-0004.vcf>
On Mon, May 5, 2008 at 7:23 PM, Allen Tsang <atsang at advance.net> wrote:> Don't let your hurt ego get in the way of the facts.With the list moderator hat on: Please quit the personal attacks. The subject of this list is virtualization, not psychology ;). Besides that, top-posting is not really appreciated, since it tends to mess with our brain-wiring. Thanks, Daniel
Allen Tsang wrote on Mon, 5 May 2008 13:23:26 -0400:> Last time I checked, this was a > CentOS mailing list.My god, I suggested you actually *read* what's there. You obviously didn't. Please spare me your half-educated guesswork in the future.> How is that an unrelated topic?Just read! Good night, EOT. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
On Mon, May 5, 2008 at 10:39 AM, Allen Tsang <atsang at advance.net> wrote:> > I've tried almost everything else under the sun with a number of test VMs > on our ESX setup, and the best combination of low idle load and accurate > timekeeping was achieved using that combination of settings. Yes, ntpd is > off. Feel free to give it a shot; I don't take credit for it, I found notes > about this on the CentOS bug tracker > (http://bugs.centos.org/view.php?id=2189). Like other fine folks have > mentioned on this list (much to their amusement likely, now), > clocksource=pit is nice, but it doesn't work with divider=10 and hangs on > boot.As you can see in that bug tracker, we have spent a lot of time to come up with 100Hz kernels, kernel-vm. These kernels do not have problems with clocksource=pit. Until this bug is eliminated upstream, I think kernel-vm offered by CentOS may be the best solution (shameless advertisement). I just hope it won't take long for the upstream developers to find a fix for the problem associated with the divider= option. Akemi / toracat