Problemas conocidos

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

Problemas conocidos de las instancias de VM de Linux

Las imágenes de Linux presentan los siguientes problemas conocidos.

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 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 <[e-mail]>

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

• Entorno de invitado de Compute Engine
• SDK de Cloud con la herramienta de línea de comandos de gcloud
• Agente de Stackdriver Logging

Para resolver este error, debes obtener el último archivo de claves apt-key.gpg válido de https://packages.cloud.google.com mediante el comando siguiente:

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 imágenes debian-cloud:
  • debian-9-stretch-v20180401 o la familia de imágenes debian-9
  • debian-8-jessie-v20180401 o la familia de imágenes debian-8
• Proyecto de imágenes ubuntu-os-cloud:
  • ubuntu-1710-artful-v20180315 o la familia de imágenes ubuntu-1710
  • ubuntu-1604-xenial-v20180323 o la familia de imágenes ubuntu-1604-lts
  • ubuntu-1404-trusty-v20180308 o la 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 que ejecutan imágenes públicas rhel-7-v20170719 y anteriores, o centos-7-v20170719 y anteriores pueden iniciarse con el sistema de archivos raíz activado 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 que podrían estar afectadas mediante los comandos siguientes de 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 de forma automática el paquete corregido y quita la opción de activación dañada del archivo /etc/fstab. Si la instancia no tiene habilitadas las actualizaciones automáticas, puedes corregirla con el proceso siguiente:

1. Conéctate a la instancia mediante SSH. Si la conexión falla, la instancia podría estar bloqueada en modo de solo lectura. Sin embargo, puedes intentar recuperarla. Si ya te conectaste antes a la instancia afectada mediante SSH, tus Llaves SSH públicas ya están en el sistema de archivos raíz y continuarán funcionando. Debes ejecutar un comando remoto mediante ssh para volver a activar el sistema de archivos en modo rw. Por ejemplo, puedes usar el comando siguiente de 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 de RHEL 7 creadas antes de rhel-7-v20160418 o imágenes de CentOS 7 creadas antes de centos-7-v20160418:

1. Conéctate a la instancia mediante SSH. Si la conexión falla, la instancia podría estar bloqueada en modo de solo lectura. Sin embargo, puedes intentar recuperarla. Si ya te conectaste antes a la instancia afectada mediante SSH, tus Llaves SSH públicas ya están en el sistema de archivos raíz y continuarán funcionando. Debes ejecutar un comando remoto mediante ssh para volver a activar el sistema de archivos en modo rw. Por ejemplo, puedes usar el comando siguiente de 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 cualquier opción de activación barrier=1. La opción de activación default debe ser la única establecida para la entrada del sistema de archivos raíz. Puedes corregir esta opción de activación dañada con el comando siguiente:

   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 ejemplo siguiente, 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 introdujo un cambio rotundo en el que iptables se activa de forma predeterminada

La versión v20131120 de la imagen de CentOS 6 centos-6-v20131120 tiene un cambio rotundo en el que iptables se activa de forma predeterminada. Esto evita que el tráfico externo llegue a instancias de CentOS que ejecutan centos-6-v20131120, incluso si hay un recurso de regla de firewall relevante 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

Las imágenes de Windows presentan los siguientes problemas conocidos:

• 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 el mismo rendimiento que tienen las instancias de Linux.
• En Windows 2008 R2, la instalación de Python 2.7.9 o posterior 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 pueden activarse sin una conexión de red a kms.windows.googlecloud.com y dejan de funcionar si no hay una autenticación iniciar en 30 días. El software que activa el KMS debe volver a activarse cada 180 días, pero el KMS intenta la reactivación cada 7 días. Tus instancias de Windows con una IP externa pueden autenticarse de forma periódica.
• 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.