# [VMware] Synchro Horloge: PIT clocksource et SMP (résolu)

## El_Goretto

Bonjour,

Je me permets de faire un double post anglais/français, parce que ce problème me pourrit la vie... Et qu'il ne se produit que sur une gentoo (pas sur RedHat par exemple).

Problème: j'ai déjà réussi à garder l'horloge synchro sur toutes mes machines virtuelles (VMs) sauf les VM gentoos qui ont plus d'un CPU. Tout est paramétré comme d'habitude, de façon à choisir la "clocksource" PIT pour que l'horloge de la VM soit trop lente, et que les outils type VMware (open-vm-utils) compensent la lenteur (c'est la façon clean de faire, de toute façon NTP ne suffit pas).

Voilà le symptôme:

Avé 1 CPU:

```
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource

jiffies tsc pit
```

La même VM avé 2 CPUs:

```
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource

jiffies tsc
```

Forcément, du coup, quand je boote la VM avec 2 CPUs, c'est la "clocksource" TSC qui est choisie, et ça ne va pas du tout.

Si vous avez des idées, je suis preneur.

Ah, et j'ai besoin de plus d'1 CPU, donc non, pas cette suggestion là  :Wink: 

Les détails: 

Hôte RedHat 4U4 32b équipé avec du Vmware Server 1.0.4. La gentoo est à jour sauf le noyau 2.6.20 généré par genkernel (bugs avec des noyaux plus récents sur des produits VMware plus anciens).

----------

## El_Goretto

Raté, même avec un noyau 2.6.23-r8 "fait à la main", point de PIT.

```
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource

tsc acpi_pm jiffies

```

----------

## Mickael

Salut,

je suis tombé sur ceci : 

 *Quote:*   

> 
> 
> title Debian GNU/Linux, kernel 2.6.22-3-686
> 
> root (hd0,0)
> ...

 

à cette adresse : http://kamilkisiel.blogspot.com/2008/01/vmware-linux-guest-clock.html

EDIT 1 : je suis en train de regarder ce qui ce dit, sur différents sites, et pour l'instant c'est pas gagné avec des machines multi-cœurs...

EDIT 11 : je viens de lire que pour le cas SMP il te faudra activer le support APCI/APIC : donc adapter les noapic and Co

EDIT 2 : utilises-tu cette option  : tools.syncTime = "true" avec l'option du noyau : clocksource=pit. À tenter!

----------

## El_Goretto

 *Mickael wrote:*   

> à cette adresse : http://kamilkisiel.blogspot.com/2008/01/vmware-linux-guest-clock.html

 

Déjà vu cette page, c'est une des premières qui tombe avec les mots clés "vmware smp pic"  :Smile: . Mais eux ont une machine monoCPU, nosmp c'est pas top  :Wink: 

 *Mickael wrote:*   

> EDIT 1 : je suis en train de regarder ce qui ce dit, sur différents sites, et pour l'instant c'est pas gagné avec des machines multi-cœurs...
> 
> EDIT 11 : je viens de lire que pour le cas SMP il te faudra activer le support APCI/APIC : donc adapter les noapic and Co

 

Yep, c'est pour çà que dans mon noyau fait main avec support ACPI et APIC, j'ai un acpi_pm qui vient d'arriver dans la liste des timers dispos. Mais çà ne fait pas réapparaitre PIT...

 *Mickael wrote:*   

> EDIT 2 : utilises-tu cette option  : tools.syncTime = "true" avec l'option du noyau : clocksource=pit. À tenter!

 

T'inquiète, c'est une option indispensable à la synchro à mettre dans le fichier vmx, tout comme le clocksource=PIT pour le noyal (sinon je ne chercherais pas à tout prix à le rechopper) c'est fait depuis longtemps  :Smile: 

C'est vraiment côté guest VM que çà coince: la synchro marche bien en mode monoCPU avec une gentoo en guest.

----------

## Mickael

Laisse le ntp sur la machine hote et vire le de la machine invitée, et tu laisses faire les wmare-tools.

EDIT : On dirait que vmware ne supporte pas le SMP :  *Quote:*   

> VMware Virtual SMP facilite  le déploiement d’applications critiques de classe entreprise sur des machines virtuelles

 

La source : http://www.vmware.com/fr/products/vi/esx/vsmp.html

Donc par défaut pas de SMP :/ ? il te faudrait ce module ? Ou alors un vmware serveur version XXX qui supporte le multicoeurs...

EDIT 2 : nan ben j'ai l'impression que tu l'as dans l'os :/ dans la plaquette de pub pour vmware-server, ils disent : 

 *Quote:*   

> Capacités mono et multiprocesseurs par machine virtuelle dotée de Virtual SMP

 

----------

## El_Goretto

Tu ne m'as pas compris: je suis un vétéran de la synchro des horloges de VMs VMware...

Je suis déjà dans les clous, côté bonnes pratiques, ce que tu me dis je le fais déjà depuis le début quand il y a des vmtools de dispo (ce que n'était pas le cas sous gentoo il y a peu).

Mais bref.

Je répète: mes vmtools fonctionnent, dans le sens où ils font ce qu'ils sont sensés faire. A savoir accélérer l'horloge quand elle est en retard. Ce qu'on cherche à faire délibérément en paramétrant PIT comme clocksource. Toute autre source fait pédaler l'horloge trop vite, et dans ce cas c'est foutu, les vmtools ne peuvent rien.

D'où mon intérêt si insistant à avoir PIT de dispo quand j'ai plusieurs CPUs dans mon moulin.   :Confused: 

--

contre-edit: tu triches!  :Smile: 

En fait, le problème n'est pas d'avoir des CPUs "virtuels" de dispos dans la VM (2 max sous VMware Server, le gratuit). C'est simplement cette problématique pénible et systématique de l'horloge qui me pourrit la vie.

----------

## Mickael

J'ai fini par bien comprendre, d'où mes deux deriers EDIT, si tu n'as pas le module multi-coeurs ou cluster, ben il semblerait que cela ne soit pas possible,..

EDIt : je viens de lire ton EDIT  :Smile: 

----------

## El_Goretto

Hahaaa, baston d'edit!!  :Razz: 

Bon, finis le OFF.

Merci pour ton coup de main, retour au point de départ  :Wink: 

----------

## Mickael

Je sais déjà que tu es le vétéran du sync-clock, mais je mise sur un problème du noyau. Soit pour les smp le pit n'est plus, soit comme dans ce lien, on voit que le module HPET est configuré à PIT par défault : 

 *Quote:*   

> -   hpet=      [IA-32,HPET] option to disable HPET and use PIT.
> 
> +   hpet=      [X86-32,HPET] option to disable HPET and use PIT.

 

Le lien parle du fichier /Documentation/kernel-parameters.txt pour un 2.6.23, alors faut voir comment spécifier ce PIT avec un smp, ou alors vérifier que le clock=pit existe avec les multiprocesseurs.

Dans mon cas avec tuxonice 2.6.24-r2 : 

```
 

/usr/src/linux/Documentation $ grep -i PIT kernel-parameters.txt 

         clocksource is not available, it defaults to PIT.

         Format: { pit | tsc | cyclone | pmtmr }

         [X86-32] pit,hpet,tsc,vmi-timer;

         disable: disable HPET and use PIT instead
```

Si HPET est configuré dans le noyal, alors il se peut que l'option clock=PIT ne fonctionne pas, et que HPET finisse par passer outre cette commande.

EDIT : j'ai un CORE-duo, sur un portable dell 6400. et  grep -i pit /var/log/messages :

 *Quote:*   

> Time: pit clocksource has been installed.

 

EDIT :  *Quote:*   

>  su
> 
> Mot de passe : 
> 
> lab-mparis clocksource0 # cat current_clocksource 
> ...

 

Point de PIT avec l'option HPET. Bout de configuration : 

 *Quote:*   

> grep HPET .config
> 
> CONFIG_HPET_TIMER=y
> 
> CONFIG_HPET_EMULATE_RTC=y
> ...

 

----------

## El_Goretto

Waw, magnifique, ce serait une piste énorme, merci Mickael  :Smile: 

Alors le noyal ma VM:

```
# grep HPET .config

CONFIG_HPET_TIMER=y

CONFIG_HPET_EMULATE_RTC=y

CONFIG_HPET=y

# CONFIG_HPET_RTC_IRQ is not set

CONFIG_HPET_MMAP=y

```

Et je n'ai pas hpet comme clocksource de dispo... Je vais voir si je peux la "retrouver" et, avec l'option hpet=disable que tu cites, indirectement avoir pit.

Un seul mot: "pinaise"  :Smile: 

Je vais donc aller à fond dans cette piste.

Sinon apparemment, l'option "tickless" pourrait éventuellement être un workaround acceptable côté noyau. Cette nuit, mes 2 VMs de tests ont eu le même comportement:

au boot malgré l'option PIT explicite:

```
[ 1452.540167] Time: tsc clocksource has been installed.
```

Et puis:

```
[49500.732327] Clocksource tsc unstable (delta = 1610221713248 ns)

[49500.735813] Time: acpi_pm clocksource has been installed.
```

Et l'horloge OS n'est pas parti en avant... Je laisse tourner 1 VM encore qqs jours sur cette config pour voir si c'est fiable.

Encore merci Mickeal, j'ai honte de ne pas avoir été regarder la doc kernel directement, au lieu de chercher des recettes toutes faites sur le net...  :Embarassed:   Faut vraiment que j'arrête d'installer des bubuntus dans mon entourage  :Smile: 

----------

## Mickael

En espérant que cela fonctionne, mais il te reste encore une piste qui est un mixe noyal/vmware, mais là c'est à toi de voir car tu en sais bien plus que moi, regarde cette horloge : pmtmr j'ai lu sur leur site (wiki ou forum, je sais plus) qu'il la préconisait au cas ou leur workaround 1 (avance horlorge) ne fonctionne pas et si leur workaround 2 (horloge recul) ne fonctionne pas non plus. Il la donnait à la fin des explications, sans pour autant expliquer ce choix ---> c'est p'têtre un truc du genre dernière cartouche..  :Laughing: 

----------

## El_Goretto

 *VMware wrote:*   

> Virtual HPET
> 
> Current VMware products do not provide a virtual HPET.
> 
> 

 

Comme çà, c'est fait...  :Smile: 

 *VMware wrote:*   

> Option clock=pmtmr selects a simpler but more robust algorithm [NdE: par opposition à tsc] that makes use of the ACPI timer for interpolation. This option also includes lost tick correction code that may cause time gains.  owever, when used in a virtual machine, time gains from using this option are much smaller. This option is usable in a virtual machine, if you can tolerate the small time gain. 
> 
> 

 

Bon, alors je suppose que maintenant, l'équivalent de pmtmr est acpi_pm.

En même temps, leur white paper date du noyau 2.6.8... Super à jour, pour un problème critique et systématique  :Sad: 

Bon, je continue d'observer le comportement de acpi_pm en combinaison avec un noyau tickless "à 100Hz", avant de passer le thread en résolu.

Big merci à toi, Mickael  :Smile: 

----------

## Mickael

J'ai hâte de connaitre le résultat, et je me pose une petite question à propos de Xen, as-tu déjà installé Xen, et si oui as-tu déjà eu ce problème? Je sais que la paravirtualisation n'est pas de la virtualisation (tout court) mais dans les deux cas on souhaite que les horloges restent stables!

----------

## El_Goretto

Bon, alors bonne nouvelle, la VM qui avait 1 min d'avance sur son hôte physique hier a quasiment "perdu" cette avance ce matin, donc ça veut dire que le temps de la VM n'est pas condamné à avancer petit à petit, mais va bien très très légèrement en arrière, donc yabon avec les open-vm-tools en couverture. Pour info, la VM contient un serveur zabbix et cacti,donc la charge est constante et non négligeable, de l'ordre de 60% et 20% des temps des 2 CPU).

Pour Xen, normalement je vais tester çà sous peu, mais dans la version fournie par une distro dont le nom commence par Su et finit par SE. Oui, bah, on choisit pas toujours  :Wink: 

Si ya un truc interessant à dire côté horloge, je ferai un mini post de retour d'expérience, sinon un pm "tout va bien" suffira  :Smile: 

----------

## Mickael

Excellent !   :Wink: 

Juste une petite remarque me concernant avec cette horloge HPET, j'ai déjà remarqué une avance de mon horloge (rappel : pour une installation classique directement sur le portable; pas de para/virtualisation) donc wait and see. Peut-être est-ce dû au double boot XP/GENTOO ? Je devrais le virai ce XP, je ne l'utilise plus.

----------

