Problemas 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

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

Cuando usas la API de Google Kubernetes Engine, el grupo de nodos con la SSD local conectado que aprovisionas debe tener la misma cantidad de SSD que el tipo de máquina C3 seleccionado. Por ejemplo, si planeas crear una VM que use el tipo de máquina c3-standard-8-lssd, debe haber 2 discos SSD o recibirás un error de configuración incorrecta de SSD local del plano de control de Compute Engine.

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

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 correcció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 VM 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 VM, te recomendamos que sigas las instrucciones de Mueve una instancia de VM entre zonas o regiones.

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

Los discos persistentes 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.

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 de C3 o M3 con un tipo de disco no compatible, mueve los datos a un tipo de disco nuevo y 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 los datos de respuesta de la API sobre las cuotas de compromiso basadas en recursos de Compute Engine pueden fallar si ocurre alguna de las siguientes situaciones. Los 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 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 en 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 se encuentra fuera del rango que define el tipo int. El proceso automatizado no puede consumir el valor que muestra el método de la API y, como resultado, falla.

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

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.

Solución

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

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 asistencia para NVMe en Windows mediante el controlador de la NVMe de la comunidad se encuentra en versión Beta y no garantizamos que tenga el mismo rendimiento que las instancias de Linux. El controlador de la NVMe de la comunidad se reemplazó por el controlador de Microsoft StorNVMe en las imágenes públicas de Google Cloud. Reemplaza el controlador NVME en las VMs creadas antes de mayo de 2022 y usa 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 en el plazo de 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.

Capacidad de procesamiento de red 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 de GooGet de controlador gVNIC a la versión 1.0.0@45 o posterior mediante lo siguiente:

  1. Verifica qué versión del controlador está instalada en tu VM mediante la ejecución del 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

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 que ejecutan Microsoft Windows, tanto para la red predeterminada como por el rendimiento de herramientas de redes de nivel 1 de VM.

Habrá una actualización de rendimiento disponible en la segunda mitad de 2023.

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 controlador de StorNVME y quitar el controlador de la comunidad, si está presente en el SO invitado.

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

Menor rendimiento para SSD locales en Microsoft Windows con VM C3

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

Habrá una actualización de rendimiento disponible en la segunda mitad de 2023.

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

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

Habrá una actualización de rendimiento disponible en la segunda mitad de 2023.

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

En este momento, la capacidad de agregar o cambiar el tamaño de un hiperdisco o disco persistente para una VM M3 o C3 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 o C3 que se ejecuta en Windows después de modificar un hiperdisco o disco persistente para que los invitados reconozcan las modificaciones del disco.