Problemas conocidos

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

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

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.

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.

Problemas conocidos de las instancias de VM de Linux

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

Error de GPG: EXPKEYSIG 3746C208A7317B0F durante la actualización de paquetes

En los sistemas Debian y los sistemas Ubuntu en los que instalaste Google Cloud CLI de forma manual, incluida la estación de trabajo local, puedes encontrar un mensaje de error similar al ejemplo siguiente:

W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease:
The following signatures were invalid: EXPKEYSIG 3746C208A7317B0F
Google Cloud Packages Automatic Signing Key <gc-team@google.com>

Este error te impide obtener las últimas actualizaciones para varias herramientas de Google Cloud, lo que incluye los elementos siguientes:

Para resolver este error, obtén la última clave apt-key.gpg válida de https://packages.cloud.google.com:

Sistemas Debian

Ejecuta el siguiente comando:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Sistemas Ubuntu

Ejecuta el siguiente comando:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

Como alternativa, en las instancias de VM de Compute Engine que ejecutan imágenes de Debian o Ubuntu, puedes obtener las últimas claves si vuelves a crear tus instancias con las versiones de imágenes siguientes:

  • Proyecto de imagen debian-cloud:
    • debian-9-stretch-v20180401 o familia de imágenes debian-9
    • debian-8-jessie-v20180401 o familia de imágenes debian-8
  • Proyecto de imagen ubuntu-os-cloud:
    • ubuntu-1710-artful-v20180315 o familia de imágenes ubuntu-1710
    • ubuntu-1604-xenial-v20180323 o familia de imágenes ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180308 o familia de imágenes ubuntu-1404-lts

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

Debes ignorar este mensaje de error.

Problemas conocidos para instancias de VM de Windows

  • Aunque las instancias de Windows pueden usar la interfaz NVMe con SSD locales, la asistencia para NVMe en Windows se encuentra en versión Beta y no garantizamos que tenga el mismo rendimiento que las instancias de Linux.
  • 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

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

La capacidad de agregar un disco persistente o cambiar su tamaño en una VM M3 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 que se ejecuta en Windows después de modificar los discos persistentes para que los invitados reconozcan las modificaciones del disco.