Errores conocidos

En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas instancias de Compute Engine. Para problemas que afectan de forma específica a Confidential VMs, consulta Limitaciones de Confidential VM.

Problemas generales

Los siguientes problemas proporcionan orientación para solucionar problemas o información en general.

El agente invitado ignora la opción ip_forwarding en la configuración de NetworkInterfaces

La sección de configuración NetworkInterfaces del agente invitado incluye una opción ip_forwarding. Puedes usar esta opción para evitar que el agente instale direcciones IP de alias y rutas de reenvío de IP desde el servidor de metadatos (MDS). Sin embargo, para las versiones del agente invitado que usan la arquitectura basada en complementos, que incluye el complemento principal, el agente ignora la opción de configuración ip_forwarding. El agente invitado instala direcciones IP de alias y rutas de reenvío de IP, independientemente de la configuración. Para obtener más información, consulta la documentación del agente invitado. Este problema te afecta si usas SAP Netweaver pacemaker en una configuración con un balanceador de cargas interno (ILB).

Para mitigar este problema, establece el atributo de metadatos enable-guest-agent-core-plugin en false, como se describe en la documentación de retrocompatibilidad.

Es posible que las instancias de procesamiento con el inicio seguro habilitado no se inicien

En casos excepcionales, es posible que las instancias de VM protegida creadas antes del 7 de noviembre de 2025 con el inicio seguro habilitado o las que usan software de encriptación de disco completo o sellado de secretos en los PCR de vTPM no se inicien. Esto puede deberse a una secuencia incorrecta de actualizaciones (por ejemplo, actualizar shim sin tener los certificados adecuados) después de que venzan los certificados de inicio seguro de Microsoft en la segunda mitad de 2026.

Solución

Para resolver este problema, actualiza tus instancias de procesamiento con los certificados nuevos. Para obtener más información, consulta la guía de vencimiento de los certificados de inicio seguro de Microsoft.

Es posible que los discos SSD locales conectados a instancias C4, C4A, C4D, C4N y H4D no capturen todas las escrituras en caso de pérdida de energía

Después de una pérdida de energía en un servidor host, si Compute Engine puede recuperar los datos en los discos SSD locales, una instancia de procesamiento que se ejecuta en ese servidor host se reinicia con todos los discos conectados, y los datos incluyen todas las escrituras que se completaron antes del error del host.

En el caso de las instancias C4, C4A, C4D, C4N y H4D, es posible que los discos SSD locales restablecidos no incluyan las escrituras que se completaron inmediatamente antes del evento de pérdida de energía. Cuando se reinicia la instancia de procesamiento, la lectura de una dirección de bloque lógico (LBA) afectada devuelve un error que indica que la LBA no se puede leer. Si tu instancia de procesamiento experimenta un reinicio inesperado, revisa los registros de errores del SO para ver si hay fallas de lectura o escritura después de que se reinicie la instancia de procesamiento.

La capacidad de Hyperdisk Throughput y Hyperdisk Extreme consume cuotas de Persistent Disk de forma simultánea

Cuando creas discos de Hyperdisk Throughput o Hyperdisk Extreme, la capacidad del disco se descuenta de dos cuotas separadas al mismo tiempo: la cuota específica de Hyperdisk y una cuota correspondiente de Persistent Disk.

  • Hyperdisk Throughput Capacity (GB) (HDT-TOTAL-GB) también se descuenta de tu cuota de Persistent disk standard (GB) (DISKS-TOTAL-GB).
  • Hyperdisk Extreme Capacity (GB) (HDX-TOTAL-GB) también se descuenta de tu cuota de Persistent disk SSD (GB) (SSD-TOTAL-GB).

Si tu límite de cuota de Persistent Disk es inferior al límite de cuota de Hyperdisk, encontrarás errores QUOTA_EXCEEDED. No puedes crear discos adicionales una vez que se alcanza el límite de Persistent Disk, incluso si tienes cuota de Hyperdisk restante disponible.

Para mitigar este problema, debes ajustar ambas cuotas cada vez que solicites un aumento. Cuando ajustas tu cuota de HDT-TOTAL-GB o HDX-TOTAL-GB, también debes ajustar tu cuota de DISKS-TOTAL-GB o SSD-TOTAL-GB, respectivamente.

Interrupciones de las cargas de trabajo en las instancias A4 debido a problemas de firmware de las GPU NVIDIA B200

NVIDIA identificó dos problemas de firmware para las GPUs B200, que usan las instancias A4. Estos problemas pueden causar interrupciones en la carga de trabajo, como que el comando nvidia-smi no responda. Si notas interrupciones de la carga de trabajo en las VMs A4, confirma que se cumpla una de las siguientes condiciones:

  • El tiempo de actividad de la VM (lastStartTimestamp) supera los 65 días.
  • En los registros, se muestra un mensaje Xid 149 que menciona 0x02a.

Si se cumple una de estas condiciones, debes restablecer las GPU que están conectadas a tus VMs A4. Para evitar interrupciones futuras en tu carga de trabajo debido a problemas de firmware, te recomendamos que restablezcas tus GPUs al menos una vez cada 60 días. Para obtener más información, consulta Restablece las GPU.

Posibles errores de host durante la creación de instancias C4 en nodos de usuario único

Las instancias de tipo de máquina C4 que se ejecutan en nodos de usuario único pueden experimentar cierres inesperados debido a errores del host o fallas en la creación de instancias.

Para solucionar este problema, Google limitó a 20 la cantidad máxima de instancias C4 permitidas por nodo de usuario único.

La consola en serie es de solo lectura para las instancias de equipos físicos C4 y C4D

No puedes habilitar el acceso interactivo a la consola en serie para las instancias de equipos físicos C4 o C4D; la consola en serie es de solo lectura.

Solución alternativa

Para ejecutar comandos de forma interactiva, puedes conectarte a la instancia con SSH después de que se inicie. Para obtener información sobre cómo usar SSH con instancias de Compute Engine, consulta Acerca de las conexiones SSH.

La cancelación de trabajos en clústeres de HPC de 32 nodos o más supera el tiempo de espera

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

Para resolver este problema, usa uno de los siguientes métodos:

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

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

  • Si no puedes actualizar Cluster Toolkit o volver a implementar el clúster, puedes modificar de forma manual el parámetro UnkillableStepTimeout completando los siguientes pasos:

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

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

      Puedes encontrar el nombre y la dirección IP exactos del nodo del controlador principal con la consola de Google Cloud y navegando a la página Instancias de VM.

    2. Crea una copia de seguridad del archivo cloud.conf actual. Por lo general, este archivo se encuentra en /etc/slurm/.

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

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

    4. Agrega o modifica la línea que contiene UnkillableStepTimeout. Por ejemplo, establece 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 parámetro de configuración en todo el clúster sin necesidad de un reinicio completo.

Verifica la corrección

Para verificar que el parámetro de configuración haya cambiado, ejecuta el siguiente comando:

   scontrol show config | grep UnkillableStepTimeout

El resultado debería reflejar el valor nuevo que estableciste, por ejemplo: UnkillableStepTimeout = 900.

Resuelto: Modificar las IOPS o la capacidad de procesamiento en un disco principal de replicación asíncrona con el comando gcloud compute disks update genera un error falso

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

Cuando usas el comando gcloud compute disks update para modificar las IOPS y la capacidad de procesamiento en un disco principal de replicación asíncrona, gcloud CLI muestra un mensaje de error, incluso si la actualización se realizó correctamente.

Para verificar con precisión que una actualización se realizó de forma correcta, revisa las propiedades del disco con gcloud CLI o la consola de Google Cloud para ver los nuevos valores de IOPS y capacidad de procesamiento. Para obtener más información, consulta Consulta la configuración de rendimiento aprovisionada de Hyperdisk.

Es posible que el servidor de metadatos muestre metadatos antiguos de la instancia de procesamiento de physicalHost

Después de experimentar un error de host que mueve una instancia de procesamiento a un host nuevo, cuando consultas el servidor de metadatos, es posible que se muestren los metadatos physicalHost del host anterior de la instancia.

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

Los valores largos de baseInstanceName en los grupos de instancias administrados (MIG) pueden causar conflictos de nombres de discos

En un MIG, pueden producirse conflictos de nombres de discos si la plantilla de instancias especifica los discos que se crearán cuando se cree la instancia de procesamiento y el valor de baseInstanceName supera los 54 caracteres. Esto sucede porque Compute Engine genera nombres de discos con el nombre de la instancia como prefijo.

Cuando se generan nombres de discos, si el nombre resultante supera el límite de 63 caracteres del nombre del recurso, Compute Engine trunca los caracteres excedentes del final del nombre de la instancia. Este truncamiento puede generar la creación de nombres de discos idénticos para instancias que tienen patrones de nombres similares. En ese caso, la instancia nueva intentará conectar el disco existente. Si el disco ya está conectado a otra instancia de procesamiento, la creación de la instancia nueva falla. Si el disco no está conectado o está en modo multiescritura, la instancia nueva conecta el disco, lo que puede provocar daños en los datos.

Para evitar conflictos de nombres de discos, mantén el valor baseInstanceName en una longitud máxima de 54 caracteres.

Crear reservas o solicitudes de reserva futuras con una plantilla de instancias que especifique causas de problemas de tipos de máquina como A2, C3 o G2.

Si usas una plantilla de instancias que especifica un tipo de máquina A2, C3 o G2 para crear una reserva o crear y enviar una solicitud de reserva futura para su revisión, se producirán problemas. En particular, puede ocurrir una de las siguientes situaciones:

  • Es posible que falle la creación de la reserva. Si se ejecuta de forma correcta, se aplica una de las siguientes opciones:

    • Si creaste una reserva consumida de forma automática (predeterminada), la creación de instancias de procesamiento con propiedades coincidentes no consumirá la reserva.

    • Si creaste una reserva específica, fallará la creación de instancias de procesamiento para orientar la reserva de forma específica.

  • La creación de la solicitud de reserva futura se realiza de forma correcta. Sin embargo, si la envías para su revisión, Google Cloud rechazará tu solicitud.

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

Limitaciones cuando se usan tipos de máquinas -lssd con Google Kubernetes Engine

Cuando usas la API de Google Kubernetes Engine, el grupo de nodos que aprovisionas con discos SSD locales debe tener la misma cantidad de discos SSD locales que el tipo de máquina C4, C3 o C3D seleccionado. Por ejemplo, si planeas crear una instancia de procesamiento que use el tipo de máquina c3-standard-8-lssd, debe haber dos discos SSD locales. Si usas el tipo de máquina c3d-standard-8-lssd, solo se requiere un disco. 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 Tipos de máquinas que conectan discos SSD locales de forma automática para seleccionar la cantidad correcta de discos SSD locales según el tipo de máquina lssd.

Si usas la consola de Google Kubernetes Engine Google Cloud para crear un clúster o un grupo de nodos, la creación del nodo falla o los discos SSD locales no se detectan como almacenamiento efímero cuando usas cualquiera de los siguientes tipos de máquinas:

  • c4-standard-*-lssd
  • c4-highmem-*-lssd
  • c3-standard-*-lssd
  • c3d-standard-*-lssd

Variabilidad de la capacidad de procesamiento de TCP de un solo flujo en las instancias de C3D

Las instancias C3D que tienen más de 30 CPUs virtuales pueden experimentar una variabilidad de la capacidad de procesamiento de TCP de flujo único y, en ocasiones, se limitan a 20 a 25 Gbps. Para alcanzar tasas más altas, usa varios flujos de TCP.

La métrica de observabilidad del uso de CPU es incorrecta para las instancias de procesamiento que usan un subproceso por núcleo

Si la CPU de tu instancia de procesamiento usa un subproceso por núcleo, la métrica de Cloud Monitoring para el uso de CPU en la pestaña Observabilidad* de la página Instancias de VM en la consola de Compute Engine Google Cloud solo escala al 50%. Dos subprocesos por núcleo es la configuración predeterminada para la mayoría de los tipos de máquinas. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.

Para ver el uso de CPU de la instancia de procesamiento normalizado al 100%, consulta el uso de CPU en el Explorador de métricas. Para obtener más información, consulta Crea gráficos con el Explorador de métricas.

Las conexiones SSH en el navegador de la consola deGoogle Cloud pueden fallar si usas reglas de firewall personalizadas

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

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

Nombres temporales para los discos

Durante las actualizaciones de las instancias de procesamiento que se iniciaron con el comando gcloud compute instances update o el método de la API instances.update, Compute Engine podría cambiar temporalmente el nombre de los discos de tu instancia de procesamiento agregando cualquiera de los siguientes sufijos al nombre original:

  • -temp
  • -old
  • -new

Compute Engine quita el sufijo y restablece los nombres originales de los discos a medida que se completa la actualización.

Mayor latencia para algunos Persistent Disk debido al cambio de tamaño del disco

En algunos casos, cambiar el tamaño de los Persistent Disk grandes (~3 TB o más) puede ser perjudicial para el rendimiento de E/S del disco. Si te afecta este problema, es posible que tus Persistent Disks experimenten un aumento de la latencia durante la operación de cambio de tamaño. Este problema puede afectar a los Persistent Disks de cualquier tipo.

Tus procesos automatizados pueden fallar si usan datos de respuesta de la API sobre tus cuotas de compromiso basadas en recursos

Tus procesos automatizados que consumen y usan datos de respuesta de la API sobre tus cuotas de compromiso basadas en recursos de Compute Engine pueden fallar si ocurre cada una de las siguientes situaciones. Tus procesos automatizados pueden incluir cualquier fragmento de código, lógica empresarial o campos de base de datos que usen o almacenen las respuestas de la API.

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

  2. Usas un int en lugar de un number 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 maneras para cada método:

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

    Si deseas obtener más información sobre las cuotas de compromisos y SKU comprometidos, consulta Cuotas de compromisos y recursos comprometidos.

Causa principal

Cuando tienes una cuota limitada, si defines el campo items[].quotas[].limit o quotas[].limit como un tipo int, es posible que los datos de respuesta de la API de tus límites de cuota aún se encuentren dentro del rango para el tipo int y puede que el proceso automatizado no se interrumpa. Sin embargo, cuando el límite de cuota predeterminado es ilimitado, la API de Compute Engine devuelve un valor para el campo limit que queda fuera del rango definido por el tipo int. Tu proceso automatizado no puede consumir el valor que devuelve el método de la API y, como resultado, falla.

Cómo solucionar este problema

Puedes solucionar este problema y seguir generando tus informes automatizados de las siguientes maneras:

  • Recomendado: Sigue la documentación de referencia de la API de Compute Engine y usa los tipos de datos correctos para las definiciones de métodos de API. Específicamente, usa el tipo number para definir los campos items[].quotas[].limit y quotas[].limit de tus métodos de la API.

  • Disminuye el límite de cuota a un valor inferior a 9,223,372,036,854,775,807. Debes establecer 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 maneras:

Problemas conocidos de las instancias de GPU

En la siguiente sección, se describen los problemas conocidos de las instancias de GPU de Compute Engine.

Los tipos de máquinas optimizadas para aceleradores que tienen discos SSD locales conectados de forma automática pueden tardar horas en finalizar y reiniciarse

Los tipos de máquinas optimizados para aceleradores tienen GPUs conectadas automáticamente. La mayoría de los tipos de máquinas optimizadas para aceleradores de la serie A, con la excepción de A2 estándar, tienen discos SSD locales conectados automáticamente.

Los tipos de máquinas optimizadas para aceleradores no admiten la migración en vivo, y debes establecer su política de mantenimiento del host en TERMINATE. Estos tipos de máquinas pueden tardar hasta una hora en finalizar después de fallas o errores de host. En el caso de los tipos de máquinas optimizadas para aceleradores que tienen discos SSD locales conectados automáticamente, el proceso de finalización puede tardar varias horas.

Errores de creación y disminución del rendimiento cuando se usan NIC dinámicas con instancias de GPU

Las NIC dinámicas no se admiten para usarse con instancias de GPU. Si creas una instancia de GPU con NIC dinámicas o agregas NIC dinámicas a una instancia de GPU existente, pueden ocurrir los siguientes problemas:

  • La operación falla con un error como el siguiente:

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • La operación se realiza de forma correcta, pero la instancia experimenta una disminución del rendimiento, como un ancho de banda de red significativamente menor.

Estos problemas se producen porque la configuración de NIC dinámica genera errores cuando Compute Engine intenta distribuir las vNIC de la instancia entre las NIC físicas del servidor host.

Problemas conocidos de las instancias de equipos físicos

Estos son los problemas conocidos de las instancias de Compute Engine Bare Metal.

Iniciar el mantenimiento del host de forma manual no funciona para las instancias X4

Para las instancias X4, el procedimiento descrito en Inicia un evento de mantenimiento del host de forma manual no funciona.

Solución alternativa

  1. Detén la instancia X4.
  2. Después de que el estado de la instancia cambie a TERMINATED, inicia la instancia X4.

Para obtener información sobre cómo detener o reiniciar una instancia X4, consulta Detén o reinicia una instancia de Compute Engine.

Los tipos de máquinas bare metal C4D no admiten imágenes de SUSE Linux 15 SP6

Las instancias de equipos físicos C4D no pueden ejecutar el SO SUSE Linux Enterprise Server (SLES) versión 15 SP6.

Solución alternativa

En su lugar, usa SLES 15 SP5.

La simulación del mantenimiento del host no funciona para 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 alternativa

Usa instancias de máquina virtual (VM) que se crearon 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 VM, configura la instancia C4 como Terminate en lugar de usar la migración en vivo durante los eventos de mantenimiento del host.

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

Durante un evento de mantenimiento de host simulado, el comportamiento de las VMs configuradas en Terminate es el mismo que el de las instancias de equipos físicos C4.

Rendimiento más bajo de lo esperado con instancias de equipos físicos Z3 en RHEL 8

Cuando usas la versión 8 de Red Hat Enterprise Linux (RHEL) con una instancia de equipos físicos Z3, el rendimiento de la red es inferior al esperado.

Causa principal

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

Solución alternativa

Usa una versión más reciente de RHEL o un sistema operativo diferente cuando trabajes con instancias de equipos físicos 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 las interfaces de red dinámicas.

Paquetes descartados cuando se usan NIC dinámicas con rangos de alias de IP, reenvío de protocolos o balanceadores de cargas de red de transferencia

El agente invitado agrega rutas locales de forma automática en las siguientes situaciones para las vNIC, pero no para las NIC dinámicas:

  • Cuando configuras un rango de alias de IP, el agente invitado crea una ruta local para el rango de alias de IP.
  • Cuando creas una instancia de destino que hace referencia a una instancia de procesamiento para el reenvío de protocolos, el agente invitado crea una ruta local para la dirección IP de la regla de reenvío asociada.
  • Cuando agregas un backend a un balanceador de cargas de red de transferencia, el agente invitado crea una ruta local para la dirección IP de la regla de reenvío asociada.

Debido a que no se agregan las rutas locales para las NIC dinámicas, es posible que la NIC dinámica experimente paquetes descartados.

Para resolver este problema, agrega las direcciones IP de forma manual de la siguiente manera:

  1. Conéctate a la instancia con SSH.

  2. Si configuras un rango de alias de IP, haz lo siguiente. En caso contrario, puede omitir este paso.

    1. En /etc/default/instance_configs.cfg, asegúrate de que el parámetro de configuración ip_aliases esté establecido en true.

    2. Si el parámetro de configuración ip_aliases se establece en false, modifica el archivo para cambiarlo a true y, luego, reinicia el agente invitado:

      systemctl restart google-guest-agent

  3. Configura una ruta local para el rango de alias de IP o la dirección IP de la regla de reenvío con el siguiente comando:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    Reemplaza lo siguiente:

    • IP_ADDRESS: Es el rango de alias de IP o la dirección IP de la regla de reenvío para la que deseas agregar una ruta local.
    • DYNAMIC_NIC_DEVICE_NAME: Es el nombre del dispositivo de la NIC dinámica a la que deseas agregar una ruta local. Por ejemplo, a-gcp.ens4.3

Problemas con la instalación y la administración de NIC dinámicas en las versiones del agente invitado de la 20250901.00 a la 20251120.01

Si configuras la administración automática de NIC dinámicas y tu instancia ejecuta el agente invitado en una versión de 20250901.00 a 20251120.01, es posible que encuentres los siguientes problemas:

  • El agente invitado no puede instalar ni administrar NIC dinámicas en el SO invitado de tu instancia.

    Es posible que recibas un error que incluya Cannot find device cuando ejecutes comandos en el SO invitado que hagan referencia a NIC dinámicas.

  • Borrar varias NIC dinámicas hace que el servidor de metadatos sea inaccesible.

Causa principal

A partir de la versión 20250901.00, el agente invitado migró a una nueva arquitectura basada en complementos para mejorar la modularidad. Al principio, la nueva arquitectura no admitía la instalación y administración automáticas de NIC dinámicas.

Solución

Para resolver estos problemas, actualiza tu instancia para usar la versión 20251205.00 o posterior del agente invitado:

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

Si es necesario, puedes solucionar estos problemas de forma temporal para las instancias que ejecutan las versiones 20250901.00 a 20251120.01 del agente de invitado. Para ello, sigue las instrucciones que se indican en Retrocompatibilidad y revierte a la arquitectura anterior del agente de invitado.

La intercepción de paquetes puede provocar la pérdida de paquetes debido a la falta de etiquetas de VLAN en los encabezados de Ethernet

La interceptación de paquetes cuando se usa la NIC dinámica puede provocar la pérdida de paquetes. Los paquetes descartados pueden ocurrir cuando la canalización se finaliza antes de tiempo. El problema afecta tanto a los modos basados en sesiones como a los que no se basan en sesiones.

Causa principal

Los paquetes descartados se producen durante la interceptación de paquetes cuando la canalización se finaliza antes de tiempo (interceptación de entrada y reinserción de salida). La finalización anticipada hace que falte el ID de VLAN en el encabezado de Ethernet del paquete de entrada. Debido a que el paquete de salida se deriva del paquete de entrada modificado, el paquete de salida tampoco tiene el ID de VLAN. Esto genera una selección incorrecta del índice del extremo y la posterior pérdida de paquetes.

Solución alternativa

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

Las operaciones de NIC dinámicas fallan cuando una instancia de procesamiento se encuentra en varios grupos de instancias

Si agregas o borras una NIC dinámica, y la operación se detiene en un estado RUNNING con un 0% de progreso y, finalmente, falla con un INTERNAL_ERROR, es posible que se deba a que la instancia de procesamiento se encuentra en varios grupos de instancias (administrados o no administrados).

Para permitir que se complete la operación, quita la instancia de todos los grupos de instancias, excepto uno. Puedes quitar una instancia de un grupo de instancias administrado o quitar una instancia de un grupo de instancias no administrado.

Problemas conocidos de las instancias de procesamiento de Linux

Estos son los problemas conocidos de las instancias de procesamiento de Linux.

Error de actualización de paquetes en Rocky Linux 9.7

dnf update falla en las imágenes de Rocky Linux optimizado para aceleradores con la versión v20251113 o anterior (por ejemplo, rocky-linux-9-optimized-gcp-nvidia-latest-v20251113) debido a un conflicto de dependencia de paquetes. Es posible que veas un error similar al siguiente:

[root@rockylinux9 ~]# dnf update
CIQ SIG/Cloud Next for Rocky Linux 9 37 MB/s | 49 MB 00:01
CIQ SIG/Cloud Next Nonfree for Rocky Linux 9 4.4 MB/s | 1.5 MB 00:00
NVIDIA DOCA 2.10.0 packages for EL 9.5 239 kB/s | 160 kB 00:00
Google Compute Engine 38 kB/s | 8.2 kB 00:00
Google Cloud SDK 59 MB/s | 154 MB 00:02
Rocky Linux 9 - BaseOS 24 MB/s | 6.3 MB 00:00
Rocky Linux 9 - AppStream 36 MB/s | 11 MB 00:00
Rocky Linux 9 - Extras 124 kB/s | 16 kB 00:00
Error:
 Problem 1: package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1(HNS_1.0)(64bit), but none of the providers can be installed
  - package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1()(64bit), but none of the providers can be installed
  - cannot install both libibverbs-51.0-3.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-51.0-5.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-2.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-3.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-4.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-5.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-3.el9_7_ciq.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-2.el9.x86_64 from baseos and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install the best update candidate for package perftest-25.01.0-0.70.g759a5c5.2501060.x86_64
  - cannot install the best update candidate for package libibverbs-2501mlnx56-1.2501060.x86_64
 Problem 2: package ucx-ib-mlx5-1.18.0-1.2501060.x86_64 from @System requires ucx(x86-64) = 1.18.0-1.2501060, but none of the providers can be installed
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from @System
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from doca
  - cannot install the best update candidate for package ucx-ib-mlx5-1.18.0-1.2501060.x86_64
  - cannot install the best update candidate for package ucx-1.18.0-1.2501060.x86_64
...
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Causa principal

Existe un conflicto de versión del paquete de espacio de usuario entre las versiones de DOCA OFED anteriores a la 3.20 y Rocky Linux 9.7. Específicamente, Rocky Linux 9.7 incluye paquetes ucx y perftest que son una versión posterior a los paquetes correspondientes en el repositorio de DOCA OFED. Esta discrepancia de versiones hace que dnf update falle con errores de resolución de dependencias.

Solución

Antes de realizar una actualización completa del sistema, actualiza el paquete del repositorio de DOCA:

sudo dnf update doca-repo
sudo dnf update

Las imágenes de Rocky Linux optimizadas para aceleradores compiladas en diciembre de 2025 (por ejemplo, rocky-linux-9-optimized-gcp-nvidia-latest-v20251215) ya incluyen el paquete doca-repo actualizado, por lo que este problema de actualización no está presente en esas compilaciones ni en las posteriores.

El Acceso al SO no es compatible con SLES 16

Un problema de configuración de SSH en SUSE Linux Enterprise Server (SLES) 16 impide el uso de la función OSLogin de Google Cloud . Sin embargo, las conexiones SSH administradas por metadatos no se ven afectadas y siguen funcionando.

Formatos de URL admitidos para el script de inicio

Si tu instancia de procesamiento usa la versión 20251115.00 del agente de invitado, la recuperación de una secuencia de comandos de inicio con la clave de metadatos startup-script-url falla si la URL usa el formato https://storage.googleapis.com/ que se documenta en la página Usa secuencias de comandos de inicio en VMs de Linux.

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

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

Las instancias de VM que usan imágenes de Debian 11 anteriores a la versión v20250728 no pueden ejecutar apt update

El 22 de julio de 2025, la comunidad de Debian quitó los backports de Debian 11 (Bullseye) de la versión upstream principal de Debian. Esta actualización hace que sudo apt update falle con el siguiente error:

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

Causa principal

Debido a que la comunidad de Debian quitó los repositorios de adaptaciones de la rama principal, ya no hay ninguna referencia a bullseye-backports Release.

Solución

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

  • Para actualizar la URL del repositorio y usar el archivo para bullseye-backports, haz lo siguiente:

    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 borrar la URL del repositorio y descartar bullseye-backports, haz lo siguiente:

    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 conectividad de red cuando se reinicia la instancia

Cuando reinicias una instancia de procesamiento de Ubuntu después de instalar el paquete ubuntu-desktop, es posible que las interfaces de red no se configuren correctamente.

Causa principal

El paquete ubuntu-deskop extrae ubuntu-settings como una dependencia, lo que establece NetworkManager como el "renderizador" predeterminado para 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 instancia de procesamiento se reinició y no se puede acceder a ella, haz lo siguiente:

  1. Sigue las instrucciones para rescatar una instancia de procesamiento.

  2. Después de activar la partición del sistema de archivos de Linux de la instancia de procesamiento inaccesible, ejecuta el siguiente comando (reemplaza /rescue por tu punto de activación):

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

  3. Continúa con el reinicio de la instancia de procesamiento inaccesible.

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

Es posible que veas un nombre de dominio completamente calificado (FQDN) incorrecto con la adición del sufijo .local cuando realices una de las siguientes acciones:

  • Actualiza a la versión 20250328.00 del paquete google-compute-engine.
  • Inicia instancias de procesamiento desde cualquier imagen de Ubuntu que ofrezca Canonical con el sufijo de versión v20250530.

Por ejemplo, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

Si tienes este problema, es posible 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 agrega 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 dentro de la ruta de búsqueda en el archivo /etc/resolv.conf hace que se agregue un elemento .local al nombre de host cuando se solicita un FQDN.

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

Solución alternativa

  1. Modifica el archivo de configuración de la 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. Verifica que se haya quitado local 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 versión reciente v20250724 de las imágenes de openSUSE (a partir de opensuse-leap-15-6-v20250724-x86-64) de agosto de 2025, falta el paquete e2fsprogs, que proporciona utilidades para administrar sistemas de archivos. Un síntoma común de este problema es que ves un mensaje de error como command not found cuando intentas usar el comando mkfs.ext4.

Solución alternativa

Si tienes este problema, instala el paquete faltante de forma manual con el administrador 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 instancias de procesamiento de SUSE Enterprise no se inician después de cambiar los tipos de máquinas

Después de cambiar el tipo de máquina de una instancia de procesamiento que ejecuta SUSE Enterprise Linux, es posible que la instancia no se inicie con 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 de RAM inicial) versátil que admite varios tipos de instancias. Esto se logra con las marcas --no-hostonly --no-hostonly-cmdline -o multipath durante la creación inicial de la imagen. Sin embargo, cuando se instala un kernel nuevo o se vuelve a generar el initramfs, lo que sucede durante las actualizaciones del sistema, estas marcas se omiten de forma predeterminada. Esto genera un initramfs más pequeño adaptado específicamente al hardware del sistema actual, lo que podría 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 un sistema con un initramfs que no tiene estos módulos de NVMe se migra a una instancia de C3, el proceso de inicio falla. Este problema también puede afectar a otros tipos de instancias con requisitos de hardware únicos.

Solución alternativa

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

dracut --force --no-hostonly

Si el problema ya afecta al sistema, crea una instancia de procesamiento de rescate temporal. Usa el comando chroot para acceder al disco de arranque de la instancia afectada y, luego, vuelve a generar el initramfs con el siguiente comando:

dracut -f --no-hostonly

Menor rendimiento de IOPS para SSD local en Z3 con imágenes de SUSE 12

Las instancias de procesamiento Z3 que usan imágenes de SUSE Linux Enterprise Server (SLES) 12 tienen un rendimiento significativamente inferior al esperado para las IOPS en discos SSD locales.

Causa principal

Este es un problema dentro de la base de código de SLES 12.

Solución alternativa

No hay un parche de SUSE para solucionar este problema ni se planea implementar uno. En su lugar, debes usar el sistema operativo SLES 15.

Las instancias de procesamiento de RHEL 7 y CentOS pierden acceso a la red después del reinicio

Si tus instancias de procesamiento de CentOS o RHEL 7 tienen varias tarjetas de interfaz de red (NIC) y una de estas NIC no usa la interfaz de VirtIO, es posible que se pierda el acceso a la red durante el reinicio. Esto sucede porque RHEL no admite la inhabilitación de nombres de interfaz de red predictivos si al menos una NIC no usa la interfaz VirtIO.

Solución

La conectividad de red se puede restablecer si detienes e inicias la instancia de procesamiento hasta que se resuelva el problema. Para evitar que se vuelva a perder la conectividad de red, haz lo siguiente:

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

  2. Vuelve a generar la configuración de GRUB.

  3. Reinicia la instancia de procesamiento.

No se pudo verificar la firma de repomd.xml

En los sistemas basados en Red Hat Enterprise Linux (RHEL) o CentOS 7, es posible que veas el siguiente error cuando intentes instalar o actualizar el software con yum. Este error muestra que tienes una clave GPG del repositorio vencida o incorrecta.

Registro de muestra: 

[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 corregir esto, inhabilita la verificación de claves GPG del repositorio en la configuración del repositorio de yum mediante la configuración de repo_gpgcheck=0. En las imágenes base compatibles de Compute Engine, esta configuración se puede encontrar en el archivo /etc/yum.repos.d/google-cloud.repo. Sin embargo, tu instancia de procesamiento puede tener este conjunto en diferentes archivos de configuración de repositorios o herramientas de automatización.

Los repositorios de Yum no suelen usar claves GPG para la validación de repositorios. En su lugar, el extremo https es de confianza.

Para ubicar y actualizar esta configuración, completa los siguientes pasos:

  1. Busca la configuración 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 dicen repo_gpgcheck=1 a repo_gpgcheck=0.

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

  3. Comprueba que se haya actualizado la configuración.

    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 el Acceso al SO muestran un mensaje de acceso después de la conexión

En algunas instancias que usan el Acceso al SO, es posible que recibas el siguiente mensaje de error después de establecer la conexión:

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

Solución

Debes ignorar este mensaje de error.

Problemas conocidos de las instancias de Windows

  • La compatibilidad con NVMe en Windows con el controlador NVMe de la comunidad se encuentra en versión beta, por lo que es posible que el rendimiento no coincida con el de las instancias de Linux. El controlador NVMe de la comunidad se reemplazó por el controlador StorNVMe de Microsoft en las imágenes públicas de Google Cloud . Te recomendamos que reemplaces el controlador de NVME en las instancias de procesamiento creadas antes de mayo de 2022 y uses el controlador Microsoft StorNVMe.
  • Después de crear una instancia, no puedes conectarte a ella de inmediato. Todas las instancias nuevas de Windows usan la herramienta de Preparación del sistema (sysprep) para configurar tu instancia, que puede tardar de 5 a 10 minutos en completarse.
  • 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 de forma inicial dentro de los 30 días. El software que activa el KMS debe volver a activarse cada 180 días, pero el KMS intenta volver a activarlo cada 7 días. Asegúrate de configurar tus instancias de Windows Compute para que permanezcan activas.
  • El software de kernel que accede a registros específicos de modelos no emulados generará fallas de protección generales, que pueden causar una falla del sistema en función del sistema operativo invitado.
  • El controlador vioscsi, que se usa para los discos SCSI, establece la marca removable, lo que hace que los discos se traten como almacenamiento extraíble. Esto causa restricciones de acceso inesperadas en Windows a discos que están sujetos a objetos de política de grupo (GPO) que se orientan al almacenamiento extraíble.

El agente de invitado no se inicia en Windows Server 2012 R2 y versiones anteriores

Después de actualizar los paquetes del agente invitado en instancias que ejecutan sistemas operativos Windows heredados (como Windows Server 2012 R2, Windows Server 2012 o Windows Server 2008 R2). Si ejecutas el objeto binario de forma manual, recibirás un error que indica que no se reconoce el objeto binario.

Upstream Go (Golang) dejó de admitir Windows Server 2012 R2 y versiones anteriores a partir de Go 1.21. Las compilaciones de lanzamiento del agente invitado compiladas con Go 1.21 o versiones posteriores no se pueden ejecutar en estos sistemas operativos.

Solución alternativa

Para resolver este problema, usa uno de los siguientes métodos:

  • Actualiza el sistema operativo: actualiza tu instancia de VM a una versión compatible, como Windows Server 2016 o una versión posterior. Para obtener más información, consulta Fin de la asistencia para Windows.

  • Vuelve a una versión anterior del agente invitado: Si debes seguir ejecutando Windows Server 2012 R2 o una versión anterior, reinstala los paquetes de agentes invitados compatibles desde otra instancia de procesamiento en ejecución o una instantánea:

    1. En la instancia de procesamiento en funcionamiento, verifica la versión de los paquetes google-compute-engine-windows y google-compute-engine-metadata-scripts.
    2. Ve al directorio de caché Googet C:\ProgramData\Googet\cache\` and copy the.goo` de los paquetes anteriores en la VM con errores.
    3. En la VM con errores, instala los paquetes copiados uno por uno con googet install -reinstall PACKAGE_NAME.goo.

  • Para evitar que el agente invitado se actualice a una versión incompatible, inhabilita la actualización automática del agente invitado.

No se inicia el agente invitado

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

Causa raíz El empaquetado del agente invitado de Windows para la versión 20251011.00 configura de forma incorrecta el modo de inicio del agente invitado de Windows como auto en el Administrador de servicios de Windows.

Resolución Para resolver este problema, actualiza tu instancia para usar la versión 20251120.01 o 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 administración de credenciales fallen en las instancias de Windows que usan nombres de idiomas que no están en inglés

El agente invitado de Windows identifica las cuentas y los grupos de administrador con coincidencias de cadenas. Por lo tanto, las funciones de administración de credenciales solo funcionan correctamente cuando usas nombres en inglés para las cuentas de usuario y los grupos, por ejemplo, Administrators. Si usas nombres de idiomas que no sean inglés, es posible que las funciones de administración de credenciales, como generar o restablecer contraseñas, no funcionen como se espera.

Windows Server 2016 no se iniciará en los tipos de máquinas C3D con 180 o más CPUs virtuales

Windows Server 2016 no se iniciará en tipos de máquinas C3D que tengan 180 o 360 CPUs virtuales. Para solucionar este problema, elige una de las siguientes opciones:

  • Si necesitas usar Windows Server 2016, usa un tipo de máquina que tenga menos de 180 CPUs virtuales.
  • Si necesitas usar un tipo de máquina C3D que tenga 180 o 360 CPUs virtuales, usa una versión posterior de Windows Server.

Windows Server 2025 y Windows 11 24h2/25h2: Compatibilidad con suspensión y 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 suspensión y reanudación no será compatible con Windows Server 2025, Windows 11 24h2 y Windows 11 25h2.

Errores cuando se mide el desvío de tiempo NTP con w32tm en las instancias de Windows

Para las instancias de Windows en Compute Engine que usan una interfaz de red VirtIO, hay un error conocido en el que la medición del desvío de NTP produce errores cuando se usa el siguiente comando:

w32tm /stripchart /computer:metadata.google.internal

Los errores se ven de la siguiente manera:

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 instancias de Compute Engine con NIC de VirtIO. Las instancias de procesamiento que usan interfaces de red gVNIC no tienen este problema.

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

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

Windows Server vincula la unidad de inicio a su tipo de interfaz de disco inicial durante el primer inicio. Para cambiar una instancia de procesamiento existente de una serie de máquinas más antigua (generación 1 o 2) que usa una interfaz de disco SCSI a una serie de máquinas más reciente (generación 3 o posterior) que usa una interfaz de disco NVMe, realiza un sysprep del controlador PnP de Windows antes de apagar la instancia de procesamiento. Este sysprep solo prepara los controladores de dispositivos y verifica que se analicen todos los tipos de interfaz de disco para la unidad de inicio en el próximo inicio.

Desde un mensaje de PowerShell, como Administrator, ejecuta lo siguiente:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait

Para cambiar la serie de máquinas de una instancia de procesamiento, haz lo siguiente:

  1. Detén la instancia de procesamiento.
  2. Edita la instancia de procesamiento para usar el tipo de máquina nuevo.
  3. Inicia la instancia de procesamiento.

Si la instancia de procesamiento nueva no se inicia correctamente, edítala para que use el tipo de máquina original y, luego, reiníciala. Esta secuencia de pasos debería hacer que tu instancia de procesamiento se ejecute correctamente. Revisa los requisitos de migración para verificar que los cumples. Luego, vuelve a intentar las instrucciones.

Conexión limitada del recuento de discos para series de máquinas que usan discos NVMe

Las instancias de procesamiento que usan la interfaz de disco NVMe y una imagen de SO de Microsoft Windows tienen un límite de conexión de discos de 16 para series de máquinas específicas. Este límite se aplica a las series de máquinas N4, C3, C3D y M3.

Las series de máquinas como C4, C4D, N4D y M4 admiten más de 16 discos cuando usas un controlador de NVMe compatible, como el controlador de Microsoft StorNVMe.

Este límite no se aplica al almacenamiento en SSD locales. Para evitar errores, consolida tu almacenamiento de Hyperdisk y Persistent Disk en un máximo de 16 discos por instancia de procesamiento para las series de máquinas afectadas.

Reemplaza el controlador de NVME en las instancias de procesamiento creadas antes de mayo de 2022

Si deseas usar NVMe en una instancia de procesamiento que usa Microsoft Windows y la instancia se creó antes del 1 de mayo de 2022, debes actualizar el controlador de NVMe existente en el SO invitado para usar el controlador de Microsoft StorNVMe.

Debes actualizar el controlador de NVMe en la instancia de procesamiento antes de cambiar el tipo de máquina a una serie de máquinas de tercera generación o posterior, o antes de crear una instantánea del disco de arranque que se usará para crear instancias de procesamiento nuevas que usen una serie de máquinas de tercera generación o posterior.

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

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

Menor rendimiento para los discos SSD locales en instancias C3 y C3D que ejecutan Microsoft Windows

En la actualidad, el rendimiento de los SSD locales es limitado para las instancias C3 y C3D que ejecutan Microsoft Windows.

Se están realizando mejoras en el rendimiento.

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

Las instancias de procesamiento basadas en el tipo de máquina n2-standard-80 que ejecutan Microsoft Windows pueden alcanzar un máximo de 80,000 IOPS en todos los volúmenes de Hyperdisk Extreme que están conectados a la instancia.

Solución

Para alcanzar hasta 160,000 IOPS con instancias N2 que ejecutan Windows, elige uno de los siguientes tipos de máquinas:

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

Capacidad de procesamiento de herramientas de redes deficiente cuando se usa gVNIC

Las instancias de procesamiento de Windows Server 2022 y Windows 11 que usan el controlador de gVNIC de GooGet, versión 1.0.0@44, o versiones anteriores, podrían experimentar una capacidad de procesamiento de red deficiente cuando se usa la NIC virtual de Google (gVNIC).

Para resolver este problema, actualiza el paquete GooGet del controlador de gVNIC a la versión 1.0.0@45 o posterior de la siguiente manera:

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

    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 un símbolo del sistema del administrador o una sesión de PowerShell:

    googet update

Los tipos de máquinas de CPU virtuales C4, C4D y C3D grandes no son compatibles con las imágenes de SO de Windows

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

Las instancias de C3D que se crearon con 360 CPUs virtuales y las imágenes de SO de Windows no se iniciarán. Para solucionar este problema, selecciona un tipo de máquina más pequeño o usa otra imagen de SO.

Las instancias de C4D que se crearon con más de 255 CPUs virtuales y las imágenes de Windows 2025 no se iniciarán. 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 instancias M3, C3, C3D y C4D

Por el momento, la capacidad de agregar o cambiar el tamaño de un Hyperdisk o un Persistent Disk para una instancia de M3, C3, C3D o C4D en ejecución no funciona como se espera en determinados invitados de Windows. Windows Server 2012 R2 y Windows Server 2016, así como sus imágenes de cliente de Windows correspondientes, no responden de forma correcta a los comandos de conexión o cambio de tamaño de discos.

Por ejemplo, si quitas un disco de una instancia de M3 en ejecución, el disco se desconecta, pero el sistema operativo Windows no reconoce que el disco ya no está disponible. Las escrituras posteriores en el disco devuelven un error genérico.

Solución

Si usas instancias M3, C3, C3D o C4D que se ejecutan en el sistema operativo Windows y modificas un volumen de Hyperdisk o Persistent Disk, debes reiniciar la instancia de procesamiento para que se reconozcan las modificaciones del disco.