Ce paramètre est à configurer au niveau de la VM. Vous devez pour cela modifier le fichier vmx en ajoutant/modifiant le propriété workingDir.
Vous devrez arrêter la VM pour réaliser l'opération et prendre en charge la modification
Exemple:
workingDir="/vmfs/volumes/4b7d3e11-5ef2ab42-5169-11aef34d5f63/"
Les autres fichiers (vmdk, vmx, vswap, ...) ne changeront pas d'emplacement, seulement l'emplacement des fichiers de snapshots utiliseront ce paramètre.
Pour ma part, ce paramètre m'a permis de pouvoir réaliser la maintenance d'un serveur qui se trouvait sur un datastore quasi full. J'avais besoin de créer un snapshot pour pouvoir faire un retour arrière rapide et de ne pas risquer de stopper la VM pendant la maintenance si le snapshot remplissait le datastore.
gVirtual Blog
mardi 27 décembre 2011
ESXi command line
Ci-dessous une liste des commandes que j'utilise couramment pour faire des manipulations sur les machines virtuelles :
- Lister les machines virtuelles enregistrées sur cet hôte (vous permet d'obtenir le vmid qui sera nécessaire pour les autres commandes)
vim-cmd /vmsvc/getallvms
- Désenregistrer une VM
vim-cmd /vmsvc/unregister [vmid]
- Enregistrer une VM
vim-cmd /solo/register [/path/to/file.vmx]
- Obtenir l'état d'une VM
vim-cmd /vmsvc/power.getstate
[
vmid] - Arrêter une VM
vim-cmd /vmsvc/power.off
[
vmid] - Démarrer une VM
vim-cmd /vmsvc/power.on
[
vmid]
dimanche 14 février 2010
Problème P2V Windows NT4
Lors de la migration d’une VM sous VMware Server vers un ESXi 4, la VM consommée 100 % du CPU ce qui entrainait une alerte.
Après quelques recherches, VMware ne supporte pas le SMP sur les machines virtuelles Windows NT 4.
La VM avait 2 vCPU mais le passage à 1 vCPU ne résout pas pour autant le problème.
J’ai appris qu’il y avait plusieurs versions de HAL (Hardware Abstraction Layer) et que la VM en question n’utilisé pas la bonne.
Sur les communautés VMware, il est conseillé de charger la DLL halapic.dll qui se trouve dans le SP6a de Windows NT4 ainsi que le Kernel ntoskrnl.exe.
Après avoir récupérés et copiés ces fichiers dans le répertoire system32 (ntoskrnl.exe existe peut-être déjà, renommé le fichier copier en ntkrnl.exe par ex.), modifier à présent le fichier boot.ini.
Rajouter la ligne en gras :
[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00 VM" /HAL=halapic.dll /KERNEL=ntkrnl.exe /NUMPROC=1
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00"
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00 [VGA mode]" /basevideo /sos
Redémarrer la machine et constater le changement.
Sources :
http://communities.vmware.com/thread/37856
http://support.microsoft.com/default.aspx?scid=kb;en-us;156358&sd=tech
Après quelques recherches, VMware ne supporte pas le SMP sur les machines virtuelles Windows NT 4.
La VM avait 2 vCPU mais le passage à 1 vCPU ne résout pas pour autant le problème.
J’ai appris qu’il y avait plusieurs versions de HAL (Hardware Abstraction Layer) et que la VM en question n’utilisé pas la bonne.
Sur les communautés VMware, il est conseillé de charger la DLL halapic.dll qui se trouve dans le SP6a de Windows NT4 ainsi que le Kernel ntoskrnl.exe.
Après avoir récupérés et copiés ces fichiers dans le répertoire system32 (ntoskrnl.exe existe peut-être déjà, renommé le fichier copier en ntkrnl.exe par ex.), modifier à présent le fichier boot.ini.
Rajouter la ligne en gras :
[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00 VM" /HAL=halapic.dll /KERNEL=ntkrnl.exe /NUMPROC=1
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00"
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00 [VGA mode]" /basevideo /sos
Redémarrer la machine et constater le changement.
Sources :
http://communities.vmware.com/thread/37856
http://support.microsoft.com/default.aspx?scid=kb;en-us;156358&sd=tech
lundi 21 décembre 2009
Configuration JumboFrames & Multipathing sur ESXi 4
Et oui, le jumbo frame est supporté sur VMware ESXi 4 pour les VMKernel. Il s'agit d'une bonne nouvelle pour ceux qui ont une baie SAN iSCSI supportant ce type de trame.
Jusqu'à présent le doute régné sur le support ou non de cette techno sur la version allégée de l'hyperviseur, j'ai retrouvé ce weekend sur un blog des communities VMware l'info qui affirme que c'est possible et supporté contrairement à ce qu'affirme la doc. (http://blogs.vmware.com/esxi/2009/12/esxi-40-supports-jumbo-frames.html).
Bonne nouvelle, donc, à présent passons à la configuration... Pour commencer, il vous faudra VMware vSphere CLI pour pouvoir réaliser la configuration réseau. Oui, la configuration se fait encore en ligne de commande puisque le jumbo frame (MTU 9000) n'est pas configurable via l'interface graphique.
IP du serveur ESXi : 192.168.1.10
Lancer vSphere CLI.
Création d'un vSwitch : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -a vSwitch1
Activation des jumbo frames sur le switch : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -m 9000 vSwitch1
Affecter les cartes réseaux physiques au vSwitch :
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -L vmnic4
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -L vmnic5
Création d'un port group : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN1" vSwitch1
Configuration du VMkernel (IP + Jumbo Frames):
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.10 -n 255.255.255.0 -m 9000 "VMkernel SAN1"
A l'aide des 2 dernières commande, recréer d'autre VMkernel pour la gestion du traffic SAN. J'ai 2 cartes Gigabit dédié pour le SAN et je crée en général 6 VMkernel sur lequel je configure le multipathing. Voici ce que cela donne au niveau networking :
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN2" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN3" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN4" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN5" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN6" vSwitch1
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.11 -n 255.255.255.0 -m 9000 "VMkernel SAN2"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.12 -n 255.255.255.0 -m 9000 "VMkernel SAN3"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.13 -n 255.255.255.0 -m 9000 "VMkernel SAN4"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.14 -n 255.255.255.0 -m 9000 "VMkernel SAN5"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.15 -n 255.255.255.0 -m 9000 "VMkernel SAN6"
Ensuite, je désactive une des cartes physiques sur 3 VMkernel et l'autre carte sur les 3 autres.
Pour cela :
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN1" -N vmnic5 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN2" -N vmnic5 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN3" -N vmnic5 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN4" -N vmnic4 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN5" -N vmnic4 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN6" -N vmnic4 vSwitch1
Voici le résultat de la commande : pour le VMkernel SAN1, la carte vmnic5 est désactivé.
Ensuite on réalise un bind des VMkernel sur l'iSCSI initiator :
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk2 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk3 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk4 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk5 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk6 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk7 -d vmhba33
Vous retrouverez les infos concernant l'ID du VMkernel et de l'iSCSI initiator via le client vSphere.
Aprés ces opérations, vous pouvez vérifier la configuration à l'aide des commandes suivantes :
Pour vérifier le vSwitch : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -l
Pour vérifier les VMkernel : \bin\esxcfg-vmknic.pl --server 192.168.1.10 -l
Il ne reste plus qu'à configurer l'iSCSI initiator pour l'accès à la baie SAN.
Jusqu'à présent le doute régné sur le support ou non de cette techno sur la version allégée de l'hyperviseur, j'ai retrouvé ce weekend sur un blog des communities VMware l'info qui affirme que c'est possible et supporté contrairement à ce qu'affirme la doc. (http://blogs.vmware.com/esxi/2009/12/esxi-40-supports-jumbo-frames.html).
Bonne nouvelle, donc, à présent passons à la configuration... Pour commencer, il vous faudra VMware vSphere CLI pour pouvoir réaliser la configuration réseau. Oui, la configuration se fait encore en ligne de commande puisque le jumbo frame (MTU 9000) n'est pas configurable via l'interface graphique.
IP du serveur ESXi : 192.168.1.10
Lancer vSphere CLI.
Création d'un vSwitch : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -a vSwitch1
Activation des jumbo frames sur le switch : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -m 9000 vSwitch1
Affecter les cartes réseaux physiques au vSwitch :
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -L vmnic4
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -L vmnic5
Création d'un port group : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN1" vSwitch1
Configuration du VMkernel (IP + Jumbo Frames):
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.10 -n 255.255.255.0 -m 9000 "VMkernel SAN1"
A l'aide des 2 dernières commande, recréer d'autre VMkernel pour la gestion du traffic SAN. J'ai 2 cartes Gigabit dédié pour le SAN et je crée en général 6 VMkernel sur lequel je configure le multipathing. Voici ce que cela donne au niveau networking :
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN2" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN3" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN4" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN5" vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -A "VMkernel SAN6" vSwitch1
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.11 -n 255.255.255.0 -m 9000 "VMkernel SAN2"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.12 -n 255.255.255.0 -m 9000 "VMkernel SAN3"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.13 -n 255.255.255.0 -m 9000 "VMkernel SAN4"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.14 -n 255.255.255.0 -m 9000 "VMkernel SAN5"
\bin\esxcfg-vmknic.pl --server 192.168.1.10 -a -i 10.1.2.15 -n 255.255.255.0 -m 9000 "VMkernel SAN6"
Ensuite, je désactive une des cartes physiques sur 3 VMkernel et l'autre carte sur les 3 autres.
Pour cela :
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN1" -N vmnic5 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN2" -N vmnic5 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN3" -N vmnic5 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN4" -N vmnic4 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN5" -N vmnic4 vSwitch1
\bin\esxcfg-vswitch.pl --server 192.168.1.10 -p "VMkernel SAN6" -N vmnic4 vSwitch1
Voici le résultat de la commande : pour le VMkernel SAN1, la carte vmnic5 est désactivé.
Ensuite on réalise un bind des VMkernel sur l'iSCSI initiator :
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk2 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk3 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk4 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk5 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk6 -d vmhba33
\bin\esxcli.exe --server 192.168.1.10 swiscsi nic add -n vmk7 -d vmhba33
Vous retrouverez les infos concernant l'ID du VMkernel et de l'iSCSI initiator via le client vSphere.
Aprés ces opérations, vous pouvez vérifier la configuration à l'aide des commandes suivantes :
Pour vérifier le vSwitch : \bin\esxcfg-vswitch.pl --server 192.168.1.10 -l
Pour vérifier les VMkernel : \bin\esxcfg-vmknic.pl --server 192.168.1.10 -l
Il ne reste plus qu'à configurer l'iSCSI initiator pour l'accès à la baie SAN.
samedi 21 mars 2009
Alignement de bloc
S'il y a une opération à réaliser sur vos machines virtuelles afin d'accroitre les performances en I/O c'est bien l'alignement de bloc.
En effet, l'alignement de bloc permet d'économiser quelques étapes de lecture/écriture de données sur le disques.
Je vous propose deux sites, bien détaillé ou vous trouvez les explications sur le pourquoi faut-il faire ces modifications et le comment.
Site 1 : Jason Boche
Site 2 : Viops
Pour ceux qui tenterai d'aligner les partitions de ces VMs, il n'est possible de réaliser ceci que sur un disque vierge (enfin vous perdrez les infos qui sont dessus) et pour faire cela sur un disque système, il faut le faire avant l'installation de l'OS. Pour cela j'utilise un CD winpe qui me permet d'exécuter diskpart sur la partition avant l'installation de mon OS ou vous pouvez rattacher votre futur disque système à une VM Windows et faire les opérations.
En effet, l'alignement de bloc permet d'économiser quelques étapes de lecture/écriture de données sur le disques.
Je vous propose deux sites, bien détaillé ou vous trouvez les explications sur le pourquoi faut-il faire ces modifications et le comment.
Site 1 : Jason Boche
Site 2 : Viops
Pour ceux qui tenterai d'aligner les partitions de ces VMs, il n'est possible de réaliser ceci que sur un disque vierge (enfin vous perdrez les infos qui sont dessus) et pour faire cela sur un disque système, il faut le faire avant l'installation de l'OS. Pour cela j'utilise un CD winpe qui me permet d'exécuter diskpart sur la partition avant l'installation de mon OS ou vous pouvez rattacher votre futur disque système à une VM Windows et faire les opérations.
Libellés :
Alignement bloc,
VMFS,
VMware ESX,
VMware ESXi
vendredi 20 mars 2009
Installer VMware Tools - Windows 2008 R2
En mode Core, WoW64 (Windows over Windows) est devenu une option, cette fonctionnalité n'est plus installé par défaut.
Elle permet le support des applications 32 bits sous les OS 64 bits.
Pour installer WoW64 :
C:\Users\Administrator>start /w ocsetup ServerCore-WOW64
Vous devez redémarrer le système pour activer la fonctionnalité.
Après le redémarrage, vous pourrez installer VMware Tools sans problème.
jeudi 19 mars 2009
Mise à jour serveur ESXi - Retour en arrière
La mise à jour d'un serveur peut, dans certains cas, apporter son lot de problème.
Si cela vous arrive, vous pouvez toujours revenir à la version précédent l'application du patch.
Pour revenir en arrière, vous devez redémarrer la machine. Quand la barre blanche de chargement apparait appuyer sur les touches SHIFT+R.
Un message d'avertissement apparait, vous prévenant que vous allez remplacer votre version par une version plus ancienne. Appuyer sur la touche Y pour accepter.
Appuyer sur la touche Entrée.
Voila votre serveur ESXi tourne avec la version antérieur à la mise à jour.
Mise à jour serveur ESXi
Voici les différentes étapes pour mettre à jour votre serveur VMware ESXi.
1ere étape - RCLI
Il vous faut VMware Remote Client (RCLI) sur votre machine.
Vous pouvez le télécharger ici et la documentation ici.
2eme étape - Download
Récupérer les derniers updates pour votre serveur ici.
3eme étape - Update
Lancer la console RCLI ou dans un invite de commande taper : cd "C:\Program Files\VMware\VMware VI Remote CLI". (Répertoire d'installation par défaut)
Aller dans le répertoire bin.
Lancer la commande vihostupdate.pl...
Syntax :
vihostupdate.pl –server [serveur name or ip]-username [username] -password [password] -i –b [filename] Le script va décompresser le fichier ZIP, le copier sur le serveur, l'installer et enfin redémarrer le serveur.
Une fois la mise à jour terminée, on vous invite à redémarrer le serveur ESXi. Pour cela taper yes.4eme étape - Vérification
Vérifier la version du patch installé...
Syntax :vihostupdate.pl –server [serveur name or ip]-username [username] -password [password] –q
Voila, le serveur ESXi est maintenant à jour.
Activer SSH sur VMware ESXi
J'ai vu pas mal de chose à ce sujet sur d'autres blogs ou forum mais je trouve que leurs explications ne sont pas clair ou alors il y a des étapes inutiles.
Pour ma part, j'ai réalisé les actions suivantes sur un serveur ESXi Update 3 :
- Sur le serveur ESXi, taper Alt+F1.
- Taper unsupported dans la console.
- Au prompt saisir le mot de passe root du serveur.
- Ensuite taper la commande suivante : vi /etc/inetd.conf
- Rechercher la ligne dans le fichier commençant par #ssh ; Pour cela taper /ssh puis Entrée.
- Appuyer sur la touche Inser et supprimer le caractère #.
- Pour quitter vi, appuyer sur Echap et taper :wq!.
- Maintenant il faut redémarrer le service inetd. Pour cela taper /etc/services.sh restart inetd
Autre chose, si vous n'arrivez pas à rentrer dans le mode unsupported, vous devez réaliser les étapes suivantes pour que cela fonctionne.
- Connecter vous au serveur ESXi avec VI Client.
- Cliquer sur le serveur ESXi et cliquer ensuite sur l'onglet Configuration.
- Ensuite dans l'encadrer Software cliquer sur Advanced Settings.
- Dans VMkernel cocher la case VMkernel.boot.techSupportMode.
- Rédémarrer le serveur ESXi.
Remarque : Avant d'arrêter le serveur ESXi, n'oubliez pas d'éteindre les machines virtuelles qui tournent dessus.
lundi 16 mars 2009
VMware vLaunchPad
Eric Sieberg à mis en ligne un nouveau vLaunchPad. Très pratique, il regroupe différents liens vers des sites de la communauté VMware.
C'est par ici :
Inscription à :
Articles (Atom)