This page describes known issues that you might run into while using Compute Engine.
Increased latency for some persistent disks
In some cases, snapshots of large persistent disks (~3 TB or larger) trigger operations that might be disruptive to the I/O performance of the disk. If you are impacted by this issue, your persistent disks might experience increased latency during the snapshot operation. This issue can impact persistent disks of any type and can be triggered by regular or scheduled snapshots.
Known issues for Linux VM instances
repomd.xml signature could not be verified
On Red Hat Enterprise Linux (RHEL) or CentOS 7 based systems, you might see the following error when trying to install or update software using yum. This error shows that you have an expired or incorrect repository GPG key.
[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
To fix this, disable repository GPG key checking in the yum repo configuration
repo_gpgcheck=0. In supported Compute Engine base images this
setting might be found in
/etc/yum.repos.d/google-cloud.repo file. However,
your VM can have this set in different repository configuration files
or automation tools.
Yum repositories do not usually use GPG keys for repository validation. Instead,
https endpoint is trusted.
To locate and update this setting, complete the following steps:
Look for the setting in your
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
Change all lines that say
sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo
Check that the setting is updated.
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
GPG error: EXPKEYSIG 3746C208A7317B0F when updating packages
On Debian and Ubuntu based systems, including your local workstations, you might encounter an error similar to the following example:
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 <firstname.lastname@example.org>
This error prevents you from obtaining the latest updates for several Google Cloud tools, including the following items:
To resolve this error, get the latest valid
https://packages.cloud.google.com by running the following command:
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
Alternatively, on Compute Engine VM instances running Debian or Ubuntu images, you can get the latest keys if you recreate your instances using the following image versions:
- Image project
debian-9-stretch-v20180401or image family
debian-8-jessie-v20180401or image family
- Image project
ubuntu-1710-artful-v20180315or image family
ubuntu-1604-xenial-v20180323or image family
ubuntu-1404-trusty-v20180308or image family
Instances using OS Login return a login message after connection
On some instances that use OS Login, you might receive the following error message after the connection is established:
/usr/bin/id: cannot find name for group ID 123456789
Ignore the error message.
Known issues for Windows VM instances
- Although Windows instances can use the NVMe interface with local SSDs, support for NVMe on Windows is in Beta, and we do not guarantee the same performance as Linux instances.
- After you create an instance, you cannot connect to it instantly. All new Windows instances use the System preparation (sysprep) tool to set up your instance, which can take 5–10 mins to complete.
- Windows Server images cannot activate without a network connection to
kms.windows.googlecloud.comand stop functioning if they do not initially authenticate within 30 days. Software activated by the KMS must reactivate every 180 days, but the KMS attempts to reactivate every 7 days. Make sure to configure your Windows instances so that they remain activated.
- Kernel software that accesses non-emulated model specific registers will generate general protection faults, which can cause a system crash depending on the guest operating system.