Problèmes connus

Cette page décrit les problèmes connus que vous pourriez rencontrer lors de l'utilisation de Compute Engine. Pour les problèmes qui concernent spécifiquement les Confidential VMs, consultez la section Problèmes connus de Confidential VM.

Estimation du prix indisponible lors de la création de VM Z3

Pendant la version bêta pour Z3, aucune estimation de prix n'est disponible dans la console Google Cloud. Pour connaître les tarifs associés à une VM Z3, consultez la page sur les codes SKU de Google Cloud.

Problèmes d'ordre général

Les problèmes suivants fournissent des conseils de dépannage ou des informations générales.

La création de réservations ou de demandes de réservations futures à l'aide d'un modèle d'instance qui spécifie un type de machine A2, C3 ou G2 entraîne des problèmes

Si vous utilisez un modèle d'instance qui spécifie un type de machine A2, C3 ou G2 pour créer une réservation, ou pour créer et envoyer une demande de réservation ultérieure pour examen, vous rencontrez des problèmes. à savoir :

  • La création de la réservation peut échouer. En cas de réussite, l'une des conditions suivantes s'applique :

    • Si vous avez créé une réservation utilisée automatiquement (par défaut), la création de VM avec des propriétés correspondantes n'impliquera pas la consommation de la réservation.

    • Si vous avez créé une réservation spécifique, la création de VM pour cibler spécifiquement cette réservation échoue.

  • La création de la requête de réservation future aboutit. Toutefois, si vous l'envoyez pour examen, Google Cloud refuse votre demande.

Vous ne pouvez pas remplacer le modèle d'instance utilisé pour créer une réservation ou une requête de réservation ultérieure, ni remplacer les propriétés de la VM du modèle. Si vous souhaitez réserver des ressources pour des types de machines A2, C3 ou G2, effectuez plutôt l'une des opérations suivantes :

Limites lorsque vous utilisez les types de machines c3-standard-*-lssd et c3d-standard-*-lssd avec Google Kubernetes Engine

Lorsque vous utilisez l'API Google Kubernetes Engine, le pool de nœuds auquel vous associez des disques SSD locaux que vous provisionnez doit disposer du même nombre de disques SSD que le type de machine C3 et C3D sélectionné. Par exemple, si vous envisagez de créer une VM qui utilise c3-standard-8-lssd, vous devez disposer de deux disques SSD, tandis que pour un c3d-standard-8-lssd, un seul disque SSD est requis. Si le numéro de disque ne correspond pas, vous obtenez une erreur de configuration SSD locale du plan de contrôle Compute Engine. Consultez le document Famille de machines à usage général pour sélectionner le nombre approprié de disques SSD locaux en fonction du type de machine C3 ou C3D lssd.

L'utilisation de la console Google Cloud Google Kubernetes Engine pour créer un cluster ou un pool de nœuds doté de VM c3-standard-*-lssd et c3d-standard-*-lssd entraîne l'échec de la création de nœud ou de la détection des disques SSD locaux en tant qu'espace de stockage éphémère.

Variabilité du débit TCP sur un seul flux sur les VM C3D

Les VM C3D supérieures à 30 vCPU peuvent rencontrer une variabilité de débit TCP à un seul flux et être parfois limitée à 20-25 Gbit/s. Pour atteindre des taux plus élevés, utilisez plusieurs flux TCP.

Groupe d'instances géré avec des séries de machines T2D qui ne s'adapte pas comme prévu

Les groupes d'instances gérés (MIG) qui disposent de VM de séries de machines T2D dans des projets créés avant le 18 juin 2023 ne détectent pas correctement la charge du processeur sur les VM du MIG. Dans de tels projets, l'autoscaling basé sur l'utilisation du processeur dans un MIG comportant des VM de séries de machines T2D peut être incorrect.

Pour appliquer un correctif à votre projet, contactez l'assistance Cloud Customer Care.

La métrique d'observabilité de l'utilisation du processeur est incorrecte pour les VM qui utilisent un thread par cœur

Si le processeur de votre VM utilise un thread par cœur, la métrique d'observabilité de l'utilisation du processeur de Cloud Monitoring dans l'onglet Compute Engine > Instances de VM > Observabilité n'atteint que 50 %. À l'exception de la série Tau T2D, deux threads par cœur sont utilisés par défaut pour tous les types de machines. Pour en savoir plus, consultez la section Définir le nombre de threads par cœur.

Pour afficher l'utilisation du processeur normalisée de votre VM à 100 %, affichez plutôt l'utilisation du processeur dans l'explorateur de métriques. Pour plus d'informations, consultez la page Créer des graphiques avec l'explorateur de métriques.

La console Google Cloud dans le navigateur de la console Cloud peuvent échouer si vous utilisez des règles de pare-feu personnalisées

Si vous utilisez des règles de pare-feu personnalisées pour contrôler l'accès SSH à vos instances de VM, vous ne pourrez peut-être pas utiliser la fonctionnalité SSH dans le navigateur.

Pour contourner ce problème, effectuez l'une des opérations suivantes :

Le redimensionnement ou la suppression de réservations spécifiques empêche les VM de consommer d'autres réservations

Si vous réduisez ou supprimez une réservation spécifique consommée par une ou plusieurs VM, les VM orphelines ne peuvent consommer aucune réservation.

Découvrez comment supprimer des réservations et redimensionner des réservations.

Le déplacement des VM ou des disques à l'aide de l'API moveInstance ou de gcloud CLI entraîne un comportement inattendu

Le déplacement d'instances de machines virtuelles (VM) à l'aide de la commande gcloud compute instances move ou de la méthode project.moveInstance peut entraîner une perte de données, la suppression des VM ou un autre comportement inattendu.

Pour un déplacement de VM, nous vous recommandons de suivre les instructions de la section Déplacer une instance de VM entre plusieurs zones ou régions.

Les disques associés à des VM avec des types de machines n2d-standard-64 n'atteignent pas systématiquement les limites de performances

Les disques persistants associés à des VM avec des types de machines n2d-standard-64 n'atteignent pas systématiquement la limite de performances maximale de 100 000 IOPS. Cela s'applique aussi bien aux IOPS en lecture qu'aux IOPS en écriture.

Noms temporaires des disques

Pendant les mises à jour d'instances de machines virtuelles (VM) lancées à l'aide de la commande gcloud compute instances update ou de la méthode de l'API instances.update, Compute Engine peut temporairement modifier le nom des disques de votre VM en ajoutant les suffixes suivants au nom d'origine :

  • -temp
  • -old
  • -new

Compute Engine supprime le suffixe et restaure les noms de disques d'origine à la fin de la mise à jour.

Augmentation de la latence pour certains disques persistants causée par leur redimensionnement

Dans certains cas, le redimensionnement des disques persistants volumineux (environ 3 To ou plus) peut perturber les performances d'E/S du disque. Si vous êtes concerné par ce problème, vos disques persistants peuvent connaître une latence accrue lors de l'opération de redimensionnement. Ce problème peut affecter les disques persistants de n'importe quel type.

Utiliser des images MBR avec des VM C3 dotées d'un disque SSD local

Une VM C3 créée à l'aide de c3-standard-44-lssd et de types de machines de capacité supérieure ne démarre pas correctement avec des images MBR.

Possibilité d'installer, sur des VM C3 et M3, des disques persistants standards (PD-Standard) et extrêmes (PD-Extreme) non compatibles

Les disques persistants standards (pd-standard) constituent le type de disque de démarrage par défaut lorsque vous utilisez Google Cloud CLI ou l'API Compute Engine. Toutefois, les disques pd-standard ne sont pas compatibles avec les VM C3 et M3. De plus, les VM C3 ne sont pas compatibles avec les disques pd-extreme.

Les problèmes suivants peuvent se produire lors de l'utilisation de Google Cloud CLI ou de l'API Compute Engine :

  • pd-standard est configuré en tant que type de disque de démarrage par défaut et le disque est créé, sauf si vous spécifiez un autre type de disque de démarrage compatible, tel que pd-balanced ou pd-ssd.
  • Avant la disponibilité générale de la famille C3, vous pouviez associer des disques pd-extreme à des VM C3 et des disques pd-standard à des VM C3 et M3.

Si vous avez créé une VM C3 ou M3 avec un type de disque non compatible, déplacez vos données vers un nouveau type de disque compatible, comme décrit dans la section Modifier le type de votre disque persistant. Si vous ne modifiez pas le type de disque, les VM continueront de fonctionner, mais certaines opérations telles que la dissociation et la réassociation du disque échoueront.

Solution

Pour contourner ce problème, effectuez l'une des opérations suivantes :

  • Utilisez la console Google Cloud pour créer des VM C3 ou M3 et associer des disques. La console crée des VM C3 et M3 avec des disques de démarrage pd-balanced, mais n'autorise pas l'association de types de disques non compatibles aux VM.
  • Si vous utilisez Google Cloud CLI ou l'API Compute Engine, configurez explicitement un disque de démarrage de type pd-balanced ou pd-ssd lors de la création d'une VM.

Vos processus automatisés peuvent échouer s'ils utilisent des données de réponse de l'API concernant vos quotas d'engagement basés sur les ressources

Vos processus automatisés qui consomment et utilisent des données de réponse d'API au sujet de vos quotas d'engagement basés sur les ressources Compute Engine peuvent échouer si chacun des événements suivants se produit. Vos processus automatisés peuvent inclure des extraits de code, de la logique métier ou des champs de base de données qui utilisent ou stockent les réponses de l'API.

  1. Les données de réponse proviennent de l'une des méthodes d'API Compute Engine suivantes :

  2. Vous utilisez int au lieu de number pour définir le champ de votre limite de quota de ressources dans les corps de réponse de votre API. Vous pouvez trouver le champ comme suit pour chaque méthode :

  3. Vous disposez d'un quota par défaut illimité pour tous vos codes SKU Compute Engine validés.

    Pour en savoir plus sur les quotas d'engagements et de SKU validés, consultez la page Quotas pour les engagements et les ressources validées.

Origine du problème

Lorsque vous disposez d'un quota limité, si vous définissez le champ items[].quotas[].limit ou quotas[].limit avec le type int, les données de réponse d'API pour vos limites de quota peuvent rester dans la plage de int et votre processus automatisé risque de ne pas être interrompu. Toutefois, lorsque la limite de quota par défaut est illimitée, l'API Compute Engine renvoie une valeur pour le champ limit qui se situe en dehors de la plage définie par le type int. Votre processus automatisé ne peut pas utiliser la valeur renvoyée par la méthode API et échoue donc.

Comment contourner ce problème

Vous pouvez contourner ce problème et continuer à générer vos rapports automatisés comme suit :

  • Recommandé : Suivez la documentation de référence de l'API Compute Engine et utilisez les types de données appropriés pour les définitions de la méthode API. Plus précisément, utilisez le type number pour définir les champs items[].quotas[].limit et quotas[].limit pour vos méthodes d'API.

  • Diminuez votre limite de quota à une valeur inférieure à 9 223 372 036 854 775 807. Vous devez définir des limites de quota pour tous les projets comportant des engagements basés sur les ressources, dans toutes les régions. Pour ce faire, procédez de l'une des façons suivantes :

Problèmes connus relatifs aux instances de VM Linux

Voici les problèmes connus des VM Linux.

Les VM RHEL 7 et CentOS perdent l'accès au réseau après le redémarrage

Les noms d'interface réseau prévisibles sont désactivés par défaut pour les images d'OS CentOS et Red Hat Enterprise Linux (RHEL) 7 fournies par Google.

Toutefois, si vos VM CentOS ou RHEL 7 possèdent plusieurs cartes d'interface réseau et que l'une d'entre elles n'utilise pas l'interface VirtIO, l'accès au réseau peut être perdu au redémarrage. En effet, RHEL n'est pas compatible avec la désactivation des noms d'interface réseau prévisibles si au moins une carte d'interface réseau n'utilise pas l'interface VirtIO.

Solution

Vous pouvez restaurer la connectivité réseau en arrêtant et en démarrant la VM jusqu'à ce que le problème soit résolu. Vous pouvez éviter qu'une perte de connectivité réseau ne se reproduise en procédant comme suit : 1. Modifiez le fichier /etc/default/grub et supprimez les paramètres de noyau net.ifnames=0 et biosdevname=0. 2. Générez à nouveau la configuration grub. 3. Redémarrez la VM.

Les images SUSE Google Cloud publiques n'incluent pas la configuration udev requise pour créer des liens symboliques pour les disques SSD locaux C3 et C3D.

Solution

Pour ajouter des règles udev pour SUSE et des images personnalisées, consultez la section Liens symboliques non créés C3 et C3D avec un disque SSD local.

Impossible de valider la signature repomd.xml

Sur les systèmes basés sur Red Hat Enterprise Linux (RHEL) ou CentOS 7, le message d'erreur suivant peut s'afficher lorsque vous essayez d'installer ou de mettre à jour un logiciel à l'aide de yum. Cette erreur indique que vous disposez d'une clé GPG de dépôt expirée ou incorrecte.

Exemple de journal :

[root@centos7 ~]# yum update


...

google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.

...

failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk

Solution

Pour résoudre ce problème, désactivez la vérification des clés GPG dans la configuration du dépôt yum en définissant repo_gpgcheck=0. Dans les images de base Compute Engine compatibles, ce paramètre peut se trouver dans le fichier /etc/yum.repos.d/google-cloud.repo. Toutefois, sur votre VM, il se peut que ce paramètre soit défini dans différents fichiers de configuration de dépôt ou outils d'automatisation.

Les dépôts yum n'utilisent généralement pas de clés GPG pour la validation du dépôt. Au lieu de cela, le point de terminaison https est approuvé.

Pour localiser et mettre à jour ce paramètre, procédez comme suit :

  1. Recherchez le paramètre dans votre fichier /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

  2. Remplacez toutes les lignes qui indiquent repo_gpgcheck=1 par repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

  3. Vérifiez que le paramètre a été mis à jour.

    cat /etc/yum.repos.d/google-cloud.repo

[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

Les instances utilisant OS Login renvoient un message d'erreur de connexion après la connexion

Une fois connecté à certaines instances qui utilisent OS Login, vous recevrez peut être le message d'erreur suivant :

/usr/bin/id: cannot find name for group ID 123456789

Solution

Ignorez le message d'erreur.

Problèmes connus pour les instances de VM Windows

  • Les instances exécutant Windows 11, version 22H2 ne démarrent pas. Utilisez Windows 11 version 21H2 jusqu'à ce que le problème soit résolu.
  • La compatibilité de NVMe sous Windows à l'aide du pilote NVMe de la communauté est en preview. Les performances peuvent ne pas correspondre à celles des instances Linux. Le pilote NVMe de la communauté a été remplacé par le pilote Microsoft StorNVMe dans les images publiques Google Cloud. Nous vous recommandons de remplacer le pilote NVME sur les VM créées avant mai 2022 et d'utiliser le pilote Microsoft StorNVMe à la place.
  • Une fois que vous avez créé une instance, vous ne pouvez pas vous y connecter instantanément. Toutes les nouvelles instances Windows utilisent l'outil de préparation du système (sysprep) pour leur configuration, ce qui peut prendre de 5 à 10 minutes.
  • Les images Windows Server ne peuvent pas être activées sans connexion réseau à kms.windows.googlecloud.com. De plus, elles cessent de fonctionner si elles ne s'authentifient pas dans les 30 jours suivant leur date de création. Le logiciel activé par le KMS doit être réactivé tous les 180 jours, mais le KMS tente de se réactiver tous les 7 jours. Veillez à configurer vos instances Windows afin qu'elles restent activées.
  • Les logiciels du noyau qui accèdent à des registres spécifiques au modèle non émulés génèrent des erreurs de protection générales, ce qui peut entraîner un plantage du système en fonction du système d'exploitation invité.

Erreurs lors de la mesure de la dérive temporelle NTP à l'aide de w32tm sur des VM Windows

Pour les VM Windows exécutant des cartes d'interface réseau VirtIO sur Compute Engine, il existe un bug connu où la mesure de la dérive NTP génère des erreurs lors de l'utilisation de la commande suivante:

w32tm /stripchart /computer:metadata.google.internal

Les erreurs se présentent comme suit:

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

Ce bug ne concerne que les VM Compute Engine dotées de cartes d'interface réseau VirtIO. Les VM qui utilisent gVNIC ne rencontrent pas ce problème.

Pour éviter ce problème, Google recommande d'utiliser d'autres outils de mesure de dérive NTP, tels que l'outil Meinberg Time Server Monitor.

Le déplacement d'une VM Windows vers une série de machines de troisième génération entraîne des problèmes de démarrage

Si vous déplacez une VM Windows vers une série de machines de troisième génération (par exemple, C3 ou H3), à partir d'une série de machines de première ou deuxième génération (par exemple, N1 ou N2), la VM ne parvient pas à redémarrer.

Pour contourner ce problème, procédez comme suit :

  1. Vérifiez que le disque de démarrage de la VM que vous souhaitez mettre à niveau est compatible avec les types de machines de troisième génération en exécutant la commande gcloud compute disks describe :

    gcloud compute disks describe DISK_NAME --zone=ZONE

    Remplacez les éléments suivants :

    • DISK_NAME : nom du disque de démarrage.
    • ZONE : zone du disque.

    La sortie doit contenir les éléments suivants pour utiliser le disque de démarrage avec une série de machines de troisième génération :

    guestOsFeatures:
...
- type: GVNIC
- type: WINDOWS

  2. Arrêtez la VM que vous souhaitez mettre à jour.

  3. Dissociez le disque de démarrage de la VM.

  4. Utilisez la console Google Cloud pour créer une VM Windows avec les propriétés suivantes :

    • Zone : même zone que la VM d'origine.
    • Disque de démarrage : disque de démarrage de la VM d'origine.
    • Série de machines : série de machines de troisième génération.

Débit réseau médiocre lors de l'utilisation de gVNIC

Les VM Windows Server 2022 et Windows 11 qui utilisent le package GooGet du pilote gVNIC version 1.0.0@44 ou antérieure peuvent rencontrer un débit réseau médiocre lors de l'utilisation de la carte d'interface réseau virtuelle Google (gVNIC).

Pour résoudre ce problème, mettez à jour le package GooGet du pilote gVNIC vers la version 1.0.0@45 ou une version ultérieure, en procédant comme suit :

  1. Vérifiez la version du pilote installée sur votre VM en exécutant la commande suivante à partir d'une invite de commande ou d'une session Powershell ouverte avec les autorisations d'administrateur :

    googet installed

    La sortie ressemble à ceci :

    Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...

  2. Si la version du pilote google-compute-engine-driver-gvnic.x86_64 est 1.0.0@44 ou une version antérieure, mettez à jour le dépôt du package GooGet en exécutant la commande suivante à partir d'une invite de commande ou d'une session PowerShell ouverte avec les autorisations d'administrateur :

    googet update

Bande passante limitée avec gVNIC sur Microsoft Windows avec des VM C3 et C3D

Sur les systèmes d'exploitation Windows, le pilote gVNIC n'atteint pas les limites de bande passante documentées. Le pilote gVNIC peut atteindre jusqu'à 85 Gbit/s de bande passante réseau sur les VM C3 et C3D exécutant Microsoft Windows, à la fois pour le réseau par défaut et pour la mise en réseau Tier_1 sur les VM.

Remplacer le pilote NVME sur les VM créées avant mai 2022

Si vous souhaitez utiliser NVMe sur une VM utilisant Microsoft Windows et que la VM a été créée avant le 1er mai 2022, vous devez mettre à jour le pilote NVMe existant dans le système d'exploitation invité pour utiliser le Pilote Microsoft StorNVMe

Vous devez mettre à jour le pilote NVMe sur votre VM avant de remplacer le type de machine par une machine de la série de machines de troisième génération ou avant de créer un instantané de disque de démarrage qui servira à créer des VM utilisant une machine de la série de machines de troisième génération.

Utilisez les commandes suivantes pour installer le package de pilotes StorNVME et supprimer le pilote de la communauté, s'il est présent dans le système d'exploitation invité.

googet update
googet install google-compute-engine-driver-nvme

Performances inférieures pour les disques SSD locaux sur Microsoft Windows avec des VM C3 et C3D

Les performances des disques SSD locaux sont limitées pour les VM C3 et C3D exécutant Microsoft Windows.

Des améliorations de performances sont en cours.

Performances IOPS réduites pour les hyperdisques "Extreme" sur Microsoft Windows avec les VM C3 et M3

Les performances des hyperdisques "Extreme" sont limitées sur les VM Microsoft Windows.

Des améliorations de performances sont en cours.

Les types de machines de vCPU C3D 180 et 360 ne sont pas compatibles avec les images d'OS Windows

Les types de machines de vCPU C3D 180 ne sont pas compatibles avec les images de l'OS Windows Server 2012 et 2016. Les VM C3D créées avec 180 vCPU et des images d'OS Windows Server 2012 et 2016 ne démarrent pas. Pour contourner ce problème, sélectionnez un type de machine plus petit ou utilisez une autre image de l'OS.

Les VM C3D créées avec 360 vCPU et des images d'OS Windows ne démarrent pas. Pour contourner ce problème, sélectionnez un type de machine plus petit ou utilisez une autre image de l'OS.

Erreur de disque générique sur Windows Server 2016 et 2012 R2 pour les VM M3, C3 et C3D

La possibilité d'ajouter ou de redimensionner un Hyperdisk ou un Persistent Disk pour une VM M3, C3 ou C3D en cours d'exécution ne fonctionne pas comme prévu pour des invités Windows spécifiques pour le moment. Windows Server 2012 R2 et Windows Server 2016, ainsi que leurs variantes Windows autres que serveur correspondantes, ne répondent pas correctement aux commandes d'installation de disque et de redimensionnement de disque.

Par exemple, la suppression d'un disque d'une VM M3 en cours d'exécution déconnecte le disque d'une instance Windows Server sans que le système d'exploitation Windows ne reconnaisse que le disque n'est plus là. Les écritures suivantes sur le disque renvoient une erreur générique.

Solution

Vous devez redémarrer la VM M3, C3 ou C3D exécutée sous Windows après avoir modifié un Hyperdisk ou un Persistent Disk pour que les modifications apportées au disque soient reconnues par ces invités.