已知问题

Linux Windows

---

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

常见问题

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

使用指定 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 流。

具有 T2D 机器系列的托管式实例组无法按预期自动扩缩

在 2023 年 6 月 18 日之前创建的项目中具有 T2D 机器系列虚拟机的代管式实例组 (MIG) 无法正确检测 MIG 中虚拟机上的 CPU 负载。在此类项目中，根据具有 T2D 机器系列虚拟机的 MIG 中的 CPU 利用率进行自动扩缩可能不正确。

如需修复项目，请与 Cloud Customer Care 团队联系。

对于每个核心使用一个线程的虚拟机，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-browser Google Cloud 控制台功能连接到虚拟机。

• 重新创建 default-allow-ssh 防火墙规则以继续使用 SSH-in-browser 连接到虚拟机。

• 使用 Google Cloud CLI 而非 SSH-in-browser 连接到虚拟机。

缩减或删除特定预留会阻止虚拟机使用其他预留

如果您缩减或删除一个或多个虚拟机使用的特定预留，则孤立虚拟机无法使用任何预留。

• （可选）为防止此问题，请删除虚拟机或更新虚拟机的 reservationAffinity 属性，直至以特定预留为目标的虚拟机数量与为特定预留计划的虚拟机数量相匹配。之后，您可以缩减或删除特定预留。

• 要解决此问题，请按以下步骤操作：

  1. 通过执行以下一项或多项操作，将特定预留中的虚拟机数量设置为以该预留为目标的虚拟机的数量：删除虚拟机、更新虚拟机的 reservationAffinity 属性、增加已缩减预留的大小或重新创建已删除的特定预留。

  2. 停止和启动任何剩余的虚拟机。

详细了解如何删除预留和调整预留的大小。

使用 moveInstance API 或 gcloud CLI 移动虚拟机或磁盘会导致意外行为

注意：projects.moveInstance 方法已于 2022 年 5 月弃用。projects.moveInstance 方法将于 2024 年 2 月或之后移除。

使用 gcloud compute instances move 命令或 project.moveInstance 方法移动虚拟机 (VM) 实例可能会导致数据丢失、虚拟机删除或其他意外行为。

如需移动虚拟机，我们建议您按照在可用区或区域之间移动虚拟机实例中的说明操作。

挂接到具有 n2d-standard-64 机器类型的虚拟机的磁盘无法一直达到性能限制

挂接到具有 n2d-standard-64 机器类型的虚拟机的永久性磁盘无法一直达到 100,000 IOPS 的最大性能限制。这是读取和写入 IOPS 的情况。

磁盘的临时名称

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

• -temp
• -old
• -new

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

由永久性磁盘大小调整导致的某些永久性磁盘的延迟时间增加

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

将 MBR 映像与具有本地 SSD 的 C3 虚拟机搭配使用

使用 c3-standard-44-lssd 和更大机器类型创建的 C3 虚拟机无法使用 MBR 映像成功启动。

能够将不受支持的 PD-Standard 和 PD-Extreme 磁盘挂接到 C3 和 M3 虚拟机

使用 Google Cloud CLI 或 Compute Engine API 时，标准永久性磁盘 (pd-standard) 是默认启动磁盘类型。但是，C3 和 M3 虚拟机不支持 pd-standard 磁盘。此外，C3 虚拟机不支持 pd-extreme 磁盘。

使用 Google Cloud CLI 或 Compute Engine API 时，可能会出现以下问题：

• pd-standard 配置为默认启动磁盘类型，并且系统会创建该磁盘，除非您指定其他受支持的启动磁盘类型（例如 pd-balanced 或 pd-ssd）。
• 在 C3 正式版 (GA) 发布之前，您可以将 pd-extreme 磁盘挂接到 C3 虚拟机，并将 pd-standard 磁盘挂接到 C3 和 M3 虚拟机。

如果您创建的 C3 或 M3 虚拟机具有不受支持的磁盘类型，请将数据迁移到受支持的新磁盘类型，如更改永久性磁盘的类型中所述。如果您未更改磁盘类型，虚拟机将继续正常运行，但磁盘分离和重新挂接等某些操作将失败。

临时解决方法

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

• 使用 Google Cloud 控制台创建 C3 或 M3 虚拟机并挂接磁盘。控制台会使用 pd-balanced 启动磁盘创建 C3 和 M3 虚拟机，并且不允许将不受支持的磁盘类型挂接到虚拟机。
• 如果使用 Google Cloud CLI 或 Compute Engine API，请在创建虚拟机时明确配置 pd-balanced 或 pd-ssd 类型的启动磁盘。

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

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

1. 响应数据来自以下任意一种 Compute Engine API 方法：

   • compute.regions.list 方法
   • compute.regions.get 方法
   • compute.projects.get 方法

2. 您可以使用 int 而不是 number 来定义 API 响应正文中的资源配额上限字段。您可以在每个方法中通过以下方式查找该字段：

   • 用于 compute.regions.list 方法的 items[].quotas[].limit。
   • 用于 compute.regions.get 方法的 quotas[].limit。
   • 用于 compute.projects.get 方法的 quotas[].limit。

3. 任何 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 的值。您必须为所有区域中具有基于资源的承诺的所有项目设置配额上限。您可以通过以下某种方式执行此操作：

  • 按照与申请提高配额部分相同的步骤，申请降低配额上限。
  • 设置使用方配额替换值。

注意：限制配额上限只是一个临时解决方法，您最终需要修改 items[].quotas[].limit 字段 [compute.regions.list 方法]的定义并将其更改为 number 类型。如需将承诺 SKU 的默认配额上限恢复为无限配额，您必须移除对配额上限施加的限制。

裸金属实例的已知问题

以下是 Compute Engine 裸机实例的已知问题。

丢弃的数据包的统计数据不正确

VIRTCHNL2_OP_GET_STATS 报告的丢弃数据包数量是一个很大的数值。

根本原因是，IDPF 向操作系统报告 EthStats::rx_discards 为 rtnl_link_stats64::rx_dropped。当您运行 ifconfig 时，此值会显示为 RX dropped。

Linux 虚拟机实例的已知问题

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

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 设备缺少符号链接

公共 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 端点。

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

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

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

   sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

3. 检查该设置是否已更新。

   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 11 版本 22H2 的实例无法启动。在此问题得到解决之前，请使用 Windows 11 版本 21H2。
• 在 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 虚拟机上使用 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

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

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

具有 C3 和 C3D 虚拟机的 Microsoft Windows 上的 gVNIC 带宽受限

在 Windows 操作系统上，gVNIC 驱动程序不会达到文档中说明的带宽限制。目前，对于默认网络和每个虚拟机的 Tier_1 网络性能，gVNIC 驱动程序可以在运行 Microsoft Windows 的 C3 和 C3D 虚拟机上实现高达 85 Gbps 的网络带宽。

替换 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 性能限制。

性能改进正在进行中。

通过 C3 和 M3 虚拟机降低 Microsoft Windows 上的 Hyperdisk Extreme 的 IOPS 性能

Microsoft Windows 虚拟机上的 Hyperdisk Extreme 性能目前受限。

性能改进正在进行中。

使用 gVNIC 时网络吞吐量不佳

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

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

1. 从管理员命令提示符或 Powershell 会话中运行以下命令，检查虚拟机上安装了哪个驱动程序版本：

   googet installed
   

   输出类似于以下内容：

   Installed packages:
     ...
     google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
     ...
   

2. 如果 google-compute-engine-driver-gvnic.x86_64 驱动程序版本为 1.0.0@44 或更早版本，请通过管理员命令提示符或 Powershell 会话运行以下命令来更新 GooGet 软件包代码库：

   googet update
   

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

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

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

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

警告：Windows Server 2012 R2 不再受支持，因此不建议使用。请升级到受支持的 Windows Server 版本。

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

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

解决方法

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