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 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

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 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.