Problemas conocidos

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

Problemas generales

Mayor latencia para algunos discos persistentes

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

Error de permiso de operaciones de procesamiento

Si tu proyecto usa la versión 286.0.0 o una posterior de la herramienta de gcloud, es posible que recibas uno de los siguientes errores cuando ejecutes comandos que actualizan datos, como gcloud compute instances start o gcloud compute disks snapshot:

ERROR: (gcloud.compute.METHOD) Could not fetch resource:
 - Required 'compute.globalOperations.get' permission

ERROR: (gcloud.compute.METHOD) Could not fetch resource:
 - Required 'compute.regionOperations.get' permission

ERROR: (gcloud.compute.METHOD) Could not fetch resource:
 - Required 'compute.zoneOperations.get' permission

ERROR: (gcloud.compute.METHOD) HTTPError 403:
Required 'compute.globalOperations.get' permission for RESOURCE

ERROR: (gcloud.compute.METHOD) HTTPError 403:
Required 'compute.regionOperations.get' permission for RESOURCE

ERROR: (gcloud.compute.METHOD) HTTPError 403:
Required 'compute.zoneOperations.get' permission for RESOURCE

También puedes encontrar errores similares cuando llamas a los métodos de la API compute.globalOperations.wait, compute.regionOperations.wait o compute.zoneOperations.wait.

Si tienes permisos de IAM configurados a nivel de la instancia y no a nivel del proyecto, los errores de permisos pueden deberse al Error 179836 de Compute Engine. Para mitigar este problema, prueba una de las siguientes soluciones:

  • Crea una función de IAM personalizada a nivel del proyecto que incluya el permiso faltante: compute.regionOperations.get, compute.regionOperations.get o compute.zoneOperations.get. Asigna esta función a los usuarios que recibieron el error de permiso.
  • Regresa la herramienta de gcloud a la versión 285 o una anterior.

  • Asigna la función roles/compute.viewer a los usuarios que recibieron el error de permiso.

Algunos proyectos tienen la cuenta de servicio predeterminada incorrecta

Cuando habilitas la API de Compute Engine en tu proyecto, se agrega una cuenta de servicio predeterminada a tu proyecto. Por lo general, la cuenta de servicio predeterminada tiene el siguiente correo electrónico:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Para una cantidad pequeña de proyectos, el correo electrónico de la cuenta de servicio predeterminada está configurado de forma incorrecta de la siguiente manera:

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

Si te afecta este problema, es posible que veas errores 403 Forbidden y que no puedas crear recursos nuevos de Compute Engine. Si este es el caso, comunícate con la asistencia de Google Cloud para resolver el problema y obtener respuestas a tus preguntas. Mientras se desarrolla una solución a largo plazo, existe una solución de lanzamiento automático para corregir el problema.

Para seguir el estado de este problema, consulta Error 171305221 de Compute Engine.

Problemas conocidos de las instancias de VM que ejecutan Linux

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

En los sistemas basados en Debian y Ubuntu, incluidas tus estaciones de trabajo locales, 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 el último archivo válido de claves apt-key.gpg de https://packages.cloud.google.com mediante la ejecución del siguiente comando:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key 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

Problema del sistema de archivos raíz de solo lectura de Red Hat Enterprise Linux 7 y CentOS 7

Las instancias de VM en ejecución en imágenes públicas rhel-7-v20170719 o anteriores, o en centos-7-v20170719 o anteriores, se pueden iniciar con el sistema de archivos raíz activo en modo de solo lectura. Las apps, daemons o secuencias de comandos que requieren acceso de escritura al sistema de archivos raíz fallarán.

No reinicies instancias en ejecución que usen las imágenes públicas afectadas o quedarán bloqueadas en modo de solo lectura. Si tus instancias ya están bloqueadas en modo de solo lectura, puedes restablecer de forma remota el modo de lectura o escritura en el sistema de archivos raíz y, luego, corregir el problema.

Identifica las instancias afectadas:

Identifica las instancias potencialmente afectadas con los siguientes comandos gcloud compute disks list:

RHEL 7:

gcloud compute disks list --filter="sourceImage ~ rhel-7-v201[4-6].* OR sourceImage ~ rhel-7-v20170[1-7].*" --uri

CentOS 7:

gcloud compute disks list --filter="sourceImage ~ centos-7-v201[4-6].* OR sourceImage ~ centos-7-v20170[1-7].*" --uri

Si estos discos están adjuntados a tus instancias, puedes corregir el problema en esas instancias. El proceso para corregir las instancias afectadas depende de la versión de la imagen que usaste a fin de crear la instancia.

Instancias creadas mediante imágenes de RHEL 7 entre rhel-7-v20160418 y rhel-7-v20170719, o imágenes de CentOS 7 entre centos-7-v20160418 y centos-7-v20170719:

Si la instancia usa actualizaciones automáticas, yum-cron instala el paquete fijo de forma automática y quita la opción de activación rota del archivo /etc/fstab. Si la instancia no tiene habilitadas las actualizaciones automáticas, puedes corregirla con el siguiente proceso:

  1. Conéctate a la instancia mediante SSH. Si la conexión falla, puede que la instancia esté atascada en modo de solo lectura. Sin embargo, puedes intentar recuperarla. Si te conectaste a la instancia afectada mediante SSH, tus Llaves SSH públicas ya están en el sistema de archivos raíz y seguirán funcionando. Ejecuta un comando remoto mediante ssh para volver a activar el sistema de archivos en modo rw. Por ejemplo, puedes usar el siguiente comando gcloud para volver a activar el sistema de archivos raíz:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"

    Una vez que el sistema de archivos se vuelva a activar en modo de lectura o escritura, conéctate a la instancia mediante SSH.

  2. Ejecuta sudo yum -y update para actualizar todos los paquetes instalados, incluido el paquete gce-disk-expand, que contiene la corrección.

Ahora se puede reiniciar la instancia sin necesidad de activar el sistema de archivos raíz en modo de solo lectura.

Instancias creadas con imágenes RHEL 7 antes de rhel-7-v20160418 o imágenes CentOS 7 creadas antes de centos-7-v20160418:

  1. Conéctate a la instancia mediante SSH. Si la conexión falla, puede que la instancia esté atascada en modo de solo lectura. Sin embargo, puedes intentar recuperarla. Si te conectaste a la instancia afectada mediante SSH, tus Llaves SSH públicas ya están en el sistema de archivos raíz y seguirán funcionando. Ejecuta un comando remoto mediante ssh para volver a activar el sistema de archivos en modo rw. Por ejemplo, puedes usar el siguiente comando gcloud para volver a activar el sistema de archivos raíz:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"

    Una vez que el sistema de archivos se vuelva a activar en modo de lectura o escritura, conéctate a la instancia mediante SSH.

  2. Edita el archivo /etc/fstab y quita las opciones de activación barrier=1 de ese archivo. La opción de activación default debe ser la única opción de activación configurada para la entrada del sistema de archivos raíz. Puedes corregir esta opción de activación dañada con el siguiente comando:

    sudo sed -i 's/defaults,barrier[^ ,]*/defaults/' /etc/fstab

    Después de quitar la opción de activación barrier=1, la entrada del sistema de archivos raíz en el archivo /etc/fstab debería tener un aspecto similar al siguiente ejemplo, pero con un valor diferente para el UUID:

    UUID=b5e54172-67e3-4d52-95f4-4314e71b25fd / xfs defaults 0 0

Ahora se puede reiniciar la instancia sin necesidad de activar el sistema de archivos raíz en modo de solo lectura.

La imagen de CentOS v20131120 ingresó un cambio rotundo en el que las iptables se activan de forma predeterminada

La actualización v20131120 de la imagen de CentOS 6, centos-6-v20131120, tiene un cambio rotundo en el que las iptables se activan de forma predeterminada. Esto evita que el tráfico externo llegue a las instancias de CentOS que ejecutan centos-6-v20131120, incluso si hay un recurso de regla de firewall pertinente que permite la conexión.

Como solución alternativa, los usuarios pueden inhabilitar o actualizar iptables para permitir la conexión deseada (además de permitir el tráfico mediante reglas de firewall). Para inhabilitar iptables, ejecuta los comandos siguientes:

# Save your iptable settings
user@centos-instance:~$ sudo service iptables save

# Stop the iptables service
user@centos-instance:~$ sudo service iptables stop

# Disable iptables on start up
user@centos-instance:~$ sudo chkconfig iptables off

Las imágenes que proporciona Google tienen un error conocido en el controlador ext4/scsi en los kernels estables de Debian y CentOS

Para las imágenes centos-6-v20131120 y debian-7-wheezy-v20131120, hay un error ext4 conocido que puede causar una pérdida de memoria y una eventual falla de una instancia de máquina virtual bajo una carga intensiva del disco persistente. Para obtener más información, consulta la conversación de la pregunta sobre el tiempo de bloqueo excesivo de ext4 en la lista de distribución del kernel de Linux.

Los nombres de instancia de más de 32 caracteres pueden causar problemas con varias herramientas de UNIX

Fecha de notificación: junio de 2012

Aunque los nombres de instancia pueden tener hasta 63 caracteres, los nombres que tienen más de 32 caracteres pueden hacer que algunas herramientas no sean confiables, incluidas las herramientas que podrían ejecutarse durante el inicio. Como solución alternativa, elige nombres de instancia que tengan menos de 32 caracteres.

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.
  • En Windows Server 2008 R2, para la instalación de Python 2.7.9 o posterior, se requiere Visual C++. Python 2.7.8 evita esta dependencia, pero recomendamos instalar la última versión.
  • Compute Engine aún no es compatible con IPv6. Incluso si seleccionas la opción para habilitar IPv6 en una instancia de Windows, la configuración se ignora.
  • 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.
  • El problema se resolvió el 30 de octubre de 2020. Las VM de Windows que ejecutan servidores Microsoft SQL Server u otras cargas de trabajo de bases de datos podrían dejar de responder a conexiones de RDP y a otras solicitudes de herramientas de redes. Si la VM no responde después de reiniciarla, sigue los pasos que se indican en el artículo Soluciona problemas de las VM de Windows.