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.bour...@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/
