Gerenciar máquinas virtuais

Nesta página, descrevemos como gerenciar máquinas virtuais no Google Distributed Cloud executando o ambiente de execução de VMs no Google Distributed Cloud. É necessário conhecer o ambiente de execução de VM no GDC antes de concluir as etapas nesta página. Para uma lista de sistemas operacionais convidados compatíveis, consulte Sistemas operacionais convidados verificados para o ambiente de execução de VMs no GDC.

Para saber como as máquinas virtuais funcionam como um componente essencial da plataforma Distributed Cloud, consulte Extensão do GKE Enterprise para gerenciar VMs de edge locais.

Os clusters de plano de controle local são compatíveis com webhooks de máquina virtual. Isso permite que o Distributed Cloud valide as solicitações de usuários feitas ao servidor da API Kubernetes local. As solicitações rejeitadas geram informações detalhadas sobre o motivo da rejeição.

Ativar o suporte do ambiente de execução de VMs no GDC no Distributed Cloud

Por padrão, o suporte a máquina virtual do ambiente de execução de VMs no GDC está desativado no Distributed Cloud. Para ativar, siga as etapas nesta seção. As instruções nesta seção pressupõem que você tenha um cluster do Distributed Cloud totalmente funcional.

O recurso VMRuntime que configura o suporte do ambiente de execução de VMs no GDC no Distributed Cloud também configura o suporte a GPU no cluster usando o parâmetro enableGPU. Configure os dois parâmetros de acordo com as necessidades da sua carga de trabalho. Não é necessário ativar o suporte a GPUs para ativar o suporte do ambiente de execução de VMs no GDC no cluster do Distributed Cloud.

A tabela a seguir descreve as configurações disponíveis:

Valor de enable Valor de enableGPU Configuração resultante
false false As cargas de trabalho são executadas apenas em contêineres e não podem usar recursos de GPU.
false true As cargas de trabalho são executadas apenas em contêineres e podem usar recursos de GPU.
true true As cargas de trabalho podem ser executadas em máquinas virtuais e em contêineres.
Os dois tipos de cargas de trabalho podem usar recursos de GPU.
true false As cargas de trabalho podem ser executadas em máquinas virtuais e em contêineres.
Nenhum tipo de carga de trabalho pode usar recursos de GPU.

Se você já tiver ativado o suporte a GPU, modifique o recurso VMRuntime para adicionar o parâmetro enable, defina o valor como true e aplique ao cluster do Distributed Cloud.

Ativar o ambiente de execução de VM no subsistema de máquina virtual do GDC

Dependendo do tipo de cluster em que você quer ativar o VM Runtime no subsistema de máquina virtual do GDC, faça o seguinte:

  • Para clusters do plano de controle do Cloud, é necessário criar manualmente o recurso VMRuntime.
  • Para clusters de plano de controle local, edite o recurso VMRuntime atual.

Para ativar o ambiente de execução de VMs no subsistema de máquina virtual do GDC, siga estas etapas:

  1. Dependendo do tipo de cluster de destino, crie ou modifique o recurso personalizado VMRuntime com o seguinte conteúdo e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  # Enable Anthos VM Runtime support
  enabled: true
  # vmImageFormat defaults to "raw" if not set
  vmImageFormat: "raw"

    Não mude o valor do parâmetro vmImageFormat. O Distributed Cloud não é compatível com nenhum outro formato de disco virtual.

    Esse processo geralmente leva alguns minutos para ser concluído.

  2. Use o seguinte comando para verificar se o recurso personalizado VMRuntime foi aplicado ao cluster:

    kubectl get vmruntime -o yaml

    O comando retorna uma saída semelhante a este exemplo:

     - apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
     ...
   spec:
     enabled: true
     vmImageFormat: raw
   status:
     ...
   ready: true
     ...

  3. Use o comando a seguir para verificar se o suporte a máquina virtual do ambiente de execução de VM no GDC foi ativado no cluster:

    kubectl get pods -n vm-system

    O comando retorna uma saída mostrando os pods do subsistema do VM Runtime no GDC em execução no cluster, semelhante ao exemplo a seguir:

    NAME                                                READY   STATUS         RESTARTS        AGE
cdi-apiserver-6c76c6cf7b-n68wn                      1/1     Running        0               132m
cdi-deployment-f78fd599-vj7tv                       1/1     Running        0               132m
cdi-operator-65c4df9647-fcb9d                       1/1     Running        0               134m
cdi-uploadproxy-7765ffb694-6j7bf                    1/1     Running        0               132m
macvtap-fjfjr                                       1/1     Running        0               134m
virt-api-77dd99dbbb-bs2fb                           1/1     Running        0               132m
virt-api-77dd99dbbb-pqc27                           1/1     Running        0               132m
virt-controller-5b44dbbbd7-hc222                    1/1     Running        0               132m
virt-controller-5b44dbbbd7-p8xkk                    1/1     Running        0               132m
virt-handler-n76fs                                  1/1     Running        0               132m
virt-operator-86565697d9-fpxqh                      2/2     Running        0               134m
virt-operator-86565697d9-jnbt7                      2/2     Running        0               134m
vm-controller-controller-manager-7844d5fb7b-72d8m   2/2     Running        0               134m
vmruntime-controller-manager-845649c847-m78r9       2/2     Running        0               175m

Conceder ao namespace de destino acesso ao registro do Distributed Cloud

As etapas desta seção se aplicam apenas aos clusters do plano de controle do Cloud. Se você estiver configurando o ambiente de execução da VM no subsistema de máquina virtual do GDC em um cluster de plano de controle local, pule esta seção.

Antes de criar uma máquina virtual em um namespace, é necessário conceder a esse namespace acesso ao registro do Distributed Cloud. O registro contém os componentes necessários para criar e implantar suas máquinas virtuais no namespace de destino. Não é possível executar máquinas virtuais em namespaces reservados para gerenciamento do sistema do Distributed Cloud. Para mais informações, consulte Restrições de namespace de gerenciamento.

Conclua as etapas a seguir para conceder ao namespace de destino acesso ao registro do Distributed Cloud:

  1. Adicione um patch à conta de serviço padrão no namespace de destino com a chave imagePullSecret chamada gcr-pull:

    kubectl patch sa default -p "{\"imagePullSecrets\": [{\"name\": \"gcr-pull\"}]}" -n NAMESPACE

    Substitua NAMESPACE pelo nome do namespace de destino.

  2. Atualize o secret associado no namespace de destino:

    # Delete existing secret.
kubectl delete secret gcr-pull -n NAMESPACE --ignore-not-found
# Copy the new secret to the target namespace.
kubectl get secret gcr-pull -n vm-system -o yaml | sed "s/namespace: vm-system/namespace: NAMESPACE/g" | kubectl apply -f -

    Substitua NAMESPACE pelo nome do namespace de destino.

    O secret expira após uma hora. É necessário atualizar manualmente depois que ele expirar.

Instalar a ferramenta de gerenciamento virtctl

Você precisa da ferramenta de cliente virtctl para gerenciar máquinas virtuais no cluster do Distributed Cloud. Para instalar a ferramenta, siga estas etapas:

  1. Instalar a ferramenta do cliente virtctl como um plug-in kubectl

    export VERSION=v0.49.0-anthos1.12-gke.7
gcloud storage cp gs://anthos-baremetal-release/virtctl/${VERSION}/linux-amd64/virtctl /usr/local/bin/virtctl
cd /usr/local/bin
sudo ln -s virtctl kubectl-virt
sudo chmod a+x virtctl
cd -

  2. Verifique se o plug-in virt está instalado:

    kubectl plugin list

    Se o plug-in tiver sido instalado, a saída do comando vai listar kubectl-virt como um dos plug-ins.

Provisionar uma máquina virtual no Distributed Cloud com armazenamento em blocos brutos

Esta seção fornece exemplos de configuração que ilustram como provisionar uma máquina virtual Linux e uma máquina virtual Windows em um cluster do Distributed Cloud com armazenamento de blocos brutos. Os exemplos usam armazenamento em blocos instanciado como um PersistentVolume.

Limitações do uso do armazenamento em blocos brutos

As limitações a seguir se aplicam ao executar máquinas virtuais com armazenamento em blocos brutos no Distributed Cloud:

  • O campo OSType não é compatível com especificações de recursos VirtualMachine em clusters do plano de controle do Cloud. Por isso, apenas os métodos console e vnc são compatíveis para acessar máquinas virtuais em execução em clusters do plano de controle do Cloud.
  • Não é possível criar uma máquina virtual em um cluster do Distributed Cloud diretamente usando o comando kubectl virt porque o Distributed Cloud não oferece armazenamento de sistema de arquivos para máquinas virtuais.
  • Os recursos de armazenamento em blocos PersistentVolumeClaim não são compatíveis com o formato de imagem de disco qcow2.
  • O plug-in Containerized Data Importer (CDI) não é compatível com recursos DataVolume no armazenamento em blocos porque o espaço de trabalho do plug-in funciona apenas no armazenamento do sistema de arquivos. Para mais informações, consulte Espaço de trabalho temporário.

Provisionar uma máquina virtual Linux no Distributed Cloud com armazenamento em blocos bruto

O exemplo a seguir ilustra como provisionar uma máquina virtual Linux com armazenamento em blocos brutos executando o Ubuntu Server 22.04. A origem da instalação é a imagem do disco ISO do Ubuntu Server 22.04.

  1. Crie um recurso PersistentVolumeClaim com o conteúdo a seguir para a imagem do disco de instalação do Ubuntu Server e aplique-o ao cluster:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: containerized-data-importer
  name: iso-ubuntu
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-block
  volumeMode: Block
  resources:
    requests:
      storage: 5Gi

  2. Crie um recurso PersistentVolumeClaim com o seguinte conteúdo para o disco rígido virtual da máquina virtual e aplique-o ao cluster:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ubuntuhd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: local-block
  volumeMode: Block

  3. Crie um recurso VirtualMachineDisk com o conteúdo a seguir para a imagem do disco de instalação do Ubuntu Server e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-iso-disk"
spec:
  persistentVolumeClaimName: iso-ubuntu
  diskType: cdrom

  4. Crie um recurso VirtualMachineDisk com o seguinte conteúdo para o disco rígido virtual da máquina virtual e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-main-disk"
spec:
  persistentVolumeClaimName: ubuntuhd

  5. Crie um recurso VirtualMachineType com o seguinte conteúdo, que especifica a configuração da máquina virtual, e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  6. Crie um recurso VirtualMachine com o conteúdo a seguir, que instancia e inicia a máquina virtual no cluster. Em seguida, aplique ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: ubu-vm
  name: ubu-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Linux
  compute:
    virtualMachineTypeName: small-2-20
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: ubuntu-main-disk
      boot: true
    - virtualMachineDiskName: ubuntu-iso-disk

    O campo osType só se aplica a clusters de plano de controle local. É necessário em clusters de plano de controle local para configurar os seguintes recursos:

  7. Instale o Ubuntu Server na máquina virtual:

    1. Aguarde o pod importer fazer o download da imagem do disco de instalação do Ubuntu Server.

    2. Verifique o status da máquina virtual:

      kubectl get gvm VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    3. Faça login na máquina virtual:

      kubectl virt vnc VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    4. Conclua as etapas de instalação do Ubuntu Linux.

  8. Limpeza:

    1. Pare a máquina virtual:

      kubectl virt stop VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    2. Edite o arquivo YAML da máquina virtual para remover a referência à imagem do disco de instalação:

      kubectl edit gvm VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    3. Inicie a máquina virtual:

      kubectl virt start VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    4. Exclua os recursos VirtualMachineDisk e PersistentVolumeClaim da imagem do disco de instalação:

      kubectl delete virtualmachinedisk ubuntu-iso-disk
kubectl delete pvc iso-ubuntu

Provisionar uma máquina virtual do Windows no Distributed Cloud com armazenamento em blocos bruto

O exemplo a seguir mostra como provisionar uma máquina virtual do Windows com armazenamento em blocos brutos. As etapas são semelhantes ao provisionamento de uma máquina virtual Linux, com a adição da imagem de disco do driver virtio, que é necessária para instalar o Windows.

  1. Consiga uma cópia licenciada do Windows e a imagem da mídia de instalação.

  2. Crie um recurso PersistentVolumeClaim com o seguinte conteúdo para a imagem do disco de instalação do Windows e aplique-o ao cluster. Para instruções, consulte Da imagem.

  3. Crie um recurso PersistentVolumeClaim com o conteúdo a seguir para o driver virtio e aplique-o ao cluster:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: containerized-data-importer
  name: virtio-driver
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-block
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi

  4. Crie um recurso PersistentVolumeClaim com o seguinte conteúdo para o disco rígido virtual da máquina virtual e aplique-o ao cluster:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: windowshd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: local-block
  volumeMode: Block

  5. Crie um recurso VirtualMachineDisk com o seguinte conteúdo para a imagem do disco de instalação do Windows e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "windows-iso-disk"
spec:
  persistentVolumeClaimName: iso-windows
  diskType: cdrom

  6. Crie um recurso VirtualMachineDisk com o conteúdo a seguir para o driver virtio e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "win-virtio-driver"
spec:
  persistentVolumeClaimName: virtio-driver
  diskType: cdrom

  7. Crie um recurso VirtualMachineDisk com o seguinte conteúdo para o disco rígido virtual da máquina virtual e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "windows-main-disk"
spec:
  persistentVolumeClaimName: windowshd

  8. Crie um recurso VirtualMachineType com o seguinte conteúdo, que especifica a configuração da máquina virtual, e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  9. Crie um recurso VirtualMachine com o seguinte conteúdo, que instancia e inicia a máquina virtual no cluster, e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: win-vm
  name: win-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Windows
  compute:
    virtualMachineTypeName: my-vmt
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: windows-main-disk
      boot: true
    - virtualMachineDiskName: windows-iso-disk
    - virtualMachineDiskName: win-virtio-driver

    O campo osType só se aplica a clusters de plano de controle local. É necessário em clusters de plano de controle local para configurar os seguintes recursos:

  10. Instale o Windows na máquina virtual:

    1. Aguarde o pod importer fazer o download da imagem do disco de instalação do Windows.

    2. Verifique o status da máquina virtual:

      kubectl get gvm VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, win-vm neste exemplo.

    3. Conclua a instalação do Windows seguindo as etapas em Conectar-se à VM do Windows e concluir a instalação do SO.

  11. Limpeza:

    1. Pare a máquina virtual:

      kubectl virt stop VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, win-vm neste exemplo.

    2. Conclua as etapas em Remover a imagem ISO e o disco dos drivers.

Provisionar uma máquina virtual no Distributed Cloud com o Symcloud Storage

Esta seção fornece exemplos de configuração que ilustram como provisionar uma máquina virtual do Linux e uma máquina virtual do Windows em um cluster do Distributed Cloud com a camada de abstração do Symcloud Storage.

Antes de concluir as etapas nesta seção, conclua as etapas em Configurar o Distributed Cloud para o Symcloud Storage. Se você desativar o Symcloud Storage no cluster, as máquinas virtuais configuradas para usar esse serviço vão falhar.

Provisionar uma máquina virtual Linux no Distributed Cloud com o Symcloud Storage

O exemplo a seguir ilustra como provisionar uma máquina virtual Linux com o Symcloud Storage executando o Ubuntu Server 22.04. A origem da instalação é a imagem do disco ISO do Ubuntu Server 22.04.

  1. Crie um recurso VirtualMachineDisk com o conteúdo a seguir para a imagem do disco de instalação do Ubuntu Server e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: ubuntu-iso-disk
spec:
  size: 20Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso

  2. Crie um recurso VirtualMachineDisk com o seguinte conteúdo para o disco rígido virtual da máquina virtual e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-main-disk"
spec:
  size: 200Gi
  storageClassName: robin

  3. Crie um recurso VirtualMachineType com o seguinte conteúdo, que especifica a configuração da máquina virtual, e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  4. Crie um recurso VirtualMachine com o conteúdo a seguir, que instancia e inicia a máquina virtual no cluster. Em seguida, aplique ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: ubu-vm
  name: ubu-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Linux
  compute:
    virtualMachineTypeName: small-2-20
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: ubuntu-main-disk
      boot: true
    - virtualMachineDiskName: ubuntu-iso-disk

    O campo osType só se aplica a clusters de plano de controle local. É necessário em clusters de plano de controle local para configurar os seguintes recursos:

  5. Instale o Ubuntu Server na máquina virtual:

    1. Aguarde o pod importer fazer o download da imagem do disco de instalação do Ubuntu Server.

    2. Verifique o status da máquina virtual:

      kubectl get gvm VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    3. Faça login na máquina virtual:

      kubectl virt vnc VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    4. Conclua as etapas de instalação do Ubuntu Linux.

  6. Limpeza:

    1. Pare a máquina virtual:

      kubectl virt stop VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    2. Edite o arquivo YAML da máquina virtual para remover a referência à imagem do disco de instalação:

      kubectl edit gvm VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    3. Inicie a máquina virtual:

      kubectl virt start VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, ubu-vm neste exemplo.

    4. Exclua o recurso VirtualMachineDisk para a imagem do disco de instalação:

      kubectl delete virtualmachinedisk ubuntu-iso-disk

Provisionar uma máquina virtual do Windows no Distributed Cloud com o armazenamento do Symcloud

O exemplo a seguir mostra como provisionar uma máquina virtual do Windows com o Symcloud Storage. As etapas são semelhantes ao provisionamento de uma máquina virtual Linux, com a adição da imagem de disco do driver virtio, que é necessária para instalar o Windows.

  1. Consiga uma cópia licenciada do Windows e a imagem da mídia de instalação.

  2. Crie um recurso VirtualMachineDisk com o seguinte conteúdo para a imagem do disco de instalação do Windows e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-iso-disk
  namespace: default
spec:
  size: 5Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: WINDOWS_ISO_URL

    Substitua NAT_GATEWAY pelo URL completo da imagem ISO do disco de instalação do Windows de destino.

  3. Crie um recurso VirtualMachineDisk com o conteúdo a seguir para o driver virtio e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-virtio-driver
  namespace: default
spec:
  size: 1Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

  4. Crie um recurso VirtualMachineDisk com o seguinte conteúdo para o disco rígido virtual da máquina virtual e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-main-disk
  namespace: default
spec:
  size: 15Gi
  storageClassName: robin

  5. Crie um recurso VirtualMachineType com o seguinte conteúdo, que especifica a configuração da máquina virtual, e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  6. Crie um recurso VirtualMachine com o seguinte conteúdo, que instancia e inicia a máquina virtual no cluster, e aplique-o ao cluster:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: win-vm
  name: win-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Windows
  compute:
    virtualMachineTypeName: my-vmt
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: windows-main-disk
      boot: true
    - virtualMachineDiskName: windows-iso-disk
    - virtualMachineDiskName: win-virtio-driver

    O campo osType só se aplica a clusters de plano de controle local. É necessário em clusters de plano de controle local para configurar os seguintes recursos:

  7. Instale o Windows na máquina virtual:

    1. Aguarde o pod importer fazer o download da imagem do disco de instalação do Windows.

    2. Verifique o status da máquina virtual:

      kubectl get gvm VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, win-vm neste exemplo.

    3. Conclua a instalação do Windows seguindo as etapas em Conectar-se à VM do Windows e concluir a instalação do SO.

  8. Limpeza:

    1. Pare a máquina virtual:

      kubectl virt stop VM_NAME

      Substitua VM_NAME pelo nome da máquina virtual, win-vm neste exemplo.

    2. Conclua as etapas em Remover a imagem ISO e o disco dos drivers.

Provisionar uma máquina virtual no Distributed Cloud usando virtctl

Se você não precisar da personalização fornecida ao escrever suas próprias especificações de recursos para as máquinas virtuais, provisione uma máquina virtual no Distributed Cloud usando a ferramenta de linha de comando virtctl conforme descrito em Criar uma VM.

Gerenciar máquinas virtuais em execução no Distributed Cloud

Para instruções sobre como gerenciar máquinas virtuais em execução no Distributed Cloud, consulte a seguinte documentação do ambiente de execução de VMs no GDC:

Para gerenciar máquinas virtuais executadas em clusters de plano de controle local, primeiro configure a conectividade do kubectl.

Configurar o dispositivo ttyS0 para acesso ao console serial em máquinas virtuais Linux

Se você planeja acessar suas máquinas virtuais Linux usando o console serial (kubectl virt console), verifique se o dispositivo de console serial ttyS0 foi configurado no sistema operacional convidado. Para configurar o dispositivo, siga estas etapas:

  1. Instancie o dispositivo serial ttyS0 no sistema:

    setserial -g /dev/ttyS0

  2. Configure o carregador de inicialização grub para usar o dispositivo serial ttyS0 adicionando as seguintes linhas ao arquivo de configuração /etc/default/grub. A primeira linha substitui a variável GRUB_CMDLINE_LINUX atual.

    GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8'
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"

  3. Aplique a nova configuração grub ao setor de inicialização:

    update-grub

  4. Reinicie a máquina virtual.

Desativar o ambiente de execução de VM no GDC no Distributed Cloud

Siga as etapas nesta seção para desativar o ambiente de execução de VMs no GDC no Distributed Cloud. Antes de desativar o ambiente de execução de VM no GDC no Distributed Cloud, é preciso interromper e excluir todas as máquinas virtuais no cluster do Distributed Cloud, conforme descrito em Excluir uma VM.

Para desativar o ambiente de execução de VMs no GDC no Distributed Cloud, modifique o recurso personalizado VMRuntime definindo o parâmetro de especificação enabled como false da seguinte maneira e aplique ao cluster:

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  # Disable Anthos VM Runtime
  enabled: false
  # vmImageFormat defaults to "raw" if not set
  vmImageFormat: "raw"

A seguir