알려진 문제

이 페이지는 Compute Engine을 사용하는 동안 발생할 수 있는 알려진 문제를 설명합니다. 특히 컨피덴셜 VM에 영향을 주는 문제는 컨피덴셜 VM 제한사항을 참고하세요.

일반적인 문제

다음 문제는 문제 해결 안내나 일반 정보를 제공합니다.

A2, C3 또는 G2 머신 유형을 지정하는 인스턴스 템플릿을 사용하여 예약 또는 미래용 예약 요청을 만들면 문제 발생

A2, C3 또는 G2 머신 유형을 지정하는 인스턴스 템플릿을 사용하여 예약을 만들거나 검토를 위해 미래용 예약 요청을 만들고 제출하면 문제가 발생합니다. 구체적으로는 다음과 같습니다.

  • 예약 만들기가 실패할 수 있습니다. 성공하면 다음 중 하나가 적용됩니다.

    • 자동으로 사용된 예약(기본값)을 만든 경우 속성이 일치하는 VM을 만들면 예약이 소비되지 않습니다.

    • 특정 예약을 만든 경우 특히 예약을 타겟팅하는 VM을 만들 수 없습니다.

  • 미래용 예약 요청을 만들면 성공합니다. 그러나 검토를 위해 요청을 제출하면 Google Cloud가 요청을 거부합니다.

예약 또는 미래용 예약 요청을 만드는 데 사용된 인스턴스 템플릿을 바꾸거나 템플릿의 VM 속성을 재정의할 수 없습니다. A2, C3 또는 G2 머신 유형의 리소스를 예약하려면 대신 다음 중 하나를 수행하세요.

c3-standard-*-lssd 및 c3d-standard-*-lssd 머신 유형을 Google Kubernetes Engine과 함께 사용할 때의 제한사항

Google Kubernetes Engine API를 사용하는 경우 프로비저닝하는 로컬 SSD가 연결된 노드 풀에는 선택한 C3 및 C3D 머신 유형과 동일한 수의 SSD 디스크가 있어야 합니다. 예를 들어 c3-standard-8-lssd를 사용하는 VM을 만들려는 경우 SSD 디스크가 2개 있어야 하지만 c3d-standard-8-lssd에서는 SSD 디스크가 1개만 필요합니다. 디스크 번호가 일치하지 않으면 Compute Engine 컨트롤 플레인에서 로컬 SSD 구성 오류가 발생합니다. C3 또는 C3D lssd 머신 유형을 기준으로 올바른 로컬 SSD 디스크 수를 선택하려면 범용 머신 계열 문서를 참조하세요.

Google Kubernetes Engine Google Cloud 콘솔을 사용하여 c3-standard-*-lssd 및 c3d-standard-*-lssd VM으로 클러스터 또는 노드 풀을 만들면 노드 생성이 실패하거나 로컬 SSD를 임시 스토리지로 감지할 수 없습니다.

C3D VM의 단일 흐름 TCP 처리량 변동성

vCPU가 30개 이상인 C3D VM에서는 단일 흐름 TCP 처리량 변동이 발생할 수 있으며 20~25Gbps로 제한되는 경우가 있습니다. 속도를 높이려면 여러 tcp 흐름을 사용합니다.

T2D 머신 시리즈를 사용하는 관리형 인스턴스 그룹이 예상대로 자동 확장되지 않음

2023년 6월 18일 이전에 생성된 프로젝트에 T2D 머신 시리즈 VM이 있는 관리형 인스턴스 그룹(MIG)은 MIG의 VM에서 CPU 로드를 올바르게 감지하지 못합니다. 이러한 프로젝트에서 T2D 머신 시리즈 VM이 있는 MIG의 CPU 사용률을 기준으로 자동 확장이 잘못되었을 수 있습니다.

프로젝트에 수정사항을 적용하려면 Cloud Customer Care에 문의하세요.

코어당 하나의 스레드를 사용하는 VM에 대해 CPU 사용률 관측 가능성 측정항목이 잘못되었습니다.

VM의 CPU에 코어당 하나의 스레드가 사용되는 경우에는 Compute Engine > VM 인스턴스 > 관측 가능성 탭에서 CPU 사용률 Cloud Monitoring 관측 가능성 측정항목이 50%로만 확장됩니다. Tau T2D를 제외하고 모든 머신 유형에는 코어당 2개 스레드가 기본값입니다. 자세한 내용은 코어당 스레드 수 설정을 참조하세요.

100%로 정규화된 VM의 CPU 사용률을 보려면 대신 측정항목 탐색기에서 CPU 사용률을 확인하세요. 자세한 내용은 측정항목 탐색기로 차트 만들기를 참조하세요.

커스텀 방화벽 규칙을 사용하는 경우 Google Cloud 콘솔 브라우저 내 SSH 연결이 실패할 수 있음

커스텀 방화벽 규칙을 사용하여 VM 인스턴스에 대한 SSH 액세스를 제어하는 경우 브라우저에서 SSH를 통해 연결 기능을 사용하지 못할 수 있습니다.

이 문제를 해결하려면 다음 방법 중 하나를 따르세요.

특정 예약을 축소하거나 삭제하면 VM에서 다른 예약 사용이 중단됨

VM 하나 이상에서 소비한 특정 예약을 축소하거나 삭제하면 분리된 VM에서 예약을 사용할 수 없습니다.

예약 삭제 및 예약 크기 조정을 자세히 알아보세요.

moveInstance API 또는 gcloud CLI를 사용하여 VM 또는 디스크를 이동할 때 예기치 않은 동작 발생

gcloud compute instances move 명령어 또는 project.moveInstance 메서드를 사용하여 가상 머신(VM) 인스턴스를 이동하면 데이터 손실, VM 삭제, 기타 예기치 않은 동작이 발생할 수 있습니다.

VM을 이동하려면 영역 또는 리전 간 VM 인스턴스 이동의 안내를 따르는 것이 좋습니다.

n2d-standard-64 머신 유형의 VM에 연결된 디스크가 성능 한도에 지속적으로 도달하지 않음

머신 유형이 n2d-standard-64인 VM에 연결된 영구 디스크가 최대 성능 한도인 100,000 IOPS에 일관되게 도달하지 않습니다. 이는 읽기 IOPS와 쓰기 IOPS 모두에 해당합니다.

디스크의 임시 이름

gcloud compute instances update 명령어 또는 instances.update API 메서드를 사용하여 시작된 가상 머신(VM) 인스턴스 업데이트 도중 Compute Engine은 원래 이름에 다음 서픽스를 추가하여 VM 디스크의 이름을 일시적으로 변경할 수 있습니다.

  • -temp
  • -old
  • -new

Compute Engine은 업데이트가 완료되면 서픽스를 삭제하고 원래 디스크 이름을 복원합니다.

디스크 크기 조정으로 인한 일부 Persistent Disk의 지연 시간 증가

일부 경우에는 큰 Persistent Disk(3TB 또는 그 이상)의 크기 조정으로 인해 디스크의 I/O 성능이 저하될 수 있습니다. 이 문제에 해당할 경우에는 Persistent Disk에서 크기 조정 작업 중 지연 시간이 늘어날 수 있습니다. 이 문제는 모든 유형의 Persistent Disk에 영향을 줄 수 있습니다.

지원되지 않는 PD-Standard 및 PD-Extreme 디스크를 C3 및 M3 VM에 연결할 수 있음

표준 영구 디스크(pd-standard)는 Google Cloud CLI 또는 Compute Engine API를 사용할 때의 기본 부팅 디스크 유형입니다. 그러나 C3 및 M3 VM에서는 pd-standard 디스크가 지원되지 않습니다. 또한 C3 VM에서는 pd-extreme 디스크를 지원하지 않습니다.

Google Cloud CLI 또는 Compute Engine API를 사용할 때 다음과 같은 문제가 발생할 수 있습니다.

  • pd-standard가 기본 부팅 디스크 유형으로 구성되며 pd-balanced 또는 pd-ssd와 같이 지원되는 다른 부팅 디스크 유형을 지정하지 않는 한 디스크가 생성됩니다.
  • C3의 정식 버전(GA) 이전에는 pd-extreme 디스크를 C3 VM에, pd-standard 디스크를 C3 및 M3 VM에 연결할 수 있었습니다.

지원되지 않는 디스크 유형으로 C3 또는 M3 VM을 만든 경우 영구 디스크 유형 변경의 설명에 따라 지원되는 새 디스크 유형으로 데이터를 이동합니다. 디스크 유형을 변경하지 않으면 VM은 계속 작동하지만 디스크 분리 및 재연결 등 일부 작업이 실패합니다.

해결 방법

이 문제를 해결하려면 다음 방법 중 하나를 따르세요.

  • Google Cloud 콘솔을 사용하여 C3 또는 M3 VM을 만들고 디스크를 연결합니다. 콘솔은 pd-balanced 부팅 디스크를 사용하여 C3 및 M3 VM을 만들며 지원되지 않는 디스크 유형을 VM에 연결하는 것을 허용하지 않습니다.
  • Google Cloud CLI 또는 Compute Engine API를 사용하는 경우 VM을 만들 때 pd-balanced 또는 pd-ssd 유형의 부팅 디스크를 명시적으로 구성합니다.

리소스 기반 약정 할당량에 대한 API 응답 데이터를 사용할 경우 자동화된 프로세스가 실패할 수 있음

Compute Engine 리소스 기반 약정 할당량에 대한 API 응답 데이터를 소비하고 사용하는 자동화된 프로세스는 다음과 같은 각 상황이 발생할 경우 실패할 수 있습니다. 자동화된 프로세스에는 API 응답을 사용하거나 저장하는 코드 스니펫, 비즈니스 로직 또는 데이터베이스 필드가 포함될 수 있습니다.

  1. 응답 데이터는 다음 Compute Engine API 메서드 중 하나에서 가져온 것입니다.

  2. number 대신 int를 사용하여 API 응답 본문에서 리소스 할당량 한도의 필드를 정의합니다. 각 메서드에 대해 다음과 같은 방법으로 필드를 찾을 수 있습니다.

  3. Compute Engine 약정 SKU에 사용할 수 있는 기본 할당량은 무제한입니다.

    약정 및 약정 SKU의 할당량에 대한 자세한 내용은 약정 및 약정 리소스 할당량을 참조하세요.

근본 원인

제한된 할당량이 있는 경우 items[].quotas[].limit 또는 quotas[].limit 필드를 int 유형으로 정의하더라도 할당량 한도의 API 응답 데이터가 int 유형의 범위에 속할 수 있으며 자동화된 프로세스가 중단되지 않을 수 있습니다. 하지만 기본 할당량 한도가 무제한이면 Compute Engine API는 int 유형으로 정의된 범위를 벗어나는 limit 필드 값을 반환합니다. 자동화된 프로세스는 API 메서드에서 반환한 값을 소비할 수 없으므로 실패합니다.

이 문제를 해결하는 방법

이 문제를 해결한 후 계속해서 다음과 같은 방법으로 자동화된 보고서를 생성할 수 있습니다.

  • 권장: Compute Engine API 참고 문서를 따르고 API 메서드 정의에 올바른 데이터 유형을 사용합니다. 특히 number 유형을 사용하여 API 메서드에 대해 items[].quotas[].limit 및 quotas[].limit 필드를 정의합니다.

  • 할당량 한도를 9,223,372,036,854,775,807 미만 값으로 줄입니다. 모든 리전에서 리소스 기반 약정이 있는 모든 프로젝트에 할당량 상한을 설정해야 합니다. 다음 방법 중 하나로 이 작업을 수행할 수 있습니다.

베어메탈 인스턴스의 알려진 문제

다음은 Compute Engine 베어메탈 인스턴스의 알려진 문제입니다.

삭제된 패킷 통계가 잘못됨

VIRTCHNL2_OP_GET_STATS에서 보고된 삭제된 패킷 수가 매우 큽니다.

근본 원인은 IDPF가 EthStats::rx_discards를 OS에 rtnl_link_stats64::rx_dropped로 보고하기 때문입니다. ifconfig를 실행하면 RX dropped로 표시됩니다.

Linux VM 인스턴스의 알려진 문제

다음은 Linux VM의 알려진 문제입니다.

SUSE 12 이미지가 있는 Z3의 로컬 SSD에서 IOPS 성능 저하

SUSE Linux Enterprise Server(SLES) 12 이미지의 Z3 VM은 로컬 SSD 디스크의 IOPS 성능이 예상보다 훨씬 낮습니다.

근본 원인

이는 SLES 12 코드베이스 내의 문제입니다.

해결 방법

이 문제를 해결하기 위한 SUSE의 패치는 제공되지 않거나 계획되어 있지 않습니다. 대신 SLES 15 운영체제를 사용해야 합니다.

RHEL 7 및 CentOS VM이 재부팅 후 네트워크 액세스가 손실됨

CentOS 또는 RHEL 7 VM에 여러 네트워크 인터페이스카드(NIC)가 있고 이러한 NIC 중 하나에 VirtIO 인터페이스가 사용되지 않으면 재부팅 시 네트워크 액세스가 손실될 수 있습니다. 이 문제는 하나 이상의 NIC에 VirtIO 인터페이스가 사용되지 않을 경우 RHEL이 예측 가능한 네트워크 인터페이스 이름 사용 중지를 지원하지 않기 때문에 발생합니다.

해결 방법

문제가 해결될 때까지는 VM을 중지 및 시작하여 네트워크 연결을 복원할 수 있습니다. 다음을 수행하여 네트워크 연결 손실이 재발하지 않도록 방지할 수 있습니다. 1. /etc/default/grub 파일을 수정하고 커널 매개변수 net.ifnames=0 및 biosdevname=0을 삭제합니다. 2. grub 구성을 다시 생성합니다. 3. VM을 재부팅합니다.

공개 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 파일에 있습니다. 하지만 VM에는 여러 저장소 구성 파일 또는 자동화 도구에 설정될 수 있습니다.

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 로그인을 사용하는 인스턴스가 연결 후에 로그인 메시지를 반환함

OS 로그인을 사용하는 일부 인스턴스에서 연결이 설정된 후에 다음과 같은 오류 메시지가 표시될 수 있습니다.

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

해결 방법

이 오류 메시지를 무시하세요.

Windows VM 인스턴스의 알려진 문제

  • Community NVMe 드라이버를 사용하는 Windows의 NVMe는 베타 버전으로, Linux 인스턴스와 성능이 동일하지 않을 수 있습니다. Google Cloud 공개 이미지의 Community NVMe 드라이버가 Microsoft StorNVMe 드라이버로 대체되었습니다. 2022년 5월 이전에 생성된 VM에서 NVME 드라이버를 교체하고 대신 Microsoft StorNVMe 드라이버를 사용하는 것이 좋습니다.
  • 인스턴스를 만든 후에는 즉시 연결할 수 없습니다. 모든 새 Windows 인스턴스는 시스템 준비(sysprep) 도구를 사용하여 인스턴스를 설정하며 이 설정이 완료되는 데 5~10분 정도 걸릴 수 있습니다.
  • Windows Server 이미지는 네트워크가 kms.windows.googlecloud.com에 연결되어 있어야 활성화될 수 있으며, 30일 이내에 최초 인증하지 않으면 작동이 중지됩니다. KMS로 활성화한 소프트웨어는 180일마다 재활성화해야 하지만 KMS는 7일마다 재활성화를 시도합니다. 활성 상태로 유지되도록 Windows 인스턴스를 구성해야 합니다.
  • 커널 소프트웨어가 에뮬레이션되지 않은 MSR(모델 특정 레지스터)에 액세스하면 GPF(일반적인 보호 결함)가 발생하며 이로 인해 게스트 운영체제에 따라 시스템 장애가 발생할 수 있습니다.

Windows VM에서 w32tm을 사용하여 NTP 시간 드리프트를 측정할 때 오류 발생

Compute Engine에서 VirtIO NIC를 실행하는 Windows VM의 경우 다음 명령어를 사용하여 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

이 버그는 VirtIO NIC가 있는 Compute Engine VM에만 영향을 줍니다. gVNIC를 사용하는 VM에는 이 문제가 발생하지 않습니다.

이 문제를 방지하려면 Meinberg Time Server Monitor와 같은 다른 NTP 드리프트 측정 도구를 사용하는 것이 좋습니다.

VM을 1세대 또는 2세대에서 3세대 이상 VM으로 업데이트한 후 부팅 기기에 액세스할 수 없음

Windows Server는 첫 시작 시 부팅 드라이브를 초기 디스크 인터페이스 유형에 바인딩합니다. 기존 VM을 SCSI 디스크 인터페이스를 사용하는 이전 머신 시리즈에서 NVMe 디스크 인터페이스를 사용하는 최신 머신 시리즈로 변경하려면 VM을 종료하기 전에 Windows PnP 드라이버 sysprep을 실행합니다. 이 sysprep은 기기 드라이버만 준비하고 다음에 시작할 때 모든 디스크 인터페이스 유형이 부팅 드라이브를 위해 스캔되도록 합니다.

VM의 머신 시리즈를 업데이트하려면 다음 단계를 따르세요.

Administrator로 PowerShell 프롬프트에서 실행합니다.

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. VM을 중지합니다.
  2. VM을 새 VM 머신 유형으로 변경합니다.
  3. VM을 시작합니다.

새 VM이 올바르게 시작되지 않으면 VM을 다시 실행하려면 VM을 원래 머신 유형으로 다시 변경하세요. 성공적으로 시작됩니다. 이전 요구사항을 검토하여 요구사항을 충족하는지 확인합니다. 그런 다음 안내를 다시 시도합니다.

Windows VM의 gVNIC에서 대역폭 제한

Windows 운영체제에서 gVNIC 드라이버는 머신 유형에 대해 문서화된 대역폭 제한에 도달하지 않습니다. gVNIC 드라이버는 Windows VM에서 표준 네트워크 성능 및 VM당 Tier_1 네트워킹 성능 모두 최대 50Gbps의 네트워크 대역폭을 달성할 수 있습니다.

최신 VM 머신 시리즈의 디스크 개수 제한 연결

NVMe 디스크 인터페이스를 사용하여 Microsoft Windows에서 실행되는 VM(T2A, 모든 3세대 이상 VM, 컨피덴셜 컴퓨팅을 사용하는 VM 포함)의 디스크 연결 한도는 16개입니다. 오류를 방지하려면 영구 디스크 및 하이퍼디스크 스토리지를 VM당 최대 16개 디스크로 통합하세요. 로컬 SSD 스토리지는 이 문제에서 제외됩니다.

2022년 5월 이전에 생성된 VM에서 NVME 드라이버 교체

Microsoft Windows를 사용하는 VM에서 NVMe를 사용하려 하고 VM이 2022년 5월 1일 이전에 생성된 경우, 게스트 OS의 기존 NVMe 드라이버를 업데이트해야 Microsoft StorNVMe 드라이버를 사용할 수 있습니다.

머신 유형을 3세대 머신 시리즈로 변경하거나 3세대 머신을 사용하는 새 VM을 만드는 데 사용할 부팅 디스크 스냅샷을 만들기 전에 NVMe 드라이버를 업데이트해야 합니다.

다음 명령어를 사용하여 StorNVME 드라이버 패키지를 설치하고 게스트 OS에 커뮤니티 드라이버가 있다면 삭제합니다.

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

C3 및 C3D VM이 있는 Microsoft Windows의 로컬 SSD에서 성능 저하

Microsoft Windows를 실행하는 C3 및 C3D VM의 경우 로컬 SSD 성능이 제한됩니다.

성능 개선이 진행 중입니다.

gVNIC 사용 시 네트워킹 처리량 저하

gVNIC 드라이버 GooGet 패키지 버전 1.0.0@44 이하를 사용하는 Windows Server 2022 및 Windows 11 VM은 Google 가상 NIC(gVNIC)를 사용하는 경우 네트워킹 처리량이 저하될 수 있습니다.

이 문제를 해결하려면 다음을 수행하여 gVNIC 드라이버 GooGet 패키지를 1.0.0@45 이상 버전으로 업데이트합니다.

  1. 관리자 명령 프롬프트 또는 Powershell 세션에서 다음 명령어를 실행하여 VM에 설치된 드라이버 버전을 확인합니다.

    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 OS 이미지를 지원하지 않음

C3D 180 vCPU 머신 유형은 Windows Server 2012 및 2016 OS 이미지를 지원하지 않습니다. 180 vCPU와 Windows Server 2012 및 2016 OS 이미지로 생성된 C3D VM이 부팅되지 않습니다. 이 문제를 해결하려면 더 작은 머신 유형을 선택하거나 다른 OS 이미지를 사용하세요.

360 vCPU 및 Windows OS 이미지로 생성된 C3D VM이 부팅되지 않습니다. 이 문제를 해결하려면 더 작은 머신 유형을 선택하거나 다른 OS 이미지를 사용하세요.

M3, C3, C3D VM용 Windows Server 2016 및 2012 R2의 일반 디스크 오류

실행 중인 M3, C3 또는 C3D VM용 하이퍼디스크 또는 Persistent Disk를 추가하거나 크기를 조절하는 기능은 현재 특정 Windows 게스트에서 정상적으로 작동하지 않습니다. Windows Server 2012 R2 및 Windows Server 2016과 서버 이외의 해당 Windows 변형은 디스크 연결 및 디스크 크기 조절 명령어에 올바르게 응답하지 않습니다.

예를 들어 실행 중인 M3 VM에서 디스크를 제거하면 Windows 운영체제에서 디스크 삭제를 인식하지 않고 Windows Server 인스턴스에서 디스크를 연결 해제합니다. 이후에 디스크에 쓰면 일반 오류가 반환됩니다.

해결 방법

이러한 게스트가 디스크 수정을 인식할 수 있도록 하이퍼디스크 또는 Persistent Disk를 수정한 후 Windows에서 실행 중인 M3, C3 또는 C3D VM을 다시 시작해야 합니다.