Bonsoir,
Sur un cluster ESXi, j'ai une VM Debian Jessie 4cpu 4Go ram à jour qui lors d'un reboot n'a pas voulu redémarrer, tout de suite après grub j'ai des messages en boucle de systemd qui tente de redémarrer udev, LSB, root fs et qui échoue par manque de mémoire.
En augmentant la mémoire de la vm à 6Go de ram, la vm démarre et juste après le boot j'ai un peu plus de 4Go de ram utilisé alors que la vm ne fait rien d'autre que du ssh pour le moment.
Dès que je repasse à 4Go ou moins impossible de démarrer.
N'ayant pas fait de changement dans l'OS, j'ai pensé à un bug côté vmware (5.5, vm hardware version 8) j'ai cloné la vm, même conséquence, elle n'a pas de ressources minimum ou réservée.
J'ai migré la vm sur d'autres hosts sans succès. J'ai fixé les ressources mémoire, ça ne change rien.
Cette vm a été clonée d'un template qui est en même version et consomme 95Mo après un boot.
J'ai tenté un burn memory avec swap off pour voir si le ballonning de vmware pouvait être en cause et non la vm freeze quand la mémoire arrive à saturation après les 2Go remplis. Dans les stats de la vm que du private et shared et 4,5Go en unaccessed.
J'ai fait tourner la vm sur un host sans aucune autre vm dessus, pareil.
Je sèche si vous aviez des conseils je suis preneur, grand merci par avance.
Salut, il me semble que la debian 8 n'est pas officiellement supportée pour par vmware 5.5.
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=sof...
Typiquement dans mon cas avec un vmware 5.5 et des lames cisco 64 procs, les performances étaient catastrophiques. A l'époque je n'avais pas fait attention et j'ai voulu migrer notre cluster Elasticsearch et je me suis retrouvé avec de "Thread Pool" blindé alors que j'avais de la conf aux petits oignons. Le cluster ne tenait rien en debian 8. Je suis juste resté en debian 7 mais avec un Elasticsearch à jour de depuis pas de problème.
Tout ca pour te dire que moi j'aurai migré en vmware 6.
Alex.
On 07/06/16 20:23, Wallace wrote:
Bonsoir,
Sur un cluster ESXi, j'ai une VM Debian Jessie 4cpu 4Go ram à jour qui lors d'un reboot n'a pas voulu redémarrer, tout de suite après grub j'ai des messages en boucle de systemd qui tente de redémarrer udev, LSB, root fs et qui échoue par manque de mémoire.
En augmentant la mémoire de la vm à 6Go de ram, la vm démarre et juste après le boot j'ai un peu plus de 4Go de ram utilisé alors que la vm ne fait rien d'autre que du ssh pour le moment.
Dès que je repasse à 4Go ou moins impossible de démarrer.
N'ayant pas fait de changement dans l'OS, j'ai pensé à un bug côté vmware (5.5, vm hardware version 8) j'ai cloné la vm, même conséquence, elle n'a pas de ressources minimum ou réservée.
J'ai migré la vm sur d'autres hosts sans succès. J'ai fixé les ressources mémoire, ça ne change rien.
Cette vm a été clonée d'un template qui est en même version et consomme 95Mo après un boot.
J'ai tenté un burn memory avec swap off pour voir si le ballonning de vmware pouvait être en cause et non la vm freeze quand la mémoire arrive à saturation après les 2Go remplis. Dans les stats de la vm que du private et shared et 4,5Go en unaccessed.
J'ai fait tourner la vm sur un host sans aucune autre vm dessus, pareil.
Je sèche si vous aviez des conseils je suis preneur, grand merci par avance.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
On Tue Jun 7 20:23:45 2016, Wallace wrote:
Sur un cluster ESXi, j'ai une VM Debian Jessie 4cpu 4Go ram à jour qui lors d'un reboot n'a pas voulu redémarrer, tout de suite après grub j'ai des messages en boucle de systemd qui tente de redémarrer udev, LSB, root fs et qui échoue par manque de mémoire.
Tu as tenté de virer systemd pour voir ?
J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office.
Le 07/06/2016 20:55, Alarig Le Lay a écrit :
Bonsoir,
On Tue Jun 7 20:23:45 2016, Wallace wrote:
Sur un cluster ESXi, j'ai une VM Debian Jessie 4cpu 4Go ram à jour qui lors d'un reboot n'a pas voulu redémarrer, tout de suite après grub j'ai des messages en boucle de systemd qui tente de redémarrer udev, LSB, root fs et qui échoue par manque de mémoire.
Tu as tenté de virer systemd pour voir ?
Liste de diffusion du FRsAG http://www.frsag.org/
Lors de la creation de la vm.. Quel os choisis tu dans le wizard ? Le 8 juin 2016 9:27 AM, "Wallace" wallace@morkitu.org a écrit :
J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office.
Le 07/06/2016 20:55, Alarig Le Lay a écrit :
Bonsoir,
On Tue Jun 7 20:23:45 2016, Wallace wrote:
Sur un cluster ESXi, j'ai une VM Debian Jessie 4cpu 4Go ram à jour qui lors d'un reboot n'a pas voulu redémarrer, tout de suite après grub j'ai des messages en boucle de systemd qui tente de redémarrer udev, LSB, root fs et qui échoue par manque de mémoire.
Tu as tenté de virer systemd pour voir ?
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Toutes les vm sont en Linux Debian 64bits au niveau VMWare comme au niveau de l'OS
Le 08/06/2016 11:58, Jerome Lien a écrit :
Lors de la creation de la vm.. Quel os choisis tu dans le wizard ?
Le 8 juin 2016 9:27 AM, "Wallace" <wallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office. Le 07/06/2016 20:55, Alarig Le Lay a écrit :Bonsoir, On Tue Jun 7 20:23:45 2016, Wallace wrote:Sur un cluster ESXi, j'ai une VM Debian Jessie 4cpu 4Go ram à jour qui lors d'un reboot n'a pas voulu redémarrer, tout de suite après grub j'ai des messages en boucle de systemd qui tente de redémarrer udev, LSB, root fs et qui échoue par manque de mémoire.Tu as tenté de virer systemd pour voir ? _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 06/08/2016 10:25 AM, Wallace wrote:
J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office.
donc ça ne viendrait pas de l'OS mais de la "plateforme matérielle" ? Ceci suppose que OS=SystemRescueCD ne subit *aucun* effet de bord dû au contenu du disque, genre discovery de partition ou de LVM, toussa.
"Plateforme matérielle": je vérifierais l'intégrité du fichier de "BIOS" et les settings dans le fichier de paramétrage.
Tu pourrais aussi reconstruire la VM: - VM vierge + isolation réseau - copie + pointage des disques de la VM pourrie - injection des autres paramétrages un par un
Ca permet de travailler "tranquillement" sur une copie.
Pierre
Je conseillerais de faire l'explication de pierre en rajoutant comme guest os "other" + une copie du vmdk sans les autres fichier pour mettre de côté un problème de comportement du coté vmware. J'ai eu un problème semblable mais au niveau cpu avec un centos ou les ressources cpu était multiplié par 10 (virtuellement) Le 8 juin 2016 11:41 AM, "Pierre Bourgin" pierre.bourgin@free.fr a écrit :
On 06/08/2016 10:25 AM, Wallace wrote:
J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office.
donc ça ne viendrait pas de l'OS mais de la "plateforme matérielle" ? Ceci suppose que OS=SystemRescueCD ne subit *aucun* effet de bord dû au contenu du disque, genre discovery de partition ou de LVM, toussa.
"Plateforme matérielle": je vérifierais l'intégrité du fichier de "BIOS" et les settings dans le fichier de paramétrage.
Tu pourrais aussi reconstruire la VM:
- VM vierge + isolation réseau
- copie + pointage des disques de la VM pourrie
- injection des autres paramétrages un par un
Ca permet de travailler "tranquillement" sur une copie.
Pierre _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le type de controlleur disque n’aurait pas été modifié ? Bien vérifier ce qui est compatible entre ton os et la version de l‘esx.
Y’a pas eu d’évolution sur la version du hardware virtuel ?
Cordialement,
Olivier VAILLEAU Responsable Systèmes Centre Hospitalier William Morey - Tél : 03 85 91 00 07 Centre Hospitalier spécialisé de Sevrey - Tél : 03 85 92 82 94
De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Jerome Lien Envoyé : mercredi 8 juin 2016 12:47 À : Pierre Bourgin Cc : French SysAdmin Group Objet : Re: [FRsAG] ESXi VM comportement mémoire étrange
Je conseillerais de faire l'explication de pierre en rajoutant comme guest os "other" + une copie du vmdk sans les autres fichier pour mettre de côté un problème de comportement du coté vmware. J'ai eu un problème semblable mais au niveau cpu avec un centos ou les ressources cpu était multiplié par 10 (virtuellement) Le 8 juin 2016 11:41 AM, "Pierre Bourgin" <pierre.bourgin@free.frmailto:pierre.bourgin@free.fr> a écrit :
On 06/08/2016 10:25 AM, Wallace wrote: J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office.
donc ça ne viendrait pas de l'OS mais de la "plateforme matérielle" ? Ceci suppose que OS=SystemRescueCD ne subit *aucun* effet de bord dû au contenu du disque, genre discovery de partition ou de LVM, toussa.
"Plateforme matérielle": je vérifierais l'intégrité du fichier de "BIOS" et les settings dans le fichier de paramétrage.
Tu pourrais aussi reconstruire la VM: - VM vierge + isolation réseau - copie + pointage des disques de la VM pourrie - injection des autres paramétrages un par un
Ca permet de travailler "tranquillement" sur une copie.
Pierre _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello, Je me permet d'ajouter ma pierre. Ton probleme semble bien venir de vmware et pas de Debian. Pas du fs non plus d'apres les differents messages. Je dirai que cela vient d'une reservation/limitation de ressources. Regarder les options avancées de ta VM pour verifier ce point.
Si tu ne trouves pas. Creer une nouvelle VM sans HDD et la faire pointer vers le HDD de celle-ci (apres l'avoir éteinte bien sur.)
Cordialement
Le 8 juin 2016 à 13:16, VAILLEAU Olivier Olivier.VAILLEAU@ch-sevrey.fr a écrit :
Le type de controlleur disque n’aurait pas été modifié ?
Bien vérifier ce qui est compatible entre ton os et la version de l‘esx.
Y’a pas eu d’évolution sur la version du hardware virtuel ?
Cordialement,
*Olivier VAILLEAU*
Responsable Systèmes
Centre Hospitalier William Morey - Tél : 03 85 91 00 07
Centre Hospitalier spécialisé de Sevrey - Tél : 03 85 92 82 94
*De :* FRsAG [mailto:frsag-bounces@frsag.org] *De la part de* Jerome Lien *Envoyé :* mercredi 8 juin 2016 12:47 *À :* Pierre Bourgin *Cc :* French SysAdmin Group *Objet :* Re: [FRsAG] ESXi VM comportement mémoire étrange
Je conseillerais de faire l'explication de pierre en rajoutant comme guest os "other" + une copie du vmdk sans les autres fichier pour mettre de côté un problème de comportement du coté vmware. J'ai eu un problème semblable mais au niveau cpu avec un centos ou les ressources cpu était multiplié par 10 (virtuellement)
Le 8 juin 2016 11:41 AM, "Pierre Bourgin" pierre.bourgin@free.fr a écrit :
On 06/08/2016 10:25 AM, Wallace wrote:
J'ai tenté de démarrer sur un iso de systemrescuecd le souci est le même la machine a aussi un peu plus de 4Go de ram utilisé d'office.
donc ça ne viendrait pas de l'OS mais de la "plateforme matérielle" ? Ceci suppose que OS=SystemRescueCD ne subit *aucun* effet de bord dû au contenu du disque, genre discovery de partition ou de LVM, toussa.
"Plateforme matérielle": je vérifierais l'intégrité du fichier de "BIOS" et les settings dans le fichier de paramétrage.
Tu pourrais aussi reconstruire la VM:
- VM vierge + isolation réseau
- copie + pointage des disques de la VM pourrie
- injection des autres paramétrages un par un
Ca permet de travailler "tranquillement" sur une copie.
Pierre _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
Je me permet de donner une idée au hasard (enfin pas tant que ça) : es-tu sur du MP (physique) avec par ex 2 core i5 et une configuration bâtarde type : un CPU a plus de RAM que l'autre ? En général ESXi laisse pas passer ce genre de choses à l'install, mais ceci pourrait être la raison du comportement suspect : NUMA.
Sans avoir plus d'information: hardware réél utilisé, type de ESXi (eg version avec ou sans vcenter), utilisation en terme de ressources etc... on peux difficilement t'aider.
My 0,02€ Xavier
Bonjour, Pour parler infra, on a 4 hosts ESXi 5.5 avec vcenter sur un serveur à part. Ils ont chacun un CPU physique Xeon avec 8 core réels, 64Go de ram, SAN à part. Les hosts sont à 30% d'usage cpu, 50% ram.
Pour faire un point sur mes tests, j'ai stoppé la vm concernée, testé de mettre "OS autre" puis revenu sur Debian 64bits. Créé une vm vide en attachant les disques de la vm concernée, même effet. Pas de profil de réservation de ressources, je l'ai mis en dehors de tous les pool de ressources pour être sur.
Le 12/06/2016 22:03, Xavier Beaudouin a écrit :
Hello,
Je me permet de donner une idée au hasard (enfin pas tant que ça) : es-tu sur du MP (physique) avec par ex 2 core i5 et une configuration bâtarde type : un CPU a plus de RAM que l'autre ? En général ESXi laisse pas passer ce genre de choses à l'install, mais ceci pourrait être la raison du comportement suspect : NUMA.
Sans avoir plus d'information: hardware réél utilisé, type de ESXi (eg version avec ou sans vcenter), utilisation en terme de ressources etc... on peux difficilement t'aider.
My 0,02€ Xavier
Liste de diffusion du FRsAG http://www.frsag.org/
Peux tu faire un test hors environnement ESXi 5.5 ? un esxi de dev en 6 ou alors un workstation ?
Le 13 juin 2016 à 15:35, Wallace wallace@morkitu.org a écrit :
Bonjour, Pour parler infra, on a 4 hosts ESXi 5.5 avec vcenter sur un serveur à part. Ils ont chacun un CPU physique Xeon avec 8 core réels, 64Go de ram, SAN à part. Les hosts sont à 30% d'usage cpu, 50% ram.
Pour faire un point sur mes tests, j'ai stoppé la vm concernée, testé de mettre "OS autre" puis revenu sur Debian 64bits. Créé une vm vide en attachant les disques de la vm concernée, même effet. Pas de profil de réservation de ressources, je l'ai mis en dehors de tous les pool de ressources pour être sur.
Le 12/06/2016 22:03, Xavier Beaudouin a écrit :
Hello,
Je me permet de donner une idée au hasard (enfin pas tant que ça) : es-tu sur du MP (physique) avec par ex 2 core i5 et une configuration bâtarde type : un CPU a plus de RAM que l'autre ? En général ESXi laisse pas passer ce genre de choses à l'install, mais ceci pourrait être la raison du comportement suspect : NUMA.
Sans avoir plus d'information: hardware réél utilisé, type de ESXi (eg version avec ou sans vcenter), utilisation en terme de ressources etc... on peux difficilement t'aider.
My 0,02€ Xavier
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Je n'ai pas cela sous la main, aucune infra en 6 pour le moment et pas de Workstation sur nos postes Linux on marche plutôt à Virtualbox ou Docker.
Le 13/06/2016 15:54, Jerome Lien a écrit :
Peux tu faire un test hors environnement ESXi 5.5 ? un esxi de dev en 6 ou alors un workstation ?
Le 13 juin 2016 à 15:35, Wallace <wallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
Bonjour, Pour parler infra, on a 4 hosts ESXi 5.5 avec vcenter sur un serveur à part. Ils ont chacun un CPU physique Xeon avec 8 core réels, 64Go de ram, SAN à part. Les hosts sont à 30% d'usage cpu, 50% ram. Pour faire un point sur mes tests, j'ai stoppé la vm concernée, testé de mettre "OS autre" puis revenu sur Debian 64bits. Créé une vm vide en attachant les disques de la vm concernée, même effet. Pas de profil de réservation de ressources, je l'ai mis en dehors de tous les pool de ressources pour être sur. Le 12/06/2016 22:03, Xavier Beaudouin a écrit :Hello, Je me permet de donner une idée au hasard (enfin pas tant que ça) : es-tu sur du MP (physique) avec par ex 2 core i5 et une configuration bâtarde type : un CPU a plus de RAM que l'autre ? En général ESXi laisse pas passer ce genre de choses à l'install, mais ceci pourrait être la raison du comportement suspect : NUMA. Sans avoir plus d'information: hardware réél utilisé, type de ESXi (eg version avec ou sans vcenter), utilisation en terme de ressources etc... on peux difficilement t'aider. My 0,02€ Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Wallace wallace@morkitu.org : [...]
Je sèche si vous aviez des conseils je suis preneur, grand merci par avance.
Commencer par imposer la vérification des systèmes de fichier de la VM - même s'ils semblent cohérents - depuis un système tiers puis se farcir la section de la page de man de systemd relative aux paramètres de ligne de commande du noyau pour faire progresser systemd une étape après l'autre si les symptômes persistent.
Au pif: système de fichiers moisi ou absent.
-
Alarig Le Lay -
Alexandre -
Francois Romieu -
Jerome Lien -
Pierre Bourgin -
Sébastien FOUTREL -
VAILLEAU Olivier -
Wallace -
Xavier Beaudouin