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:
Habilita Identity-Aware Proxy para TCP si quieres conectarte a las VM mediante la función SSH en el navegador de la consola de Google Cloud.
Vuelve a crear la regla de firewall
default-allow-ssh
para continuar con la conexión a las VM mediante SSH en el navegador.Conéctate a las VM mediante Google Cloud CLI en lugar de SSH en el navegador.
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.
De forma opcional, para evitar este problema, borra las VMs o actualiza la propiedad
reservationAffinity
de las VMs hasta que la cantidad de VMs dirigidas a la instancia específica coincida con la cantidad de VMs planificadas para la reserva específica. Después, puedes reducir el tamaño de la reserva específica o borrarla.Para solucionar este problema, haz lo siguiente:
Para que la cantidad de VMs en la reserva específica sea igual a la cantidad de VMs dirigidas a ella, haz una o más de las siguientes acciones: borra VMs, actualiza la propiedad
reservationAffinity
de VMs, aumenta el tamaño de la reserva que redujiste o vuelve a crear la reserva específica borrada.Inicia y detén cualquier VM restante.
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:
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
Cambia todas las líneas que dicen
repo_gpgcheck=1
arepo_gpgcheck=0
.sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo
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:
- Entorno de invitado de Compute Engine
- Google Cloud CLI con la Google Cloud CLI
- Agente de Cloud Logging
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ágenesdebian-9
debian-8-jessie-v20180401
o familia de imágenesdebian-8
- Proyecto de imagen
ubuntu-os-cloud
:ubuntu-1710-artful-v20180315
o familia de imágenesubuntu-1710
ubuntu-1604-xenial-v20180323
o familia de imágenesubuntu-1604-lts
ubuntu-1404-trusty-v20180308
o familia de imágenesubuntu-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:
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 ...
Si la versión del controlador
google-compute-engine-driver-gvnic.x86_64
es1.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.