PowerProtect | FLR PPDM sur la machine virtuelle Linux n'a pas pu être monté : échec de la fonction En attente d'appareil

Échec de la restauration FLR sur la machine virtuelle Linux dû à l'échec du montage des VMDKs sur la machine virtuelle et de la fonction En attente d'appareil.

FLR:mount: Mount [0/4/0 0/5/0] failed: Waiting for devices failed
FLR:mount: ====End of output from FLR Agent monitor.
FLR:mount: Waiting for devices failed
Step 'Mounting disks' done: Failed
Unmounting after mount unsuccessful: Could not mount VMDKs onto VM '' filesystems: Waiting for devices failed
PowerProtect DD System: Host = '', Storage Unit = '', Model = 'DD9900', Operating System Version = 'Data Domain OS 7.3.0.5-663138', DDBoost Version = '7.7.0.0-1002040, OperatingSystem: LinuxRedhat

Le fichier VMDM.log montre que le moteur VM Direct ne peut pas restaurer la machine virtuelle, car le montage des disques virtuels de la machine virtuelle a échoué

2022-01-21T17:25:38.643Z INFO [vproxyMonitor] [][][][TRACE_ID:ad7662b37006eb34;JOB_ID:95662004bbd4f165][] [c.e.b.v.r.s.VmdmMountService.doFailureMountTask(570)] -  MOUNT-MONITOR: Failed. Activity resource id 
State COMPLETED
Progress 100
Stats:Result:
{
  "status" : "FAILED",
  "summaries" : [ "Unmount complete" ],
  "error" : {
    "code" : "ARV0032",
    "reason" : "VM Direct engine is unable to restore the virtual machine '' on vCenter '' because the mount of the virtual machine's virtual disks was unsuccessful.",
    "detailedDescription" : "The VM Direct engine cannot complete the restore of this virtual machine because the engine is unable to complete the mount of the virtual disks.",
    "remediation" : "Review the error details and summary log in the Jobs window, or review the log files at /var/log/brs/vmdm for more detailed information to troubleshoot the issue.",
    "extendedReason" : "Could not mount VMDKs onto VM '' filesystems: Waiting for devices failed",
    "messageID" : "ARV0032",

Dans /opt/emc/vproxy/runtime/logs/recycle/vproxyd/20220121_1/mount-xxx.log, nous constatons que le datastore a été créé. Lorsque nous essayons d'ajouter les disques du datastore à la machine virtuelle, nous rencontrons des difficultés pour déterminer les volumes logiques.

Environ 2 minutes après avoir essayé de monter les disques, nous constatons que le montage échoue avec le message « Échec de la fonction En attente d'appareil ».

L'un des disques de la sauvegarde est un peu inhabituel, examiné par vProxy en tant qu'appareil « loop0 ». L'élément clé est la partition « p3 » qui n'a pas de propriété UUID (uniquement PARTUUID). La propriété UUID est l'UUID du système de fichiers, que nous nous attendons normalement à voir (dans le contexte FLR). Même une partition d'échange Linux en possède normalement une.

Lorsque toutes les partitions disposent d'une propriété UUID, l'agent (via vflrmount) met en corrélation les appareils à l'aide des valeurs UUID pour identifier les disques auxquels le vProxy est rattaché. Lorsque ce n'est pas le cas, il utilise la correspondance d'adresses SCSI, ce qui a été le cas ici. Le vProxy a rattaché les disques à l'aide des cibles 4 et 5 du contrôleur 0, mais pour une raison quelconque, le système d'exploitation de la machine virtuelle invité les a mappés aux cibles 22 et 23. Étant donné que les ID cibles ne correspondent pas, vflrmount n'a pas pu identifier les disques.

La sauvegarde (machine virtuelle d'origine) contient une partition sans UUID, ce qui fait que la machine virtuelle cible identifie les disques par ID SCSI plutôt que par UUID.  La machine virtuelle cible qui échoue présente les disques de FLR avec des ID SCSI différents de ce qui est utilisé au niveau du vCenter.  Par conséquent, les ID SCSI ne correspondent pas et les disques nécessaires ne sont pas identifiés par l'agent.

Le code vérifie explicitement les partitions d'échange Linux, et il ne possède pas ce type. De plus, FLR ne fonctionne pas avec des partitions non formatées, l'opération va donc échouer, car il n'existe aucune prise en charge de la reconnaissance ou de la manipulation de disques ou de partitions non formatés.

La meilleure solution immédiate/à court terme permettant au client de récupérer les données nécessaires sera à l'aide de l'accès instantané.

L'application d'ext2fs à la partition non formatée signifie qu'elle n'est plus « non formatée », cela devrait donc résoudre le problème, pour exécuter FLR à partir de futures sauvegardes de cette machine virtuelle.  Dans la mesure où cela ne modifie pas le contenu d'une sauvegarde passée existante, cela n'a aucun effet sur les tentatives de restauration de fichiers à partir de sauvegardes existantes qui contiennent une partition non formatée.

La seule solution de contournement définitive que nous proposons actuellement pour les sauvegardes existantes affectées consiste à utiliser l'accès instantané.