Errores conocidos

En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas 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.

No puedes usar la consola de Google Cloud para crear VMs Spot para A4 y A3 Ultra.

No puedes crear una VM Spot que use la serie de máquinas A4 o A3 Ultra con la Google Cloud consola. Específicamente, en la página Crear una instancia, después de seleccionar un tipo de GPU para estas series de máquinas en el panel Configuración de máquina, el panel Avanzado indica que Se requiere una reserva y no te permite seleccionar Spot en la lista Modelo de aprovisionamiento de VM.

Para solucionar el problema, usa gcloud CLI o REST para crear VMs Spot para A4 y A3 Ultra. Como alternativa, puedes usar la consola de Google Cloud paracrear VMs de A4 y A3 Ultra que usen el modelo de aprovisionamiento vinculado a la reserva.

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

Cuando usas el comando gcloud compute disks update para modificar las IOPS y el procesamiento en un disco principal de replicación asíncrona, Google Cloud 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, usa Google Cloud CLI o la consola de Google Cloud para ver si las propiedades del disco muestran 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 de VM physicalHost antiguos

Después de experimentar un error de host que mueve una instancia 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 baseInstanceName largos en los grupos de instancias administrados (MIG) pueden provocar conflictos en los nombres de los 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 VM 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 nombres de disco 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, falla la creación de la instancia nueva. Si el disco no está conectado o está en modo multiescritura, la instancia nueva conectará 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, haz lo siguiente:

  • 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 de forma automática (predeterminada), la creación de VMs con propiedades coincidentes no consumirá la reserva.

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

  • Se crea correctamente la solicitud de reserva futura. 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 VM 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 c3-standard-*-lssd y c3d-standard-*-lssd con Google Kubernetes Engine

Cuando usas la API de Google Kubernetes Engine, el grupo de nodos con la SSD local conectada que aprovisionas debe tener la misma cantidad de SSD que el tipo de máquina C3 y C3D seleccionado. Por ejemplo, si planeas crear una VM que use el tipo de máquina c3-standard-8-lssd, debe haber 2 discos SSD, mientras que para un c3d-standard-8-lssd, solo se requiere 1 disco SSD. Si el número de discos no coincide, recibirás un error de configuración incorrecta de SSD local del plano de control de Compute Engine. Consulta el documento Familia de máquinas de uso general para seleccionar la cantidad correcta de discos SSD locales según el tipo de máquina lssd C3 o C3D.

Cuando usas la consola de Google Kubernetes Engine Google Cloud para crear un clúster o grupo de nodos con VMs c3-standard-*-lssd y c3d-standard-*-lssd, se produce una falla en la creación del nodo o una detección de SSD locales como almacenamiento efímero.

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

Las VMs de C3D con más de 30 CPU virtuales pueden experimentar una variedad de capacidad de procesamiento de TCP de flujo único y, en ocasiones, se limitan a 20 a 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 VM que usan un subproceso por núcleo

Si la CPU de tu VM usa un subproceso por núcleo, la métrica de observabilidad de Cloud Monitoring para el uso de CPU en la pestaña Compute Engine > Instancias de VM > Observabilidad solo escala al 50%. Dos subprocesos por núcleo es la configuración predeterminada para todos los tipos de máquina, excepto Tau T2D. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.

Para ver el uso de CPU de la VM 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.

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

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

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

Nombres temporales para los discos

Durante las actualizaciones de la instancia de máquina virtual (VM) 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 VM mediante la adición 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:

  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 raíz

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:

Problemas conocidos de las instancias de Bare Metal

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.

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.

Pérdida de paquetes con tamaños de MTU personalizados

Es posible que una NIC dinámica con una vNIC principal experimente pérdida de paquetes con tamaños de MTU personalizados.

Solución alternativa

Para evitar la pérdida de paquetes, usa uno de los siguientes tamaños de MTU:

  • 1,460 bytes (el valor predeterminado para las redes de VPC)
  • 1,500 bytes (Ethernet estándar)
  • 8,896 bytes (el valor máximo posible)

Interacciones del firewall cuando se reutiliza un ID de VLAN con NIC dinámicas

En una instancia, reutilizar un ID de VLAN para una nueva NIC dinámica tiene implicaciones en el seguimiento de conexiones del firewall. Si borras una NIC dinámica y creas una NIC dinámica de reemplazo que usa el mismo ID de VLAN, las entradas de la tabla de seguimiento de conexiones del firewall no se borran automáticamente. En el siguiente ejemplo, se muestran las consideraciones de seguridad pertinentes:

  1. Una instancia de procesamiento tiene un ejemplo de NIC dinámica con el ID de VLAN 4 conectado a una subred en la red de VPC network-1.
  2. La instancia envía paquetes a la dirección IP de destino y al puerto de destino 192.0.2.7:443. Las reglas de firewall de salida aplicables permiten la conexión saliente.
  3. Dado que las reglas del NGFW de Cloud tienen estado, la conexión saliente permitida crea una entrada de tabla de seguimiento de conexión del firewall que permite paquetes entrantes desde la dirección IP de origen y el puerto de origen 192.0.2.7:443.
  4. Borra la NIC dinámica de ejemplo y crea una NIC dinámica de reemplazo. La NIC dinámica de reemplazo también usa el ID de VLAN 4, pero se conecta a una subred en una red de VPC diferente, network-2.
  5. Todas las entradas no vencidas de la tabla de seguimiento de conexión del firewall que eran aplicables a la NIC dinámica original también son aplicables a la NIC dinámica de reemplazo. Esto significa que un recurso en la red de VPC network-2 puede enviar paquetes cuyas fuentes coincidan con 192.0.2.7:443, y la instancia de procesamiento los acepta sin necesidad de evaluar las reglas de firewall de entrada.

Para obtener más información sobre el seguimiento de conexiones y las reglas de firewall, consulta Especificaciones en la documentación del firewall de nueva generación de Cloud.

Solución

Por instancia, si necesitas crear una NIC dinámica que use el mismo ID de VLAN que una NIC dinámica que se quitó de la instancia, haz lo siguiente:

  • Espera al menos 10 minutos entre la eliminación de la NIC dinámica original y la creación de la NIC dinámica de reemplazo.
  • Detén la instancia, borra la NIC dinámica original y crea la NIC dinámica de reemplazo. Luego, inicia la instancia.

La interceptació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 VM de Linux

Estos son los problemas conocidos de las VMs de Linux.

Las VMs de Ubuntu que usan la versión de imagen del SO v20250530 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 desde cualquier imagen de Ubuntu que ofrece 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 del paquete guest-config 20250328.00 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 genera 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

La VM de SUSE Enterprise no se inicia después de cambiar los tipos de instancias

Después de cambiar el tipo de instancia de una VM de SUSE Linux Enterprise, es posible que no se inicie con el siguiente error que se repite en la consola en serie:

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

Causa principal

SUSE crea sus imágenes de nube con un initramfs (sistema de archivos RAM inicial) versátil que admite varios tipos de instancias. 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 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 sistema ya se ve afectado por el problema, crea una VM de recuperación temporal. Usa el comando chroot para acceder al disco de arranque de la VM 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 VMs Z3 en las imágenes de SUSE Linux Enterprise Server (SLES) 12 tienen un rendimiento significativamente inferior al esperado para los IOPS en discos SSD locales.

Causa raíz

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 VMs de RHEL 7 y CentOS pierden acceso a la red después del reinicio

Si tus VMs 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 VM 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 VM.

El siguiente problema se resolvió el 13 de enero de 2025.

Las imágenes públicas de Google Cloud SUSE no incluyen la configuración de udev requerida para crear symlinks para dispositivos SSD locales de C3 y C3D.

Solución

Para agregar reglas de udev para SUSE y, también, imágenes personalizadas, consulta Symlinks no creados en VMs C3 y C3D con SSD locales.

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

Solució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 VM 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 VM que ejecutan 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 Microsoft StorNVMe en las Google Cloud imágenes públicas. Te recomendamos que reemplaces el controlador NVME en las VMs 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 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.

Windows Server 2025 y Windows 11 24h2: Compatibilidad con la suspensión y reanudación

Windows Server 2025 y Windows 11 24h2 no pueden reanudarse cuando se suspenden. Hasta que se resuelva este problema, no se admitirá la función de suspensión y reanudación para Windows Server 2025 y Windows 11 24h2.

Errores cuando se mide el desvío de tiempo NTP mediante w32tm en las VMs de Windows

Para las VMs de Windows en Compute Engine que ejecutan NIC 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 VMs de Compute Engine con NIC VirtIO. Las VMs que usan 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 VM de la generación 1 o 2 a una VM 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 VM existente de una serie de máquinas más antigua que usa una interfaz de disco SCSI a una serie de máquinas más reciente que usa una interfaz de disco NVMe, realiza un sysprep del controlador PnP de Windows antes de apagar la VM. 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.

Para actualizar la serie de máquinas de una VM, haz lo siguiente:

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

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

Si la VM nueva no se inicia correctamente, vuelve a cambiarla al tipo de máquina original para que vuelva a funcionar. Debería iniciarse correctamente. Revisa los requisitos de migración para verificar que los cumplas. Luego, vuelve a intentar las instrucciones.

Ancho de banda limitado con gVNIC en VMs de Windows

El controlador de gVNIC empaquetado en las imágenes de Windows que ofrece Compute Engine puede alcanzar hasta 50 Gbps de ancho de banda de red en las instancias de Windows, tanto para el rendimiento de red estándar como para el rendimiento de red Tier_1 por VM. Una versión actualizada del controlador de gVNIC puede ofrecer un rendimiento de velocidad de línea (hasta 200 Gbps) y compatibilidad con marcos jumbo.

El controlador actualizado solo está disponible para las series de máquinas de tercera generación y posteriores (excepto N4). Para obtener más información, consulta Cómo actualizar la versión de gVNIC en el SO de Windows.

Conexión limitada del recuento de discos para series de máquinas de VM más recientes

Las VMs que se ejecutan en Microsoft Windows con la interfaz de disco NVMe (que incluye a T2A, todas las VMs de tercera generación y versiones posteriores) tienen un límite de conexión de discos de 16. Para evitar errores, consolida tu almacenamiento de Hyperdisk y Persistent Disk en un máximo de 16 discos por VM. El almacenamiento SSD local no se incluye en este problema.

Reemplaza el controlador de NVME en las VMs creadas antes de mayo de 2022

Si deseas usar NVMe en una VM que usa Microsoft Windows y la VM 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 VM antes de cambiar el tipo de máquina a una serie de máquinas de tercera generación o antes de crear una instantánea del disco de arranque que se usará para crear VMs nuevas que usen una máquina de tercera generación.

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 SSD local en Microsoft Windows con VMs de C3 y C3D

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

Se están realizando mejoras en el rendimiento.

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

Las VMs 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 VM, 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 C4D y C3D grandes no son compatibles con las imágenes de SO de Windows

Los tipos de máquinas C4D y C3D con más de 180 CPU virtuales no admiten imágenes de SO de Windows Server 2012 y 2016. Los tipos de máquinas 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 VMs 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 VMs C4D creadas con más de 255 CPUs virtuales y 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 VMs M3, C3, C3D y C4D

La capacidad de agregar o cambiar el tamaño de un Hyperdisk o un Persistent Disk para una VM 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 variantes correspondientes de Windows sin servidores, no responden de forma correcta a los comandos de conexión o cambio de tamaño de discos.

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

Solución

Debes reiniciar la VM M3, C3, C3D o C4D que se ejecuta en Windows después de modificar un Hyperdisk o un Persistent Disk para que los invitados reconozcan las modificaciones del disco.