Problemas conocidos

Esta página describe problemas conocidos que puedes encontrar al usar Compute Engine. Para problemas que afectan específicamente a las máquinas virtuales confidenciales, consulte Limitaciones de las máquinas virtuales confidenciales .

Cuestiones generales

Los siguientes problemas proporcionan orientación para la solución de problemas o información general.

Modificar el IOPS o el rendimiento en un disco primario de replicación asincrónica mediante el comando gcloud compute disks update genera un error falso

Cuando usas el comando gcloud compute disks update para modificar el IOPS y el rendimiento en un disco principal de replicación asincrónica, la CLI de Google Cloud muestra un mensaje de error incluso si la actualización se realizó correctamente.

Para verificar con precisión que una actualización se realizó correctamente, use la CLI de Google Cloud o la consola de Google Cloud para ver si las propiedades del disco muestran los nuevos valores de IOPS y rendimiento. Para obtener más información, consulte Ver la configuración de rendimiento aprovisionada para Hyperdisk .

El servidor de metadatos puede mostrar metadatos antiguos de la máquina virtual physicalHost

Después de experimentar un error de host que mueve una instancia a un nuevo host, cuando consulta el servidor de metadatos , es posible que se muestren los metadatos del host physicalHost del host anterior de la instancia.

Para solucionar este problema, realice una de las siguientes acciones:

VM C3 solo IPv6 inalcanzable durante la migración en vivo

Es posible que no se pueda acceder a una máquina virtual solo IPv6 que utilice un tipo de máquina C3 durante la migración en vivo.

Solución alternativa:

Para que sea menos probable que encuentre este problema, puede actualizar la política de mantenimiento de la instancia y establecer el comportamiento de mantenimiento en TERMINATE y el reinicio automático en TRUE .

Si su VM se somete a una migración en vivo y experimenta este problema, reinicie la VM para recuperar el acceso a la instancia.

Los valores largos baseInstanceName en grupos de instancias administrados (MIG) pueden causar conflictos en el nombre del disco

En un MIG, pueden ocurrir conflictos de nombre de disco si la plantilla de instancia especifica los discos que se crearán al crear la VM y el valor baseInstanceName supera los 54 caracteres. Esto sucede porque Compute Engine genera nombres de discos usando el nombre de la instancia como prefijo.

Al generar nombres de disco, si el nombre resultante excede el límite de 63 caracteres del nombre del recurso, Compute Engine trunca los caracteres sobrantes desde el final del nombre de la instancia. Este truncamiento puede llevar a la creación de nombres de disco idénticos para instancias que tienen patrones de nombres similares. En tal caso, la nueva instancia intentará adjuntar el disco existente. Si el disco ya está conectado a otra instancia, la creación de la nueva instancia falla. Si el disco no está conectado o está en modo de escritura múltiple , la nueva instancia conectará el disco, lo que podría provocar daños en los datos.

Para evitar conflictos de nombres de disco, mantenga el valor baseInstanceName en una longitud máxima de 54 caracteres.

La creación de reservas o solicitudes de reserva futuras utilizando una plantilla de instancia que especifica un tipo de máquina A2, C3 o G2 causa problemas

Si utiliza una plantilla de instancia que especifica un tipo de máquina A2, C3 o G2 para crear una reserva, o para crear y enviar una solicitud de reserva futura para su revisión, encontrará problemas. Específicamente:

  • Es posible que no se pueda crear la reserva. Si tiene éxito, entonces se aplica uno de los siguientes:

    • Si creó una reserva consumida automáticamente (predeterminada), la creación de máquinas virtuales con propiedades coincidentes no consumirá la reserva.

    • Si creó una reserva específica, falla la creación de máquinas virtuales para apuntar específicamente a la reserva.

  • La creación de la futura solicitud de reserva se realizó correctamente. Sin embargo, si lo envía para su revisión, Google Cloud rechaza su solicitud.

No puede reemplazar la plantilla de instancia utilizada para crear una reserva o una solicitud de reserva futura, ni anular las propiedades de la VM de la plantilla. Si desea reservar recursos para los tipos de máquinas A2, C3 o G2, realice una de las siguientes acciones:

Limitaciones al utilizar los tipos de máquinas c3-standard-*-lssd y c3d-standard-*-lssd con Google Kubernetes Engine

Al utilizar la API de Google Kubernetes Engine, el grupo de nodos con SSD local adjunto que aprovisione debe tener la misma cantidad de discos SSD que el tipo de máquina C3 y C3D seleccionado. Por ejemplo, si planea crear una máquina virtual que use c3-standard-8-lssd debe haber 2 discos SSD, mientras que para c3d-standard-8-lssd , solo se requiere 1 disco SSD. Si el número de disco no coincide, recibirá un error de configuración incorrecta del SSD local desde el plano de control de Compute Engine. Consulte el documento sobre la familia de máquinas de uso general para seleccionar la cantidad correcta de discos SSD locales según el tipo de máquina C3 o C3D lssd .

El uso de la consola de Google Cloud de Google Kubernetes Engine para crear un clúster o grupo de nodos con máquinas virtuales c3-standard-*-lssd y c3d-standard-*-lssd produce un error en la creación de nodos o una falla al detectar los SSD locales como almacenamiento efímero.

Variabilidad del rendimiento de TCP de flujo único en máquinas virtuales C3D

Las máquinas virtuales C3D de más de 30 vCPU pueden experimentar variabilidad en el rendimiento de TCP de flujo único y, en ocasiones, estar limitadas a 20-25 Gbps. Para lograr tasas más altas, utilice múltiples flujos TCP.

La métrica de observabilidad de la utilización de la CPU es incorrecta para las máquinas virtuales que utilizan un subproceso por núcleo

Si la CPU de su VM usa un subproceso por núcleo, la métrica de observabilidad de Cloud Monitoring de la utilización de la CPU en la pestaña Compute Engine > Instancias de VM > Observabilidad solo aumenta al 50 %. Dos subprocesos por núcleo es el valor predeterminado para todos los tipos de máquinas, excepto Tau T2D. Para obtener más información, consulte Establecer el número de subprocesos por núcleo .

Para ver la utilización de CPU de su VM normalizada al 100 %, consulte la utilización de CPU en Metrics Explorer. Para obtener más información, consulte Crear gráficos con Metrics Explorer .

Las conexiones SSH en el navegador de la consola de Google Cloud pueden fallar si usa reglas de firewall personalizadas

Si utiliza reglas de firewall personalizadas para controlar el acceso SSH a sus instancias de VM, es posible que no pueda utilizar la función SSH en el navegador .

Para solucionar este problema, realice una de las siguientes acciones:

Los discos resueltos conectados a máquinas virtuales con tipos de máquinas n2d-standard-64 no alcanzan constantemente los límites de rendimiento

El siguiente problema se resolvió en octubre de 2023.

Los discos persistentes conectados a máquinas virtuales con tipos de máquinas n2d-standard-64 no alcanzan constantemente el límite máximo de rendimiento de 100 000 IOPS. Este es el caso tanto para IOPS de lectura como de escritura.

Nombres temporales para discos

Durante las actualizaciones de instancias de máquinas virtuales (VM) iniciadas con el comando gcloud compute instances update o el método API instances.update , Compute Engine puede cambiar temporalmente el nombre de los discos de tu VM agregando los siguientes sufijos al nombre original:

  • -temp
  • -old
  • -new

Compute Engine elimina el sufijo y restaura los nombres de los discos originales a medida que se completa la actualización.

Aumento de la latencia para algunos discos persistentes causado por el cambio de tamaño del disco

En algunos casos, cambiar el tamaño de discos persistentes grandes (~3 TB o más) puede afectar el rendimiento de E/S del disco. Si este problema lo afecta, sus discos persistentes podrían experimentar una mayor latencia durante la operación de cambio de tamaño. Este problema puede afectar a los discos persistentes de cualquier tipo .

Sus procesos automatizados pueden fallar si utilizan datos de respuesta de API sobre sus cuotas de compromiso basadas en recursos

Tus procesos automatizados que consumen y usan datos de respuesta de API sobre tus cuotas de compromiso basadas en recursos de Compute Engine podrían fallar si sucede cada una de las siguientes cosas. Sus procesos automatizados pueden incluir fragmentos de código, lógica empresarial o campos de base de datos que utilicen o almacenen las respuestas de la API.

  1. Los datos de respuesta provienen de cualquiera de los siguientes métodos de API de Compute Engine:

  2. Utilice un int en lugar de un number para definir el campo para su límite de cuota de recursos en los cuerpos de respuesta de su API. Puede encontrar el campo de las siguientes maneras para cada método:

  3. Tienes una cuota predeterminada ilimitada disponible para cualquiera de tus SKU comprometidos de Compute Engine.

    Para obtener más información sobre cuotas para compromisos y SKU comprometidas, consulte Cuotas para compromisos y recursos comprometidos .

Causa principal

Cuando tiene una cuota limitada, si define el campo items[].quotas[].limit o quotas[].limit como un tipo int , los datos de respuesta de API para sus límites de cuota aún podrían estar dentro del rango para el tipo int y su proceso automatizado podría no verse interrumpido. Pero cuando el límite de cuota predeterminado es ilimitado, la API de Compute Engine devuelve un valor para el campo limit que queda fuera del rango definido por el tipo int . Su proceso automatizado no puede consumir el valor devuelto por el método API y, como resultado, falla.

Cómo solucionar este problema

Puede solucionar este problema y continuar generando sus informes automatizados de las siguientes maneras:

  • Recomendado: siga la documentación de referencia de la API de Compute Engine y utilice los tipos de datos correctos para las definiciones de los métodos de la API. Específicamente, use el tipo number para definir los campos items[].quotas[].limit y quotas[].limit para sus métodos API.

  • Disminuya su límite de cuota a un valor inferior a 9.223.372.036.854.775.807. Debe establecer límites de cuota para todos los proyectos que tengan compromisos basados ​​en recursos, en todas las regiones. Puedes hacer esto de una de las siguientes maneras:

Problemas conocidos para instancias de VM de Linux

Estos son los problemas conocidos de las máquinas virtuales Linux.

SUSE Enterprise VM no arranca después de cambiar los tipos de instancias

Después de cambiar el tipo de instancia de una máquina virtual SUSE Linux Enterprise, es posible que no se inicie y se repita el siguiente error en la consola serie:

            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"

Causa principal

SUSE crea sus imágenes en la nube con un initramfs (sistema de archivos RAM inicial) versátil que admite varios tipos de instancias. Esto se logra utilizando los indicadores de ruta --no-hostonly --no-hostonly-cmdline -o multipath durante la creación inicial de la imagen. Sin embargo, cuando se instala un nuevo kernel o se regenera initramfs , lo que ocurre durante las actualizaciones del sistema, estos indicadores se omiten de forma predeterminada. Esto da como resultado un initramfs más pequeño diseñado específicamente para el hardware del sistema actual, excluyendo potencialmente los controladores necesarios para otros tipos de instancias.

Por ejemplo, las instancias C3 utilizan unidades NVMe, que requieren que se incluyan módulos específicos en initramfs . Si un sistema con un initramfs que carece de estos módulos NVMe se migra a una instancia C3, el proceso de arranque falla. Este problema también puede afectar a otros tipos de instancias con requisitos de hardware únicos.

Solución alternativa

Antes de cambiar el tipo de máquina, regenere initramfs con todos los controladores:

dracut --force --no-hostonly

Si el sistema ya se ve afectado por el problema, cree una máquina virtual de rescate temporal . Utilice el comando chroot para acceder al disco de arranque de la VM afectada y luego regenere initramfs utilizando el siguiente comando:

dracut -f --no-hostonly

Menor rendimiento de IOPS para SSD local en Z3 con imágenes SUSE 12

Las máquinas virtuales Z3 en imágenes SUSE Linux Enterprise Server (SLES) 12 tienen un rendimiento significativamente menor al esperado para IOPS en discos SSD locales.

Causa principal

Este es un problema dentro del código base de SLES 12.

Solución alternativa

No hay disponible ni está planificado un parche de SUSE para solucionar este problema. En su lugar, deberías utilizar el sistema operativo SLES 15.

Las máquinas virtuales RHEL 7 y CentOS pierden el acceso a la red después del reinicio

Si sus máquinas virtuales CentOS o RHEL 7 tienen varias tarjetas de interfaz de red (NIC) y una de estas NIC no utiliza la interfaz VirtIO, es posible que se pierda el acceso a la red al reiniciar. Esto sucede porque RHEL no admite la desactivación de nombres de interfaces de red predecibles si al menos una NIC no usa la interfaz VirtIO.

Resolución

La conectividad de la red se puede restaurar deteniendo e iniciando la VM hasta que se resuelva el problema. Se puede evitar que vuelva a ocurrir la pérdida de conectividad de red haciendo lo siguiente: 1. Edite el archivo /etc/default/grub y elimine los parámetros del kernel net.ifnames=0 y biosdevname=0 . 2. Regenere la configuración de grub. 3. Reinicie la máquina virtual.

Público Google Cloud Las imágenes de SUSE no incluyen la configuración udev requerida para crear enlaces simbólicos para dispositivos SSD locales C3 y C3D.

Resolución

Para agregar reglas udev para SUSE e imágenes personalizadas, consulte Enlaces simbólicos no creados C3 y C3D con SSD local .

No se pudo verificar la firma repomd.xml

En sistemas basados ​​en Red Hat Enterprise Linux (RHEL) o CentOS 7, es posible que vea el siguiente error al intentar instalar o actualizar software mediante yum. Este error muestra que tiene una clave GPG de repositorio caducada o incorrecta.

Registro de muestra:

[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

Resolución

Para solucionar este problema, deshabilite la verificación de la clave GPG del repositorio en la configuración del repositorio de yum configurando repo_gpgcheck=0 . En las imágenes base de Compute Engine compatibles, esta configuración se puede encontrar en el archivo /etc/yum.repos.d/google-cloud.repo . Sin embargo, su VM puede tener esto configurado en diferentes archivos de configuración del repositorio o herramientas de automatización.

Los repositorios de Yum no suelen utilizar claves GPG para la validación del repositorio. En cambio, se confía en el punto final https .

Para localizar y actualizar esta configuración, complete los siguientes pasos:

  1. Busque la configuración en su archivo /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. Cambie todas las líneas que dicen repo_gpgcheck=1 a repo_gpgcheck=0 .

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

  3. Compruebe que la configuración esté actualizada.

    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

Las instancias que utilizan el inicio de sesión del sistema operativo devuelven un mensaje de inicio de sesión después de la conexión

En algunas instancias que usan OS Login , es posible que reciba el siguiente mensaje de error después de establecer la conexión:

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

Resolución

Ignore el mensaje de error.

Problemas conocidos para instancias de VM de Windows

  • La compatibilidad con NVMe en Windows mediante el controlador Community NVMe está en versión Beta ; es posible que el rendimiento no coincida con el de las instancias de Linux. El controlador Community NVMe ha sido reemplazado por el controlador Microsoft StorNVMe en Google Cloud imágenes públicas. Le recomendamos que reemplace el controlador NVME en las máquinas virtuales creadas antes de mayo de 2022 y utilice el controlador Microsoft StorNVMe en su lugar.
  • Después de crear una instancia, no podrá conectarse a ella instantáneamente. Todas las instancias nuevas de Windows utilizan la herramienta de preparación del sistema (sysprep) para configurar su instancia, lo que puede tardar entre 5 y 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 inicialmente dentro de los 30 días. El software activado por el KMS debe reactivarse cada 180 días, pero el KMS intenta reactivarse cada 7 días. Asegúrese de configurar sus instancias de Windows para que permanezcan activadas.
  • El software del kernel que accede a registros específicos de modelos no emulados generará fallas de protección generales, lo que puede provocar una falla del sistema según el sistema operativo invitado.

Windows Server 2025 y Windows 11 24h2: suspender y reanudar el soporte

Windows Server 2025 y Windows 11 24h2 no pueden reanudarse cuando están suspendidos. Hasta que se resuelva este problema, la función suspender y reanudar no será compatible con Windows Server 2025 y Windows 11 24h2.

Errores al medir la deriva del tiempo NTP usando w32tm en máquinas virtuales Windows

Para las máquinas virtuales de Windows en Compute Engine que ejecutan NIC VirtIO, existe un error conocido por el cual medir la deriva de NTP produce errores al usar el siguiente comando:

w32tm /stripchart /computer:metadata.google.internal

Los errores parecen similares a los siguientes: 

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

Este error solo afecta a las máquinas virtuales de Compute Engine con NIC VirtIO. Las máquinas virtuales que usan gVNIC no encuentran este problema.

Para evitar este problema, Google recomienda utilizar otras herramientas de medición de deriva NTP, como Meinberg Time Server Monitor .

Dispositivo de arranque inaccesible después de actualizar una VM de Gen 1 o 2 a una VM Gen 3+

Windows Server vincula la unidad de arranque a su tipo de interfaz de disco inicial durante el primer inicio. Para cambiar una máquina virtual existente de una serie de máquinas más antigua que usa una interfaz de disco SCSI a una serie de máquinas más nueva que usa una interfaz de disco NVMe, realice una preparación del sistema del controlador PnP de Windows antes de apagar la máquina virtual. Este sysprep solo prepara los controladores de dispositivos y garantiza que todos los tipos de interfaz de disco se analicen en busca de la unidad de arranque en el siguiente inicio.

Para actualizar la serie de máquinas de una VM, haga lo siguiente:

Desde un mensaje de Powershell como Administrator , ejecute: 

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Detenga la máquina virtual.
  2. Cambie la VM al nuevo tipo de máquina VM.
  3. Inicie la máquina virtual.

Si la nueva máquina virtual no se inicia correctamente, vuelva a cambiarla al tipo de máquina original para que vuelva a funcionar. Debería comenzar con éxito. Revise los requisitos de migración para asegurarse de cumplirlos. Luego vuelva a intentar las instrucciones.

Ancho de banda limitado con gVNIC en máquinas virtuales Windows

El controlador gVNIC empaquetado en las imágenes de Windows ofrecidas por Compute Engine puede alcanzar hasta 50 Gbps de ancho de banda de red en instancias de Windows, tanto para el rendimiento de red estándar como para el rendimiento de red por VM Tier_1. Una versión actualizada del controlador gVNIC puede ofrecer rendimiento de velocidad de línea (hasta 200 Gbps) y compatibilidad con tramas Jumbo.

El controlador actualizado solo está disponible para series de máquinas de tercera generación y posteriores (excluyendo N4). Para obtener más información, consulte Actualizar la versión de gVNIC en el sistema operativo Windows .

Accesorio de recuento de discos limitado para series de máquinas VM más nuevas

Las máquinas virtuales que se ejecutan en Microsoft Windows con la interfaz de disco NVMe (que incluye T2A, todas las máquinas virtuales de tercera generación y más recientes, y las máquinas virtuales que utilizan Confidential Computing) tienen un límite de conexión de disco de 16 discos. Para evitar errores, consolide su almacenamiento de disco persistente e hiperdisco en un máximo de 16 discos por máquina virtual. El almacenamiento SSD local está excluido de este problema.

Reemplace el controlador NVME en máquinas virtuales creadas antes de mayo de 2022

Si desea usar NVMe en una máquina virtual que usa Microsoft Windows y la máquina virtual se creó antes del 1 de mayo de 2022, debe actualizar el controlador NVMe existente en el sistema operativo invitado para usar el controlador Microsoft StorNVMe .

Debe actualizar el controlador NVMe en su máquina virtual antes de cambiar el tipo de máquina a una serie de máquinas de tercera generación, o antes de crear una instantánea del disco de arranque que se usará para crear nuevas máquinas virtuales que utilicen una serie de máquinas de tercera generación.

Utilice los siguientes comandos para instalar el paquete del controlador StorNVME y eliminar el controlador comunitario, si está presente en el sistema operativo invitado. 

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

Menor rendimiento para SSD local en Microsoft Windows con máquinas virtuales C3 y C3D

El rendimiento del SSD local está limitado para las máquinas virtuales C3 y C3D que ejecutan Microsoft Windows.

Se están realizando mejoras de rendimiento.

Rendimiento de red deficiente al utilizar gVNIC

Las máquinas virtuales Windows Server 2022 y Windows 11 que utilizan el paquete GooGet del controlador gVNIC versión 1.0.0@44 o anterior pueden experimentar un rendimiento de red deficiente al utilizar la NIC virtual de Google (gVNIC) .

Para resolver este problema, actualice el paquete GooGet del controlador gVNIC a la versión 1.0.0@45 o posterior haciendo lo siguiente:

  1. Verifique qué versión del controlador está instalada en su VM ejecutando el siguiente comando desde un símbolo del sistema del administrador o una sesión de Powershell: 

    googet installed

    El resultado es similar al siguiente: 

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

  2. Si la versión del controlador google-compute-engine-driver-gvnic.x86_64 es 1.0.0@44 o anterior, actualice el repositorio de paquetes GooGet ejecutando el siguiente comando desde un símbolo del sistema de administrador o una sesión de Powershell: 

    googet update

Los tipos de máquinas C3D 180 y 360 vCPU no admiten imágenes del sistema operativo Windows

Los tipos de máquinas C3D 180 vCPU no admiten imágenes de sistema operativo Windows Server 2012 y 2016. Las máquinas virtuales C3D creadas con 180 vCPU e imágenes de sistema operativo Windows Server 2012 y 2016 no podrán iniciarse. Para solucionar este problema, seleccione un tipo de máquina más pequeña o utilice otra imagen del sistema operativo.

Las máquinas virtuales C3D creadas con 360 vCPU e imágenes del sistema operativo Windows no podrán iniciarse. Para solucionar este problema, seleccione un tipo de máquina más pequeña o utilice otra imagen del sistema operativo.

Error de disco genérico en Windows Server 2016 y 2012 R2 para máquinas virtuales M3, C3 y C3D

La capacidad de agregar o cambiar el tamaño de un hiperdisco o un disco persistente para una máquina virtual M3, C3 o C3D en ejecución no funciona como se esperaba en invitados Windows específicos en este momento. Windows Server 2012 R2 y Windows Server 2016, y sus correspondientes variantes de Windows que no son de servidor, no responden correctamente a los comandos de conexión de disco y cambio de tamaño del disco.

Por ejemplo, al quitar un disco de una máquina virtual M3 en ejecución, se desconecta el disco de una instancia de Windows Server sin que el sistema operativo Windows reconozca que el disco ya no está. Las escrituras posteriores en el disco devuelven un error genérico.

Resolución

Debe reiniciar la máquina virtual M3, C3 o C3D que se ejecuta en Windows después de modificar un hiperdisco o un disco persistente para que estos invitados reconozcan las modificaciones del disco.