[vmware] guest os niet stabiel te krijgen

[Verwijderd]

Tweakers,

na ook hier al een tijdje rond te hebben gezocht, en op google rond te hebben gekeken krijg ik het niet voor elkaar om een stabiele VMware omgeving op te zetten, hieronder mijn situatie, en bevindingen:

Main server:

code:

root@ubuntu:~# w
 09:09:06 up 248 days,  9:28,  2 users,  load average: 0.00, 0.00, 0.00

root@ubuntu:~# cat /proc/version
Linux version 2.6.22-14-server (buildd@palmer) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Sun Oct 14 23:34:23 GMT 2007

CPU: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
MEM: 4149276 kB
HD: 1x 160 GB SATA
HD: 1x 1024GB SATA

al met al naar mijn idee een prima servertje om voor een ontwikkel omgeving wat VMware OSjes op te draaien. Draait colocated, 100mbit pijp met wat IPtjes die ik dus via Bridged mode me VMware machines online beschikbaar stel.

so far so good, met heel wat geklooi en howto's heb ik op Ubuntu de Vmware Server (laatste versie) aan de gang gekregen (packages en libs zijn standaard niet allemaal aanwezig om de Vmware installer out of the box te runnen).

Na de installatie, netjes met VMware Server Console inloggen, Vmware guest OS aangemaakt, ubuntu iso gemount, geinstalleerd, netwerk config gedaan, en voila me ubuntu guest machine is alive!

klinkt allemaal niet verkeerd, maar op een of andere mannier gaat er iets mis met de tijd o.i.d. na het weekend me guest os te hebben laten draaien zijn dit de meest voorkomende problemen:

guest os

code:

root@ubuntu-vm-start:~# w
 12:14:03 up -24855 days, -3:-14,  1 user,  load average: 0.00, 0.00, 0.00

main os

code:

[3413837.220206] /dev/vmmon[20803]: host clock rate change request 2 -> 3
[3413839.257101] /dev/vmmon[20802]: host clock rate change request 3 -> 153
[3413849.427786] /dev/vmmon[20802]: host clock rate change request 153 -> 2
[3413849.431724] /dev/vmmon[20803]: host clock rate change request 2 -> 0
[3413849.431754] /dev/vmmon[20803]: host clock rate change request 0 -> 2
[3413849.431813] /dev/vmmon[20802]: host clock rate change request 2 -> 3
[3413851.469193] /dev/vmmon[20803]: host clock rate change request 3 -> 153
[3413861.634352] /dev/vmmon[20803]: host clock rate change request 153 -> 2
[3413861.635501] /dev/vmmon[20803]: host clock rate change request 2 -> 3
[3416061.681021] /dev/vmmon[20802]: host clock rate change request 3 -> 5

... etc etc

Nu heb ik daar op gegoogled, maar kan niks geen bruikbare oplossing vinden, clock=pit aan boot meegeven doet ook niks.

verder valt de verbinding naar me vmware os ook vaak weg (elke 15-20 min is die dan 5 min down).

verder heb ik op het host os, elk uur een ntp-date met ntp.xs4all.nl en ook binnen mijn guest os, maar ook dit lost het probleem niet op.

graag hulp!

[Verwijderd]

VMware Tools al eens geinstalleerd op je guest OS?

[Verwijderd]

Verwijderd schreef op maandag 07 juli 2008 @ 09:28:
VMware Tools al eens geinstalleerd op je guest OS?

Yep, vergeten te vermelden, maar ook die draait!

[Verwijderd]

Ik denk dat je Kernel in de guest niet op 100Hz draait, dit moet je wel doen.

[ Voor 8% gewijzigd door Verwijderd op 07-07-2008 09:42 ]

[Verwijderd]

Verwijderd schreef op maandag 07 juli 2008 @ 09:42:
Ik denk dat je Kernel in de guest niet op 100Hz draait, dit moet je wel doen.

code:

root@ubuntu-vm-start:~# cat /boot/config-`uname -r` | grep '^CONFIG_HZ='
CONFIG_HZ=100

[doc]

Heb je in je .vmx file dit staan?

tools.syncTime = "TRUE"

Als dat niet werkt kan je de tips op de volgende paginas ook eens proberen

http://theether.net/kb/100039
http://kb.vmware.com/self...displayKC&externalId=1420

[Redje]

Heb je Speedstep etc aan of uitstaan in de bios van de server?

Ik heb Vmware op een AMD draaien en daar klokt de processor terug als deze idle is, guests vinden dat dus niet prettig.

[Verwijderd]

Welke Vmware draai je eigenlijk ? 2.0 of the 1.x versie ?

[Verwijderd]

Ik draai de 1.0.6 versie.

Power Savings, en dat soort dingen kan ik helaas niet vanuit hier uitlezen remote, maar mijn 2de exact zelfde server staat dat default uit, dat hij dus niet terug clocked. (100% zeker kan ik dit dus niet zeggen)

[Verwijderd]

Raar iets, het draait bij mij echt altijd out of de box.

Je mem eens controleren ?

[AtleX]

Redje schreef op maandag 07 juli 2008 @ 10:12:
Ik heb Vmware op een AMD draaien en daar klokt de processor terug als deze idle is, guests vinden dat dus niet prettig.

Mijn Athlon LE-1620 klokt ook terug naar 1GHz, maar de 5 VM's die er permanent op draaien (4x Debian Linux, 1x Gentoo) hebben er geen enkel probleem mee. Ook een incidentele VM met XP gaat gewoon goed.

[Verwijderd]

Verwijderd schreef op maandag 07 juli 2008 @ 10:17:
Raar iets, het draait bij mij echt altijd out of de box.

Je mem eens controleren ?

Alles OK... maar nog steeds problemen, raar maar waar

[ Voor 10% gewijzigd door Verwijderd op 07-07-2008 10:45 ]

[Verwijderd]

doc schreef op maandag 07 juli 2008 @ 10:01:
Heb je in je .vmx file dit staan?

tools.syncTime = "TRUE"

Als dat niet werkt kan je de tips op de volgende paginas ook eens proberen

http://theether.net/kb/100039
http://kb.vmware.com/self...displayKC&externalId=1420

zojuist geprobeerd, ik zal morgen ochtend eens zien of de tijd nog goed loopt, nu in elk geval (al) 15 min up

[Verwijderd]

Bevindingen so far:

code:

root@ubuntu-vm-start:/boot/grub# w
 08:11:22 up 10:44,  1 user,  load average: 0.00, 0.00, 0.00

aanpassingen gedaan:

- tools.syncTime = "TRUE" gezet in de vmx file.
- ntpdate elk uur via crontab (ntpdate ntp.xs4all.nl)
- vmware tools geinstalleerd
- grub aangepast met volgende instructie:

code:

title           Ubuntu 8.04, kernel 2.6.24-16-server
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.24-16-server root=UUID=ea8a23e3-785b-4901-bbab-b4f0776ecd52 ro quiet splash clocksource=pit noapic nolapic
initrd          /boot/initrd.img-2.6.24-16-server
quiet

dit lijkt zijn vruchten af te werpen, alleen heb ik nu nog op het host OS de vervelende melding:

code:

[41039.266821] /dev/vmmon[4801]: host clock rate change request 29 -> 36
[41044.409287] /dev/vmmon[4801]: host clock rate change request 36 -> 44
[41045.427696] /dev/vmmon[4801]: host clock rate change request 44 -> 47
[41054.683962] /dev/vmmon[4801]: host clock rate change request 47 -> 59
[41065.677629] /dev/vmmon[4801]: host clock rate change request 59 -> 3
[41065.677649] /dev/vmmon[4801]: host clock rate change request 3 -> 24

- bios powersavings staat niet aan ( gister nog gechecked in datacenter )

iemand een tip hoe ik deze melding kan oplossen zonder de syslogger configuratie aan te passen dat hij deze melding onderdrukt

[deadinspace]

Verwijderd schreef op dinsdag 08 juli 2008 @ 08:14:
- ntpdate elk uur via crontab (ntpdate ntp.xs4all.nl)

Leuk als je sprongen in je tijdsverloop wil (hint: dat wil je niet). Waarom niet gewoon een NTP daemon?

[AtleX]

Niet voor elke server is het vervelend als z'n logfiles niet helemaal kloppen. Ik heb een paar VM's die niets doen behalve software compilen op vastgestelde momenten. Deze VM's worden gesuspend, gebackuped en weer gestart op een bepaald moment van de dag. Dat zorgt ervoor dat de tijd achter gaat lopen, en dus sync ik elk uur met mijn eigen timeserver. De logfiles op die dingen boeien me niet echt, en verder kan ik me serieus geen probleem voorstellen met een tijdsprong op die machines.

Dat het bij bijvoorbeeld een webserver vervelender kan zijn wel ja, maar wat voor NTP daemon bedoel jij dan om het op te lossen? Eentje die elke 5 minuten checkt oid? Dan heb je alsnog een jump van 5 minuten maximaal.

[blaataaps]

Een ntp-daemon checkt continu (en niet elke 5 minuten) als dat nodig is, en verandert de tijd met kleine stapjes zodat er geen gaten of dubbele tijdstippen ontstaan. De "normale" manier is dan hoogstens bij het opstarten 1x ntpdate (of equivalent) en daarna ntpd.

[ Voor 22% gewijzigd door blaataaps op 08-07-2008 10:17 ]

[AtleX]

Ah, dat verklaart een hoop. Maar ik neem aan dat je dan wel je eigen timeserver moet draaien. Geen enkele Stratum x beheerder wordt er blij van als jij constant de tijd vraagt aan die dingen.

[blaataaps]

Dat is precies waarvoor ze draaien (als je eentje uit de openbare pool hebt), en continu is ook niet dat ze kilobytes per seconde vragen, maar dat ntpd het min of meer continu in de gaten houdt in plaats van op onhandige intervallen.

[_JGC_]

Ik gok erop dat je de dynamic ticks aan hebt staan in je guest OS (CONFIG_NOHZ voor zover ik weet).

[Verwijderd]

_JGC_ schreef op dinsdag 08 juli 2008 @ 11:04:
Ik gok erop dat je de dynamic ticks aan hebt staan in je guest OS (CONFIG_NOHZ voor zover ik weet).

CONFIG_NO_HZ=y

is dit verkeerd? de tijd blijft nu in me guest OS redelijk stabiel lopen, laatste ntp-date responses vanuit crontab:

code:

 8 Jul 08:00:00 ntpdate[18926]: step time server 194.109.22.18 offset -1.480068 sec
 8 Jul 09:00:01 ntpdate[5904]: step time server 194.109.22.18 offset -34.246086 sec
 8 Jul 10:00:01 ntpdate[6240]: step time server 194.109.22.18 offset -1.522529 sec
 8 Jul 11:00:01 ntpdate[6310]: step time server 194.109.22.18 offset -1.537596 sec

[deadinspace]

AtleX schreef op dinsdag 08 juli 2008 @ 10:15:
Niet voor elke server is het vervelend als z'n logfiles niet helemaal kloppen.

Het gaat om een stuk meer dan alleen timestamps in logfiles. Als een process sleep(1) doet, en gedurende die seconde wordt de clock een minuut achteruit gezet, dan sleept dat process dus 61 seconden in plaats van 1. Denk ook aan timestamp-based acties, of time-based sessies (kan voor webservers van belang zijn).

Als praktisch voorbeeld: Mijn desktop heeft nogal wat clock drift, en ik had daar ooit een ntpdate voor gescheduled. Als ik TV opnam van mijn analoge TV-kaart met mencoder, dan ging de AV-sync aardig de mist in als ntpdate langs kwam: audio liep gewoon door, maar video werd gepauzeerd voor evenveel seconden als de clock verzet werd. Dat was een direct gevolg van mencoders gebruik van timestamps om dingen te syncen.

Het hangt er natuurlijk wel van af wat je computer doet, maar er zijn potentieel heel wat meer gevolgen dan "de logs kloppen niet helemaal".

Dat het bij bijvoorbeeld een webserver vervelender kan zijn wel ja, maar wat voor NTP daemon bedoel jij dan om het op te lossen? Eentje die elke 5 minuten checkt oid? Dan heb je alsnog een jump van 5 minuten maximaal.

Nee, een NTP daemon vraagt regelmatig de tijd op en vergelijkt die met de tijd van het systeem. Op basis daarvan laat hij de system clock iets sneller of iets langzamer lopen zodat het verschil op termijn gecorrigeerd wordt, maar hij verzet de tijd niet.

Voor VM guests die je suspend en weer wakker maakt zal het waarschijnljik wel zinnig zijn om een ntpdate te draaien na het wakker maken van zo'n guest. Als die guest een ACPI event oid krijgt van de wakeup, dan is dat zelfs wel te automatiseren.

Een hoop van mijn systemen draaien ook ntpdate tijdens het booten, om te zorgen dat het systeem in ieder geval begint met een goede tijd. Dat is zeker wenselijk voor systemen die wat langer uit kunnen staan (en dus meer kunnen driften), omdat tijdscorrectie door een NTP daemon een traag proces is.

[_JGC_]

Overigens kan je openntpd gewoon met -s starten waardoor de tijd bij het starten ervan in 1 stap goed wordt gezet, heb je geen ntpdate voor nodig

Wat betreft CONFIG_NOHZ: die optie zorgt ervoor dat je timerfrequentie in de kernel variabel wordt. Dit is goed voor energiebesparing, maar minder goed als je in een gevirtualiseerde omgeving werkt.

[LauPro]

Volgens mij regelt de VMWare client de klok van het guest OS, het is ook een aparte instelling afaik.

[deadinspace]

_JGC_ schreef op dinsdag 08 juli 2008 @ 11:32:
Overigens kan je openntpd gewoon met -s starten waardoor de tijd bij het starten ervan in 1 stap goed wordt gezet, heb je geen ntpdate voor nodig

Ow, dat is nuttig! Mooi tip