Pour activer l'accès à la console virtuelle de ESX en SSH, il suffit de s'authentifier sur la machine physique (touche F2) et d'aller dans le menu Troubleshooting Options, puis d'activer SSH.
Il est également possible d'activer SSH depuis vphere dans configuration / profil de sécurité
## VMDK
Les fichiers VMDK sont des disques virtuels pour VMware.
<http://sanbarrow.com/vmdk-handbook.html>
Note préalable : pour naviguer dans un "datastore" il est préférable d'utiliser WinSCP plutôt que le "Navigateur de datastore" intégré qui ne nous montre pas exactement la réalité.
Par exemple, avec une machine virtuelle Linux sur un ESXi 4.1, on a :
* Un fichier foo.vmdk (de moins d'1 Ko) contenant des infos sur le disque virtuel :
Lors d'une copie d'un disque virtuel, il faut copier ces 2 fichiers.
## Performances
Quelques "astuces" :
* Attention, dans vSphere les graphes de performance disque sont notés en Kbps MAIS il s'agit en fait de Ko/s !!
* Les performances en utilisant SCP via SSH sont déplorables (environ 9 Mo/s). Via <http://www.veeam.com/vmware-esxi-fastscp.html>
## Réseau
* Les adresses MAC des interfaces réseau sont générées automatiquement. ATTENTION, un mode manuel est possible (et même conseillé si l'on souhaite basculer de machine sans utiliser Vmotion) MAIS l'on devra mettre dès le départ une adresse MAC manuellement pour pouvoir la repréciser sur un autre ESXi. En effet, les plages d'adresses MAC automatiques et manuelles sont différentes.
* Les cartes réseau Intel ne sont parfois pas reconnues par défaut (!!). Il faut installer un driver. Pour cela, on récupère le modèle de la carte via `lspci` + `lspci -n` et le site <http://pci-ids.ucw.cz>
Ensuite, il faut aller télécharger le driver sur <http://downloads.vmware.com/d/#drivers_tools> on récupère alors un driver au format .zip
On doit enstuie passer l'ESXi en mode maintenance puis exécuter en SSH :
Si un diqsque SCSI géré par VMware a été étendu, pour que l'hôte Linux puisse precevoir son agrandissement, sans avoir a le redémarrer, on peux forcer le scan de ce périphérique avec les commandes suivantes :
Starting VMware Tools services in the virtual machine:
Switching to guest configuration: done
Paravirtual SCSI module: done
Guest memory manager: done
VM communication interface: done
VM communication interface socket family: done
Guest operating system daemon: done
The configuration of VMware Tools 4.0.0 build-256968 for Linux for this running
kernel completed successfully.
You must restart your X session before any mouse or graphics changes take
effect.
You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an X server session.
To enable advanced X features (e.g., guest resolution fit, drag and drop, and
file and text copy/paste), you will need to do one (or more) of the following:
1. Manually start /usr/bin/vmware-user
2. Log out and log back into your desktop session; and,
3. Restart your X session.
Enjoy,
--the VMware team
Found VMware Tools CDROM mounted at /mnt. Ejecting device /dev/hda ...
# reboot
~~~
## vCLI VMware vSphere CLI
C'est un outil qui permet d'administrer un ESX en CLI.
### Installation
Le télécharger sur le site de VMware : <http://communities.vmware.com/community/vmtn/server/vsphere/automationtools/vsphere_cli>
Décompresser l'archive tar.gz, créer un fichier /etc/tmp-release avec à l'intérieur «ubuntu» pour faire croire que l'on est sur une Ubuntu. (L'installeur ne gère que Red Hat, Suse et Ubuntu).
<http_proxy> not set. please set environment variable '<http_proxy'> e.g. export
<http_proxy=http://myproxy.mydomain.com:0000> .
ftp_proxy not set. please set environment variable 'ftp_proxy' e.g. export
ftp_proxy=<http://myproxy.mydomain.com:0000>
~~~
Modifier dans le script
~~~
if ( !( $ftpproxy && $<httpproxy))> {
uninstall_file($gInstallerMainDB);
exit 1;
}
~~~
par
~~~
if ( !( $ftpproxy && $<httpproxy))> {
#uninstall_file($gInstallerMainDB);
#exit 1;
}
~~~
### Configuration
Le but est de créer un fichier de configuration pour s'authentifier sans passer à chaque fois l'adresse IP, le login et le mot de passe. Pour cela il suffit de créer un fichier texte avec les informations suivantes :
~~~
VI_SERVER = 192.168.0.10
VI_USERNAME = root
VI_PASSWORD = UberPass
VI_PROTOCOL = <https>
VI_PORTNUMBER = 443
~~~
Ensuite on pourra spécifier ce fichier lors de l'exécution des commandes, comme esxcli.
~~~
esxcli --config vmware.cfg network ip interface list
~~~
### top / stats
Stats I/O (iotop like) :
~~~
TERM=xterm esxtop
puis v
puis L 36 Entrée
~~~
### Étendre une partition VMFS
1. Récupérez l’ID et secteurs de la partition VMFS. Ici, c’est l’ID 3, début au secteur 10229760 et fin au secteur 860050190.
Et voilà, et en plus c’est à chaud, il suffira de cliquer sur ré-analyser dans le gestionnaire de disques (de vSphere) pour voir apparaître la nouvelle taille !
Disponible à partir de VMware vSphere 6.7, le DRS est la méthode par laquelle VMware permet l'automatisation de la répartition des ressources entre plusieurs hyperviseurs, dans le but d'équilibrer la charge sur ces hyperviseurs. Il est défini par cluster vSphere et peut avoir 3 modes (assumant qu'il soit actif):
* automatique : les VM sont réparties automatiquement au démarrage et peuvent être migrées automatiquement entre hyperviseurs pour répartir la charge,
* semi-automatique : les VM sont réparties automatiquement au démarrage. Si VMware pense qu'une migration devrait être faite pour répartir la charge, une recommandation est donné à l'utilisateur qui peut décider de l'appliquer ou non,
* manuelle : VMware ne fait que donner des recommandations de répartition de charge.
Si le DRS est activé globalement, il est possible de le désactiver pour certaines VM uniquement (ou inversement : le désactiver partout sauf pour certaines) :
* Depuis le cluster, onglet "Configure", sous "Configuration", cliquer sur "VM Overrides" > "Add..."
* Sélectionner les VM pour lesquelles on veut appliquer une modification particulière
* Sélectionner l'option à modifier pour ces VM : cocher Override pour "DRS automation level", et choisir le niveau voulu
Il est possible de définir des affinités entre VMs et hyperviseurs pour dire à VMware de préférer faire tourner un groupe de VM sur un groupe d'hyperviseurs ou d'éviter de faire tourner un groupe de VM sur un groupe d'hyperviseurs. Pour ce faire il faut :
Il est possible de définir des affinités entre VMs pour dire à VMware qu'elles devraient tourner sur des hyperviseurs différent (autant que possible) ou sur le même hyperviseur. Pour ce faire il faut :
* Sélectionner le type correspondant à ce qui est voulu entre "Keep Virtual Machines Together" (faire tourner sur un même hyperviseur) et "Separate Virtual Machines" (faire tourner sur des hyperviseurs différents)
Disponible à partir de VMware vSphere 6.7, le SDRS est la méthode par laquelle VMware permet l'automatisation de la répartition des ressources entre plusieurs Datastores, dans le but d'équilibrer l'espace disponible. Pour l'utiliser il faut définir un "Datastore Cluster" (c'est fait au niveau du datacenter) avec les datastores sur lesquels répartir la charge. Il est possible de choisir les seuils de migration et si les migrations devraient aussi se faire pour des questions de performance.
> Note : Ajouter des datastores déjà utilisés peut ajouter des Overrides qu'il peut être nécessaire de supprimer (depuis le du "Datastore cluster", dans l'onglet "Configure", sous "Configuration", cliquer sur "VM Overrides")
> Note : Si des disques sont dans le mode "Independent - Persistent" ou "Independent - Non-Persistent" alors SDRS ne peut pas fonctionner pour la machine.
Il est possible de dire à VMware qu'un groupe de VM devrait avoir leurs données dans des datastore différents autant que possible. Pour ce faire il faut :
Lors d'un (re)démarrage d'une VM il se peut que vous obteniez un message d'erreur du type « This operation would violate a virtual machine affinity/anti » et que le machine ne démarre pas.
Ça signifie qu'une règle d'affinité empèche son démarrage. Par exemple si vous avez un groupe de 3 VM qui on comme rêgle de chacune tourner sur des hôtes différents mais que vous avez seulement 2 hôte alors vsphere vous empéchera de demarer une 3eme VM car tous les hyperviseurs ont déjà une VM de ce groupe en cours d'execution.
Dans ce cas là on peut temporairement désactiver la règle d'affinité pour que vsphere nous laisse démarrer la machine. Il est possible de rétablir la règle d'affinité, une fois la machine lancée, sans générer d'erreur ou de message supplémentaire.