En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas Compute Engine. Para problemas que afectan de forma específica a Confidential VMs, consulta Limitaciones de Confidential VMs.
Problemas generales
Los siguientes problemas proporcionan orientación para solucionar problemas o información en general.
Crear reservas o solicitudes de reserva futuras con una plantilla de instancias que especifique causas de problemas de tipos de máquina como A2, C3 o G2.
Si usas una plantilla de instancias que especifica un tipo de máquina A2, C3 o G2 para crear una reserva o crear y enviar una solicitud de reserva futura para su revisión, se producirán problemas. En particular, haz lo siguiente:
La creación de la reserva puede fallar. Si se ejecuta de forma correcta, se aplicará una de las siguientes opciones:
Si creaste una reserva consumida de forma automática (predeterminada), la creación de VMs con propiedades coincidentes no consumirá la reserva.
Si creaste una reserva específica, fallará la creación de VMs para orientar la reserva de forma específica.
La creación de la solicitud de reserva futura se realiza de forma correcta. Sin embargo, si la envías para su revisión, en Google Cloud se rechazará tu solicitud.
No puedes reemplazar la plantilla de instancias que se usa para crear una solicitud de reserva o una solicitud de reserva futura, o anular las propiedades de VM de la plantilla. Si deseas reservar recursos para los tipos de máquinas A2, C3 o G2, realiza una de las siguientes acciones:
Para crear una reserva compartida o un proyecto único nuevo, especifica las propiedades directamente.
Para crear una solicitud de reserva futura nueva, haz lo siguiente:
Si deseas evitar que una solicitud de reserva futura existente restrinja las propiedades de las solicitudes de reserva futuras, puedes crear en tu proyecto actual o en los proyectos con los que se comparte la solicitud de reserva futura. —borra la solicitud de reserva futura.
Crea unproyecto único o unasolicitud de reserva futura compartida especificando las propiedades directamente y envíela para su revisión.
Limitaciones cuando se usan tipos de máquinas c3-standard-*-lssd
y c3d-standard-*-lssd
con Google Kubernetes Engine
Cuando usas la API de Google Kubernetes Engine, el grupo de nodos con la SSD local conectada que aprovisionas debe tener la misma cantidad de SSD que el tipo de máquina C3 y C3D seleccionado. Por ejemplo, si planeas crear una VM que use c3-standard-8-lssd
, debe haber 2 discos SSD, mientras que para un c3d-standard-8-lssd
, solo se requiere 1 disco SSD. Si el número de disco no coincide, recibirás un error de configuración incorrecta de SSD local del plano de control de Compute Engine. Consulta el documento Familia de máquinas de uso general para seleccionar la cantidad correcta de discos SSD locales según el tipo de máquina lssd
C3 o C3D.
Cuando usas Google Kubernetes Engine con la consola de Google Cloud para crear un clúster o grupo de nodos con VMs c3-standard-*-lssd
y c3d-standard-*-lssd
, se produce una falla en la creación del nodo o una detección de SSD locales como almacenamiento efímero.
Variabilidad de la capacidad de procesamiento de TCP de un solo flujo en las VMs de C3D
Las VMs de C3D con más de 30 CPU virtuales pueden experimentar una variedad de capacidad de procesamiento de TCP de flujo único y, en ocasiones, se limitan a 20 a 25 Gbps. Para lograr tasas más altas, usa varios flujos TCP.
El grupo de instancias administrado que tiene series de máquinas T2D no realiza el ajuste de escala automático como se espera
Los grupos de instancias administrados (MIGs) que tienen VM de series de máquinas T2D en proyectos que se crearon antes del 18 de junio de 2023 no detectan de forma correcta la carga de CPU en las VMs del MIG. En esos proyectos, el ajuste de escala automático basado en el uso de CPU en un MIG que tiene VMs de la serie de máquinas T2D puede ser incorrecto.
Para aplicar una solución a tu proyecto, comunícate con la Atención al cliente de Cloud.
La métrica de observabilidad del uso de CPU es incorrecta para las VMs que usan un subproceso por núcleo
Si la CPU de tu VM usa un subproceso por núcleo, la métrica de observabilidad de Cloud Monitoring para el uso de CPU en la pestaña Compute Engine > Instancias de VM > Observabilidad solo escala al 50%. Dos subprocesos por núcleo es la configuración predeterminada para todos los tipos de máquina, excepto Tau T2D. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.
Para ver el uso de CPU de la VM normalizado al 100%, consulta el uso de CPU en el Explorador de métricas. Para obtener más información, consulta Crea gráficos con el Explorador de métricas.
Las conexiones SSH en el navegador de la consola de Google Cloud pueden fallar si usas reglas de firewall personalizadas
Si usas reglas de firewall personalizadas para controlar el acceso SSH a tus instancias de VM, es posible que no puedas usar la función SSH en el navegador.
Para solucionar este problema, realiza una de las siguientes acciones:
Habilita Identity-Aware Proxy para TCP si quieres conectarte a las VM mediante la función SSH en el navegador de la consola de Google Cloud.
Vuelve a crear la regla de firewall
default-allow-ssh
para continuar con la conexión a las VM mediante SSH en el navegador.Conéctate a las VM mediante Google Cloud CLI en lugar de SSH en el navegador.
Reducir o borrar una reserva específica evita que las VMs consuman otras reservas
Si reduces o borras una reserva específica que consumieron una o más VMs, las VMs huérfanas no pueden consumir ninguna reserva.
De forma opcional, para evitar este problema, borra las VMs o actualiza la propiedad
reservationAffinity
de las VMs hasta que la cantidad de VMs dirigidas a la instancia específica coincida con la cantidad de VMs planificadas para la reserva específica. Después, puedes reducir el tamaño de la reserva específica o borrarla.Para solucionar este problema, haz lo siguiente:
Para que la cantidad de VMs en la reserva específica sea igual a la cantidad de VMs dirigidas a ella, haz una o más de las siguientes acciones: borra VMs, actualiza la propiedad
reservationAffinity
de VMs, aumenta el tamaño de la reserva que redujiste o vuelve a crear la reserva específica borrada.Inicia y detén cualquier VM restante.
Obtén más información para borrar reservas y cambiar el tamaño de las reservas.
Trasladar VMs o discos mediante la API de moveInstance
o la CLI de gcloud genera un comportamiento inesperado
Mover instancias de máquina virtual (VM) mediante el comando gcloud compute instances move
o el método project.moveInstance
puede causar la pérdida de datos, la eliminación de VM u otro comportamiento inesperado.
Cuando muevas VMs, te recomendamos que sigas las instrucciones de Mueve una instancia de VM entre zonas o regiones.
Los discos conectados a VMs con tipos de máquina n2d-standard-64
no alcanzan los límites de rendimiento de forma coherente
Los Persistent disks conectados a VM con tipos de máquina n2d-standard-64
no alcanzan el límite máximo de rendimiento de 100,000 IOPS de manera coherente. Este es el caso de las IOPS de lectura y escritura.
Nombres temporales para los discos
Durante las actualizaciones de la instancia de máquina virtual (VM) que se iniciaron con el comando gcloud compute instances update
o el
método de la API instances.update
, Compute Engine podría cambiar temporalmente el nombre de los discos de VM mediante la adición de los siguientes sufijos al nombre original:
-temp
-old
-new
Compute Engine quita el sufijo y restablece los nombres originales de los discos a medida que se completa la actualización.
Mayor latencia para algunos Persistent Disk debido al cambio de tamaño del disco
En algunos casos, cambiar el tamaño de los Persistent Disk grandes (~3 TB o más) puede ser perjudicial para el rendimiento de E/S del disco. Si te afecta este problema, es posible que tus Persistent Disks experimenten un aumento de la latencia durante la operación de cambio de tamaño. Este problema puede afectar a los Persistent Disks de cualquier tipo.
Capacidad para conectar discos PDs estándar y PDs extremos no compatibles a VMs C3 y M3
Los discos persistentes estándar (pd-standard
) son el tipo de disco de arranque predeterminado cuando se usa Google Cloud CLI o la API de Compute Engine. Sin embargo, los discos pd-standard
no son compatibles con las VMs C3 y M3. Además, las VMs C3 no admiten discos pd-extreme
.
Los siguientes problemas pueden ocurrir cuando usas Google Cloud CLI o la API de Compute Engine:
pd-standard
se configura como el tipo de disco de arranque predeterminado, y el disco se crea, a menos que especifiques un tipo de disco de arranque diferente y compatible, comopd-balanced
opd-ssd
.- Antes de la disponibilidad general (DG) de C3, podías conectar discos
pd-extreme
a VMs C3 y discospd-standard
a VMs C3 y M3.
Si creaste una VM C3 o M3 con un tipo de disco no compatible, mueve tus datos a un tipo de disco nuevo compatible, como se describe en Cambia el tipo de disco persistente. Si no cambias el tipo de disco, las VMs continuarán funcionando, pero algunas operaciones como la desconexión y la reconexión del disco fallarán.
Solución alternativa
Para solucionar este problema, realiza una de las siguientes acciones:
- Usa la consola de Google Cloud para crear VMs C3 o M3 y conectar discos. La consola crea VMs C3 y M3 con discos de arranque
pd-balanced
y no permite adjuntar tipos de disco no compatibles a las VMs. - Si usas Google Cloud CLI o la API de Compute Engine, configura de forma explícita un disco de arranque de tipo
pd-balanced
opd-ssd
cuando crees una VM.
Tus procesos automatizados pueden fallar si usan datos de respuesta de la API sobre tus cuotas de compromiso basadas en recursos
Los procesos automatizados que consumen y usan datos de respuesta de la API sobre tus cuotas de compromiso basadas en recursos de Compute Engine pueden fallar si ocurre cada una de las siguientes situaciones. Tus procesos automatizados pueden incluir cualquier fragmento de código, lógica empresarial o campos de base de datos que usen o almacenen las respuestas de la API.
Los datos de respuesta son de cualquiera de los siguientes métodos de la API de Compute Engine:
- Método
compute.regions.list
- Método
compute.regions.get
- Método
compute.projects.get
- Método
Usa un
int
en lugar de unnumber
para definir el campo de tu límite de cuota de recursos en los cuerpos de respuesta de tu API. Puedes encontrar el campo de las siguientes maneras para cada método:items[].quotas[].limit
para el métodocompute.regions.list
.quotas[].limit
para el métodocompute.regions.get
.quotas[].limit
para el métodocompute.projects.get
.
Tienes una cuota predeterminada ilimitada disponible para cualquiera de tus SKU comprometidos de Compute Engine.
Si deseas obtener más información sobre las cuotas de compromisos y SKU comprometidos, consulta Cuotas de compromisos y recursos comprometidos.
Causa raíz
Cuando tienes una cuota limitada, si defines el campo items[].quotas[].limit
o quotas[].limit
como un tipo int
, es posible que los datos de respuesta de la API de tus límites de cuota aún se encuentren dentro del rango para el tipo int
y puede que el proceso automatizado no se interrumpa. Sin embargo, cuando el límite de cuota predeterminado es ilimitado, la API de Compute Engine muestra un valor para el campo limit
que está fuera del rango definido por el tipo int
. Tu proceso automatizado no puede consumir el valor que muestra el método de la API y falla como resultado.
Cómo solucionar este problema
Puedes solucionar este problema y seguir generando informes automáticos de las siguientes maneras:
Recomendado: Sigue la documentación de referencia de la API de Compute Engine y usa los tipos de datos correctos para las definiciones de métodos de API. En particular, usa el tipo
number
a fin de definir los campositems[].quotas[].limit
yquotas[].limit
para los métodos de tu API.Disminuye el límite de tu cuota a un valor inferior a 9,223,372,036,854,775,807. Debes establecer límites de cuota para todos los proyectos que tengan compromisos basados en recursos en todas las regiones. Puedes hacerlo de una de las siguientes maneras:
- Sigue los mismos pasos que para realizar una solicitud de aumento de cuota y solicitar un límite de cuota más bajo.
- Configura una anulación de cuota del consumidor.
Problemas conocidos de las instancias de Bare Metal
Estos son los problemas conocidos de las instancias de Compute Engine Bare Metal.
La estadística de paquetes perdidos es incorrecta.
La cantidad de paquetes descartados que informa VIRTCHNL2_OP_GET_STATS
es un número muy grande.
La causa raíz es que IDPF informa EthStats::rx_discards
al SO como rtnl_link_stats64::rx_dropped
.
Aparece como RX dropped
cuando ejecutas ifconfig
.
Problemas conocidos de las instancias de VM de Linux
Estos son los problemas conocidos de las VMs de Linux.
Menor rendimiento de IOPS para SSD local en Z3 con imágenes de SUSE 12
Las VMs Z3 en las imágenes de SUSE Linux Enterprise Server (SLES) 12 tienen un rendimiento significativamente inferior al esperado para los IOPS en discos SSD locales.
Causa raíz
Este es un problema dentro de la base de código de SLES 12.
Solución alternativa
No hay un parche de SUSE para solucionar este problema ni se planea implementar uno. En su lugar, debes usar el sistema operativo SLES 15.
Las VMs de RHEL 7 y CentOS pierden acceso a la red después del reinicio
Si tus VMs de CentOS o RHEL 7 tienen varias tarjetas de interfaz de red (NIC) y una de estas NICs no usa la interfaz de VirtIO, es posible que se pierda el acceso a la red durante el reinicio. Esto sucede porque RHEL no admite la inhabilitación de nombres de interfaz de red predictivos si al menos una NIC no usa la interfaz VirtIO.
Solución
La conectividad de red se puede restablecer si detienes e inicias la VM hasta que se resuelva el problema. Para evitar que vuelva a ocurrir la pérdida de conectividad de red, sigue estos pasos:1. Edita el archivo /etc/default/grub
y quita los parámetros de kernel net.ifnames=0
y biosdevname=0
.
2. Vuelve a generar la configuración de grub.
3. Reinicia la VM.
symlinks faltantes para dispositivos SSD locales en VMs C3 y C3D que ejecutan SUSE Linux
Las imágenes públicas de SUSE de Google Cloud no incluyen la configuración de udev requerida para crear symlinks para dispositivos SSD locales de C3 y C3D.
Solución
Para agregar reglas de udev para SUSE y, también, imágenes personalizadas, consulta Symlinks no creados en VMs C3 y C3D con SSD locales.
No se pudo verificar la firma de repomd.xml
En los sistemas basados en Red Hat Enterprise Linux (RHEL) o CentOS 7, es posible que veas el siguiente error cuando intentes instalar o actualizar el software con yum. Este error muestra que tienes una clave GPG del repositorio vencida 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
Solución
Para corregir esto, inhabilita la verificación de claves GPG del repositorio en la configuración del repositorio de yum mediante la configuración de repo_gpgcheck=0
. En las imágenes base compatibles de Compute Engine, esta configuración se puede encontrar en el archivo /etc/yum.repos.d/google-cloud.repo
. Sin embargo, tu VM puede tener este conjunto en diferentes archivos de configuración de repositorios o herramientas de automatización.
Los repositorios de yum no suelen usar claves GPG para la validación del repositorio. En su lugar, el extremo https
es de confianza.
Para ubicar y actualizar esta configuración, completa los siguientes pasos:
Busca la configuración en el 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
Cambia todas las líneas que dicen
repo_gpgcheck=1
arepo_gpgcheck=0
.sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo
Comprueba que se haya actualizado la configuración.
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 usan el acceso de SO muestran un mensaje de acceso después de la conexión
En algunas instancias que usan el acceso de SO, es posible que recibas el siguiente mensaje de error después de establecer la conexión:
/usr/bin/id: cannot find name for group ID 123456789
Solución
Debes ignorar este mensaje de error.
Problemas conocidos de las instancias de VM que ejecutan Windows
- La compatibilidad con NVMe en Windows con el controlador NVMe de la comunidad se encuentra en versión beta, por lo que es posible que el rendimiento no coincida con el de las instancias de Linux. El controlador de NVMe de la comunidad se reemplazó por el controlador de Microsoft StorNVMe en las imágenes públicas de Google Cloud. Te recomendamos reemplazar el controlador de NVME en las VMs creadas antes de mayo de 2022 y usar el controlador de Microsoft StorNVMe.
- Después de crear una instancia, no puedes conectarte a ella de inmediato. Todas las instancias nuevas de Windows usan la herramienta de Preparación del sistema (sysprep) para configurar tu instancia, que puede tardar de 5 a 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 de forma inicial dentro de los 30 días. El software que activa el KMS debe volver a activarse cada 180 días, pero el KMS intenta volver a activarlo cada 7 días. Asegúrate de configurar tus instancias de Windows para que permanezcan activas. - El software de kernel que accede a registros específicos de modelos no emulados generará fallas de protección generales, que pueden causar una falla del sistema en función del sistema operativo invitado.
Errores cuando se mide el desvío de tiempo NTP mediante w32tm en las VMs de Windows
Para las VMs de Windows en Compute Engine que ejecutan NIC VirtIO, hay un error conocido en el que la medición del desvío NTP produce errores cuando se usa el siguiente comando:
w32tm /stripchart /computer:metadata.google.internal
Los errores son 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 VMs de Compute Engine con NIC de VirtIO. Las VMs que usan gVNIC no tienen este problema.
Para evitar este problema, Google recomienda usar otras herramientas de medición de deriva NTP, como el Meinberg Time Server Monitor.
Dispositivo de arranque inaccesible después de actualizar una VM de la generación 1 o 2 a una VM de la generación 3 o posterior
Windows Server vincula la unidad de inicio a su tipo de interfaz de disco inicial durante el primer inicio. Para cambiar una VM 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 reciente que usa una interfaz de disco NVMe, realiza un sysprep del controlador PnP de Windows antes de apagar la VM. Este sysprep solo prepara los controladores de dispositivos y garantiza que se analicen todos los tipos de interfaz de disco para la unidad de inicio en el próximo inicio.
Para actualizar la serie de máquinas de una VM, haz lo siguiente:
Desde un mensaje de PowerShell como Administrator
, ejecuta lo siguiente:
PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
- Detén la VM.
- Cambia la VM al nuevo tipo de máquina.
- Inicia la VM.
Si la VM nueva no se inicia correctamente, vuelve a cambiarla al tipo de máquina original para que vuelva a funcionar. Debería iniciarse correctamente. Revisa los requisitos de migración para asegurarte de cumplirlos. Luego, vuelve a intentar las instrucciones.
Ancho de banda limitado con gVNIC en VMs de Windows
En los sistemas operativos Windows, el controlador de gVNIC no alcanza los límites de ancho de banda documentados para el tipo de máquina. El controlador de gVNIC puede alcanzar hasta 50 Gbps de ancho de banda de red en las VMs de Windows, tanto para el rendimiento de red estándar como para el rendimiento de red Tier_1 por VM.
Conexión limitada de recuento de discos para series de máquinas de VM más recientes
Las VMs que se ejecutan en Microsoft Windows con la interfaz de disco NVMe (que incluye a T2A, todas las VMs de tercera generación y versiones posteriores, y las VMs que usan Confidential Computing) tienen un límite de conexión de discos de 16. Para evitar errores, consolida tu almacenamiento de Hyperdisk y Persistent Disk en un máximo de 16 discos por VM. El almacenamiento SSD local no se incluye en este problema.
Reemplaza el controlador de NVME en las VMs creadas antes de mayo de 2022
Si deseas usar NVMe en una VM que usa Microsoft Windows y la VM se creó antes del 1 de mayo de 2022, debes actualizar el controlador de NVMe existente en el SO invitado para usar el Controlador de Microsoft StorNVMe.
Debes actualizar el controlador de NVMe en la VM 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 VMs nuevas que usen una máquina de tercera generación.
Usa los siguientes comandos para instalar el paquete del controlador StorNVME y quitar el controlador de la comunidad, si está presente en el SO invitado.
googet update
googet install google-compute-engine-driver-nvme
Menor rendimiento para SSD local en Microsoft Windows con VMs de C3 y C3D
En la actualidad, el rendimiento de los SSD locales es limitado para las VMs C3 y C3D que ejecutan Microsoft Windows.
Se están realizando mejoras en el rendimiento.
Capacidad de procesamiento de herramientas de redes deficiente cuando se usa gVNIC
Las VMs de Windows Server 2022 y Windows 11 que usan el controlador de gVNIC de GooGet, versión 1.0.0@44
, o versiones anteriores, podrían experimentar una capacidad de procesamiento de red deficiente cuando se usa la NIC virtual de Google (gVNIC).
Para resolver este problema, actualiza el paquete GooGet del controlador de gVNIC a la versión 1.0.0@45
o posterior de la siguiente manera:
Para verificar qué versión del controlador está instalada en tu VM, ejecuta 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 ...
Si la versión del controlador
google-compute-engine-driver-gvnic.x86_64
es1.0.0@44
o anterior, actualiza el repositorio de paquetes GooGet mediante la ejecución del siguiente comando desde un símbolo del sistema del administrador o una sesión de PowerShell:googet update
Los tipos de máquinas de CPU virtuales C3D 180 y 360 no son compatibles con las imágenes de SO de Windows
Los tipos de máquinas de CPU virtuales C3D de 180 no son compatibles con las imágenes de SO de Windows Server 2012 y 2016. Las VM de C3D creadas con 180 CPU virtuales y las imágenes de SO de Windows Server 2012 y 2016 no se iniciarán. Para solucionar este problema, selecciona un tipo de máquina más pequeño o usa otra imagen de SO.
Las VMs de C3D creadas con 360 CPUs virtuales y las imágenes de SO de Windows no se iniciarán. Para solucionar este problema, selecciona un tipo de máquina más pequeño o usa otra imagen de SO.
Error de disco genérico en Windows Server 2016 y 2012 R2 para VMs M3, C3 y C3D
En este momento, la capacidad de agregar o cambiar el tamaño de un Hyperdisk o un Persistent Disk para una VM M3, C3 o C3D en ejecución no funciona como se espera en invitados específicos de Windows. Windows Server 2012 R2 y Windows Server 2016, así como sus variantes correspondientes de Windows sin servidores, no responden de forma correcta a los comandos de conexión o cambio de tamaño de discos.
Por ejemplo, si se quita un disco de una VM 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 muestran un error genérico.
Solución
Debes reiniciar la VM M3, C3 o C3D que se ejecuta en Windows después de modificar un Hyperdisk o un Persistent Disk para que los invitados reconozcan las modificaciones del disco.