Problemas conocidos


En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas Compute Engine.

Problemas generales

Mover VM o discos mediante la API de moveInstance o la herramienta 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, eliminación de VM, o bien otro comportamiento inesperado. Cuando muevas VM, te recomendamos que sigas las instrucciones en Transferencia de instancias 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.

Mayor latencia para algunos discos persistentes debido a las instantáneas

El siguiente problema se resolvió el 30 de marzo de 2021.

En algunos casos, las instantáneas de grandes discos persistentes (~3 TB o más) producen operaciones que pueden ser perjudiciales 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 las instantáneas. Este problema puede afectar a discos persistentes de cualquier tipo, y se puede realizar con instantáneas normales o programadas.

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 de forma manual la herramienta de línea de comandos de gcloud, incluida tu estación de trabajo local, puedes encontrar un 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 el último archivo válido de claves apt-key.gpg 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 de 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.