Errores conocidos

Linux Windows

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.

Es posible que no se puedan iniciar las instancias de Compute con el inicio seguro habilitado

En casos excepcionales, es posible que no se puedan iniciar 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 secreto para los PCR de vTPM. Esto puede deberse a una secuencia incorrecta de actualizaciones (por ejemplo, actualizar el 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 nuevos certificados. 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 C4A, C4D, C4 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 de los discos SSD locales, se reinicia una instancia de procesamiento que se ejecuta en ese servidor host con todos los discos conectados, y los datos incluyen todas las escrituras que se completaron antes del error de host.

En el caso de las instancias C4A, C4D, C4 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, verifica los registros de errores del SO para detectar fallas de lectura o escritura después de que se reinicie la instancia de procesamiento.

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

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

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

Si el límite de tu cuota de Persistent Disk es inferior al límite de tu cuota de Hyperdisk, encontrarás errores de QUOTA_EXCEEDED. No puedes crear discos adicionales una vez que se alcanza el límite de Persistent Disk, incluso si te queda cuota de Hyperdisk 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 cargas de trabajo en instancias A4 debido a problemas de firmware en las GPU NVIDIA B200

NVIDIA identificó dos problemas de firmware en las GPU B200, que se usan en las instancias A4, que provocan interrupciones en las cargas de trabajo. Específicamente, si observas interrupciones en las cargas de trabajo en las instancias A4, verifica si se cumple alguna de las siguientes condiciones:

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

Para mitigar este problema, restablece las GPUs. Para evitar el problema, restablece las GPUs en las instancias A4 al menos una vez cada 60 días.

Nota: Si ejecutas en GKE, usa la herramienta de restablecimiento de GPU para restablecer las GPU. Esta herramienta automatiza el proceso de restablecimiento y solo requiere el nombre del nodo de destino.

Posibles errores del host durante la creación de instancias C4 en nodos de instancia única

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

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

La consola en serie es de solo lectura para las instancias de Bare Metal C4 y C4D

No puedes habilitar el acceso interactivo a la consola en serie para las instancias de metal desnudo 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 el uso de SSH con instancias de Compute Engine, consulta Información sobre las conexiones SSH.

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

En el caso de trabajos grandes en clústeres de 32 nodos o más, el tiempo que lleva 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 ni volver a implementar el clúster, puedes modificar manualmente el parámetro UnkillableStepTimeout. Para ello, completa los siguientes pasos:

  Advertencia: Si completas estos pasos, pero no actualizas Cluster Toolkit a la versión 1.65.0 o posterior, estos cambios manuales se sobrescribirán si el clúster se vuelve a implementar con el comando gcluster deploy.

  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 en la Google Cloud consola 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 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.

     Nota: Las implementaciones de Cluster Toolkit suelen configurar un recurso compartido de NFS desde el nodo del controlador para directorios como /etc/slurm y /home. Esta configuración significa que todos los cambios realizados en cloud.conf en el nodo del controlador son visibles automáticamente para todos los nodos de procesamiento.

  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 cambió, ejecuta el siguiente comando:

   scontrol show config | grep UnkillableStepTimeout

El resultado debe reflejar el nuevo valor que estableciste, por ejemplo, UnkillableStepTimeout = 900.

Resuelto: La modificación de las IOPS o el procesamiento en un disco principal de replicación asíncrona con el comando gcloud compute disks update provoca 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, la 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ó correctamente, consulta las propiedades del disco con la gcloud CLI o la consola de Google Cloud para ver los nuevos valores de IOPS y de 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 muestre los metadatos physicalHost del host anterior de la instancia.

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

• Usa el método instances.get o el comando gcloud compute instances describe para recuperar la información correcta de physicalHost.
• Detén y, luego, inicia tu instancia. Este proceso actualiza la información de physicalHost en el servidor de metadatos.
• Espera 24 horas para que se actualice la información de physicalHost de la instancia afectada.

Los valores de baseInstanceName largos 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 que se creen discos cuando se cree la instancia de procesamiento y el valor de baseInstanceName supere 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 nombres de discos idénticos para instancias que tienen patrones de nombres similares. En ese caso, la instancia nueva intentará adjuntar el disco existente. Si el disco ya está conectado a otra instancia de procesamiento, falla la creación de la instancia nueva. Si el disco no está conectado o está en modo de varios escritores, la instancia nueva conecta el disco, lo que podría provocar daños en los datos.

Para evitar conflictos con los nombres de los discos, mantén el valor de baseInstanceName con 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, podría ocurrir una de las siguientes situaciones:

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

  • Si creaste una reserva consumida automáticamente (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.

• Se crea la solicitud de reserva futura correctamente. 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 la instancia de la plantilla. Si deseas reservar recursos para los tipos de máquinas A2, C3 o G2, realiza una de las siguientes acciones:

• Para crear una reserva compartida o un proyecto único nuevo, especifica las propiedades directamente.

• Para crear una nueva solicitud de reserva futura, haz lo siguiente:

  1. Si deseas evitar que una solicitud de reserva futura existente restrinja las propiedades de las solicitudes de reserva futura que puedes crear en tu proyecto actual o en los proyectos con los que se comparte la solicitud de reserva futura, borra la solicitud de reserva futura.

  2. Crea unproyecto único o unasolicitud de reserva futura compartida especificando las propiedades directamente y envíela para su revisión.

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, se produce una falla en la creación del nodo o no se detectan los discos SSD locales como almacenamiento efímero cuando se usa 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 de C3D que tienen más de 30 CPU virtuales pueden experimentar una variabilidad en la capacidad de procesamiento de TCP de flujo único y, en ocasiones, se limitan a 20 o 25 Gbps. Para lograr 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 tu 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:

• Habilita Identity-Aware Proxy para TCP si quieres seguir conectándote a instancias de procesamiento con la función SSH en el navegador de la consola deGoogle Cloud .

• Vuelve a crear la regla de firewall default-allow-ssh para continuar con la conexión a las instancias de procesamiento con SSH en el navegador.

• Conéctate a las instancias de procesamiento con Google Cloud CLI en lugar de SSH en el navegador.

Nombres temporales para los discos

Durante las actualizaciones de 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 la 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 uno de los siguientes eventos. 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 provienen de cualquiera de los siguientes métodos de la API de Compute Engine:

   • Método compute.regions.list
   • Método compute.regions.get
   • Método compute.projects.get

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:

   • items[].quotas[].limit para el método compute.regions.list
   • quotas[].limit para el método compute.regions.get
   • quotas[].limit para el método compute.projects.get

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 se encuentra 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 API.

• Disminuye el límite de tu 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:

  • Sigue los mismos pasos que seguirías para solicitar un ajuste de cuota y solicita un límite de cuota más bajo.
  • Crea una anulación de cuota.

Nota: Configurar una restricción de límite de cuota es solo una solución temporal hasta que corrijas la definición del campo items[].quotas[].limit para método compute.regions.list y la cambies al tipo number. Para que se vuelvan a establecer los límites de cuota predeterminados de los SKU comprometidos a sus valores ilimitados, debes quitar las restricciones de límites de cuotas.

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 automáticamente pueden tardar horas en detenerse y reiniciarse.

Los tipos de máquinas optimizados para aceleradores tienen GPUs conectadas automáticamente. La mayoría de los tipos de máquinas optimizados 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 completarse después de fallas o errores de host. En el caso de los tipos de máquinas optimizados 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 son compatibles con el uso de instancias de GPU. Si creas una instancia con GPU y NIC dinámicas, o agregas NIC dinámicas a una instancia con GPU existente, es posible que se produzcan 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 correctamente, 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 NIC virtuales de la instancia en las NIC físicas del servidor host.

Problemas conocidos de las instancias de Bare Metal

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

Los tipos de máquinas Bare Metal C4D no admiten imágenes de SUSE Linux 15 SP6

Las instancias de metal desnudo 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áquina 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) 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 VM, configura la instancia C4 en 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 del host simulado, el comportamiento de las VMs configuradas en Terminate es el mismo que el de las instancias de metal desnudo C4.

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

Cuando se usa Red Hat Enterprise Linux (RHEL) versión 8 con una instancia de equipo físico 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 metal puro 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.

Se descartan paquetes cuando se usan NIC dinámicas con rangos de IP de alias, reenvío de protocolos o balanceadores de cargas de red de transferencia.

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

• Cuando configuras un rango de IP de alias, el agente invitado crea una ruta local para el rango de IP de alias.
• 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 está establecido 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 IP del alias 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 IP alias 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 para 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 20250901.00 a 20251120.01

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

• El agente de 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.

• Si se borran varias NIC dinámicas, el servidor de metadatos se vuelve 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. En un 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 que use 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 Cómo ver los paquetes instalados por versión del sistema operativo.

Si es necesario, puedes solucionar estos problemas de forma temporal en las instancias que ejecutan las versiones del agente invitado de 20250901.00 a 20251120.01. Para ello, sigue las instrucciones en Compatibilidad con versiones anteriores para revertir a la arquitectura anterior del agente invitado.

La intercepción de paquetes puede provocar que se descarten 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 lo son.

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 reinyección de salida). La finalización anticipada hace que falte el ID de VLAN en el encabezado Ethernet del paquete de entrada. Debido a que el paquete de salida se deriva del paquete de entrada modificado, el paquete de salida también carece del ID de VLAN. Esto genera una selección incorrecta del índice de extremos y la posterior pérdida de paquetes.

Solución alternativa

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

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 Accelerator Optimized de 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 los paquetes ucx y perftest, que son una versión posterior a los paquetes correspondientes en el repositorio de DOCA OFED. Esta falta de coincidencia 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 Accelerator Optimized 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.

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 Google Cloud OSLogin. Sin embargo, las conexiones SSH administradas por metadatos no se ven afectadas y siguen funcionando.

Formatos de URL admitidos para la secuencia de comandos de inicio

Si tu instancia de procesamiento usa la versión 20251115.00 del agente 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 la CLI de gcloud: 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ó las versiones secundarias de Debian 11 (Bullseye) del repositorio 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 del upstream 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 dependencia, lo que establece NetworkManager como el "renderizador" predeterminado para netplan. Más específicamente, 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 se reinició la instancia de procesamiento 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 Compute 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 experimentas 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 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 local se haya quitado 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 te encuentras con 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 y muestre el siguiente error en la consola 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 Cloud con un initramfs (sistema de archivos 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 regenera initramfs, lo que sucede durante las actualizaciones del sistema, estas marcas se omiten de forma predeterminada. Esto genera un initramfs más pequeño y 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 initramfs. Si se migra un sistema con un initramfs que carece de estos módulos NVMe a una instancia de C3, el proceso de arranque 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 sistema ya se ve afectado por el problema, crea una instancia de procesamiento temporal de rescate. 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 los 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 NICs 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 producir la pérdida de 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 del repositorio. 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 de SO muestran un mensaje de acceso después de la conexión

En algunas instancias que usan el acceso de 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 Google Cloud imágenes públicas. Te recomendamos que reemplaces el controlador 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 procesamiento de Windows 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 provoca restricciones de acceso inesperadas en Windows a los discos sujetos a objetos de política de grupo (GPO) que tienen como objetivo el almacenamiento extraíble.

No se pudo iniciar el agente invitado

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

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

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

Solución 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 son inglés

El agente invitado de Windows identifica las cuentas y los grupos de administrador con la coincidencia de cadenas. Por lo tanto, las funciones de administración de credenciales solo funcionan correctamente cuando usas nombres en inglés para las cuentas y los grupos de usuarios, por ejemplo, Administrators. Si usas nombres en un idioma que no sea inglés, es posible que las funciones de administración de credenciales, como la generación o el restablecimiento de 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 los 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 CPU virtuales.
• Si necesitas usar un tipo de máquina C3D que tenga 180 o 360 CPU virtuales, usa una versión posterior de Windows Server.

Windows Server 2025 y Windows 11 24H2/25H2: Compatibilidad con la suspensión y reanudación

Windows Server 2025, Windows 11 24h2 y Windows 11 25h2 no pueden reanudarse 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 ni Windows 11 25H2.

Errores cuando se mide el desvío de tiempo NTP con w32tm en 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 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 VirtIO. Las instancias de Compute 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 que use el nuevo tipo de máquina.
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 permitir que tu instancia de procesamiento se ejecute correctamente. Revisa los requisitos de migración para verificar que los cumplas. 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 Compute que usan la interfaz de disco NVMe y una imagen del SO Microsoft Windows tienen un límite de conexión de discos de 16. Este límite se aplica a las instancias T2A, a todas las instancias de procesamiento de tercera generación y a las instancias de procesamiento de cuarta generación de la serie N (N4, N4D y N4A). Para evitar errores, consolida tu almacenamiento de Hyperdisk y Persistent Disk en un máximo de 16 discos por instancia de procesamiento. El almacenamiento SSD local no se incluye en este problema.

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 tu 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 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

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 para los volúmenes de Hyperdisk Extreme conectados a instancias 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 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 mediante la ejecución del 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 creadas 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 creadas con más de 255 CPU 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

Advertencia: Windows Server 2012 R2 ya no es compatible y no se recomienda su uso. Actualiza a una versión compatible de Windows Server.

La capacidad de agregar o cambiar el tamaño de un Hyperdisk o un Persistent Disk para una instancia M3, C3, C3D o C4D en ejecución no funciona como se espera en invitados específicos de Windows en este momento. 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 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 muestran 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.