Problemas conocidos

En esta página se describen los problemas conocidos que pueden surgir al usar Compute Engine. Si tienes problemas específicos con las máquinas virtuales confidenciales, consulta las limitaciones de las máquinas virtuales confidenciales.

Incidencias generales

En los siguientes artículos se ofrecen instrucciones para solucionar problemas o información general.

Posibles errores de host durante la creación de VMs C4 en nodos de único cliente

Las instancias de máquina virtual (VM) del tipo de máquina C4 que se ejecutan en nodos de único inquilino pueden experimentar terminaciones inesperadas de la VM debido a errores del host o a fallos en la creación de la VM.

Para solucionar este problema, Google ha limitado a 26 el número máximo de instancias de VM C4 permitidas por nodo de único arrendatario.

Se supera el tiempo de espera al cancelar trabajos en clústeres de HPC de 32 nodos o más

En el caso de los trabajos de gran tamaño en clústeres de 32 nodos o más, el tiempo que se tarda en cancelar un trabajo puede superar el valor predeterminado UnkillableStepTimeout de 300 segundos. Si se supera este valor, los nodos afectados no se podrán usar en trabajos futuros.

Para solucionar este problema, utilice uno de los siguientes métodos:

  • Actualiza Cluster Toolkit a la versión 1.65.0 o posterior. A continuación, vuelve a implementar el clúster con el siguiente comando:

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

  • Si no puedes actualizar Cluster Toolkit ni volver a implementar el clúster, puedes modificar manualmente el parámetro UnkillableStepTimeout siguiendo estos pasos:

    1. Usa SSH para conectarte al nodo de controlador principal de tu clúster.

      gcloud compute ssh --project PROJECT_ID --zone ZONE DEPLOYMENT_NAME-controller

      Puedes encontrar el nombre exacto y la dirección IP del nodo de controlador principal en la Google Cloud consola, en la página Instancias de VM.

    2. Crea una copia de seguridad del archivo cloud.conf actual. Este archivo suele estar ubicado en /etc/slurm/.

      sudo cp /etc/slurm/cloud.conf /etc/slurm/cloud.conf.backup-$(date +%Y%m%d)

    3. Con privilegios de sudo, usa un editor de texto para abrir el archivo /etc/slurm/cloud.conf.

    4. Añade o modifica la línea que contiene UnkillableStepTimeout. Por ejemplo, puedes definir el tiempo de espera en 900 segundos (15 minutos) de la siguiente manera:

      UnkillableStepTimeout=900

    5. Guarda el archivo.

    6. Usa el comando sudo scontrol reconfigure para aplicar el nuevo ajuste en todo el clúster sin necesidad de reiniciarlo por completo.

Verificar la corrección

Para comprobar que el ajuste se ha cambiado, ejecuta el siguiente comando:

   scontrol show config | grep UnkillableStepTimeout

El resultado debe reflejar el nuevo valor que has definido. Por ejemplo: UnkillableStepTimeout = 900.

Solucionado: al modificar las IOPS o el rendimiento de un disco principal de réplica asíncrona mediante el comando gcloud compute disks update, se produce un error falso

El siguiente problema se resolvió el 1 de junio del 2025.

Cuando usas el comando gcloud compute disks update para modificar las IOPS y el rendimiento de un disco principal de replicación asíncrona, la CLI de gcloud muestra un mensaje de error aunque la actualización se haya realizado correctamente.

Para verificar con precisión que una actualización se ha realizado correctamente, usa la CLI de gcloud o la consola para comprobar si las propiedades del disco muestran los nuevos valores de IOPS y de capacidad de procesamiento. Google Cloud Para obtener más información, consulta Ver los ajustes de rendimiento aprovisionados de Hyperdisk.

El servidor de metadatos puede mostrar metadatos de VM antiguos physicalHost

Después de que se produzca un error de host que mueva una instancia a un nuevo host, cuando consultes el servidor de metadatos, es posible que se muestren los metadatos physicalHost del host anterior de la instancia.

Para solucionar este problema, siga uno de estos pasos:

Los valores baseInstanceName largos en grupos de instancias gestionados pueden provocar conflictos con los nombres de los discos

En un MIG, pueden producirse conflictos de nombres de disco si la plantilla de instancia especifica que se creen discos al crear la VM y el valor de baseInstanceName supera los 54 caracteres. Esto ocurre porque Compute Engine genera nombres de disco usando el nombre de la instancia como prefijo.

Al generar nombres de disco, si el nombre resultante supera el límite de 63 caracteres, Compute Engine trunca los caracteres que sobran del final del nombre de la instancia. Este truncamiento puede provocar que se creen nombres de disco idénticos para instancias que tengan patrones de nomenclatura similares. En ese caso, la nueva instancia intentará montar el disco. Si el disco ya está conectado a otra instancia, no se podrá crear la nueva instancia. Si el disco no está conectado o está en modo multiescritura, la nueva instancia conectará el disco, lo que puede provocar daños en los datos.

Para evitar conflictos con los nombres de los discos, el valor de baseInstanceName debe tener una longitud máxima de 54 caracteres.

Se producen problemas al crear reservas o solicitudes de reserva futuras con una plantilla de instancia que especifica un tipo de máquina A2, C3 o G2

Si usas una plantilla de instancia que especifica un tipo de máquina A2, C3 o G2 para crear una reserva o para crear y enviar una solicitud de reserva futura para que se revise, tendrás problemas. En concreto, este cambio afecta a las siguientes acciones:

  • Es posible que no se pueda crear la reserva. Si se completa correctamente, se aplicará una de las siguientes opciones:

    • Si has creado una reserva de consumo automático (opción predeterminada), al crear máquinas virtuales con propiedades coincidentes no se consumirá la reserva.

    • Si has creado una reserva específica, no podrás crear máquinas virtuales que tengan como objetivo esa reserva.

  • La creación de la solicitud de reserva futura se realiza correctamente. Sin embargo, si la envías para que la revisemos y Google Cloud rechaza tu solicitud.

No puedes sustituir la plantilla de instancia que se ha usado para crear una reserva o una solicitud de reserva futura, ni anular las propiedades de la máquina virtual de la plantilla. Si quieres reservar recursos para los tipos de máquinas A2, C3 o G2, haz una de las siguientes acciones:

Limitaciones al usar tipos de -lssd máquina con Google Kubernetes Engine

Cuando se usa la API de Google Kubernetes Engine, el grupo de nodos con SSD local adjunto que aprovisiones debe tener el mismo número de discos SSD que el tipo de máquina C4, C3 o C3D seleccionado. Por ejemplo, si tienes previsto crear una VM que use c3-standard-8-lssd, debe haber dos discos SSD, mientras que, para c3d-standard-8-lssd, solo se necesita un disco SSD. Si el número de disco no coincide, recibirás un error de configuración incorrecta de SSD local del plano de control de Compute Engine. Consulta la sección Tipos de máquinas que adjuntan automáticamente discos SSD locales para seleccionar el número correcto de discos SSD locales en función del lssdtipo de máquina.

Si se usa la consola de Google Kubernetes Engine Google Cloud para crear un clúster o un grupo de nodos con máquinas virtuales c4-standard-*-lssd, c4-highmem-*-lssd, c3-standard-*-lssd y c3d-standard-*-lssd, se produce un error al crear los nodos o no se detectan las unidades SSD locales como almacenamiento efímero.

Variabilidad del rendimiento de TCP de un solo flujo en VMs C3D

Las máquinas virtuales C3D con más de 30 vCPUs pueden experimentar variaciones en el rendimiento de TCP de un solo flujo y, en ocasiones, estar limitadas a entre 20 y 25 Gbps. Para conseguir tasas más altas, usa varios flujos TCP.

La métrica de observabilidad de la utilización de CPU es incorrecta en las VMs que usan un hilo por núcleo

Si la CPU de tu máquina virtual usa un hilo por núcleo, la métrica de observabilidad de uso de CPU de Cloud Monitoring en la pestaña Compute Engine > Instancias de VM > Observabilidad solo se escala hasta el 50%. El valor predeterminado es de dos subprocesos por núcleo para todos los tipos de máquinas, excepto Tau T2D. Para obtener más información, consulta Definir el número de hilos por núcleo.

Para ver la utilización de la CPU de tu VM normalizada al 100%, consulta la utilización de la CPU en el explorador de métricas. Para obtener más información, consulta Crear gráficos con el explorador de métricas.

Es posible que las conexiones SSH en el navegador de la consola deGoogle Cloud fallen si usas reglas de cortafuegos personalizadas

Si usas reglas de firewall personalizadas para controlar el acceso SSH a tus instancias de VM, es posible que no puedas usar la función SSH en el navegador.

Para solucionar este problema, haz una de las siguientes acciones:

Nombres temporales de los discos

Durante las actualizaciones de instancias de máquinas virtuales (VM) iniciadas mediante el comando gcloud compute instances update o el método de la API instances.update, Compute Engine puede cambiar temporalmente el nombre de los discos de tu VM añadiendo uno de los siguientes sufijos al nombre original:

  • -temp
  • -old
  • -new

Compute Engine elimina el sufijo y restaura los nombres originales de los discos cuando se completa la actualización.

Aumento de la latencia de algunos discos persistentes debido al cambio de tamaño de los discos

En algunos casos, cambiar el tamaño de discos persistentes grandes (de unos 3 TB o más) puede afectar al rendimiento de E/S del disco. Si te ves afectado por este problema, es posible que tus discos persistentes experimenten un aumento de la latencia durante la operación de cambio de tamaño. Este problema puede afectar a los discos persistentes de cualquier tipo.

Es posible que tus procesos automatizados fallen si usan datos de respuesta de la API sobre tus cuotas de compromisos basados en recursos

Es posible que los procesos automatizados que consumen y usan datos de respuesta de la API sobre las cuotas de compromiso basadas en recursos de Compute Engine fallen si se dan las siguientes circunstancias. Tus procesos automatizados pueden incluir cualquier fragmento de código, lógica empresarial o campo de base de datos que use o almacene las respuestas de la API.

  1. Los datos de respuesta proceden de cualquiera de los siguientes métodos de la API Compute Engine:

  2. En lugar de number, se usa int para definir el campo del límite de cuota de recursos en los cuerpos de respuesta de la API. Puedes encontrar el campo de las siguientes formas para cada método:

  3. Tienes una cuota predeterminada ilimitada disponible para cualquiera de tus SKUs comprometidos de Compute Engine.

    Para obtener más información sobre las cuotas de los compromisos y los SKUs comprometidos, consulta Cuotas de compromisos y recursos comprometidos.

Causa principal

Si tiene una cuota limitada y define el campo items[].quotas[].limit o quotas[].limit como tipo int, es posible que los datos de respuesta de la API de sus límites de cuota sigan estando dentro del intervalo del tipo int y que su proceso automatizado no se interrumpa. Sin embargo, cuando el límite de cuota predeterminado es ilimitado, la API Compute Engine devuelve un valor para el campo limit que está fuera del intervalo definido por el tipo int. Tu proceso automatizado no puede consumir el valor devuelto por el método de la API y, por lo tanto, falla.

Cómo solucionar este problema

Para solucionar este problema y seguir generando informes automatizados, puede hacer lo siguiente:

  • Recomendación: sigue la documentación de referencia de la API Compute Engine y usa los tipos de datos correctos en las definiciones de los métodos de la API. En concreto, usa el tipo number para definir los campos items[].quotas[].limit y quotas[].limit de los métodos de tu API.

  • Reduce el límite de tu cuota a un valor inferior a 9.223.372.036.854.775.807. Debes definir límites de cuota para todos los proyectos que tengan compromisos basados en recursos en todas las regiones. Puedes hacerlo de una de las siguientes formas:

Problemas conocidos de las instancias de hardware desnudo

Estos son los problemas conocidos de las instancias de hardware desnudo de Compute Engine.

C4D Bare Metal no admite imágenes de SUSE Linux 15 SP6

Las instancias de Bare Metal C4D no pueden ejecutar el SO SUSE Linux Enterprise Server (SLES) versión 15 SP6.

Solución

Usa SLES 15 SP5 en su lugar.

La simulación del mantenimiento del host no funciona en las instancias de Bare Metal C4

Los tipos de máquinas c4-standard-288-metal y c4-highmem-288-metal no admiten la simulación de eventos de mantenimiento del host.

Solución

Puedes usar instancias de VM creadas con otros tipos de máquinas C4 para simular eventos de mantenimiento.

  1. Crea una instancia de VM con un tipo de máquina C4 que no termine en -metal.

    Cuando crees la instancia de VM, configura la VM C4 para que Terminate en lugar de usar la migración en tiempo real durante los eventos de mantenimiento del host.

  2. Simula un evento de mantenimiento de host para esta VM.

Durante un evento de mantenimiento del host simulado, el comportamiento de las VMs configuradas para finalizar es el mismo que el de las instancias de metal desnudo C4.

Rendimiento inferior al esperado con instancias de hardware desnudo Z3 en RHEL 8

Cuando se usa la versión 8 de Red Hat Enterprise Linux (RHEL) con una instancia de hardware desnudo Z3, el rendimiento de la red es inferior al esperado.

Causa principal

Falta una función de Page Pool en la versión 4.18 del kernel de Linux que usa RHEL 8.

Solución

Usa una versión más reciente de RHEL u otro sistema operativo cuando trabajes con instancias de hardware de Z3.

Problemas relacionados con el uso de interfaces de red dinámicas

En esta sección se describen los problemas conocidos relacionados con el uso de varias interfaces de red y de interfaces de red dinámicas.

Las versiones del agente invitado de 20250901.00 a 20251108.00 no instalan NICs dinámicas

Si intentas configurar la gestión automática de NICs dinámicas y tu instancia ejecuta el agente invitado en una versión comprendida entre 20250901.00 y 20251108.00, el agente invitado no podrá instalar ni gestionar NICs dinámicas en el sistema operativo invitado de tu instancia.

Es posible que recibas un error que incluya Cannot find device al ejecutar comandos en el SO invitado que hagan referencia a NICs dinámicas.

Causa principal

A partir de la versión 20250901.00, el agente invitado se ha migrado a una nueva arquitectura basada en complementos para mejorar la modularidad. La nueva arquitectura no admitía la instalación y la gestión automáticas de NICs dinámicas en las versiones 20250901.00 a 20251108.00.

La versión 20251115.00 del agente invitado resuelve este problema.

Resolución

Para solucionar este problema, actualice su instancia para que use la versión 20251115.00 o una posterior del agente invitado:

  1. Para actualizar el agente invitado a la versión más reciente, consulta Actualizar el entorno invitado.
  2. Para confirmar que tu instancia ejecuta la versión 20251115.00 o una posterior del agente invitado, consulta Ver los paquetes instalados por versión del sistema operativo.

Si es necesario, puedes solucionar temporalmente este problema en las instancias que ejecuten versiones del agente invitado de 20250901.00 a 20251108.00 siguiendo las instrucciones de Compatibilidad con versiones anteriores para volver a la arquitectura anterior del agente invitado.

La intercepción de paquetes puede provocar que se pierdan paquetes debido a que faltan etiquetas VLAN en los encabezados Ethernet

La intercepción de paquetes al usar NIC dinámico puede provocar que se eliminen paquetes. Los paquetes perdidos pueden producirse cuando la canalización se termina antes de tiempo. El problema afecta tanto al modo basado en sesiones como al que no lo está.

Causa principal

Los paquetes perdidos se producen durante la interceptación de paquetes cuando la canalización se termina antes de tiempo (interceptación de entrada y reinyección de salida). La finalización anticipada provoca que falte el ID de VLAN en el encabezado Ethernet del paquete de entrada. Como el paquete de salida se deriva del paquete de entrada modificado, el paquete de salida tampoco tiene el ID de VLAN. Esto provoca que se seleccione un índice de endpoint incorrecto y que se pierdan paquetes.

Solución

No uses Google Cloud funciones que dependan de la interceptación de paquetes, como los endpoints de firewall.

Problemas conocidos de las instancias de máquina virtual de Linux

Estos son los problemas conocidos de las VMs Linux.

Formatos de URL admitidos para la secuencia de comandos de inicio

Si tu instancia usa la versión 20251115.00 del agente invitado, no se podrá obtener una secuencia de comandos de inicio con la clave de metadatos startup-script-url si la URL usa el formato https://storage.googleapis.com/ que se describe en la página Usar secuencias de comandos de inicio en máquinas virtuales Linux.

Para solucionar este problema, usa uno de los siguientes formatos de URL admitidos:

  • URL autenticada: https://storage.cloud.google.com/BUCKET/FILE
  • URI de almacenamiento de la CLI de gcloud: gs://BUCKET/FILE

Las VMs de Debian 11 que usan una versión de imagen de SO anterior a la v20250728 no pueden ejecutar apt update

El 22 de julio del 2025, la comunidad de Debian retiró las versiones anteriores de Debian 11 (Bullseye) del upstream principal de Debian. Esta actualización provoca que se produzca un error en sudo apt update con el siguiente mensaje:

The repository 'https://deb.debian.org/debian bullseye-backports Release' does
not have a Release file.

Causa principal

Como la comunidad de Debian ha quitado los repositorios de versiones anteriores del upstream principal, ya no hay ninguna referencia a bullseye-backports Release.

Resolución

Usa la versión de imagen debian-11-bullseye-v20250728 o una posterior. Estas versiones no contienen los repositorios de backports. También puedes actualizar las instancias actuales modificando /etc/apt/sources.list:

  • Para actualizar la URL del repositorio y usar el archivo de bullseye-backports, sigue estos pasos:

    sudo sed -i 's/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/deb https:\/\/archive.debian.org\/debian bullseye-backports main/g; s/^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/deb-src https:\/\/archive.debian.org\/debian bullseye-backports main/g' /etc/apt/sources.list

  • Para eliminar la URL del repositorio y descartar bullseye-backports, sigue estos pasos:

    sudo sed -i '/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/d; /^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/d' /etc/apt/sources.list

La instalación del paquete ubuntu-desktop interrumpe la red de la máquina virtual al reiniciar

Después de instalar el paquete ubuntu-desktop en una VM de Ubuntu, debes ejecutar la siguiente solución alternativa antes de reiniciar la VM:

echo -e 'network:\n  version: 2\n  renderer: networkd' | sudo tee /etc/netplan/99-gce-renderer.yaml

De lo contrario, es posible que las interfaces de red no se configuren correctamente al reiniciar.

Causa principal

El paquete ubuntu-deskop extrae ubuntu-settings como dependencia, que define NetworkManager como el "renderizador" predeterminado de netplan. En concreto, inserta una nueva configuración de YAML para netplan en /usr/lib/netplan/00-network-manager-all.yaml que contiene lo siguiente:

network:
  version: 2
  renderer: NetworkManager

Esta configuración entra en conflicto con nuestro aprovisionamiento anticipado basado en networkd con cloud-init.

Recuperación

Si la VM se ha reiniciado y no se puede acceder a ella, haz lo siguiente:

  1. Sigue las instrucciones para recuperar una VM.

  2. Después de montar la partición del sistema de archivos Linux de la VM inaccesible, ejecuta el siguiente comando (sustituye /rescue por tu punto de montaje):

    echo -e 'network:\n  version: 2\n  renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yaml

  3. Sigue las instrucciones para reiniciar la VM a la que no puedes acceder.

Las VMs de Ubuntu que usan la versión v20250530 de la imagen del SO muestran un FQDN incorrecto

Es posible que veas un nombre de dominio completo incorrecto con el sufijo .local cuando hagas una de las siguientes acciones:

  • Actualiza a la versión 20250328.00 del paquete google-compute-engine.
  • Lanza instancias desde cualquier imagen de Ubuntu ofrecida por Canonical con el sufijo de versión v20250530. Por ejemplo, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

Si tienes este problema, puede que veas un FQDN similar al siguiente:

   [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

Causa principal

En todas las imágenes de Ubuntu con la versión v20250530, la versión 20250328.00 del paquete guest-config añade local a la ruta de búsqueda debido a la introducción de un nuevo archivo de configuración: 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 presencia de esta entrada local en la ruta de búsqueda del archivo /etc/resolv.conf hace que se añada un elemento .local al nombre de host cuando se solicita un nombre de dominio completo.

Ten en cuenta que la versión 20250501 de guest-configs ya soluciona el problema, pero Canonical aún no ha incorporado la corrección en sus imágenes.

Solución

  1. Modifica el archivo de configuración de resolución de nombres de red /etc/systemd/resolved.conf.d/gce-resolved.conf cambiando Domains=local por Domains=~local
  2. Ejecuta el siguiente comando para reiniciar el servicio systemd-resolved: systemctl restart systemd-resolved
  3. Comprueba que local se haya eliminado de la ruta de búsqueda en /etc/resolv.conf

  4. Confirma el FQDN con el comando hostname -f.

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

Falta mkfs.ext4 en las imágenes de openSUSE

En la v20250724versión reciente de las imágenes de openSUSE (a partir de opensuse-leap-15-6-v20250724-x86-64) de agosto del 2025, falta el paquete e2fsprogs, que proporciona utilidades para gestionar sistemas de archivos. Un síntoma habitual de este problema es que aparece un mensaje de error, como command not found, cuando intentas usar el comando mkfs.ext4.

Solución

Si te encuentras con este problema, instala el paquete que falta manualmente con el gestor de paquetes de openSUSE, zypper.

# Update the package index
user@opensuse:~> sudo zypper refresh

# Install the e2fsprogs package
user@opensuse:~> sudo zypper install e2fsprogs

# Verify the installation
user@opensuse:~> which mkfs.ext4

Las VMs de SUSE Enterprise no se inician después de cambiar los tipos de instancia

Después de cambiar el tipo de instancia de una máquina virtual de SUSE Linux Enterprise, es posible que no se pueda arrancar y que se repita el siguiente error en la consola en serie:

            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"

Causa principal

SUSE crea sus imágenes de nube con un initramfs (sistema de archivos RAM inicial) versátil que admite varios tipos de instancias. Para ello, se usan las marcas --no-hostonly --no-hostonly-cmdline -o multipath durante la creación inicial de la imagen. Sin embargo, cuando se instala un nuevo kernel o se regenera el initramfs, lo que ocurre durante las actualizaciones del sistema, estas marcas se omiten de forma predeterminada. De esta forma, se obtiene un initramfs más pequeño y adaptado específicamente al hardware del sistema actual, lo que puede excluir los controladores necesarios para otros tipos de instancias.

Por ejemplo, las instancias C3 usan unidades NVMe, que requieren que se incluyan módulos específicos en el initramfs. Si se migra a una instancia C3 un sistema con un initramfs que no tenga estos módulos NVMe, el proceso de arranque fallará. Este problema también puede afectar a otros tipos de instancias con requisitos de hardware únicos.

Solución

Antes de cambiar el tipo de máquina, vuelve a generar el initramfs con todos los controladores:

dracut --force --no-hostonly

Si el sistema ya se ha visto afectado por el problema, crea una máquina virtual de rescate temporal. Usa el comando chroot para acceder al disco de arranque de la VM afectada y, a continuación, vuelve a generar el initramfs con el siguiente comando:

dracut -f --no-hostonly

Rendimiento de IOPS inferior para SSD local en Z3 con imágenes de SUSE 12

Las máquinas virtuales Z3 de imágenes de SUSE Linux Enterprise Server (SLES) 12 tienen un rendimiento significativamente inferior al esperado en cuanto a IOPS en discos SSD locales.

Causa principal

Se trata de un problema en la base de código de SLES 12.

Solución

No hay ningún parche de SUSE disponible ni previsto para solucionar este problema. En su lugar, debes usar el sistema operativo SLES 15.

Las VMs de RHEL 7 y CentOS pierden el acceso a la red después de reiniciar

Si tus VMs de CentOS o RHEL 7 tienen varias tarjetas de interfaz de red (NICs) y una de estas NICs no usa la interfaz VirtIO, es posible que se pierda el acceso a la red al reiniciar. Esto ocurre porque RHEL no admite la inhabilitación de nombres de interfaz de red predecibles si al menos una NIC no usa la interfaz VirtIO.

Resolución

La conectividad de red se puede restaurar deteniendo e iniciando la VM hasta que se resuelva el problema. Para evitar que se vuelva a producir una pérdida de conectividad de red, haz lo siguiente:

  1. Edita el archivo /etc/default/grub y elimina los parámetros del kernel net.ifnames=0 y biosdevname=0.

  2. Regenera la configuración de grub.

  3. Reinicia la VM.

No se ha podido verificar la firma de repomd.xml

En sistemas basados en Red Hat Enterprise Linux (RHEL) o CentOS 7, es posible que veas el siguiente error al intentar instalar o actualizar software con yum. Este error indica que la clave GPG del repositorio ha caducado o es incorrecta.

Registro de ejemplo: 

[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
Resolución

Para solucionar este problema, inhabilita la comprobación de la clave GPG del repositorio en la configuración del repositorio yum definiendo repo_gpgcheck=0. En las imágenes base de Compute Engine compatibles, este ajuste se puede encontrar en el archivo /etc/yum.repos.d/google-cloud.repo. Sin embargo, tu VM puede tener este valor definido en diferentes archivos de configuración de repositorios o herramientas de automatización.

Los repositorios de Yum no suelen usar claves GPG para validar repositorios. En su lugar, se confía en el endpoint https.

Para localizar y actualizar este ajuste, sigue estos pasos:

  1. Busca el ajuste en el archivo /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. Cambia todas las líneas que digan repo_gpgcheck=1 por repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

  3. Comprueba que el ajuste se haya actualizado.

    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

Las instancias que usan OS Login devuelven un mensaje de inicio de sesión después de la conexión

En algunas instancias que usan el inicio de sesión del SO, puede que recibas el siguiente mensaje de error después de que se establezca la conexión:

/usr/bin/id: cannot find name for group ID 123456789

Resolución

Ignora el mensaje de error.

Problemas conocidos de las instancias de VM de Windows

  • La compatibilidad con NVMe en Windows mediante el controlador NVMe de la comunidad está en fase beta y el rendimiento puede no ser el mismo que el de las instancias de Linux. El controlador NVMe de la comunidad se ha sustituido por el controlador StorNVMe de Microsoft en las imágenes públicas de Google Cloud . Te recomendamos que sustituyas el controlador NVME en las VMs creadas antes de mayo del 2022 y que utilices el controlador StorNVMe de Microsoft.
  • Después de crear una instancia, no puedes conectarte a ella al instante. Todas las instancias de Windows nuevas usan la herramienta Preparación del sistema (sysprep) para configurar la instancia, lo que puede tardar entre 5 y 10 minutos.
  • Las imágenes de Windows Server no se pueden activar sin una conexión de red a kms.windows.googlecloud.com y dejan de funcionar si no se autentican inicialmente en un plazo de 30 días. El software activado por el KMS debe reactivarse cada 180 días, pero el KMS intenta reactivarlo cada 7 días. Asegúrate de configurar tus instancias de Windows para que sigan activadas.
  • El software del kernel que acceda a registros específicos del modelo no emulados generará fallos de protección generales, que pueden provocar un fallo del sistema en función del sistema operativo invitado.
  • El controlador vioscsi, que se usa para los discos SCSI, define la marca removable, lo que provoca que los discos se traten como almacenamiento extraíble. Esto provoca restricciones de acceso inesperadas en Windows a los discos sujetos a objetos de directiva de grupo (GPOs) que tienen como objetivo el almacenamiento extraíble.

No se puede iniciar el agente invitado

La versión 20251011.00 del agente invitado de Windows no se inicia en determinadas condiciones de carga.

Causa principal El paquete del agente invitado de Windows para la versión 20251011.00 establece incorrectamente el modo de inicio del agente invitado de Windows en auto en el Administrador de servicios de Windows.

Resolución Para solucionar este problema, actualiza tu instancia para que use la versión 20251120.01 o una posterior del agente invitado.

Solución alternativa manual Si no puedes instalar la versión 20251120.01, ejecuta el siguiente comando:

  • sc.exe config GCEAgent start=delayed-auto

Es posible que las funciones de gestión de credenciales no funcionen en máquinas virtuales Windows que usen nombres en idiomas distintos del inglés

El agente invitado de Windows identifica las cuentas y los grupos de administrador mediante la coincidencia de cadenas. Por lo tanto, las funciones de gestión de credenciales solo funcionan correctamente cuando se usan nombres en inglés para las cuentas de usuario y los grupos, como Administrators. Si usas nombres en un idioma distinto del inglés, es posible que las funciones de gestión de credenciales, como la generación o el restablecimiento de contraseñas, no funcionen correctamente.

Windows Server 2016 no se inicia en tipos de máquinas C3D con 180 vCPUs o más

Windows Server 2016 no se iniciará en tipos de máquinas C3D que tengan 180 vCPUs o más (c3d-standard-180 o c3d-standard-360) o un número superior. Para solucionar este problema, elige una de las siguientes opciones:

  • Si necesitas usar Windows Server 2016, utiliza una máquina C3D más pequeña.
  • Si necesitas usar los tipos de máquina c3d-standard-180 o c3d-standard-360, utiliza una versión posterior de Windows Server.

Windows Server 2025 y Windows 11 24h2/25h2: compatibilidad con la suspensión y la reanudación

Windows Server 2025, Windows 11 24H2 y Windows 11 25H2 no se pueden reanudar cuando se suspenden. Hasta que se resuelva este problema, la función de suspender y reanudar no será compatible con Windows Server 2025, Windows 11 24H2 y Windows 11 25H2.

Errores al medir la desviación de la hora NTP con w32tm en VMs de Windows

En las VMs de Windows en Compute Engine que ejecutan NICs VirtIO, hay un error conocido por el que la medición de la desviación de NTP produce errores al usar el siguiente comando:

w32tm /stripchart /computer:metadata.google.internal

Los errores tienen un aspecto similar al siguiente:

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

Este error solo afecta a las máquinas virtuales de Compute Engine con NICs VirtIO. Las VMs que usan gVNIC no tienen este problema.

Para evitar este problema, Google recomienda usar otras herramientas de medición de la desviación de NTP, como Meinberg Time Server Monitor.

Dispositivo de arranque inaccesible después de actualizar una VM de generación 1 o 2 a una VM de generación 3 o posterior

Windows Server vincula la unidad de arranque a su tipo de interfaz de disco inicial en el primer inicio. Para cambiar una máquina virtual de una serie anterior que usa una interfaz de disco SCSI a una serie más reciente que usa una interfaz de disco NVMe, realiza una preparación del sistema del controlador PnP de Windows antes de apagar la máquina virtual. Este sysprep solo prepara los controladores de dispositivos y verifica que se analicen todos los tipos de interfaz de disco en la unidad de arranque en el siguiente inicio.

Para actualizar la serie de máquinas de una VM, sigue estos pasos:

En un símbolo del sistema de PowerShell como Administrator, ejecuta lo siguiente:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Detén la VM.
  2. Cambia la máquina virtual al nuevo tipo de máquina virtual.
  3. Inicia la VM.

Si la nueva VM no se inicia correctamente, vuelve a cambiarla al tipo de máquina original para que vuelva a funcionar. Debería iniciarse correctamente. Consulta los requisitos de migración para comprobar que los cumples. A continuación, vuelve a probar las instrucciones.

Número limitado de discos que se pueden asociar a series de máquinas virtuales más recientes

Las máquinas virtuales que se ejecutan en Microsoft Windows con la interfaz de disco NVMe, que incluye T2A y todas las máquinas virtuales de tercera generación, tienen un límite de 16 discos asociados. Esta limitación no se aplica a las VMs de cuarta generación (C4 y M4). Para evitar errores, consolida tu almacenamiento de Persistent Disk y Hyperdisk en un máximo de 16 discos por VM. El almacenamiento en SSD local no se ve afectado por este problema.

Sustituir el controlador NVME en las VMs creadas antes de mayo del 2022

Si quieres usar NVMe en una VM que utilice Microsoft Windows y la VM se creó antes del 1 de mayo del 2022, debes actualizar el controlador NVMe en el SO invitado para usar el controlador StorNVMe de Microsoft.

Debes actualizar el controlador NVMe de tu VM antes de cambiar el tipo de máquina a una serie de máquinas de tercera generación o antes de crear una instantánea del disco de arranque que se usará para crear VMs que utilicen una serie de máquinas de tercera generación.

Usa los siguientes comandos para instalar el paquete de controladores StorNVME y eliminar el controlador de la comunidad, si está presente en el SO invitado.

googet update
googet install google-compute-engine-driver-nvme

Rendimiento inferior de las SSDs locales en Microsoft Windows con máquinas virtuales C3 y C3D

El rendimiento de las SSD locales está limitado en las VMs C3 y C3D que ejecutan Microsoft Windows.

Estamos mejorando el rendimiento.

Rendimiento inferior de los volúmenes Hyperdisk Extreme conectados a instancias n2-standard-80 que ejecutan Microsoft Windows

Las instancias de Microsoft Windows que se ejecutan en tipos de máquinas n2-standard-80 pueden alcanzar un máximo de 80.000 IOPS en todos los volúmenes de Hyperdisk Extreme que estén conectados a la instancia.

Resolución

Para alcanzar hasta 160.000 IOPS con instancias N2 que ejecuten Windows, elige uno de los siguientes tipos de máquina:

  • n2-highmem-80
  • n2-highcpu-80
  • n2-standard-96
  • n2-highmem-96
  • n2-highcpu-96
  • n2-highmem-128
  • n2-standard-128

Rendimiento de red deficiente al usar gVNIC

Las máquinas virtuales con Windows Server 2022 y Windows 11 que usen el paquete GooGet del controlador gVNIC de la versión 1.0.0@44 o anterior pueden experimentar un rendimiento de red deficiente al usar NIC virtual de Google (gVNIC).

Para solucionar este problema, actualiza el paquete GooGet del controlador gVNIC a la versión 1.0.0@45 o posterior. Para ello, sigue estos pasos:

  1. Para comprobar qué versión del controlador está instalada en tu VM, ejecuta el siguiente comando desde una sesión de PowerShell o del símbolo del sistema de administrador:

    googet installed

    El resultado es similar al siguiente:

    Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...

  2. Si la versión del controlador google-compute-engine-driver-gvnic.x86_64 es 1.0.0@44 o anterior, actualiza el repositorio de paquetes GooGet ejecutando el siguiente comando desde una sesión de símbolo del sistema o de PowerShell con privilegios de administrador:

    googet update

Los tipos de máquinas con gran número de vCPUs C4, C4D y C3D no admiten imágenes del SO Windows

Los tipos de máquina C4 con más de 144 vCPUs y los tipos de máquina C4D y C3D con más de 180 vCPUs no admiten imágenes de SO Windows Server 2012 y 2016. Los tipos de máquinas C4, C4D y C3D más grandes que usan imágenes del SO Windows Server 2012 y 2016 no se podrán iniciar. Para solucionar este problema, selecciona un tipo de máquina más pequeño o usa otra imagen de SO.

Las VMs C3D creadas con 360 vCPUs e imágenes del SO Windows no se podrán iniciar. Para solucionar este problema, selecciona un tipo de máquina más pequeño o usa otra imagen de SO.

Las máquinas virtuales C4D creadas con más de 255 vCPUs y Windows 2025 no se podrán iniciar. Para solucionar este problema, selecciona un tipo de máquina más pequeño o usa otra imagen de SO.

Error de disco genérico en Windows Server 2016 y 2012 R2 para máquinas virtuales M3, C3, C3D y C4D

En este momento, no se puede añadir ni cambiar el tamaño de un Hyperdisk o un disco persistente en una máquina virtual M3, C3, C3D o C4D en ejecución en determinados sistemas operativos Windows. Windows Server 2012 R2 y Windows Server 2016, así como sus variantes de Windows que no son de servidor, no responden correctamente a los comandos de adjuntar y cambiar el tamaño de disco.

Por ejemplo, si se quita un disco de una máquina virtual M3 en ejecución, el disco se desconecta de una instancia de Windows Server sin que el sistema operativo Windows reconozca que el disco ya no está. Las escrituras posteriores en el disco devuelven un error genérico.

Resolución

Debes reiniciar la máquina virtual M3, C3, C3D o C4D que se ejecute en Windows después de modificar un Hyperdisk o un disco persistente para que estos huéspedes reconozcan las modificaciones del disco.