Problemas conocidos

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

Incidencias generales

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

No puedes usar la consola Google Cloud para crear máquinas virtuales Spot para A4 y A3 Ultra

No puedes crear una máquina virtual de Spot que use las series de máquinas A4 o A3 Ultra mediante la consola Google Cloud . En concreto, 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 la máquina, en el panel Avanzado se indica que se requiere una reserva y no se puede seleccionar Spot en la lista Modelo de aprovisionamiento de VMs.

Para solucionar este problema, usa la CLI de gcloud o REST para crear máquinas virtuales Spot para A4 y A3 Ultra. También puedes usar la consola de Google Cloud para crear máquinas virtuales A4 y A3 Ultra que usen el modelo de aprovisionamiento vinculado a la reserva.

Si se modifican las IOPS o el rendimiento de un disco primario de réplica asíncrona mediante el comando gcloud compute disks update, se produce un error falso

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

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

El servidor de metadatos puede mostrar metadatos de VM antiguos physicalHost

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

Para solucionar este problema, siga uno de estos pasos:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nombres temporales de los discos

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

  • -temp
  • -old
  • -new

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

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

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

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

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

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

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

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

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

Causa principal

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

Cómo solucionar este problema

Puede solucionar este problema y seguir generando sus informes automatizados de las siguientes formas:

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

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

Problemas conocidos de las instancias de hardware desnudo

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

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

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

Solución

Usa SLES 15 SP5 en su lugar.

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

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

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

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

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

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

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

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

Causa principal

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

Solución

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

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

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

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

Una interfaz de red dinámica con una interfaz de red virtual principal puede experimentar pérdida de paquetes con tamaños de MTU personalizados.

Solución

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

  • 1460 bytes (el valor predeterminado de las redes de VPC)
  • 1500 bytes (Ethernet estándar)
  • 8896 bytes (el valor máximo posible)

Interacciones del cortafuegos al reutilizar un ID de VLAN con NICs dinámicas

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

  1. Una instancia de proceso tiene una NIC dinámica de ejemplo con el ID de VLAN 4 conectada a una subred de la red de VPC network-1.
  2. La instancia envía paquetes a la dirección IP de destino 192.0.2.7 y al puerto de destino 443. Las reglas de cortafuegos de salida aplicables permiten la conexión saliente.
  3. Como las reglas de Cloud NGFW tienen estado, la conexión saliente permitida crea una entrada en la tabla de seguimiento de conexiones del cortafuegos que permite los paquetes entrantes de la dirección IP de origen y el puerto de origen 192.0.2.7:443.
  4. Elimina la NIC dinámica de ejemplo y crea una NIC dinámica de sustitución. La NIC dinámica de sustitución también usa el ID de VLAN 4, pero se conecta a una subred de otra red de VPC, network-2.
  5. Todas las entradas de la tabla de seguimiento de conexiones del cortafuegos que no hayan caducado y que se aplicaran a la NIC dinámica original se aplican a la NIC dinámica de sustitución. Esto significa que un recurso de la red de VPC network-2 puede enviar paquetes cuyas fuentes coincidan con 192.0.2.7:443, y la instancia de computación los acepta sin necesidad de evaluar las reglas de cortafuegos de entrada.

Para obtener más información sobre el seguimiento de conexiones y las reglas de cortafuegos, consulta las especificaciones en la documentación de Cloud Next Generation Firewall.

Solución

En cada instancia, si necesitas crear una NIC dinámica que use el mismo ID de VLAN que una NIC dinámica que se haya quitado de la instancia, sigue estos pasos:

  • 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 sustitución.
  • Detén la instancia, elimina la NIC dinámica original, crea la NIC dinámica de sustitución y, a continuación, inicia la instancia.

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

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

Causa principal

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

Solución

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

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

Estos son los problemas conocidos de las VMs Linux.

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

El 22 de julio del 2025, la comunidad de Debian retiró las versiones anteriores de Debian 11 (Bullseye) del upstream principal de Debian. Esta actualización provoca que sudo apt update falle y muestre el siguiente error:

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

Causa principal

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

Resolución

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

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

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

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

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

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

Es posible que veas un nombre de dominio completo (FQDN) incorrecto con el sufijo .local cuando hagas lo siguiente:

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

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

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

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

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

Causa principal

En todas las imágenes de Ubuntu con la versión v20250530, la versión 20250328.00 del paquete guest-config añade local a la ruta de búsqueda debido a la introducción de un nuevo archivo de configuración: https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf.

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

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

La presencia de esta entrada local en la ruta de búsqueda del archivo /etc/resolv.conf hace que se añada un elemento .local al nombre de host cuando se solicita un nombre de dominio completo.

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

Solución

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

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

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

Falta mkfs.ext4 en las imágenes de openSUSE

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

Solución

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

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

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

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

No se puede iniciar una VM de SUSE Enterprise después de cambiar los tipos de instancia

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

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

Causa principal

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

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

Solución

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

dracut --force --no-hostonly

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

dracut -f --no-hostonly

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

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

Causa principal

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

Solución

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

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

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

Resolución

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

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

  2. Regenera la configuración de grub.

  3. Reinicia la VM.

No se ha podido verificar la firma de repomd.xml

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

Registro de ejemplo:

[root@centos7 ~]# yum update


...

google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.

...

failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk

Resolución

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

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

Para localizar y actualizar este ajuste, sigue estos pasos:

  1. Busca el ajuste en el archivo /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

  2. Cambia todas las líneas que digan repo_gpgcheck=1 por repo_gpgcheck=0.

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

  3. Comprueba que el ajuste se haya actualizado.

    cat /etc/yum.repos.d/google-cloud.repo

[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

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

En algunas instancias que usan el inicio de sesión del SO, 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

Resolución

Ignora el mensaje de error.

Problemas conocidos de las instancias de VM de Windows

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

Windows Server 2025 y Windows 11 24H2: compatibilidad con la suspensión y la reanudación

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

Errores al medir la desviación de la hora NTP con w32tm en máquinas virtuales Windows

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

w32tm /stripchart /computer:metadata.google.internal

Los errores tienen un aspecto similar al siguiente:

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Estamos mejorando el rendimiento.

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

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

Resolución

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

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

Rendimiento de red deficiente al usar gVNIC

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

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

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

    googet installed

    El resultado es similar al siguiente:

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

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

    googet update

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

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

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

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

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

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

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

Resolución

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