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 Problemas conocidos de Confidential VM.

Problemas generales

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

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:

  • La creación de la reserva puede fallar. Si se ejecuta de forma correcta, se aplicará 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.

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

No puedes reemplazar la plantilla de instancias que se usa para crear una solicitud de reserva o una solicitud de reserva futura, o anular las propiedades de VM de la plantilla. Si deseas reservar recursos para los tipos de máquinas A2, C3 o G2, realiza 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 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 disco 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 Google Kubernetes Engine con la consola de 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 TCP.

El grupo de instancias administrado que tiene series de máquinas T2D no realiza el ajuste de escala automático como se espera

Los grupos de instancias administrados (MIGs) que tienen VM de series de máquinas T2D en proyectos que se crearon antes del 18 de junio de 2023 no detectan de forma correcta la carga de CPU en las VMs del MIG. En esos proyectos, el ajuste de escala automático basado en el uso de CPU en un MIG que tiene VMs de la serie de máquinas T2D puede ser incorrecto.

Para aplicar una solución a tu proyecto, comunícate con la Atención al cliente de Cloud.

La métrica de observabilidad del uso de CPU es incorrecta para las VMs 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.

Las conexiones SSH en el navegador de la consola de Google Cloud 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:

Reducir o borrar una reserva específica evita que las VMs consuman otras reservas

Si reduces o borras una reserva específica que consumieron una o más VMs, las VMs huérfanas no pueden consumir ninguna reserva.

Obtén más información para borrar reservas y cambiar el tamaño de las reservas.

Trasladar VMs o discos mediante la API de moveInstance o la CLI de gcloud genera un comportamiento inesperado

Mover instancias de máquina virtual (VM) mediante el comando gcloud compute instances move o el método project.moveInstance puede causar la pérdida de datos, la eliminación de VM u otro comportamiento inesperado.

Cuando muevas VMs, te recomendamos que sigas las instrucciones de Mueve una instancia de VM entre zonas o regiones.

Los discos conectados a VMs con tipos de máquina n2d-standard-64 no alcanzan los límites de rendimiento de forma coherente

Los Persistent disks conectados a VM con tipos de máquina n2d-standard-64 no alcanzan el límite máximo de rendimiento de 100,000 IOPS de manera coherente. Este es el caso de las IOPS de lectura y escritura.

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 discos persistentes debido al cambio de tamaño del disco

En algunos casos, cambiar el tamaño de los discos persistentes 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 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.

Usa imágenes MBR con VM C3 con SSD local

Una VM C3 creada con c3-standard-44-lssd y tipos de máquina más grandes no se inician de forma correcta con imágenes MBR.

Capacidad para conectar discos PDs estándar y PDs extremos no compatibles a VMs C3 y M3

Los discos persistentes estándar (pd-standard) son el tipo de disco de arranque predeterminado cuando se usa Google Cloud CLI o la API de Compute Engine. Sin embargo, los discos pd-standard no son compatibles con las VMs C3 y M3. Además, las VMs C3 no admiten discos pd-extreme.

Los siguientes problemas pueden ocurrir cuando usas Google Cloud CLI o la API de Compute Engine:

  • pd-standard se configura como el tipo de disco de arranque predeterminado, y el disco se crea, a menos que especifiques un tipo de disco de arranque diferente y compatible, como pd-balanced o pd-ssd.
  • Antes de la disponibilidad general (DG) de C3, podías conectar discos pd-extreme a VMs C3 y discos pd-standard a VMs C3 y M3.

Si creaste una VM C3 o M3 con un tipo de disco no compatible, mueve tus datos a un tipo de disco nuevo compatible, como se describe en Cambia el tipo de disco persistente. Si no cambias el tipo de disco, las VMs continuarán funcionando, pero algunas operaciones como la desconexión y la reconexión del disco fallarán.

Solución alternativa

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

  • Usa la consola de Google Cloud para crear VMs C3 o M3 y conectar discos. La consola crea VMs C3 y M3 con discos de arranque pd-balanced y no permite adjuntar tipos de disco no compatibles a las VMs.
  • Si usas Google Cloud CLI o la API de Compute Engine, configura de forma explícita un disco de arranque de tipo pd-balanced o pd-ssd cuando crees una VM.

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

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

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

  2. Usa un int en lugar de un number para definir el campo de tu límite de cuota de recursos en los cuerpos de respuesta de tu 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 muestra un valor para el campo limit que está fuera del rango definido por el tipo int. Tu proceso automatizado no puede consumir el valor que muestra el método de la API y falla como resultado.

Cómo solucionar este problema

Puedes solucionar este problema y seguir generando informes automáticos de las siguientes maneras:

Problemas conocidos de las instancias de VM de Linux

Estos son los problemas conocidos de las VMs de Linux.

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

Las imágenes de SO de CentOS y Red Hat Enterprise Linux (RHEL) 7 que proporciona Google tienen nombres de interfaz de red predecibles inhabilitados de forma predeterminada.

Sin embargo, 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 predecibles si al menos una NIC no usa la interfaz de 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 vuelva a ocurrir la pérdida de conectividad de red, sigue estos pasos:1. Edita el archivo /etc/default/grub y quita los parámetros de kernel net.ifnames=0 y biosdevname=0. 2. Vuelve a generar la configuración de grub. 3. Reinicia la VM.

Las imágenes públicas de SUSE de Google Cloud 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

  • Las instancias que ejecutan Windows 11, versión 22H2 no se inician. Usa Windows 11 versión 21H2 hasta que se resuelva este problema.
  • La compatibilidad con NVMe en Windows mediante el controlador NVMe de la comunidad se encuentra en versión Beta, es posible que el rendimiento no coincida con el de las instancias de Linux. El controlador de NVMe de la comunidad se reemplazó por el controlador de Microsoft StorNVMe en las imágenes públicas de Google Cloud. Te recomendamos reemplazar el controlador de NVME en las VMs creadas antes de mayo de 2022 y usar el controlador de 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.

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 son similares a los siguientes:

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 de VirtIO. Las VMs que usan gVNIC no tienen este problema.

Para evitar este problema, Google recomienda usar otras herramientas de medición de desvíos NTP, como el supervisor del servidor de tiempo de Meinberg.

Trasladar una VM de Windows a una serie de máquinas de tercera generación causa problemas de inicio

Si mueves una VM de Windows a una serie de máquinas de tercera generación (por ejemplo, C3 o H3) desde una serie de máquinas de primera o segunda generación (por ejemplo, N1 o N2), la VM no se iniciará cuando la reinicies.

Para solucionar este problema, haz lo siguiente:

  1. Confirma que el disco de arranque de la VM que deseas actualizar sea compatible con los tipos de máquina de tercera generación mediante la ejecución del comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME --zone=ZONE

    Reemplaza lo siguiente:

    • DISK_NAME: por el nombre del disco de arranque
    • ZONE: la zona del disco

    El resultado debe contener lo siguiente para usar el disco de arranque con una serie de máquinas de tercera generación:

    guestOsFeatures:
...
- type: GVNIC
- type: WINDOWS

  2. Detén la VM que deseas actualizar.

  3. Desvincula el disco de arranque de la VM.

  4. Usa la consola de Google Cloud para crear una VM de Windows con las siguientes propiedades:

    • Zona: la misma zona que la VM original
    • Disco de arranque: el disco de arranque de la VM original
    • Serie de máquinas: una serie de máquinas de tercera generación

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

Ancho de banda limitado con gVNIC en Microsoft Windows con VMs C3 y C3D

En los sistemas operativos Windows, el controlador de gVNIC no alcanza los límites de ancho de banda documentados. Actualmente, el controlador de gVNIC puede alcanzar hasta 85 Gbps de ancho de banda de red en las VMs C3 y C3D que ejecutan Microsoft Windows, tanto para la red predeterminada como por el rendimiento de herramientas de redes de nivel 1 de VM.

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 del controlador 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.

Menor rendimiento de IOPS para Hyperdisk Extreme en Microsoft Windows con VMs de C3 y M3

En la actualidad, el rendimiento de Hyperdisk Extreme está limitado en las VMs de Microsoft Windows.

Se están realizando mejoras en el rendimiento.

Los tipos de máquinas de CPU virtuales C3D 180 y 360 no son compatibles con las imágenes de SO de Windows

Los tipos de máquinas de CPU virtuales C3D de 180 no son compatibles con las imágenes de SO de Windows Server 2012 y 2016. Las VM de C3D creadas con 180 CPU virtuales y las 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.

Error de disco genérico en Windows Server 2016 y 2012 R2 para VMs M3, C3 y C3D

En este momento, la capacidad de agregar o cambiar el tamaño de un Hyperdisk o un Persistent Disk para una VM M3, C3 o C3D en ejecución no funciona como se espera en invitados específicos de Windows. 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 o C3D que se ejecuta en Windows después de modificar un Hyperdisk o un Persistent Disk para que los invitados reconozcan las modificaciones del disco.