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 Limites de Confidential VM.

Problèmes d'ordre général

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

Impossible de créer une remise sur engagement d'utilisation (CUD) pour C4A

Vous ne pouvez pas créer de CUD pour une instance C4A à l'aide de la console Google Cloud, de gcloud CLI ou de REST.

Les CUD pour C4A ne sont pas disponibles dans toutes les régions. La prise en charge est progressivement ajoutée à toutes les régions.

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.

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.

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 de l'API concernant vos quotas d'engagement basés sur les ressources Compute Engine peuvent échouer si chacune des situations suivantes se produit. Vos processus automatisés peuvent inclure des extraits de code, de logique métier ou de 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 un int au lieu d'un number pour définir le champ de la limite de quota de ressources dans le corps de vos réponses d'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 SKU Compute Engine associés à un engagement.

    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 comme un type int, les données de réponse de l'API pour vos limites de quota peuvent toujours se trouver dans la plage du type int et votre processus automatisé ne sera peut-être pas perturbé. 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 consommer la valeur renvoyée par la méthode de l'API et échoue par conséquent.

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 de 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 plafonds 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.

La VM SUSE Enterprise ne démarre pas après avoir modifié les types d'instances

Après avoir modifié le type d'instance d'une VM SUSE Linux Enterprise, il est possible qu'elle ne démarre pas, et que l'erreur suivante s'affiche de manière répétée dans la console série:

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

Origine du problème

SUSE crée ses images cloud avec un initramfs (système de fichiers RAM initial) polyvalent compatible avec différents types d'instances. Pour ce faire, utilisez les indicateurs --no-hostonly --no-hostonly-cmdline -o multipath lors de la création initiale de l'image. Toutefois, lorsqu'un nouveau noyau est installé ou que initramfs est régénéré, ce qui se produit lors des mises à jour du système, ces indicateurs sont omis par défaut. Vous obtenez ainsi une initramfs plus petite, adaptée spécifiquement au matériel du système actuel, ce qui peut exclure les pilotes nécessaires pour d'autres types d'instances.

Par exemple, les instances C3 utilisent des disques NVMe, qui nécessitent l'inclusion de modules spécifiques dans initramfs. Si un système avec un initramfs ne disposant pas de ces modules NVMe est migré vers une instance C3, le processus de démarrage échoue. Ce problème peut également affecter d'autres types d'instances avec des exigences matérielles uniques.

Solution

Avant de modifier le type de machine, regénérez le initramfs avec tous les pilotes:

dracut --force --no-hostonly

Si le système est déjà affecté par le problème, envisagez d'utiliser la console série ou une VM de secours temporaire pour accéder au système et régénérer le initramfs à l'aide de la commande suivante:

dracut -f --no-hostonly -v /boot/initramfs-$(uname -r).img $(uname -r)

Performances IOPS réduites pour les disques SSD locaux sur Z3 avec des images SUSE 12

Les performances des IOPS sur les disques SSD locaux des VM Z3 sur les images SUSE Linux Enterprise Server (SLES) 12 sont nettement inférieures aux performances attendues.

Origine du problème

Il s'agit d'un problème dans le codebase SLES 12.

Solution

Aucun correctif de la part de SUSE pour résoudre ce problème n'est disponible ni prévu. À la place, vous devez utiliser le système d'exploitation SLES 15.

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

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

  • 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.

Appareil de démarrage inaccessible après la mise à niveau d'une VM de génération 1 ou 2 vers une VM de génération 3 ou ultérieure

Windows Server lie le disque de démarrage à son type d'interface de disque initial au premier démarrage. Pour remplacer une série de machines plus ancienne qui utilise une interface de disque SCSI par une série de machines plus récente qui utilise une interface de disque NVMe, effectuez un sysprep de pilote PnP Windows avant d'arrêter la VM. Ce sysprep ne prépare que les pilotes d'appareils et s'assure que tous les types d'interfaces de disque sont analysés pour le disque de démarrage au prochain démarrage.

Pour mettre à jour la série de machines d'une VM, procédez comme suit:

À partir d'une invite Powershell en tant que Administrator, exécutez:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Arrêtez la VM.
  2. Remplacez le type de machine de la VM par le nouveau type de machine.
  3. Démarrez la VM.

Si la nouvelle VM ne démarre pas correctement, rétablissez le type de machine d'origine pour qu'elle fonctionne à nouveau. Il devrait démarrer correctement. Consultez les conditions requises pour la migration pour vous assurer de les respecter. Réessayez ensuite de suivre les instructions.

Bande passante limitée avec gVNIC sur les VM Windows

Le pilote gVNIC empaqueté sur les images Windows proposées par Compute Engine peut atteindre jusqu'à 50 Gbit/s de bande passante réseau sur les instances Windows, à la fois pour les performances réseau standards et pour les performances de mise en réseau Tier_1 par VM. Une version mise à jour du pilote gVNIC peut offrir des performances de ligne (jusqu'à 200 Gbit/s) et prendre en charge les trames géantes.

Le pilote mis à jour n'est disponible que pour les séries de machines de troisième génération et ultérieures (à l'exception de la N4). Pour en savoir plus, consultez la section Mettre à jour la version de gVNIC sur l'OS Windows.

Nombre limité d'associations de disques pour les nouvelles séries de machines VM

Les VM exécutées sur Microsoft Windows avec l'interface de disque NVMe (qui inclut T2A, toutes les VM de troisième génération et les versions ultérieures, ainsi que les VM utilisant l'informatique confidentielle) sont limitées à 16 disques de rattachement. Pour éviter les erreurs, consolidez votre stockage Persistent Disk et Hyperdisk à un maximum de 16 disques par VM. Le stockage SSD local est exclu de ce problème.

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.

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

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.