Problèmes connus

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

Problèmes connus relatifs aux instances de VM Linux

Les problèmes connus suivants concernent les images Linux.

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

L'erreur suivante peut apparaître sur les systèmes basés sur Debian et Ubuntu, y compris sur vos postes de travail locaux :

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 en exécutant la commande suivante :

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key 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

Problème de système de fichiers racine en lecture seule Red Hat Enterprise Linux 7 et CentOS 7

Les instances de VM exécutant les images publiques rhel-7-v20170719 ou versions antérieures, ou centos-7-v20170719 ou versions antérieures, peuvent démarrer avec le système de fichiers racine installé en mode lecture seule. Les applications, les daemons ou les scripts nécessitant un accès en écriture au système de fichiers racine échoueront.

N'essayez pas de redémarrer ou d'exécuter une nouvelle fois les instances qui utilisent les images publiques mentionnées, car elles risquent de se bloquer en mode lecture seule. Si vos instances sont déjà bloquées en mode lecture seule, vous pouvez restaurer à distance le mode lecture-écriture sur le système de fichiers racine, puis résoudre le problème.

Identifier les instances concernées :

Identifiez les instances potentiellement concernées à l'aide des commandes gcloud compute disks list suivantes :

RHEL 7 :

gcloud compute disks list --filter="sourceImage ~ rhel-7-v201[4-6].* OR sourceImage ~ rhel-7-v20170[1-7].*" --uri

CentOS 7

gcloud compute disks list --filter="sourceImage ~ centos-7-v201[4-6].* OR sourceImage ~ centos-7-v20170[1-7].*" --uri

Si ces disques sont associés à vos instances, vous pouvez résoudre le problème sur celles-ci. Le processus de correction des instances concernées dépend de la version de l'image que vous avez utilisée pour créer l'instance.

Instances créées à l'aide d'images RHEL 7 entre rhel-7-v20160418 et rhel-7-v20170719 ou d'images CentOS 7 entre centos-7-v20160418 etcentos-7-v20170719 :

Si l'instance utilise des mises à jour automatiques, yum-cron installe automatiquement le package fixe et supprime l'option d'installation défectueuse du fichier /etc/fstab. Si les mises à jour de l'instance ne sont pas automatiquement activées, vous pouvez effectuer la correction avec le processus suivant :

  1. Connectez-vous à l'instance via SSH. Si la connexion échoue, il se peut que l'instance soit bloquée en mode lecture seule. Cependant, vous pouvez tenter de la récupérer. Si vous vous êtes précédemment connecté à l'instance concernée via SSH, vos clés SSH publiques se trouvent déjà dans le système de fichiers racine et sont toujours activées. Exécutez une commande distante via ssh pour réinstaller le système de fichiers en mode rw. Par exemple, vous pouvez utiliser la commande gcloud suivante pour réinstaller le système de fichiers racine :

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"

    Une fois le système de fichiers installé en mode lecture-écriture, connectez-vous à l'instance via SSH.

  2. Exécutez sudo yum -y update pour mettre à jour tous les packages installés, y compris le gce-disk-expand, qui contient le correctif.

L'instance peut maintenant redémarrer sans l'installation du système de fichiers racine en mode lecture seule.

Instances créées à l'aide d'images RHEL 7 antérieures aux versions rhel-7-v20160418 ou d'images CentOS 7 antérieures aux versions centos-7-v20160418 :

  1. Connectez-vous à l'instance via SSH. Si la connexion échoue, il se peut que l'instance soit bloquée en mode lecture seule. Cependant, vous pouvez tenter de la récupérer. Si vous vous êtes précédemment connecté à l'instance concernée via SSH, vos clés SSH publiques se trouvent déjà dans le système de fichiers racine et sont toujours activées. Exécutez une commande distante via ssh pour réinstaller le système de fichiers en mode rw. Par exemple, vous pouvez utiliser la commande gcloud suivante pour réinstaller le système de fichiers racine :

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"

    Une fois le système de fichiers installé en mode lecture-écriture, connectez-vous à l'instance via SSH.

  2. Modifiez le fichier /etc/fstab et supprimez toutes les options d'installation de barrier=1 dans ce fichier. Seule l'option d'installation default doit être définie pour l'entrée du système de fichiers racine. Vous pouvez corriger cette option d'installation défectueuse à l'aide de la commande suivante :

    sudo sed -i 's/defaults,barrier[^ ,]*/defaults/' /etc/fstab

    Une fois que vous avez supprimé l'option d'installation barrier=1, l'entrée du système de fichiers racine dans le fichier /etc/fstab doit ressembler à l'exemple suivant, mais avec une valeur différente pour l'UUID :

    UUID=b5e54172-67e3-4d52-95f4-4314e71b25fd / xfs defaults 0 0

L'instance peut maintenant redémarrer sans l'installation du système de fichiers racine en mode lecture seule.

L'image CentOS v20131120 présente un changement radical car iptables est activé par défaut

La version v20131120 de l'image CentOS 6, centos-6-v20131120, présente un changement radical car iptables est activé par défaut. Cela empêche le trafic externe d'atteindre les instances CentOS qui exécutent centos-6-v20131120, même s'il existe une ressource de règle de pare-feu correspondante qui permet la connexion.

Pour contourner ce problème, les utilisateurs peuvent désactiver iptables ou le mettre à jour pour permettre la connexion souhaitée (en plus d'autoriser le trafic à l'aide de règles de pare-feu). Pour désactiver iptables, exécutez les commandes suivantes :

# Save your iptable settings
user@centos-instance:~$ sudo service iptables save

# Stop the iptables service
user@centos-instance:~$ sudo service iptables stop

# Disable iptables on start up
user@centos-instance:~$ sudo chkconfig iptables off

Les images fournies par Google font l'objet d'un bug identifié avec le pilote ext4/scsi dans les noyaux stables des systèmes Debian et CentOS

Pour les images centos-6-v20131120 et debian-7-wheezy-v20131120, un bug identifié du système ext4 peut provoquer une fuite de mémoire et le blocage éventuel d'une instance de machine virtuelle dans le cas d'une charge importante du disque persistant. Pour en savoir plus, consultez le fil de discussion Question about ext4 excessive stall time associé à la liste de diffusion au sujet du noyau Linux.

Les noms d'instance de plus de 32 caractères peuvent créer des problèmes avec divers outils UNIX

Date du signalement : juin 2012

Bien que les noms d'instance puissent comporter jusqu'à 63 caractères, les noms de plus de 32 caractères risquent de diminuer la fiabilité de certains outils, y compris ceux qui s'exécutent au démarrage. Pour contourner le problème, choisissez des noms d'instance de moins de 32 caractères.

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

Les problèmes connus suivants concernent les images 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.
  • Sous Windows Server 2008 R2, l'installation de Python 2.7.9 ou d'une version ultérieure nécessite Visual C++. Utiliser Python 2.7.8 évite cette dépendance, mais nous vous recommandons d'installer la dernière version.
  • Compute Engine n'est pas encore compatible avec IPv6. Même si vous activez IPv6 en sélectionnant l'option dans une instance Windows, ce réglage sera ignoré.
  • 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é.