Processus de migration bloqué lors d'une migration Compute Engine

Lors de migrations depuis Compute Engine vers Google Kubernetes Engine, Migrate to Containers peut ne pas reconnaître l'UUID du disque de la VM source. Vous pouvez l'ajouter manuellement :

Chargez les journaux pour le pod à l'aide de kubectl ou de Stackdriver.
Si le message [hcrunner] - Failed to find boot partition s'affiche, suivez la procédure ci-dessous.

Remarque : hcrunner n'est utilisé que dans le flux Linux. Si vous migrez une charge de travail Windows et que les journaux stipulent la chaîne hcrunner, vous devez définir un système d'exploitation de type Windows lors de la création de la migration.
Recherchez l'UUID du disque de démarrage, qui prend la forme d'une chaîne de valeurs hexadécimales et qui est affiché dans l'un des messages. Dans l'exemple ci-dessous, l'UUID est e823158e-f290-4f91-9c3d-6f33367ae0da.
```
[util] - SHELL OUTPUT: {"name": "/dev/sdb1", "partflags": null, "parttype":
"0x83", "uuid": "<strong>e823158e-f290-4f91-9c3d-6f33367ae0da</strong>",
"fstype": "ext4"}
```
Supprimez la charge de travail existante à partir de son fichier YAML :
```
kubectl delete -f
```
Ouvrez le fichier YAML dans un éditeur de texte, puis recherchez la section nommée env.

Ajoutez les éléments suivants :

    - name: "HC_BOOTDEVICE_UUID"
      value: ""

Si le message touch: cannot touch '/vlsdata/etc/fstab': No such file or directory s'affiche, vérifiez les points suivants :
- Les charges de travail de votre pilote CSI se trouvent à l'état "OK" dans la console.
- Votre charge de travail se trouve dans le même cluster que votre déploiement Migrate to Containers.
Si l'un des messages suivants s'affiche, supprimez la requête PersistentVolumeClaim défaillante de la charge de travail, puis recréez-la.
- hcutil.Error: Failed mount -o rw None /vlsdata (32) (Output:mount: /vlsdata: special device None does not exist.
- [hcrunner] - [Errno 30] Read-only file system: '/vlsdata/rootdir/etc/dhcp/dhclient-up-hooks