Erreurs connues

Présentation

Cette page a pour objet de lister différentes erreurs pouvant être rencontrées sur un ESX et comment les résoudre.

Datastore

Échec de la création de la banque de données VMFS

Problème

En cas d'erreur du type Échec de la création de la banque de données VMFS, dans la GUI de l'ESX, se rendre dans la section Hôte -> Surveiller, onglet Journaux, journal /var/log/hostd.log.

Un message d'erreur dans ce journal du type Can't have overlapping partitions est synonyme d'une tentative d'écriture d'une partition par-dessus d'autres déjà existantes. En analysant un peu plus le fichier de log, juste au dessus de la ligne d'erreur, il y a la table de partition qu'a tentée d'écrire l'ESXi sur le disque :

Console SSH

-->  Output: gpt
--> 0 0 0 0
--> 10 2048 3891556352 AA31E02A400F11DB9590000C2911D1B8 0
--> 1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B 128
--> 5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 0
--> 6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 0
--> 7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 0
--> 8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 0
--> 9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 0
--> 2 7086080 1885988864 EBD0A0A2B9E5443387C068B6B72699C7 0
-->
-->  Error : Error: Can't have overlapping partitions.

Et un peu plus loin, toujours dans le même fichier de log, il y a le détail de la partition qu'a tentée d'écrire l'ESXi sur le disque :

Console SSH

-->    vmfs = (vim.host.VmfsVolume.Specification) {
-->       extent = (vim.host.ScsiDisk.Partition) {
-->          diskName = "t10.ATA_____HGST_HUS726020ALA610____________________K5GU6LZA____________",
-->          partition = 10
-->       },

Ainsi, on constate que la partition 10 veut démarrer son espace disque au block 2048 pour finir au block 3891556352. Ceci n'est pas cohérent car le block 2048 fait déjà partie de la partition 1.

Ceci est un bug VMware. Ce bug n'a pas encore été répertorié dans VMware.

Solution

Ce bug n'étant pas répertorié chez VMware, il n'y a donc pas de solution officielle.

Toutefois, une solution de contournement existe. Elle consiste à réécrire en ligne de commande la table des partitions du disque en question.

Pour ce faire, il suffirait, par exemple, d'utiliser l'utilitaire partedUtil pour créer une partition VMFS dans la table GPT du disque.

Or, le disque en question est celui sur lequel se trouve les fichiers de l'OS de l'ESXi. La table est donc en lecture seule et en cas de tentative de création de partition du genre :

Console SSH

partedUtil setptbl "/vmfs/devices/disks/vml.01000000004b354755364c5a41202020202020202020202020484753542048" gpt "10 15472640 3907026944 AA31E02A400F1
1DB9590000C2911D1B8 0"

Une erreur du genre Read-only file system apparaîtrait :

Console SSH

gpt
0 0 0 0
10 15472640 3907026944 AA31E02A400F11DB9590000C2911D1B8 0
Error: Read-only file system during write on /dev/disks/t10.ATA_____HGST_HUSxxxxxxxxxxxxxxx____________________xxxxxxxx____________
SetPtableGpt: Unable to commit to disk

Ainsi, sur certains forums, certains ont remarqué qu'en forçant la suppression du core dump, cela permettait à l'ESXi de créer le datastore.

Pour ce faire, identifier le core dump avec la commande :

Console SSH

[root@xxxxxxx:~] esxcli system coredump partition get
   Active: t10.ATA_____HGST_HUSxxxxxxxxxxxxxxx____________________xxxxxxxx____________:9
   Configured: t10.ATA_____HGST_HUSxxxxxxxxxxxxxxx____________________xxxxxxxx____________:9

Désactiver ensuite le coredump :

Console SSH

[root@xxxxxxx:~] esxcli system coredump partition set --enable false

Supprimer la partition du coredump :

Console SSH

[root@xxxxxxx:~] partedUtil delete /dev/disks/t10.ATA_____HGST_HUSxxxxxxxxxxxxxxx____________________xxxxxxxx____________ 9

Se rendre ensuite dans la GUI de l'ESXi et créer le datastore normalement. L'erreur ne devrait plus apparaître.