[opensuse] Re: SV: 11.1 extremely slow boot/halt on VMware..
Anders Norrbring wrote:
Anders Norrbring wrote:
Anyone with ideas on what makes 11.1 so extremely slow at boot and halt time when run as a VMware Server guest? 11.0 was really fine, but 11.1 can take up to 6-7 minutes just to come to 'Starting udev'. Same goes for a halt, it takes up to 10 minutes to halt the VM.
Hi Anders,
Try to boot with options "hpet=disable clocksource=acpi_pm"
This should help.
Thank you! That certainly did it.. Now I just have to read up on the kernel documentation to figure out WHY it worked.. ;-)
In addition to the kernel documentation, there is an interesting white paper how VMware handles the time. Googling vmware_timekeeping.pdf will probably get you a link. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Norrbring wrote:
Anders Norrbring wrote:
Anyone with ideas on what makes 11.1 so extremely slow at boot and halt time when run as a VMware Server guest? 11.0 was really fine, but 11.1 can take up to 6-7 minutes just to come to 'Starting udev'. Same goes for a halt, it takes up to 10 minutes to halt the VM.
Hi Anders,
Try to boot with options "hpet=disable clocksource=acpi_pm"
This should help.
Thank you! That certainly did it.. Now I just have to read up on the kernel documentation to figure out WHY it worked.. ;-)
In addition to the kernel documentation, there is an interesting white paper how VMware handles the time. Googling vmware_timekeeping.pdf will probably get you a link.
Joachim
Thanks! I'll take a look at that paper any day soon.. ;-) Right now I'm buried in other issues... Like VMs going into "uninterruptable sleep".. *sigh* Anders. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Norrbring wrote:
Anders Norrbring wrote:
Anyone with ideas on what makes 11.1 so extremely slow at boot and halt time when run as a VMware Server guest? 11.0 was really fine, but 11.1 can take up to 6-7 minutes just to come to 'Starting udev'. Same goes for a halt, it takes up to 10 minutes to halt the VM.
Hi Anders,
Try to boot with options "hpet=disable clocksource=acpi_pm"
This should help.
Thank you! That certainly did it.. Now I just have to read up on the kernel documentation to figure out WHY it worked.. ;-)
In addition to the kernel documentation, there is an interesting white paper how VMware handles the time. Googling vmware_timekeeping.pdf will probably get you a link.
Joachim
Thanks! I'll take a look at that paper any day soon.. ;-) Right now I'm buried in other issues... Like VMs going into "uninterruptable sleep".. *sigh* Anders. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-02-05 at 22:15 +0100, Joachim Schrod wrote:
In addition to the kernel documentation, there is an interesting white paper how VMware handles the time. Googling vmware_timekeeping.pdf will probably get you a link.
True, very interesting: even if you are not going to use vmware, the background info on "clocks" is very interesting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmMgxkACgkQtTMYHG2NR9WmMgCeMj53zR2B5Qmc3HvTKsSBacvD jJEAoIKRnPuHsnI8Bv1mpP9b4mFLaVUG =hrIG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday, 2009-02-05 at 22:15 +0100, Joachim Schrod wrote:
In addition to the kernel documentation, there is an interesting white paper how VMware handles the time. Googling vmware_timekeeping.pdf will probably get you a link.
True, very interesting: even if you are not going to use vmware, the background info on "clocks" is very interesting.
- -- Cheers, Carlos E. R.
It seems like I have HUGE problems at the host level on the machine as well, I get thousands of these log entries: Mar 19 15:53:09 beata kernel: [6783]: /dev/rtc enable interrupt failed: -1 Mar 19 15:53:12 beata kernel: [6810]: host clock rate change request 153 -> 980 Mar 19 15:53:12 beata kernel: [6810]: /dev/rtc enable interrupt failed: -1 Mar 19 15:53:12 beata kernel: [6428]: host clock rate change request 153 -> 432 Mar 19 15:53:12 beata kernel: [6428]: /dev/rtc enable interrupt failed: -1 Mar 19 15:53:12 beata kernel: [6783]: host clock rate change request 153 -> 598 Mar 19 15:53:12 beata kernel: [6783]: /dev/rtc enable interrupt failed: -1 As it seems, VMware wants an rtc interrupt, which SUSE 11.1 x86_64 doesn't provide. I looked at this: # hwclock --debug --show hwclock from util-linux-ng 2.14.1 Using /dev interface to clock. Last drift adjustment done at 1237473082 seconds after 1969 Last calibration done at 1237471613 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... /dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change ...got clock tick Time read from Hardware Clock: 2009/03/19 14:54:35 Hw clock time : 2009/03/19 14:54:35 = 1237474475 seconds since 1969 Thu Mar 19 15:54:35 2009 -0.325498 seconds No interrupt function at all.. Currently I boot the host o/s with 'hpet=disable nohpet clocksource=acpi_pm' Running kernel 2.6.27.19-3.2-default #1 SMP 2009-02-25 15:40:44 +0100 x86_64 on a Arima SW310 motherboard with 2 x Opteron 275 (Dual core). Any ideas on this please? __________ Information from ESET NOD32 Antivirus, version of virus signature database 3948 (20090319) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-03-19 at 15:56 +0100, Anders Norrbring wrote:
It seems like I have HUGE problems at the host level on the machine as well, I get thousands of these log entries:
Mar 19 15:53:09 beata kernel: [6783]: /dev/rtc enable interrupt failed: -1 Mar 19 15:53:12 beata kernel: [6810]: host clock rate change request 153 -> 980
You are out of luck, because Novell doesn't want to even look at vmware related problems. I opened a bugzilla about this or a very similar problem accessing /dev/rtc, which they closed as "WONTFIX". Try having a look around here: <http://www.vmware.com/info?id=34> What I did is configure vmware "host.useFastclock = FALSE".
No interrupt function at all.. Currently I boot the host o/s with 'hpet=disable nohpet clocksource=acpi_pm'
Why? :-? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknCaJsACgkQtTMYHG2NR9WMAgCcCOgYuXGj+Vcy8sbU90V9/X1/ 1voAoIKVby5XYAmoQLb5JsDnM9tPRPuM =04CL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday, 2009-03-19 at 15:56 +0100, Anders Norrbring wrote:
It seems like I have HUGE problems at the host level on the machine as well, I get thousands of these log entries:
Mar 19 15:53:09 beata kernel: [6783]: /dev/rtc enable interrupt failed: -1 Mar 19 15:53:12 beata kernel: [6810]: host clock rate change request 153 -> 980
You are out of luck, because Novell doesn't want to even look at vmware related problems. I opened a bugzilla about this or a very similar problem accessing /dev/rtc, which they closed as "WONTFIX".
Try having a look around here: <http://www.vmware.com/info?id=34>
What I did is configure vmware "host.useFastclock = FALSE".
That is a setting for the guest's vmx file as it looks.. The document also states a custom built kernel with a higher HZ setting, are you using that as well, or only the vmx setting?
No interrupt function at all.. Currently I boot the host o/s with 'hpet=disable nohpet clocksource=acpi_pm'
Why? :-?
Just stumbling around in the dark... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-03-19 at 17:02 +0100, Anders Norrbring wrote:
Try having a look around here: <http://www.vmware.com/info?id=34>
What I did is configure vmware "host.useFastclock = FALSE".
That is a setting for the guest's vmx file as it looks..
Correct, it is. I have: tools.syncTime = "FALSE" host.useFastclock = "FALSE"
The document also states a custom built kernel with a higher HZ setting, are you using that as well, or only the vmx setting?
No, the standard kernel on both host and guest (host is 11.0). Too high a clock frequency makes your machine too busy. If things go well, you might get a faster response to the user, but it expends more time handling interrupts, and may lose some. That PDF explains it all. The changes above make the guest be less demanding of the clock, and it works. As long as you do not need to use functions that need an accurate and fast clock, it works better. Of course, do not use NTP on the guest, nor multimedia.
No interrupt function at all.. Currently I boot the host o/s with 'hpet=disable nohpet clocksource=acpi_pm'
Why? :-?
Just stumbling around in the dark...
But that may be why you are getting the no irq message in the host. That setting is intented for the guest, not the host. You have to play mainly with vmware settings and guest settings. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknC3U0ACgkQtTMYHG2NR9VNgACcDC4ea7lOpsJGwRuRMjn9ORRR JjsAmwdcBLzf7GHfyC4IiS5rotuyjrKH =FduC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday, 2009-03-19 at 17:02 +0100, Anders Norrbring wrote:
Try having a look around here: <http://www.vmware.com/info?id=34>
What I did is configure vmware "host.useFastclock = FALSE".
That is a setting for the guest's vmx file as it looks..
Correct, it is. I have:
tools.syncTime = "FALSE" host.useFastclock = "FALSE"
The document also states a custom built kernel with a higher HZ setting, are you using that as well, or only the vmx setting?
No, the standard kernel on both host and guest (host is 11.0). Too high a clock frequency makes your machine too busy. If things go well, you might get a faster response to the user, but it expends more time handling interrupts, and may lose some. That PDF explains it all.
The changes above make the guest be less demanding of the clock, and it works. As long as you do not need to use functions that need an accurate and fast clock, it works better. Of course, do not use NTP on the guest, nor multimedia.
I suppose you mean not ntp as server, but I guess it would be okay to use ntp for syncing the guest clock to the real world? After all, I have a VM running MySQL and many queries are time related.. Another VM is working as a media streaming server, but I doubt time would affect that much.
No interrupt function at all.. Currently I boot the host o/s with 'hpet=disable nohpet clocksource=acpi_pm'
Why? :-?
Just stumbling around in the dark...
But that may be why you are getting the no irq message in the host. That setting is intented for the guest, not the host. You have to play mainly with vmware settings and guest settings.
Nope, the interrupt issues was long before that change, I just tested everything. Setting the host.useFastclock to false seems to have helped a lot, but now I see that heartbeat often is "gone" and management interface reports "vmware tools not available" in some of the guests. Anders. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-03-20 at 07:22 +0100, Anders Norrbring wrote:
The changes above make the guest be less demanding of the clock, and it works. As long as you do not need to use functions that need an accurate and fast clock, it works better. Of course, do not use NTP on the guest, nor multimedia.
I suppose you mean not ntp as server, but I guess it would be okay to use ntp for syncing the guest clock to the real world?
Neither. For NTP to work on the guest the environment has to virtualize a full clock, instead of just using the host timepiece. It can work, but it is not optimal. An NTP server, even less. It is better to use NTP on the host, and configure vmware to sync the guest to the host.
After all, I have a VM running MySQL and many queries are time related.. Another VM is working as a media streaming server, but I doubt time would affect that much.
Not really. Watching a movie could be affected, though.
Just stumbling around in the dark...
But that may be why you are getting the no irq message in the host. That setting is intented for the guest, not the host. You have to play mainly with vmware settings and guest settings.
Nope, the interrupt issues was long before that change, I just tested everything. Setting the host.useFastclock to false seems to have helped a lot, but now I see that heartbeat often is "gone" and management interface reports "vmware tools not available" in some of the guests.
Then you may have an issue on the host, and it is affecting the clocks in the guest, too. About the "vmware tools not available" I have no idea, but try searching on the vmware site, their documentation is good. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknE6bYACgkQtTMYHG2NR9VU6ACfZZd4KYslOBsXNBqP3S6ltRoi S3EAnjsyA+MPLipTjfsHTSLGWbPBPV7s =YA9g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday, 2009-03-19 at 17:02 +0100, Anders Norrbring wrote:
Try having a look around here: <http://www.vmware.com/info?id=34>
What I did is configure vmware "host.useFastclock = FALSE".
That is a setting for the guest's vmx file as it looks..
Correct, it is. I have:
tools.syncTime = "FALSE" host.useFastclock = "FALSE"
The document also states a custom built kernel with a higher HZ setting, are you using that as well, or only the vmx setting?
No, the standard kernel on both host and guest (host is 11.0). Too high a clock frequency makes your machine too busy. If things go well, you might get a faster response to the user, but it expends more time handling interrupts, and may lose some. That PDF explains it all.
The changes above make the guest be less demanding of the clock, and it works. As long as you do not need to use functions that need an accurate and fast clock, it works better. Of course, do not use NTP on the guest, nor multimedia.
Well, my VMs all drift about 15 seconds per minute now, which is totally unacceptable, so for now I've set: tools.syncTime = "true" tools.syncTime.period = "10" host.useFastclock = "FALSE" which makes clocks, not accurate, but at least fairly okay for the time being. I have no idea if this would work better if I scrapped the VMware Server and go ESXi instead, I'll see if I can set up a test rig to experiment a little. That would of course force me into some major rethinking about how things are run, but what the heck.. Anders. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-03-21 at 09:23 +0100, Anders Norrbring wrote:
Correct, it is. I have:
tools.syncTime = "FALSE" host.useFastclock = "FALSE"
Well, my VMs all drift about 15 seconds per minute now, which is totally unacceptable, so for now I've set: tools.syncTime = "true" tools.syncTime.period = "10" host.useFastclock = "FALSE"
Now, I'm wondering why I set tools.syncTime to false, it should be true... it tells the guest to get the time from the host, directly, which is simple. Maybe I set it to false because I had problems when I hibernated the machine :-? But that's not your case, I suppose.
which makes clocks, not accurate, but at least fairly okay for the time being. I have no idea if this would work better if I scrapped the VMware Server and go ESXi instead, I'll see if I can set up a test rig to experiment a little. That would of course force me into some major rethinking about how things are run, but what the heck..
I have no idea about that. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknE7ScACgkQtTMYHG2NR9UVHwCfUEq2fkcMe05K6ybNPdmS51BL BKAAnioS0w1QbRRIAdBkv4e03ucnDbuX =65H0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Den 2009-03-21 14:35, Carlos E. R. skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2009-03-21 at 09:23 +0100, Anders Norrbring wrote:
Correct, it is. I have:
tools.syncTime = "FALSE" host.useFastclock = "FALSE"
Well, my VMs all drift about 15 seconds per minute now, which is totally unacceptable, so for now I've set: tools.syncTime = "true" tools.syncTime.period = "10" host.useFastclock = "FALSE"
Now, I'm wondering why I set tools.syncTime to false, it should be true... it tells the guest to get the time from the host, directly, which is simple.
Maybe I set it to false because I had problems when I hibernated the machine :-? But that's not your case, I suppose.
which makes clocks, not accurate, but at least fairly okay for the time being. I have no idea if this would work better if I scrapped the VMware Server and go ESXi instead, I'll see if I can set up a test rig to experiment a little. That would of course force me into some major rethinking about how things are run, but what the heck..
I have no idea about that.
-
Well, things are at least running for now. Which is a good thing.. I'll look into details after the weekend, and I'll also set up a ESXi box to test it a little. Thanks for all your help so far Carlos! Anders. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-03-21 at 17:47 +0100, Anders Norrbring wrote:
Well, things are at least running for now. Which is a good thing.. I'll look into details after the weekend, and I'll also set up a ESXi box to test it a little.
Thanks for all your help so far Carlos!
Welcome. Remember also that there is also a very low traffic mail list, opensuse-virtual, where they should know more about these things. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknFKjoACgkQtTMYHG2NR9UFKwCeNzVrRVgF2x0RG0tz6BXeIXpI ySwAn31Fhz7g5uJUbseIxo1xa8pYnXG5 =X6JP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-03-19 at 15:56 +0100, Anders Norrbring wrote:
No interrupt function at all.. Currently I boot the host o/s with 'hpet=disable nohpet clocksource=acpi_pm'
That recomendation was for the guest, not the host. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknCaXQACgkQtTMYHG2NR9X6CgCfcD02nAosJ9ngXoLNNCRjkgEO B88An3IAJbZQmO4LpnYJN7g8dE90BKbr =UlY3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Anders Norrbring -
Carlos E. R. -
Joachim Schrod