Bienvenue sur ILoveBlueScreen.org

Ce blog est rédigé par Alexandre Breniaux.

  • Links

  • Categories

  • Meta

  • Archives

  • MENU DE NAVIGATION

    Problème de souris sous VMware ESX

    J’ai recontré un problème de souris lors d’une conversion de machine physique en machine virtuelle.

    J’ai converti un serveur physique à l’aide de VMware Converter Standalone 4.0.1 vers un serveur ESX 4.1.

    Lorsque j’ai démarré mon serveur virtuel, je ne pouvais plus effectué de click avec ma souris.

    J’ai résolu le problème en relançant la conversion sans installer les VMwaretools automatiquement sur ma machine virtuelle, puis en les installant manuellement une fois la conversion terminée.

    L’erreur que je décris est apparue sur un contrôleur de domaine Windows 2003 Serveur R2 en version française.

    Je n’ai pas pu terminer  l’installation du logiciel VMware Converter Standalone Client 4.0.1 car une erreur m’indiquait que je ne possédais pas les droits suffisants pour démarrer le service vmware-convert-server.

    L’erreur retournée(event id 11920) dans le journal d’événements windows est la suivante:

    Après quelques recherches sur internet, j’ai résolu le problème en créant un groupe nommé « Domain Admins » et en y intégrant mon compte administrateur.

    Le problème se pose apparament avec les versions non anglaises de 2003 server lorsque celui ci est contrôleur de domaine.

    Le service vmware-controler-server nécessiterait le droit Domain Admins pour fonctionner, qui dans une version française sera nommé Administrateur du domaine.

    Une alternative à la création de ce groupe serait de télécharger la version 3.x sur le site de VMware, cette solution semble fonctionner mais je ne l’ai pas testée étant donné que la création du groupe « Domain Admin » a résolu mon problème.

    J’ai eu la douce joie de redémarrer mon PC avec un joli message d’erreur qui me disais que l’explorateur s’était arreté et qu’il devait redémarrer.

    La cerise sur le gâteau c’est que l’erreur se répétait toute les 10 secondes…

    Je me connecte donc en mode sans échec et là magie, plus d’erreur!

    Je fais un coup de MSCONFIG, supprime les services autres que les services windows puis redémarre en Clean boot comme le conseil Microsoft, mais pas de chance, l’erreur s’accroche !

    Un petit tour sur google et je tomber sur cet article:

    http://social.answers.microsoft.com/Forums/en-US/w7files/thread/b46503e8-8875-4e68-b3c4-793a874d11ad/?prof=required

    qui décrit exactement la bonne méthode pour résoudre ce problème.

    Si vous ne voulez pas lire l’article, tapez simplement la commande suivante dans l’exécuteur et validez:

    reg delete HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions /v MachineThrottling /f

    Après un redémarrage tout devrait rentrer dans l’ordre.

    Sur le serveur ESX entrez en mode console en tant qu’utilisateur root (ALT+F1):

    root@servername#passwd

    Et saisissez le nouveau mot de passe.

    Sur le serveur ESX entrez en mode console en tant qu’utilisateur root (ALT+F1).

    Editez le fichier de configuration de SSH :

    root@servername#vi /etc/ssh/sshd_config

    Trouvez la ligne se nommant PermitRootLogin no et remplacez la par PermitRootLogin yes.

    Sauvegardez et quittez( :wq)

    Redémarrez le service SSH pour appliquez les modifications.

    root@servername#service sshd restart

    Ouvrez les ports du firewall afin de garantir la communication via SSH :

    root@servername#esxcfg-firewall -e sshServer
    root@servername#esxcfg-firewall -e sshClient

    Vous pouvez prendre la main sur votre serveur ESX  via un client SSH(putty est un excellent choix…).

    Ouvrez le serveur  ESX 4.x en mode console (ALT+F1).

    Authentifiez vous en tant que root.

    Saisisez ensuite la commande suivante:

    root@servername#console-setup

    Il vous est proposez un menu comprenant 6 choix qui se présentent de la manière suivante:

    1. Show Current Service Consoles
    2. Show Network Adapters
    3. Show vSwitch/vDS Information
    4. Delete Service Console
    5. Configure Service Console
    6. Exit
    Pour modifiez l’interface vswif0  sélectionnez le choix numéro 5 puis validez.
    Vous arrivez dans un nouveau menu qui se présente selon cette forme:
    5.1 vswif ID, default to vswif0
    5.2 Name of service console port group: default to “Service Console”
    5.3 vSwitch for service console, default to vSwitch0
    5.4 IP Address:
    5.5 Subnet mask:
    5.6 Default gateway:
    5.7 VLAN ID: default to 0
    5.8 vmnic to use for the service console
    5.9 Save Changes
    5.10 Return to Menu
    Choix 4
    Input ‘DHCP’ or a static IP Address []:a.b.c.d
    a.b.c.d étant l’adresse ip que vous souhaitez attribuer à votre interface service console
    Choix5
    Input subnet mask []: e.f.g.h
    e.f.g.h étant le masque de sous réseau de cette interface
    Choix6
    Input default gateway []:i.j.k.l
    i.j.k.l étant l’adresse de la passerelle par défaut.
    Choix 8:
    Input vmnic to use with service console [] : vmnicx
    x représentant le numéro de carte réseau  sur laquelle vous souahitez définir le service console(par défaut 0)
    Choix 9
    ALL REMOTE CONSOLE CONNECTIONS WILL BE LOST!!
    Yes
    Choix 10
    Choix 6
    Votre interface est à présent configurée.

    Ouvrez le serveur  ESX 4.x en mode console (ALT+F1).

    Authentifiez vous en tant que root.

    Supprimez  la  configuration existante de la carte service console:

    root@servername#esxcfg-vswif -d vswif0

    Ne tenez pas compte du message d’avertissement, la commande supprime la configuration actuelle.

    Pour paramétrez l’adresse ip exécutez ensuite cette commande en la modifiant selon votre réseau :

    root@servername#esxcfg-vswif -i <a.b.c.d> -n <w.x.y.z> vswif0

    a.b.c.d représente votre adresse ip fixe et w.x.y.z son masque de sous réseau.

    Saisisez ensuite le nom que vous allez donnez à l’interface

    root@servername#hostname newname

    Editez ensuite le fichier /etc/hosts et modifiez le afin de le complétez avec la nouvelle adresse et le nom d’hôte nouvellement modifiés:

    root@servername#vi /etc/hosts

    Pour éditer tapez « i »

    Ajoutez la ligne suivante au fichier:

    a.b.c.d newname

    a.b.c.d représentant la nouvelle adresse ip et newname votre nouveau nom d’hôte

    Sauvegardez et quittez l’éditeur (:wq)

    Il ne vous reste maintenant qu’à changer l’adresse ip de la  passerelle par défaut en éditant le fichier suivant:

    root@servername#vi /etc/sysconfig/network

    « i » pour éditez le fichier

    Remplacez HOSTNAME=localhost par HOSTNAME=newname

    Renseignez  la passerelle en ajoutant la ligne

    GATEWAY=a.b.c.d

    avec a.b.c.d étant l’adresse ip de la passerelle

    Sauvegardez et quittez.(:wq)

    Relancez ensuite les services réseau :

    root@servername#service network restart

    Vérifiez que tout fonctionne:

    root@servername#esxcfg-vswif -l

    Vous pouvez à présent vous reconnectez sur votre serveur via vSphere Client ou VCENTER grâce à la nouvelle adresse ip.

    Si vous rencontrez le message d’erreur suivant en démarrant une machine virtuelle VMware:

    VMware “Cannot open the disk ‘XXXXXX.vmdk’ or one of the snapshot disks it depends on.”

    Il se peut que vous ayez endommagé un fichier .vmdk, qui est le descriptif du disque dur d’une machine virtuelle VMware.

    Le fichier présent  monserveur-flat.vmdk, correspond aux données contenues dans le disque virtuel, va vous permettre de recréer le descriptif du disque afin de relancez la machine virtuelle sans problème.

    Ouvrez Vmware en mode console, pour cela pressez Alt+f1 sur l’écran d’accueil de votre ESXi.

    Tapez unsupported

    Si vous avez correctement saisi unsupported un mot de passe administrateur vous est demandé.

    Une fois le mot de passe saisi, vous pouvez naviguer dans le volume contenant votre fichier flat-monserveur.vmdk.

    cd /vmfs/volumes/Datastorename/Servername

    Vérifiez que votre disque soit bien présent:

    ls  -ltr *.vmdk

    Récupérez le type de connexion SCI par laquelle votre disque virtuel est relié à votre machine:

    less *.vmx | grep –i virtualdev

    En principe un disque attaché en iscsi dans vmware  sera nommé “lsilogic”

    Notez la taille du disque:

    ls –l *-flat.vmdk

    Créez un descripteur temporaire de votre disque en utilisant la commande vmfkstools:

    vmkfstools –c filesize –a scsitype –d thin temp.vmdk

    filesize aura pour valeur la taille du disque trouvé plus haut et scsitype aura comme valeur lsilogic(en principe)

    Veillez à ce que  le descripteur temporaire soit bien créé:

    ls –ltr *.vmdk

    3 fichiers doivent être présents

    temp.vmdk

    temp-flat.vmdk

    monserveur-flat.vmdk

    Supprimer le fichier temp-flat.vmdk

    rm temp-flat.vmdk

    Renommez le descripteur temp.vmdk en monserveur.vmdk:

    mv temp.vmdk monserveur.vmdk

    Editez le descriptif afin qu’il pointe correctement sur le fichier monserveur-flat.vmdk  contenant les données:

    vi monserveur.vmdk

    Trouvez la ligne commençant par RW et remplacez temp-flat.vmdk avec le nom correct monserveur-flat.vmdk:

    Supprimez ensuite  la ligne ddb.thinprovisioned = « 1 » puis enregistrez le fichier et quittez vi.

    Votre machine virtuelle est prête à redémarrer.

    Plus d’infos sur le lien suivant:

    KB VMware

    Si vous tentez de désinstaller Exchange 2010, il se peut que vous rencontriez une erreur 1638 lors de la suppression du rôle Transport Hub.

    Pour pouvoir passer cette étape, il vous faut réinstaller la mise à jour cumulative d’Exchange 2010(Microsoft Exchange Rollup 4) que vous pouvez télécharger à l’adresse suivante:

    Correctif cumulatif 4 pour Exchange Server 2010 (KB982639)

    Une fois que la mise à jour est installée, vous pouvez relancer la désinstallation sans rencontrer l’erreur 1638.

    Ouvrez ADSIEDIT:

    Saisissez adsiedit.msc dans le menu exécuter

    Naviguez dans :

    Configuration > Services > Microsoft Exchange >Nom de votre Organisation Exchange>Administrative Groups> Nom du Groupe Administratif> Servers> Nom du serveur Exchange> Information Store

    Faites un click droit sur Information Store, puis séléctionnez Proprietés et éditez msExchESEPParamCacheSizeMax

    Vous devez ensuite saisir la limite de pages afin de limiter le cache de la database Exchange.

    Il faut savoir qu’Exchange 2007 fonctionne avec un cache pages de 8Ko  et Exchange 2010 avec 32Ko.

    Pour régler le cache à 4Go, ce qui correspond au fonctionnement normal de la base de données Exchange 2010, réglez le paramètre msExchESEparamCacheSizeMax sur 131072, ce qui corrsespond à 4Go=4,194.304Ko / 32Ko.

    Pour Exchange 2007, le fonctionnement normal de la base de donnée Exchange est de 8Ko, réglez  le paramètre  msExchESEparamCacheSizeMax sur 262144, 2 Go = 2.097.152 Ko / 8 Ko.

    Redémarrez le service Microsoft Exchange-Banque d’informations pour effectuer les modifications.

    « Previous Entries