Problèmes connus

Linux Windows

Cette page décrit les problèmes connus que vous pourriez rencontrer lors de l'utilisation de Compute Engine.

Problèmes d'ordre général

Les connexions SSH 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 :

Activez Identity-Aware Proxy pour TCP pour continuer à vous connecter aux VM à l'aide de la fonctionnalité "SSH dans le navigateur" de la console Cloud.
Recréez la règle de pare-feu default-allow-ssh pour continuer à vous connecter aux VM à l'aide de la fonctionnalité "SSH dans le navigateur".
Connectez-vous aux VM à l'aide de Google Cloud CLI plutôt qu'avec SSH dans le navigateur.

Résolu : Quotas d'API Compute Engine en double affichés dans la console Google Cloud

Le problème suivant a été résolu le 14 mars 2022.

Le 3 février 2022, Compute Engine a annoncé la mise à jour des limitation du débit des API Compute Engine (ou quotas d'API), y compris une transition consistant à appliquer les limites par seconde par intervalles d'une minute (60 secondes) au lieu de 100 secondes. Dans le cadre de cette transition, la page affichant les quotas d'API Compute Engine dans Cloud Console affiche à la fois les nouveaux groupes de quotas d'API d'une minute et les groupes de quotas d'API de 100 secondes précédemment utilisés. Les groupes de quotas d'API par minute sont listés avant les groupes de quotas d'API de 100 secondes.

Utilisez les groupes de quotas par minute pour surveiller l'utilisation des quotas et demander un nouveau quota. L'affichage continu des groupes de quotas par intervalle de 100 secondes est intentionnel et temporaire : vous pouvez vous reporter aux groupes de quotas par intervalle de 100 secondes pour voir votre utilisation avant la transition.

En savoir plus sur les limitation du débit des API.

Augmentation possible du nombre d'erreurs 403 `rateLimitExceeded`

Le 3 février 2022, Compute Engine a annoncé la mise à jour des limitation du débit des API Compute Engine, y compris une transition consistant à appliquer les limites par seconde par intervalles d'une minute (60 secondes) au lieu de 100 secondes. Bien que les limites de débit par seconde soient légèrement augmentées, des intervalles d'application plus courts signifient que le nombre maximal de requêtes que vous pouvez passer en utilisation intensive est légèrement inférieur pour chaque intervalle. Toutefois, ce nombre maximal est désormais actualisé plus fréquemment. Si vous rencontrez davantage d'erreurs 403 incluant des messages d'erreur rateLimitExceeded, vous pourrez peut-être réduire ces erreurs en ajustant vos requêtes de façon à attendre des intervalles plus courts avant de réessayer pour correspondre au nouvel intervalle d'application d'une minute.

En savoir plus sur les limitation du débit des API.

La suppression de réservations spécifiques empêche les VM de consommer d'autres réservations

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

Pour éviter ce problème, vous pouvez supprimer les VM qui consomment une réservation spécifique avant de supprimer la réservation spécifique.
Pour résoudre ce problème :
1. Recréez une réservation spécifique avec le même nom et les mêmes propriétés que la réservation spécifique supprimée.
2. Arrêtez et démarrez les VM concernées.

En savoir plus sur la suppression 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 :

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

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

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 :

Environnement invité Compute Engine
Google Cloud CLI avec Google Cloud CLI
Agent Cloud Logging

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