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.

Vous ne pouvez pas utiliser la console Google Cloud pour créer des VM Spot pour A4 et A3 Ultra.

Vous ne pouvez pas créer de VM Spot utilisant les séries de machines A4 ou A3 Ultra à l'aide de la console Google Cloud . Plus précisément, sur la page Créer une instance, après avoir sélectionné un type de GPU pour ces séries de machines dans le volet Configuration de la machine, le volet Avancé indique qu'une réservation est requise et ne vous permet pas de sélectionner Spot dans la liste Modèle de provisionnement de VM.

Pour contourner ce problème, utilisez la gcloud CLI ou REST pour créer des VM Spot pour A4 et A3 Ultra. Vous pouvez également utiliser la console Google Cloud pour créer des VM A4 et A3 Ultra qui utilisent le modèle de provisionnement lié à une réservation.

La modification des IOPS ou du débit sur un disque principal de réplication asynchrone à l'aide de la commande gcloud compute disks update entraîne une fausse erreur.

Lorsque vous utilisez la commande gcloud compute disks update pour modifier les IOPS et le débit d'un disque principal de réplication asynchrone, Google Cloud CLI affiche un message d'erreur même si la mise à jour a réussi.

Pour vérifier précisément qu'une mise à jour a réussi, utilisez la Google Cloud CLI ou la console Google Cloud pour voir si les propriétés du disque affichent les nouvelles valeurs d'IOPS et de débit. Pour en savoir plus, consultez Afficher les paramètres de performances provisionnés pour Hyperdisk.

Le serveur de métadonnées peut afficher d'anciennes métadonnées de VM physicalHost.

Après avoir rencontré une erreur d'hôte qui déplace une instance vers un nouvel hôte, lorsque vous interrogez le serveur de métadonnées, il peut afficher les métadonnées physicalHost de l'hôte précédent de l'instance.

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

Les valeurs baseInstanceName longues dans les groupes d'instances gérés (MIG) peuvent entraîner des conflits de noms de disque.

Dans un MIG, des conflits de noms de disques peuvent se produire si le modèle d'instance spécifie des disques à créer lors de la création de la VM et si la valeur baseInstanceName dépasse 54 caractères. Cela se produit, car Compute Engine génère des noms de disques en utilisant le nom de l'instance comme préfixe.

Lors de la génération des noms de disque, si le nom obtenu dépasse la limite de 63 caractères, Compute Engine tronque les caractères en trop à la fin du nom de l'instance. Cette troncature peut entraîner la création de noms de disques identiques pour les instances dont les schémas de nommage sont similaires. Dans ce cas, la nouvelle instance tentera d'associer le disque existant. Si le disque est déjà associé à une autre instance, la création de la nouvelle instance échoue. Si le disque n'est pas associé ou est en mode écriture simultanée, la nouvelle instance l'associera, ce qui peut entraîner une corruption des données.

Pour éviter les conflits de noms de disque, la valeur baseInstanceName ne doit pas dépasser 54 caractères.

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 -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 C4, C3 ou 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 Types de machines qui associent automatiquement des disques SSD locaux pour sélectionner le nombre approprié de disques SSD locaux en fonction du type de machine lssd.

L'utilisation de la console Google Kubernetes Engine Google Cloud pour créer un cluster ou un pool de nœuds avec des VM c4-standard-*-lssd, c4-highmem-*-lssd, 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.

Les connexions SSH dans le navigateur de la consoleGoogle 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 :

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 les données de réponse de l'API concernant vos quotas d'engagement basés sur les ressources Compute Engine peuvent échouer si les conditions suivantes sont remplies. Vos processus automatisés peuvent inclure des extraits de code, une 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 un int au lieu d'un number pour définir le champ de la 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 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 votre quota est limité, si vous définissez le champ items[].quotas[].limit ou quotas[].limit comme type int, les données de réponse de l'API pour vos limites de quota peuvent toujours se situer dans la plage du type int, et votre processus automatisé ne sera peut-être pas 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 consommer la valeur renvoyée par la méthode API et échoue en conséquence.

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 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 pour les instances Bare Metal

Les instances C4D bare metal ne peuvent pas exécuter l'OS SUSE Linux Enterprise Server (SLES) version 15 SP6.

Solution

Utilisez plutôt SLES 15 SP5.

Problèmes liés à l'utilisation des interfaces réseau dynamiques

Cette section décrit les problèmes connus liés à l'utilisation de plusieurs interfaces réseau et d'interfaces réseau dynamiques.

Perte de paquets avec des tailles MTU personnalisées

Une interface réseau dynamique avec une carte d'interface réseau virtuelle parente peut entraîner une perte de paquets avec des tailles de MTU personnalisées.

Solution

Pour éviter les pertes de paquets, utilisez l'une des tailles de MTU suivantes :

  • 1 460 octets (valeur par défaut pour les réseaux VPC)
  • 1 500 octets (Ethernet standard)
  • 8 896 octets (la valeur maximale possible)

Interactions du pare-feu lors de la réutilisation d'un ID de VLAN avec des cartes d'interface réseau dynamiques

Sur une instance, la réutilisation d'un ID de VLAN pour une nouvelle carte d'interface réseau dynamique a des implications sur le suivi des connexions du pare-feu. Si vous supprimez une carte d'interface réseau dynamique et que vous en créez une de remplacement qui utilise le même ID de VLAN, les entrées de la table de suivi des connexions du pare-feu ne sont pas effacées automatiquement. L'exemple suivant illustre les considérations de sécurité pertinentes :

  1. Une instance de calcul possède une carte d'interface réseau dynamique avec l'ID de VLAN 4 connectée à un sous-réseau du réseau VPC network-1.
  2. L'instance envoie des paquets à l'adresse IP de destination 192.0.2.7 et au port de destination 443. Les règles de pare-feu de sortie applicables autorisent la connexion sortante.
  3. Étant donné que les règles Cloud NGFW sont avec état, la connexion sortante autorisée crée une entrée dans la table de suivi des connexions du pare-feu, ce qui autorise les paquets entrants provenant de l'adresse IP source et du port source 192.0.2.7:443.
  4. Supprimez l'exemple de carte d'interface réseau dynamique et créez une carte d'interface réseau dynamique de remplacement. L'interface réseau dynamique de remplacement utilise également l'ID de VLAN 4, mais se connecte à un sous-réseau dans un autre réseau VPC, network-2.
  5. Toutes les entrées non expirées du tableau de suivi des connexions du pare-feu qui s'appliquaient à la carte d'interface réseau dynamique d'origine s'appliquent à la carte d'interface réseau dynamique de remplacement. Cela signifie qu'une ressource du réseau VPC network-2 peut envoyer des paquets dont les sources correspondent à 192.0.2.7:443, et que l'instance de calcul les accepte sans avoir besoin d'évaluer les règles de pare-feu d'entrée.

Pour en savoir plus sur le suivi des connexions et les règles de pare-feu, consultez la section Spécifications de la documentation sur le pare-feu Cloud nouvelle génération.

Solution

Si vous devez créer une interface réseau dynamique qui utilise le même ID de VLAN qu'une interface réseau dynamique supprimée de l'instance, procédez comme suit :

  • Attendez au moins 10 minutes entre la suppression de l'interface réseau dynamique d'origine et la création de l'interface réseau dynamique de remplacement.
  • Arrêtez l'instance, supprimez la carte d'interface réseau dynamique d'origine et créez la carte d'interface réseau dynamique de remplacement, puis démarrez l'instance.

L'interception de paquets peut entraîner la perte de paquets en raison de l'absence de tags VLAN dans les en-têtes Ethernet.

L'interception de paquets lors de l'utilisation d'une carte d'interface réseau dynamique peut entraîner la perte de paquets. Des paquets peuvent être perdus lorsque le pipeline est arrêté prématurément. Ce problème affecte les modes basés sur les sessions et ceux qui ne le sont pas.

Origine du problème

Les paquets supprimés se produisent lors de l'interception de paquets lorsque le pipeline est arrêté prématurément (interception d'entrée et réinjection de sortie). La résiliation anticipée entraîne l'absence d'ID de VLAN dans l'en-tête Ethernet du paquet entrant. Étant donné que le paquet de sortie est dérivé du paquet d'entrée modifié, il ne contient pas non plus d'ID de VLAN. Cela entraîne une sélection incorrecte de l'index du point de terminaison et des pertes de paquets ultérieures.

Solution

N'utilisez pas les fonctionnalités Google Cloud qui s'appuient sur l'interception de paquets, comme les points de terminaison de pare-feu.

Problèmes connus relatifs aux instances de VM Linux

Voici les problèmes connus des VM Linux.

Les VM Ubuntu qui utilisent la version d'image OS v20250530 affichent un FQDN incorrect

Un nom de domaine complet incorrect peut s'afficher avec le suffixe .local lorsque vous effectuez l'une des actions suivantes :

  • Mettez à jour le package google-compute-engine vers la version 20250328.00.
  • Lancez des instances à partir de n'importe quelle image Ubuntu proposée par Canonical avec le suffixe de version v20250530. Exemple :projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

Si vous rencontrez ce problème, un nom de domaine complet semblable à celui-ci peut s'afficher :

   [root@ubuntu2204 ~]# apt list --installed | grep google
   ...
   google-compute-engine/noble-updates,now 20250328.00-0ubuntu2~24.04.0 all [installed]
   ...

   [root@ubuntu2204 ~]# curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
   projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

   [root@ubuntu2204 ~]# hostname -f
   ubuntu2204.local

Origine du problème

Sur toutes les images Ubuntu de version v20250530, la version 20250328.00 du package guest-config ajoute local au chemin de recherche en raison de l'introduction d'un nouveau fichier de configuration : https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf.

   [root@ubuntu2204 ~]# cat /etc/resolv.conf
   # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
   # Do not edit.
   ...

   nameserver 127.0.0.53
   options edns0 trust-ad
   search local ... google.internal

La présence de cette entrée local dans le chemin de recherche du fichier /etc/resolv.conf entraîne l'ajout d'un élément .local au nom d'hôte lorsqu'un nom de domaine complet est demandé.

Notez que la version 20250501 de guest-configs corrige déjà le problème, mais que Canonical n'a pas encore intégré la correction dans ses images.

Solution

  1. Modifiez le fichier de configuration de la résolution du nom de réseau /etc/systemd/resolved.conf.d/gce-resolved.conf en remplaçant Domains=local par Domains=~local.
  2. Exécutez la commande suivante pour redémarrer le service systemd-resolved : systemctl restart systemd-resolved
  3. Vérifiez que local est supprimé du chemin de recherche dans /etc/resolv.conf.

  4. Confirmez le nom de domaine complet à l'aide de la commande hostname -f.

    [root@ubuntu2204 ~]# hostname -f
ubuntu2204.us-central1-a.c.my-project.internal

Échec du démarrage de la VM SUSE Enterprise après modification des 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 se répète 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 qui prend en charge 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. Cela entraîne la création d'un initramfs plus petit, spécifiquement adapté 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 lecteurs NVMe, qui nécessitent l'inclusion de modules spécifiques dans le initramfs. Si un système initramfs sans 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 ayant des exigences matérielles spécifiques.

Solution

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

dracut --force --no-hostonly

Si le système est déjà affecté par le problème, créez une VM de secours temporaire. Utilisez la commande chroot pour accéder au disque de démarrage de la VM concernée, puis régénérez initramfs à l'aide de la commande suivante :

dracut -f --no-hostonly

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

Les VM Z3 sur les images SUSE Linux Enterprise Server (SLES) 12 présentent des performances d'IOPS sur les disques SSD locaux nettement inférieures aux attentes.

Origine du problème

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

Solution

Aucun correctif de SUSE n'est disponible ni prévu pour résoudre ce problème. Utilisez plutôt 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.

Le problème suivant a été résolu le 13 janvier 2025.

Les images SUSE publiques Google Cloud 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é.

Windows Server 2025 et Windows 11 24h2 : compatibilité avec la suspension et la réactivation

Windows Server 2025 et Windows 11 24h2 ne peuvent pas reprendre leur activité lorsqu'ils sont suspendus. Tant que ce problème n'est pas résolu, la fonctionnalité de suspension et de reprise ne sera pas prise en charge pour Windows Server 2025 et Windows 11 24h2.

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.

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

Windows Server associe le lecteur de démarrage à son type d'interface de disque initial lors du premier démarrage. Pour remplacer une VM existante d'une ancienne série de machines utilisant une interface de disque SCSI par une série de machines plus récente utilisant une interface de disque NVMe, effectuez un sysprep du pilote Windows PnP avant d'arrêter la VM. Ce sysprep ne prépare que les pilotes de périphériques et vérifie que tous les types d'interface de disque sont analysés pour le lecteur de démarrage au prochain démarrage.

Pour modifier 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. Modifiez le type de machine de la VM.
  3. Démarrez la VM.

Si la nouvelle VM ne démarre pas correctement, rétablissez le type de machine d'origine pour que votre VM fonctionne à nouveau. Il devrait démarrer correctement. Consultez les conditions requises pour la migration afin de vérifier que vous les respectez. Réessayez ensuite de suivre les instructions.

Bande passante limitée avec gVNIC sur les VM Windows

Le pilote gVNIC intégré aux 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 réseau Tier_1 par VM. Une version mise à jour du pilote gVNIC peut offrir des performances à débit maximal (jusqu'à 200 Gbit/s) et la prise en charge des trames Jumbo.

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

Nombre limité de disques pouvant être associés aux séries de machines VM plus récentes

Les VM exécutant Microsoft Windows avec l'interface de disque NVMe, y compris les VM T2A et toutes les VM de troisième génération, sont limitées à 16 disques de rattachement. Cette limite ne s'applique pas aux VM de quatrième génération (c4, m4). Pour éviter les erreurs, regroupez votre stockage Persistent Disk et Hyperdisk sur un maximum de 16 disques par VM. Le stockage SSD local n'est pas concerné par 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 C4, C4D et C3D à grand nombre de vCPU ne sont pas compatibles avec les images d'OS Windows

Les types de machines C4 avec plus de 144 vCPU et les types de machines C4D et C3D avec plus de 180 vCPU ne sont pas compatibles avec les images d'OS Windows Server 2012 et 2016. Les types de machines C4, C4D et C3D de grande taille qui utilisent 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.

Les VM C4D créées avec plus de 255 vCPU et Windows 2025 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, C3D et C4D

La possibilité d'ajouter ou de redimensionner un Hyperdisk ou un Persistent Disk pour une VM M3, C3, C3D ou C4D 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, C3D ou C4D 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.