Problèmes connus

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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.

Problèmes d'ordre général

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. Lorsque vous déplacez des VM, nous vous recommandons de suivre les instructions de la section Déplacer une instance de VM entre des zones ou des 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.

Problèmes connus relatifs aux instances de VM Linux

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

Erreur GPG : EXPKEYSIG 3746C208A7317B0F lors de la mise à jour des packages

Sur les systèmes Debian et les systèmes Ubuntu dans lesquels vous avez installé manuellement Google Cloud CLI, y compris votre poste de travail local, vous pouvez rencontrer une erreur semblable à l'exemple suivant :

W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease:
The following signatures were invalid: EXPKEYSIG 3746C208A7317B0F
Google Cloud Packages Automatic Signing Key <gc-team@google.com>

Cette erreur vous empêche d'obtenir les dernières mises à jour de plusieurs outils Google Cloud, y compris les éléments suivants :

Pour résoudre cette erreur, procurez-vous le dernier fichier de clé apt-key.gpg valide sur https://packages.cloud.google.com :

Systèmes Debian

Exécutez la commande suivante :

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Systèmes Ubuntu

Exécutez la commande suivante :

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

Sur les instances de VM Compute Engine exécutant des images Debian ou Ubuntu, vous pouvez également obtenir les dernières clés si vous recréez vos instances à l'aide des versions d'image suivantes :

  • Projet de l'image debian-cloud :
    • debian-9-stretch-v20180401 ou famille d'images debian-9
    • debian-8-jessie-v20180401 ou famille d'images debian-8
  • Projet de l'image ubuntu-os-cloud :
    • ubuntu-1710-artful-v20180315 ou famille d'images ubuntu-1710
    • ubuntu-1604-xenial-v20180323 ou famille d'images ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180308 ou famille d'images ubuntu-1404-lts

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

Ignorez le message d'erreur.

Problèmes connus pour les instances de VM Windows

  • Bien que les instances Windows puissent utiliser l'interface NVMe avec des disques SSD locaux, la compatibilité de NVMe sous Windows est en version bêta et nous ne garantissons pas des performances identiques à celles obtenues avec les instances Linux.
  • 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é.

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

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

La possibilité d'ajouter ou de redimensionner un disque persistant pour une VM M3 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 exécutée sous Windows après avoir modifié les disques persistants pour que ces modifications soient reconnues par ces invités.