已知问题

Linux Windows

本页面介绍在使用 Compute Engine 时可能遇到的已知问题。如需了解明确影响机密虚拟机的问题，请参阅机密虚拟机限制。

常见问题

以下问题提供了问题排查指南或一般信息。

您无法使用 Google Cloud 控制台为 A4 和 A3 Ultra 创建 Spot 虚拟机

您无法使用 Google Cloud 控制台创建使用 A4 或 A3 Ultra 机器系列的 Spot 虚拟机。具体而言，在创建实例页面上，当您在机器配置窗格中为这些机器系列选择 GPU 类型后，高级窗格会显示必须选择预留，并且不允许您在虚拟机预配模型列表中选择 Spot。

如需解决此问题，请使用 gcloud CLI 或 REST 为 A4 和 A3 Ultra 创建 Spot 虚拟机。或者，您也可以使用 Google Cloud 控制台创建使用受预留约束的预配模型的 A4 和 A3 Ultra 虚拟机。

使用 `gcloud compute disks update` 命令修改异步复制主磁盘上的 IOPS 或吞吐量会导致误报错误

当您使用 gcloud compute disks update 命令修改异步复制主磁盘上的 IOPS 和吞吐量时，即使更新成功，Google Cloud CLI 也会显示错误消息。

如需准确验证更新是否成功，请使用 Google Cloud CLI 或 Google Cloud 控制台查看磁盘属性是否显示新的 IOPS 和吞吐量值。如需了解详情，请参阅查看 Hyperdisk 的预配性能设置。

元数据服务器可能会显示旧的 `physicalHost` 虚拟机元数据

遇到导致实例移至新主机的主机错误后，当您查询元数据服务器时，它可能会显示实例之前主机的 physicalHost 元数据。

如需解决此问题，请执行以下任一操作：

使用 instances.get 方法或 gcloud compute instances describe 命令检索正确的 physicalHost 信息。
停止实例，然后启动实例。此过程会更新元数据服务器中的 physicalHost 信息。
等待 24 小时，以便更新受影响实例的 physicalHost 信息。

实时迁移期间无法访问仅限 IPv6 的 C3 虚拟机

使用 C3 机器类型的仅限 IPv6 的虚拟机可能会在实时迁移期间变得无法访问。

临时解决方法：

如需降低遇到此问题的可能性，您可以更新实例的维护政策，并将维护行为设置为 TERMINATE，将自动重启设置为 TRUE。

如果您的虚拟机进行实时迁移，并且您遇到此问题，请重启虚拟机以重新获得实例的访问权限。

托管式实例组 (MIG) 中的较长 `baseInstanceName` 值可能会导致磁盘名称冲突

在 MIG 中，如果实例模板指定在创建虚拟机时要创建的磁盘，并且 baseInstanceName 值超过 54 个字符，则可能会发生磁盘名称冲突。出现这种情况是因为 Compute Engine 使用实例名称作为前缀来生成磁盘名称。

生成磁盘名称时，如果生成的名称超过 63 个字符的资源名称限制，Compute Engine 会从实例名称末尾截断多余的字符。这种截断可能会导致为具有类似命名模式的实例创建相同的磁盘名称。在这种情况下，新实例将尝试挂接现有磁盘。如果磁盘已挂接到其他实例，则新实例创建将失败。如果磁盘未挂接或处于多写入者模式，则新实例将挂接磁盘，这可能会导致数据损坏。

如需避免磁盘名称冲突，请将 baseInstanceName 值的长度限制为不超过 54 个字符的长度上限。

使用指定 A2、C3 或 G2 机器类型的实例模板来创建预留或未来预留请求会导致问题

如果您使用指定 A2、C3 或 G2 机器类型的实例模板来创建预留，或创建和提交未来预留请求以供审核，则会遇到问题。具体而言：

创建预留可能会失败。如果成功，则适用以下其中一项：
- 如果您创建了自动使用的预留（默认），则创建具有匹配属性的虚拟机不会使用该预留。
- 如果您创建了特定预留，则创建专门指向该预留的虚拟机将失败。
未来预留请求创建成功。但是，如果您提交以进行审核， Google Cloud 会拒绝您的请求。

您无法替换用于创建预留或未来预留请求的实例模板，也无法替换模板的虚拟机属性。如果要为 A2、C3 或 G2 机器类型预留资源，请改为执行以下操作之一：

通过直接指定属性，创建新的单项目或共享预留。
通过执行以下操作，创建新的未来预留请求：
1. 如果您想要阻止现有的未来预留请求限制您可以在当前项目（或与未来预留请求共享的项目中）创建的未来预留请求的属性，请删除未来预留请求。
2. 直接指定属性以创建单项目或共享未来预留请求并提交以供审核。

将 `c3-standard--lssd` 和 `c3d-standard--lssd` 机器类型与 Google Kubernetes Engine 搭配使用时的限制

使用 Google Kubernetes Engine API 时，您预配的挂接了本地 SSD 的节点池必须具有与所选 C3 和 C3D 机器类型相同的 SSD 磁盘数量。例如，如果您计划创建使用 c3-standard-8-lssd 的虚拟机，则必须有 2 个 SSD 磁盘，而 c3d-standard-8-lssd 仅需要 1 个 SSD 磁盘。如果磁盘编号不匹配，您会收到 Compute Engine 控制平面发出的本地 SSD 配置错误。请参阅通用机器系列文档，以根据 C3 或 C3D lssd 机器类型选择正确的本地 SSD 磁盘数量。

如果使用 Google Kubernetes Engine Google Cloud 控制台创建具有 c3-standard-*-lssd 和 c3d-standard-*-lssd 虚拟机的集群或节点池，则会导致节点创建失败或无法将本地 SSD 检测为临时存储空间。

C3D 虚拟机上的单个流 TCP 吞吐量可变性

超过 30 个 vCPU 的 C3D 虚拟机可能会遇到单流 TCP 吞吐量变化，并且偶尔限制为 20-25 Gbps。如需实现更高的速率，请使用多个 TCP 流。

对于每个核心使用一个线程的虚拟机，CPU 利用率可观测性指标不正确

如果虚拟机的 CPU 使用每个核心一个线程，则 Compute Engine > 虚拟机实例 > 可观测性标签页中的 CPU 利用率 Cloud Monitoring 可观测性指标最高只能到 50%。对于除 Tau T2D 之外的所有机器类型，每个核心默认都有两个线程。如需了解详情，请参阅设置每个核心的线程数。

如需查看虚拟机的 CPU 利用率（已标准化为 100%），请改为在 Metrics Explorer 中查看 CPU 利用率。如需了解详情，请参阅使用 Metrics Explorer 创建图表。

如果您使用自定义防火墙规则，则Google Cloud 控制台 SSH-in-browser 连接可能会失败

如果您使用自定义防火墙规则来控制对虚拟机实例的 SSH 访问权限，则可能无法使用 SSH-in-browser 功能。

如需解决此问题，请执行以下任一操作：

启用 Identity-Aware Proxy for TCP 以继续使用 SSH-in-browserGoogle Cloud 控制台功能连接到虚拟机。
重新创建 default-allow-ssh 防火墙规则以继续使用 SSH-in-browser 连接到虚拟机。
使用 Google Cloud CLI 而非 SSH-in-browser 连接到虚拟机。

磁盘的临时名称

在使用 gcloud compute instances update 命令或 instances.update API 方法启动的虚拟机 (VM) 实例更新期间，Compute Engine 可能会向原始名称添加以下后缀，以临时更改虚拟机的磁盘名称：

-temp
-old
-new

Compute Engine 会在更新完成后移除后缀并恢复原始磁盘名称。

由磁盘大小调整导致的某些 Persistent Disk 的延迟时间增加

在某些情况下，调整大型 Persistent Disk（约 3 TB 或更大）的大小可能会极大影响磁盘的 I/O 性能。如果您受到此问题的影响，则 Persistent Disk 在调整大小操作期间可能会遇到延迟时间增加的情况。此问题可能会影响任何类型的 Persistent Disk。

如果自动化流程使用基于资源的承诺配额相关的 API 响应数据，则这些自动化流程可能会失败

如果发生以下任一情况，使用和处理基于 Compute Engine 资源的承诺配额相关 API 响应数据的自动化流程可能会失败。自动化流程可以包含使用或存储 API 响应的任何代码段、业务逻辑或数据库字段。

响应数据来自以下任意一种 Compute Engine API 方法：
您可以使用 int 而不是 number 来定义 API 响应正文中的资源配额上限字段。您可以在每个方法中通过以下方式查找该字段：
- 用于 compute.regions.list 方法的 items[].quotas[].limit。
- 用于 compute.regions.get 方法的 quotas[].limit。
- 用于 compute.projects.get 方法的 quotas[].limit。
任何 Compute Engine 承诺 SKU 都有默认的无限配额。

如需详细了解承诺及承诺 SKU 的配额，请参阅承诺及承诺资源的配额。

根本原因

如果您的配额有限，并且您将 items[].quotas[].limit 或 quotas[].limit 字段定义为 int 类型，则您的配额上限的 API 响应数据仍有可能在 int 类型的范围内，但您的自动化流程可能不会中断。但是，如果您的配额上限默认为无限配额，则 Compute Engine API 会为 limit 字段返回一个在 int 类型定义的范围之外的值。在这种情况下，自动化流程将无法使用 API 方法返回的值，从而导致失败。

如何解决此问题

您可以通过以下方式解决此问题，并继续自动生成报告：

推荐做法：遵循 Compute Engine API 参考文档，为 API 方法定义使用正确的数据类型。具体来说，使用 number 类型为您的 API 方法定义 items[].quotas[].limit 和 quotas[].limit 字段。
将配额上限减小至一个小于 9,223,372,036,854,775,807 的值。您必须为所有区域中具有基于资源的承诺的所有项目设置配额上限。您可以通过以下某种方式执行此操作：
- 按照与申请调整配额相同的步骤，申请降低配额上限。
- 创建配额替换值。

裸金属实例的已知问题

C4D 裸金属实例无法运行 SUSE Linux Enterprise Server (SLES) 版本 15 SP6 操作系统。

临时解决方法

请改用 SLES 15 SP5。

与使用 Dynamic Network Interface 相关的问题

本部分介绍了与使用多个网络接口和 Dynamic Network Interface 相关的已知问题。

使用自定义 MTU 大小时发生丢包

具有父级 vNIC 的 Dynamic NIC 可能会在使用自定义 MTU 大小时遇到丢包。

临时解决方法

如需避免丢包，请使用以下 MTU 大小之一：

1,460 字节（适用于 VPC 网络的默认值）
1,500 字节（标准以太网）
8,896 字节（可能的最大值）

将 VLAN ID 重复用于 Dynamic NIC 时的防火墙互动

在实例中，将 VLAN ID 重复用于新的 Dynamic NIC 会影响防火墙连接跟踪。如果您删除 Dynamic NIC 并创建使用相同 VLAN ID 的替换 Dynamic NIC，防火墙连接跟踪表条目不会自动清除。以下示例展示了相关的安全注意事项：

计算实例具有一个示例 Dynamic NIC，其 VLAN ID 为 4 并连接到 network-1 VPC 网络中的子网。
该实例会将数据包发送到 192.0.2.7:443 目标 IP 地址和目标端口。适用的出站防火墙规则允许进行出站连接。
由于 Cloud NGFW 规则是有状态规则，因此允许的出站连接会创建一个防火墙连接跟踪表条目，该条目允许来自来源 IP 地址和来源端口 192.0.2.7:443 的入站数据包。
您可以删除示例 Dynamic NIC 并创建替换 Dynamic NIC。替换 Dynamic NIC 也使用 VLAN ID 4，但连接到另一个 VPC 网络 network-2 中的子网。
适用于原始 Dynamic NIC 的所有未过期防火墙连接跟踪表条目都适用于替换 Dynamic NIC。这意味着 network-2 VPC 网络中的资源可以发送来源与 192.0.2.7:443 匹配的数据包，计算实例会接受这些数据包，而无需评估入站防火墙规则。

如需详细了解连接跟踪和防火墙规则，请参阅《Cloud 新一代防火墙》文档中的规范。

解决方案

在单个实例基础上，如果您需要创建 Dynamic NIC 并使用与从实例中移除的 Dynamic NIC 相同的 VLAN ID，请执行以下操作：

在删除原始 Dynamic NIC 和创建替换 Dynamic NIC 之间，请等待至少 10 分钟。
停止实例，删除原始 Dynamic NIC 并创建替换 Dynamic NIC，然后启动实例。

数据包拦截可能会导致数据包因为以太网标头中缺少 VLAN 标记而被丢弃

使用 Dynamic NIC 时，数据包拦截可能会导致丢弃数据包。当流水线提前终止时，可能会发生数据包丢弃问题。此问题会同时影响基于会话的模式和非基于会话的模式。

根本原因

当流水线提前终止时，在数据包拦截期间会发生数据包丢弃问题（入站拦截和出站重新注入）。提前终止会导致入站数据包的以太网标头中缺少 VLAN ID。由于出站数据包派生自修改后的入站数据包，因此出站数据包也缺少 VLAN ID。这会导致端点索引选择错误和后续数据包丢弃。

临时解决方法

请勿使用依赖于数据包拦截的 Google Cloud 功能，例如防火墙端点。

Linux 虚拟机实例的已知问题

以下是 Linux 虚拟机的已知问题。

使用操作系统映像版本 v20250530 的 Ubuntu 虚拟机显示不正确的 FQDN

如果您执行以下操作之一，可能会看到添加了 .local 后缀的不正确的完全限定域名 (FQDN)：

更新到 google-compute-engine 软件包的 20250328.00 版本。
通过 Canonical 提供的版本后缀为 v20250530 的任何 Ubuntu 映像启动实例。例如 projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530。

如果您遇到此问题，可能会看到类似于以下内容的 FQDN：

   [root@ubuntu2204 ~]# apt list --installed | grep google
   ...
   google-compute-engine/noble-updates,now 20250328.00-0ubuntu2~24.04.0 all [installed]
   ...

   [root@ubuntu2204 ~]# curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
   projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

   [root@ubuntu2204 ~]# hostname -f
   ubuntu2204.local

根本原因

在版本为 v20250530 的所有 Ubuntu 映像中，guest-config 软件包版本 20250328.00 会将 local 添加到搜索路径中，因为引入了新的配置文件：https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf

   [root@ubuntu2204 ~]# cat /etc/resolv.conf
   # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
   # Do not edit.
   ...

   nameserver 127.0.0.53
   options edns0 trust-ad
   search local ... google.internal

如果 /etc/resolv.conf 文件的搜索路径中存在此 local 条目，则在请求 FQDN 时，系统会将 .local 元素附加到主机名。

请注意，guest-configs 版本 20250501 已修复此问题，但 Canonical 尚未将修复程序整合到其映像中。

临时解决方法

通过将 Domains=local 更改为 Domains=~local，来修改网络名称解析配置文件 /etc/systemd/resolved.conf.d/gce-resolved.conf
运行以下命令以重启 systemd-resolved 服务：systemctl restart systemd-resolved
检查是否从 /etc/resolv.conf 中的搜索路径中移除了 local

使用命令 hostname -f 确认 FQDN

[root@ubuntu2204 ~]# hostname -f
ubuntu2204.us-central1-a.c.my-project.internal

更改实例类型后，SUSE Enterprise 虚拟机无法启动

更改 SUSE Linux Enterprise 虚拟机的实例类型后，虚拟机可能会无法启动，并且串行控制台中会重复显示以下错误：

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

根本原因

SUSE 使用支持各种实例类型的多功能 initramfs（初始 RAM 文件系统）创建其云映像。这是通过在初始映像创建期间使用 --no-hostonly --no-hostonly-cmdline -o multipath 标志来实现的。不过，当安装新内核或重新生成 initramfs（在系统更新期间发生）时，这些标志默认情况下会被省略。这会生成专门针对当前系统硬件量身定制的较小 initramfs，可能会排除其他实例类型所需的驱动程序。

例如，C3 实例使用 NVMe 硬盘，而这类硬盘需要在 initramfs 中包含特定模块。如果使用缺少这些 NVMe 模块的 initramfs 的系统迁移到 C3 实例，则启动过程会失败。此问题还可能会影响具有独特硬件要求的其他实例类型。

临时解决方法

在更改机器类型之前，请重新生成包含所有驱动程序的 initramfs：

dracut --force --no-hostonly

如果系统已受此问题影响，请创建临时抢救虚拟机。使用 chroot 命令访问受影响虚拟机的启动磁盘，然后使用以下命令重新生成 initramfs：

dracut -f --no-hostonly

使用 SUSE 12 映像的 Z3 上的本地 SSD 的 IOPS 性能较低

对于本地 SSD 磁盘上的 IOPS，SUSE Linux Enterprise Server (SLES) 12 映像上的 Z3 虚拟机的性能显著低于预期。

根本原因

这是 SLES 12 代码库中的问题。

临时解决方法

SUSE 尚未发布或计划发布用于解决此问题的补丁。您应改用 SLES 15 操作系统。

RHEL 7 和 CentOS 虚拟机在重新启动后失去网络连接

如果您的 CentOS 或 RHEL 7 虚拟机具有多个网络接口卡 (NIC)，并且其中一个 NIC 不使用 VirtIO 接口，则可能会在重新启动时失去网络连接。这是因为如果至少有一个 NIC 不使用 VirtIO 接口，则 RHEL 不支持停用可预测的网络接口名称。

解决方法

可通过停止并启动虚拟机来恢复网络连接，直到问题解决。您可以执行以下操作来防止再次失去网络连接： 1. 修改 /etc/default/grub 文件并移除内核参数 net.ifnames=0 和 biosdevname=0。 2. 重新生成 grub 配置。 3. 重新启动虚拟机。

已解决：运行 SUSE Linux 的 C3 和 C3D 虚拟机上的本地 SSD 设备缺少符号链接

以下问题已于 2025 年 1 月 13 日解决。

公共 Google Cloud SUSE 映像不包含为 C3 和 C3D 本地 SSD 设备创建符号链接所需的 udev 配置。

解决方法

如需为 SUSE 和自定义映像添加 udev 规则，请参阅未在具有本地 SSD 的 C3 和 C3D 上创建符号链接。

无法验证 repomd.xml 签名

在 Red Hat Enterprise Linux (RHEL) 或基于 CentOS 7 的系统上，您可能会在尝试使用 yum 安装或更新软件时看到以下错误。此错误表示您的代码库 GPG 密钥已过期或不正确。

日志示例：

[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

解决方法

如要解决此问题，请通过设置 repo_gpgcheck=0，在 yum 代码库配置中停用代码库 GPG 密钥检查。在受支持的 Compute Engine 基础映像中，您可能会在 /etc/yum.repos.d/google-cloud.repo 文件中找到此设置。但是，您的虚拟机可以在不同的代码库配置文件或自动化工具中进行此设置。

Yum 代码库通常不使用 GPG 密钥进行代码库验证。相反，此类仓库选择信任 https 端点。

如需找到并更新此设置，请完成以下步骤：

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

将所有显示 repo_gpgcheck=1 的行更改为 repo_gpgcheck=0。

sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /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=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

使用 OS Login 的实例在连接后返回登录消息

在某些使用 OS Login 的实例上，您可能会在连接建立后收到以下错误消息：

/usr/bin/id: cannot find name for group ID 123456789

解决方法

请忽略此错误消息。

Windows 虚拟机实例的已知问题

在 Windows 上使用社区 NVMe 驱动程序为 NVMe 提供支持的功能目前处于 Beta 版，因此性能可能与 Linux 实例的情况不匹配。社区 NVMe 驱动程序已替换为 Google Cloud 公共映像中的 Microsoft StorNVMe 驱动程序。我们建议您替换 2022 年 5 月之前创建的虚拟机上的 NVME 驱动程序，并改用 Microsoft StorNVMe 驱动程序。
创建实例之后，您无法即时连接到该实例。所有新的 Windows 实例都会使用系统准备 (sysprep) 工具来设置您的实例，这可能需要 5-10 分钟才能完成。
如果没有与 kms.windows.googlecloud.com 建立网络连接，Windows Server 映像将无法激活，而如果这些映像未在 30 天内进行初始身份验证，则会停止运行。由 KMS 激活的软件必须每 180 天重新激活一次，但是 KMS 会尝试每 7 天重新激活一次。请务必配置您的 Windows 实例，以使其保持激活状态。
访问非模拟的模型专用寄存器的内核软件将会产生一般保护性错误，这可能会导致系统崩溃，具体取决于客机操作系统。

Windows Server 2025 和 Windows 11 24h2 - 暂停和恢复支持

Windows Server 2025 和 Windows 11 24h2 在暂停时无法恢复。在此问题得到解决之前，Windows Server 2025 和 Windows 11 24h2 不支持暂停和恢复功能。

在 Windows 虚拟机上使用 w32tm 测量 NTP 时间偏移时出错

对于 Compute Engine 上运行 VirtIO NIC 的 Windows 虚拟机，存在一个已知的 bug，即使用以下命令时测量 NTP 偏移会发生错误：

w32tm /stripchart /computer:metadata.google.internal

错误内容如下：

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

这个 bug 仅影响具有 VirtIO NIC 的 Compute Engine 虚拟机。使用 gVNIC 的虚拟机不会遇到此问题。

为避免此问题，Google 建议使用其他 NTP 偏移测量工具，例如 Meinberg 时间服务器监视器。

将虚拟机从第 1 代或第 2 代更新为第 3 代及以上虚拟机后启动设备无法访问

Windows Server 会在首次启动时将启动磁盘绑定到其初始磁盘接口类型。如需将现有虚拟机从使用 SCSI 磁盘接口的较旧机器系列更改为使用 NVMe 磁盘接口的较新机器系列，请在关停虚拟机之前执行 Windows PnP 驱动程序 sysprep。此 sysprep 仅准备设备驱动程序，并确保在下次启动时为启动驱动器扫描所有磁盘接口类型。

如需更新虚拟机的机器系列，请执行以下操作：

以 Administrator 身份在 Powershell 提示符下运行以下命令：

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait

停止虚拟机。
将虚拟机更改为新的虚拟机机器类型。
启动虚拟机。

如果新虚拟机未正确启动，请将虚拟机更改回原始机器类型，以使虚拟机重新运行。它应该会成功启动。查看迁移要求，以验证您是否符合这些要求。然后重试说明。

Windows 虚拟机上的 gVNIC 带宽受限

对于标准网络性能和每个虚拟机的 Tier_1 网络性能，Compute Engine 提供的 Windows 映像中的已封装 gVNIC 驱动程序可以在 Windows 实例上实现高达 50 Gbps 的网络带宽。更新后的 gVNIC 驱动程序版本可以提供线路速率性能（最高 200 Gbps）并支持巨型帧。

更新后的驱动程序仅适用于第三代及更高版本的机器系列（不包括 N4）。如需了解详情，请参阅在 Windows 操作系统上更新 gVNIC 版本。

较新虚拟机机器系列的磁盘挂接数受限

在 Microsoft Windows 上运行且具有 NVMe 磁盘接口的虚拟机（包括 T2A、所有第三代及更高版本的虚拟机）的磁盘挂接限制为 16 个磁盘。为避免出错，请将每个虚拟机的 Persistent Disk 和 Hyperdisk 存储整合为最多 16 个磁盘。本地 SSD 存储不受此问题的影响。

替换 2022 年 5 月之前创建的虚拟机上的 NVME 驱动程序

如果您要在使用 Microsoft Windows 的虚拟机上使用 NVMe，并且该虚拟机是在 2022 年 5 月 1 日之前创建的，则您必须更新客机操作系统中的现有 NVMe 驱动程序以使用 Microsoft StorNVMe 驱动程序。

在将机器类型更改为第三代机器系列之前，或在创建启动磁盘快照（用于创建使用第三代机器系列的新虚拟机）之前，您必须先更新虚拟机上的 NVMe 驱动程序。

使用以下命令安装 StorNVME 驱动程序软件包并移除社区驱动程序（如果客机操作系统中存在）。

googet update
googet install google-compute-engine-driver-nvme

具有 C3 和 C3D 虚拟机的 Microsoft Windows 上的本地 SSD 的性能降低

目前，运行 Microsoft Windows 的 C3 和 C3D 虚拟机存在本地 SSD 性能限制。

性能改进正在进行中。

使用 gVNIC 时网络吞吐量不佳

使用 Google 虚拟 NIC (gVNIC) 时，使用 gVNIC 驱动程序 GooGet 软件包版本 1.0.0@44 或更早版本的 Windows Server 2022 和 Windows 11 虚拟机可能会遇到网络吞吐量不佳问题。

如需解决此问题，请通过执行以下操作将 gVNIC 驱动程序 GooGet 软件包更新到 1.0.0@45 或更高版本：

从管理员命令提示符或 Powershell 会话中运行以下命令，检查虚拟机上安装了哪个驱动程序版本：
```
googet installed
```
输出类似于以下内容：
```
Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...
```
如果 google-compute-engine-driver-gvnic.x86_64 驱动程序版本为 1.0.0@44 或更早版本，请通过管理员命令提示符或 Powershell 会话运行以下命令来更新 GooGet 软件包代码库：
```
googet update
```

大型 C4D 和 C3D vCPU 机器类型不支持 Windows 操作系统映像

具有 180 个以上的 vCPU 的 C4D 和 C3D 机器类型不支持 Windows Server 2012 和 2016 操作系统映像。使用 Windows Server 2012 和 2016 操作系统映像的大型 C4D 和 C3D 机器类型将无法启动。如需解决此问题，请选择较小的机器类型或使用其他操作系统映像。

使用 360 个 vCPU 和 Windows 操作系统映像创建的 C3D 虚拟机将无法启动。如需解决此问题，请选择较小的机器类型或使用其他操作系统映像。

使用 255 个以上的 vCPU 和 Windows 2025 创建的 C4D 虚拟机将无法启动。如需解决此问题，请选择较小的机器类型或使用其他操作系统映像。

用于 M3、C3、C3D 和 C4D 虚拟机的 Windows Server 2016 和 2012 R2 上的通用磁盘错误

目前，在特定 Windows 客机上，无法按预期为正在运行的 M3、C3、C3D 或 C4D 虚拟机添加 Hyperdisk 或 Persistent Disk 或是调整其大小。Windows Server 2012 R2 和 Windows Server 2016 及其相应的非服务器 Windows 变体无法正确响应磁盘挂接和磁盘大小调整命令。

例如，从正在运行的 M3 虚拟机中移除磁盘会断开磁盘与 Windows Server 实例的连接，但 Windows 操作系统不能识别出磁盘已移除。对磁盘的后续写入会返回一般性错误。

解决方法

修改 Hyperdisk 或 Persistent Disk 后，您必须重启 Windows 上运行的 M3、C3、C3D 或 C4D 虚拟机，才能让这些客机识别磁盘修改。

已知问题 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

常见问题

您无法使用 Google Cloud 控制台为 A4 和 A3 Ultra 创建 Spot 虚拟机

使用 gcloud compute disks update 命令修改异步复制主磁盘上的 IOPS 或吞吐量会导致误报错误

元数据服务器可能会显示旧的 physicalHost 虚拟机元数据

实时迁移期间无法访问仅限 IPv6 的 C3 虚拟机

托管式实例组 (MIG) 中的较长 baseInstanceName 值可能会导致磁盘名称冲突

使用指定 A2、C3 或 G2 机器类型的实例模板来创建预留或未来预留请求会导致问题

将 c3-standard-*-lssd 和 c3d-standard-*-lssd 机器类型与 Google Kubernetes Engine 搭配使用时的限制

C3D 虚拟机上的单个流 TCP 吞吐量可变性

对于每个核心使用一个线程的虚拟机，CPU 利用率可观测性指标不正确

如果您使用自定义防火墙规则，则Google Cloud 控制台 SSH-in-browser 连接可能会失败

磁盘的临时名称

由磁盘大小调整导致的某些 Persistent Disk 的延迟时间增加

如果自动化流程使用基于资源的承诺配额相关的 API 响应数据，则这些自动化流程可能会失败

根本原因

如何解决此问题

裸金属实例的已知问题

与使用 Dynamic Network Interface 相关的问题

使用自定义 MTU 大小时发生丢包

临时解决方法

将 VLAN ID 重复用于 Dynamic NIC 时的防火墙互动

解决方案

数据包拦截可能会导致数据包因为以太网标头中缺少 VLAN 标记而被丢弃

根本原因

临时解决方法

Linux 虚拟机实例的已知问题

使用操作系统映像版本 v20250530 的 Ubuntu 虚拟机显示不正确的 FQDN

根本原因

临时解决方法

更改实例类型后，SUSE Enterprise 虚拟机无法启动

根本原因

临时解决方法

使用 SUSE 12 映像的 Z3 上的本地 SSD 的 IOPS 性能较低

根本原因

临时解决方法

RHEL 7 和 CentOS 虚拟机在重新启动后失去网络连接

已解决：运行 SUSE Linux 的 C3 和 C3D 虚拟机上的本地 SSD 设备缺少符号链接

无法验证 repomd.xml 签名

使用 OS Login 的实例在连接后返回登录消息

Windows 虚拟机实例的已知问题

Windows Server 2025 和 Windows 11 24h2 - 暂停和恢复支持

在 Windows 虚拟机上使用 w32tm 测量 NTP 时间偏移时出错

将虚拟机从第 1 代或第 2 代更新为第 3 代及以上虚拟机后启动设备无法访问

Windows 虚拟机上的 gVNIC 带宽受限

较新虚拟机机器系列的磁盘挂接数受限

替换 2022 年 5 月之前创建的虚拟机上的 NVME 驱动程序

具有 C3 和 C3D 虚拟机的 Microsoft Windows 上的本地 SSD 的性能降低

使用 gVNIC 时网络吞吐量不佳

大型 C4D 和 C3D vCPU 机器类型不支持 Windows 操作系统映像

用于 M3、C3、C3D 和 C4D 虚拟机的 Windows Server 2016 和 2012 R2 上的通用磁盘错误

已知问题

使用 `gcloud compute disks update` 命令修改异步复制主磁盘上的 IOPS 或吞吐量会导致误报错误

元数据服务器可能会显示旧的 `physicalHost` 虚拟机元数据

托管式实例组 (MIG) 中的较长 `baseInstanceName` 值可能会导致磁盘名称冲突

将 `c3-standard--lssd` 和 `c3d-standard--lssd` 机器类型与 Google Kubernetes Engine 搭配使用时的限制