Problemas conhecidos

Esta página descreve problemas conhecidos que você pode encontrar ao usar o Compute Engine. Para problemas que afetam especificamente VMs confidenciais, consulte Limitações de VMs confidenciais .

Questões gerais

Os problemas a seguir fornecem orientações para solução de problemas ou informações gerais.

Modificar o IOPS ou a taxa de transferência em um disco primário de replicação assíncrona usando o comando gcloud compute disks update causa um erro falso

Quando você usa o comando gcloud compute disks update para modificar o IOPS e a taxa de transferência em um disco primário de replicação assíncrona, a CLI do Google Cloud mostra uma mensagem de erro mesmo que a atualização tenha sido bem-sucedida.

Para verificar com precisão se uma atualização foi bem-sucedida, use a Google Cloud CLI ou o console do Google Cloud para ver se as propriedades do disco mostram os novos valores de IOPS e de capacidade. Para obter mais informações, consulte Visualizar as configurações de desempenho provisionadas para hiperdisco .

O servidor de metadados pode exibir metadados antigos da VM physicalHost

Depois de ocorrer um erro de host que move uma instância para um novo host, quando você consulta o servidor de metadados , ele pode exibir os metadados physicalHost do host anterior da instância.

Para solucionar esse problema, siga um destes procedimentos:

VM C3 somente IPv6 inacessível durante a migração ao vivo

Uma VM somente IPv6 que usa um tipo de máquina C3 pode ficar inacessível durante a migração em tempo real.

Solução alternativa:

Para diminuir a probabilidade de você encontrar esse problema, atualize a política de manutenção da instância e defina o comportamento de manutenção como TERMINATE e a reinicialização automática como TRUE .

Se sua VM passar por uma migração em tempo real e você enfrentar esse problema, reinicie a VM para recuperar o acesso à instância.

Valores longos baseInstanceName em grupos de instâncias gerenciadas (MIGs) podem causar conflitos de nome de disco

Em um MIG, poderão ocorrer conflitos de nome de disco se o modelo de instância especificar discos a serem criados na criação da VM e o valor baseInstanceName exceder 54 caracteres. Isso acontece porque o Compute Engine gera nomes de disco usando o nome da instância como prefixo.

Ao gerar nomes de discos, se o nome resultante exceder o limite de 63 caracteres para nomes de recursos, o Compute Engine truncará os caracteres em excesso do final do nome da instância. Esse truncamento pode levar à criação de nomes de disco idênticos para instâncias que possuem padrões de nomenclatura semelhantes. Nesse caso, a nova instância tentará anexar o disco existente. Se o disco já estiver anexado a outra instância, a criação da nova instância falhará. Se o disco não estiver conectado ou estiver no modo multigravador , a nova instância anexará o disco, podendo causar corrupção de dados.

Para evitar conflitos de nome de disco, mantenha o valor baseInstanceName com um comprimento máximo de 54 caracteres.

A criação de reservas ou solicitações de reservas futuras usando um modelo de instância que especifica um tipo de máquina A2, C3 ou G2 causa problemas

Se você usar um modelo de instância que especifique um tipo de máquina A2, C3 ou G2 para criar uma reserva ou para criar e enviar uma solicitação de reserva futura para revisão, você encontrará problemas. Especificamente:

  • A criação da reserva pode falhar. Se for bem-sucedido, uma das seguintes opções se aplica:

    • Se você criou uma reserva consumida automaticamente (padrão), a criação de VMs com propriedades correspondentes não consumirá a reserva.

    • Se você criou uma reserva específica, a criação de VMs para direcionar especificamente a reserva falhará.

  • A criação da solicitação de reserva futura foi bem-sucedida. No entanto, se você enviá-lo para revisão, Google Cloud recusa seu pedido.

Não é possível substituir o modelo de instância usado para criar uma reserva ou solicitação de reserva futura, nem substituir as propriedades da VM do modelo. Se você quiser reservar recursos para os tipos de máquina A2, C3 ou G2, siga um destes procedimentos:

Limitações ao usar os tipos de máquina c3-standard-*-lssd e c3d-standard-*-lssd com o Google Kubernetes Engine

Ao usar a API Google Kubernetes Engine, o pool de nós com SSD local anexado que você provisiona deve ter o mesmo número de discos SSD que o tipo de máquina C3 e C3D selecionado. Por exemplo, se você planeja criar uma VM que use o c3-standard-8-lssd deverá haver 2 discos SSD, enquanto que para um c3d-standard-8-lssd , será necessário apenas 1 disco SSD. Se o número do disco não corresponder, você receberá um erro de configuração incorreta do SSD local no plano de controle do Compute Engine. Consulte o documento Família de máquinas de uso geral para selecionar o número correto de discos SSD locais com base no tipo de máquina lssd C3 ou C3D.

Usar o console do Google Cloud do Google Kubernetes Engine para criar um cluster ou pool de nós com VMs c3-standard-*-lssd e c3d-standard-*-lssd resulta em falha na criação de nós ou na detecção de SSDs locais como armazenamento efêmero.

Variabilidade de taxa de transferência TCP de fluxo único em VMs C3D

VMs C3D maiores que 30 vCPUs podem apresentar variabilidade de taxa de transferência TCP de fluxo único e, ocasionalmente, ser limitadas a 20-25 Gbps. Para obter taxas mais altas, use vários fluxos TCP.

A métrica de observabilidade da utilização da CPU está incorreta para VMs que usam um thread por núcleo

Se a CPU da sua VM usar um thread por núcleo, a métrica de observabilidade de utilização da CPU do Cloud Monitoring na guia Compute Engine > Instâncias de VM > Observabilidade será dimensionada apenas para 50%. Dois threads por núcleo é o padrão para todos os tipos de máquinas, exceto Tau T2D. Para obter mais informações, consulte Definir número de threads por núcleo .

Para visualizar a utilização da CPU da sua VM normalizada para 100%, visualize a utilização da CPU no Metrics Explorer. Para obter mais informações, consulte Criar gráficos com o Metrics Explorer .

As conexões SSH no navegador do console do Google Cloud poderão falhar se você usar regras de firewall personalizadas

Se você usar regras de firewall personalizadas para controlar o acesso SSH às suas instâncias de VM, talvez não consiga usar o recurso SSH no navegador .

Para contornar esse problema, siga um destes procedimentos:

Discos resolvidos anexados a VMs com tipos de máquinas n2d-standard-64 não atingem consistentemente os limites de desempenho

O seguinte problema foi resolvido em outubro de 2023.

Os discos permanentes anexados a VMs com tipos de máquina n2d-standard-64 não atingem consistentemente o limite máximo de desempenho de 100.000 IOPS. Este é o caso de IOPS de leitura e gravação.

Nomes temporários para discos

Durante atualizações de instâncias de máquina virtual (VM) iniciadas usando o comando gcloud compute instances update ou o método de API instances.update , o Compute Engine pode alterar temporariamente o nome dos discos da sua VM adicionando os seguintes sufixos ao nome original:

  • -temp
  • -old
  • -new

O Compute Engine remove o sufixo e restaura os nomes dos discos originais conforme a atualização é concluída.

Aumento da latência para alguns discos permanentes causado pelo redimensionamento do disco

Em alguns casos, o redimensionamento de discos permanentes grandes (~3 TB ou maiores) pode prejudicar o desempenho de E/S do disco. Se você for afetado por esse problema, seus discos permanentes poderão apresentar maior latência durante a operação de redimensionamento. Esse problema pode afetar discos permanentes de qualquer tipo .

Seus processos automatizados poderão falhar se usarem dados de resposta da API sobre suas cotas de compromisso baseadas em recursos

Seus processos automatizados que consomem e usam dados de resposta da API sobre suas cotas de compromisso baseadas em recursos do Compute Engine poderão falhar se cada uma das situações a seguir acontecer. Seus processos automatizados podem incluir qualquer trecho de código, lógica de negócios ou campos de banco de dados que usam ou armazenam as respostas da API.

  1. Os dados de resposta são de qualquer um dos seguintes métodos da API Compute Engine:

  2. Você usa um int em vez de um number para definir o campo do limite de cota de recursos nos corpos de resposta da API. Você pode encontrar o campo das seguintes maneiras para cada método:

  3. Você tem cota padrão ilimitada disponível para qualquer uma das SKUs comprometidas com o Compute Engine.

    Para obter mais informações sobre cotas para compromissos e SKUs comprometidos, consulte Cotas para compromissos e recursos comprometidos .

Causa raiz

Quando você tem uma cota limitada, se você definir o campo items[].quotas[].limit ou quotas[].limit como um tipo int , os dados de resposta da API para seus limites de cota ainda poderão estar dentro do intervalo do tipo int e seu processo automatizado poderá não ser interrompido. Mas quando o limite de cota padrão é ilimitado, a API Compute Engine retorna um valor para o campo limit que está fora do intervalo definido pelo tipo int . Seu processo automatizado não pode consumir o valor retornado pelo método API e, como resultado, falha.

Como contornar esse problema

Você pode contornar esse problema e continuar gerando seus relatórios automatizados das seguintes maneiras:

  • Recomendado: siga a documentação de referência da API Compute Engine e use os tipos de dados corretos para as definições de método da API. Especificamente, use o tipo number para definir os campos items[].quotas[].limit e quotas[].limit para seus métodos de API.

  • Diminua o limite da sua cota para um valor inferior a 9.223.372.036.854.775.807. Você deve definir limites de cota para todos os projetos que tenham compromissos baseados em recursos, em todas as regiões. Você pode fazer isso de uma das seguintes maneiras:

Problemas conhecidos em instâncias de VM do Linux

Estes são os problemas conhecidos das VMs Linux.

SUSE Enterprise VM falha ao inicializar após alterar os tipos de instâncias

Depois de alterar o tipo de instância de uma VM do SUSE Linux Enterprise, ela pode falhar na inicialização com o seguinte erro repetido no console serial:

            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 raiz

O SUSE cria suas imagens de nuvem com um versátil initramfs (sistema de arquivos RAM inicial) que oferece suporte a vários tipos de instância. Isso é conseguido usando os sinalizadores --no-hostonly --no-hostonly-cmdline -o multipath durante a criação inicial da imagem. Entretanto, quando um novo kernel é instalado ou o initramfs é regenerado, o que acontece durante as atualizações do sistema, esses sinalizadores são omitidos por padrão. Isso resulta em um initramfs menor, adaptado especificamente para o hardware do sistema atual, excluindo potencialmente os drivers necessários para outros tipos de instância.

Por exemplo, as instâncias C3 usam unidades NVMe, que exigem a inclusão de módulos específicos no initramfs . Se um sistema com um initramfs sem esses módulos NVMe for migrado para uma instância C3, o processo de inicialização falhará. Esse problema também pode afetar outros tipos de instância com requisitos de hardware exclusivos.

Solução alternativa

Antes de alterar o tipo de máquina, gere novamente o initramfs com todos os drivers:

dracut --force --no-hostonly

Se o sistema já tiver sido afetado pelo problema, crie uma VM de resgate temporária . Use o comando chroot para acessar o disco de inicialização da VM afetada e, em seguida, gere novamente o initramfs usando o seguinte comando:

dracut -f --no-hostonly

Menor desempenho de IOPS para SSD local no Z3 com imagens SUSE 12

As VMs Z3 em imagens do SUSE Linux Enterprise Server (SLES) 12 têm desempenho significativamente menor do que o esperado para IOPS em discos SSD locais.

Causa raiz

Este é um problema na base de código do SLES 12.

Solução alternativa

Um patch do SUSE para corrigir esse problema não está disponível ou não está planejado. Em vez disso, você deve usar o sistema operacional SLES 15.

VMs RHEL 7 e CentOS perdem acesso à rede após reinicialização

Se suas VMs CentOS ou RHEL 7 tiverem várias placas de interface de rede (NICs) e uma dessas NICs não usar a interface VirtIO, o acesso à rede poderá ser perdido na reinicialização. Isso acontece porque o RHEL não suporta a desabilitação de nomes de interface de rede previsíveis se pelo menos uma NIC não usar a interface VirtIO.

Resolução

A conectividade de rede pode ser restaurada parando e iniciando a VM até que o problema seja resolvido. A perda de conectividade de rede pode ser evitada fazendo o seguinte: 1. Edite o arquivo /etc/default/grub e remova os parâmetros do kernel net.ifnames=0 e biosdevname=0 . 2. Gere novamente a configuração do grub. 3. Reinicie a VM.

Público Google Cloud As imagens SUSE não incluem a configuração necessária do udev para criar links simbólicos para dispositivos SSD locais C3 e C3D.

Resolução

Para adicionar regras do udev para SUSE e imagens personalizadas, consulte Links simbólicos não criados C3 e C3D com SSD local .

A assinatura repomd.xml não pôde ser verificada

Em sistemas baseados em Red Hat Enterprise Linux (RHEL) ou CentOS 7, você poderá ver o seguinte erro ao tentar instalar ou atualizar software usando yum. Este erro mostra que você tem uma chave GPG de repositório expirada ou incorreta.

Registro de amostra:

[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

Resolução

Para corrigir isso, desative a verificação da chave GPG do repositório na configuração do repositório yum definindo repo_gpgcheck=0 . Nas imagens base compatíveis do Compute Engine, essa configuração pode ser encontrada no arquivo /etc/yum.repos.d/google-cloud.repo . No entanto, sua VM pode ter isso definido em diferentes arquivos de configuração de repositório ou ferramentas de automação.

Os repositórios Yum geralmente não usam chaves GPG para validação do repositório. Em vez disso, o endpoint https é confiável.

Para localizar e atualizar essa configuração, conclua as etapas a seguir:

  1. Procure a configuração em seu arquivo /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. Altere todas as linhas que dizem repo_gpgcheck=1 para repo_gpgcheck=0 .

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

  3. Verifique se a configuração está atualizada.

    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

Instâncias que usam o Login do SO retornam uma mensagem de login após a conexão

Em algumas instâncias que usam o OS Login , você poderá receber a seguinte mensagem de erro após a conexão ser estabelecida:

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

Resolução

Ignore a mensagem de erro.

Problemas conhecidos em instâncias de VM do Windows

  • O suporte para NVMe no Windows usando o driver Community NVMe está na versão Beta , o desempenho pode não corresponder ao das instâncias do Linux. O driver Community NVMe foi substituído pelo driver Microsoft StorNVMe em Google Cloud imagens públicas. Recomendamos que substitua o controlador NVME em VMs criados antes de maio de 2022 e utilize o controlador Microsoft StorNVMe.
  • Depois de criar uma instância, você não poderá conectar-se a ela instantaneamente. Todas as novas instâncias do Windows usam a ferramenta de preparação do sistema (sysprep) para configurar sua instância, o que pode levar de 5 a 10 minutos para ser concluído.
  • As imagens do Windows Server não podem ser ativadas sem uma conexão de rede com kms.windows.googlecloud.com e param de funcionar se não forem autenticadas inicialmente em 30 dias. O software ativado pelo KMS deve ser reativado a cada 180 dias, mas o KMS tenta reativar a cada 7 dias. Certifique-se de configurar suas instâncias do Windows para que permaneçam ativadas.
  • O software do kernel que acessa registros específicos do modelo não emulado gerará falhas gerais de proteção, que podem causar uma falha no sistema dependendo do sistema operacional convidado.

Windows Server 2025 e Windows 11 24h2 – Suspender e retomar o suporte

O Windows Server 2025 e o Windows 11 24h2 não podem ser retomados quando suspensos. Até que esse problema seja resolvido, o recurso de suspensão e retomada não terá suporte para Windows Server 2025 e Windows 11 24h2.

Erros ao medir o desvio de tempo NTP usando w32tm em VMs do Windows

Para VMs do Windows no Compute Engine que executam NICs VirtIO, há um bug conhecido em que a medição do desvio de NTP produz erros ao usar o seguinte comando:

w32tm /stripchart /computer:metadata.google.internal

Os erros parecem semelhantes aos seguintes: 

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

Esse bug afeta apenas VMs do Compute Engine com NICs VirtIO. As VMs que usam gVNIC não encontram esse problema.

Para evitar esse problema, o Google recomenda o uso de outras ferramentas de medição de desvio NTP, como o Meinberg Time Server Monitor .

Dispositivo de inicialização inacessível após atualizar uma VM da geração 1 ou 2 para uma VM da geração 3+

O Windows Server vincula a unidade de inicialização ao seu tipo de interface de disco inicial na primeira inicialização. Para alterar uma VM existente de uma série de máquinas mais antiga que usa uma interface de disco SCSI para uma série de máquinas mais recente que usa uma interface de disco NVMe, execute um sysprep do driver PnP do Windows antes de desligar a VM. Este sysprep apenas prepara drivers de dispositivo e garante que todos os tipos de interface de disco sejam verificados em busca da unidade de inicialização na próxima inicialização.

Para atualizar a série de máquinas de uma VM, faça o seguinte:

Em um prompt do Powershell como Administrator , execute: 

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Pare a VM.
  2. Altere a VM para o novo tipo de máquina VM.
  3. Inicie a VM.

Se a nova VM não iniciar corretamente, altere a VM de volta para o tipo de máquina original para que sua VM volte a funcionar. Deve começar com sucesso. Revise os requisitos de migração para garantir que você os atenda. Em seguida, repita as instruções.

Largura de banda limitada com gVNIC em VMs do Windows

O driver gVNIC empacotado nas imagens do Windows oferecidas pelo Compute Engine pode atingir até 50 Gbps de largura de banda de rede em instâncias do Windows, tanto para desempenho de rede padrão quanto para desempenho de rede por VM Tier_1. Uma versão atualizada do driver gVNIC pode oferecer desempenho de taxa de linha (até 200 Gbps) e suporte para quadros Jumbo.

O driver atualizado está disponível apenas para máquinas de terceira geração e séries posteriores (excluindo N4). Para obter mais informações, consulte Atualizar a versão gVNIC no sistema operacional Windows .

Anexo de contagem de disco limitada para séries de máquinas VM mais recentes

As VMs executadas no Microsoft Windows com a interface de disco NVMe (que inclui T2A, todas as VMs de terceira geração e mais recentes e VMs que usam Computação Confidencial) têm um limite de anexos de disco de 16 discos. Para evitar erros, consolide o armazenamento em disco permanente e hiperdisco em no máximo 16 discos por VM. O armazenamento SSD local está excluído deste problema.

Substitua o driver NVME em VMs criadas antes de maio de 2022

Se quiser usar o NVMe em uma VM que usa o Microsoft Windows e a VM tiver sido criada antes de 1º de maio de 2022, você deverá atualizar o driver NVMe existente no sistema operacional convidado para usar o driver Microsoft StorNVMe .

Você deve atualizar o driver NVMe em sua VM antes de alterar o tipo de máquina para uma série de máquinas de terceira geração ou antes de criar um instantâneo do disco de inicialização que será usado para criar novas VMs que usam uma série de máquinas de terceira geração.

Use os comandos a seguir para instalar o pacote de driver StorNVME e remover o driver da comunidade, se estiver presente no sistema operacional convidado. 

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

Desempenho inferior para SSD local no Microsoft Windows com VMs C3 e C3D

O desempenho do SSD local é limitado para VMs C3 e C3D que executam o Microsoft Windows.

Melhorias de desempenho estão em andamento.

Baixa taxa de transferência de rede ao usar gVNIC

As VMs do Windows Server 2022 e do Windows 11 que usam o driver gVNIC do pacote GooGet versão 1.0.0@44 ou anterior podem apresentar baixa taxa de transferência de rede ao usar o Google Virtual NIC (gVNIC) .

Para resolver esse problema, atualize o pacote GooGet do driver gVNIC para a versão 1.0.0@45 ou posterior fazendo o seguinte:

  1. Verifique qual versão do driver está instalada em sua VM executando o seguinte comando em um prompt de comando do administrador ou sessão do Powershell: 

    googet installed

    A saída é semelhante a esta: 

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

  2. Se a versão do driver google-compute-engine-driver-gvnic.x86_64 for 1.0.0@44 ou anterior, atualize o repositório de pacotes GooGet executando o seguinte comando em um prompt de comando do administrador ou sessão Powershell: 

    googet update

Os tipos de máquinas C3D 180 e 360 ​​vCPU não suportam imagens do sistema operacional Windows

Os tipos de máquinas C3D 180 vCPU não suportam imagens de sistema operacional Windows Server 2012 e 2016. VMs C3D criadas com 180 vCPUs e imagens de sistema operacional Windows Server 2012 e 2016 falharão na inicialização. Para solucionar esse problema, selecione um tipo de máquina menor ou use outra imagem de sistema operacional.

VMs C3D criadas com vCPUs 360 e imagens do sistema operacional Windows não serão inicializadas. Para contornar esse problema, selecione um tipo de máquina menor ou use outra imagem de sistema operacional.

Erro de disco genérico no Windows Server 2016 e 2012 R2 para VMs M3, C3 e C3D

A capacidade de adicionar ou redimensionar um hiperdisco ou disco permanente para uma VM M3, C3 ou C3D em execução não funciona conforme esperado em convidados específicos do Windows no momento. O Windows Server 2012 R2 e o Windows Server 2016, e suas variantes correspondentes do Windows sem servidor, não respondem corretamente aos comandos de anexação de disco e redimensionamento de disco.

Por exemplo, remover um disco de uma VM M3 em execução desconecta o disco de uma instância do Windows Server sem que o sistema operacional Windows reconheça que o disco desapareceu. As gravações subsequentes no disco retornam um erro genérico.

Resolução

Você deve reiniciar a VM M3, C3 ou C3D em execução no Windows após modificar um hiperdisco ou disco permanente para que as modificações do disco sejam reconhecidas por esses convidados.