Laboratório de Troubleshooting: Move a virtual machine to another resource group, subscription, or region
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador tenta mover uma VM de produção e seus recursos associados para um novo resource group dentro da mesma subscription. O ambiente tem as seguintes características:
- A VM está desalocada
- A subscription possui uma Azure Policy ativa que exige a tag
CostCenterem todos os recursos - O resource group de destino já existe e contém outros recursos
- A VM possui um disco gerenciado e uma NIC associada
- Um Key Vault na mesma subscription é referenciado por uma variável de ambiente da aplicação, mas não é um recurso dependente da VM no Azure Resource Manager
O comando executado foi:
az resource move \
--destination-group rg-financeiro \
--ids /subscriptions/bbbb/resourceGroups/rg-ti/providers/Microsoft.Compute/virtualMachines/vm-app01 \
/subscriptions/bbbb/resourceGroups/rg-ti/providers/Microsoft.Compute/disks/vm-app01-osdisk \
/subscriptions/bbbb/resourceGroups/rg-ti/providers/Microsoft.Network/networkInterfaces/vm-app01-nic
A saída retornada foi:
(ResourceMoveProviderValidationFailed) The resource move operation was not
successful. The following resources failed validation:
Microsoft.Compute/virtualMachines/vm-app01: The request did not include
all required tags.
Qual é a causa raiz da falha?
A. O disco gerenciado e a NIC precisam ser listados antes da VM no parâmetro --ids para que a validação ocorra na ordem correta.
B. O resource group de destino não possui a tag CostCenter, e a Azure Policy bloqueia a criação ou movimentação de recursos sem essa tag no destino.
C. A VM está desalocada e o Azure exige que ela esteja em estado Running para que a validação de dependências ocorra corretamente durante o move.
D. O Key Vault referenciado pela aplicação precisa ser incluído no mesmo comando de move, pois o Azure Resource Manager o detecta como dependência implícita.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a VM vm-migrada foi movida com sucesso para uma nova subscription, mas a sua system-assigned managed identity precisa de permissão Key Vault Secrets User no Key Vault que permaneceu na subscription de origem. A equipe já validou que a VM está operacional no destino e que a identidade gerenciada foi preservada.
O contexto de restrições é:
- O ambiente é de produção e a aplicação está fora do ar aguardando a correção
- A equipe não tem permissão para mover o Key Vault para a nova subscription
- Um colega sugere recriar a managed identity como user-assigned e refazer toda a configuração
- O time de segurança exige aprovação para qualquer alteração de política de acesso no Key Vault, mas o processo de aprovação leva menos de 15 minutos
Qual é a ação correta a tomar neste momento?
A. Recriar a VM com uma user-assigned managed identity e atribuir a permissão Key Vault Secrets User na nova identidade, substituindo a system-assigned.
B. Aguardar a aprovação do time de segurança e então adicionar um novo RBAC assignment concedendo à managed identity da VM o papel Key Vault Secrets User no Key Vault da subscription de origem.
C. Mover o Key Vault para a nova subscription imediatamente para colocar todos os recursos no mesmo escopo e eliminar a dependência entre subscriptions.
D. Adicionar o RBAC assignment sem aguardar aprovação, documentando a ação como emergência de produção e comunicando o time de segurança em seguida.
Cenário 3 — Causa Raiz
Uma VM chamada vm-relatorios foi movida para uma nova região usando o Azure Resource Mover. A operação de commit foi concluída sem erros. Dois dias depois, a equipe de finança reporta que a fatura do Azure está mostrando cobrança dupla: tanto os recursos na região de origem quanto os da região de destino aparecem ativos.
Informações coletadas pela equipe:
- O Azure Resource Mover exibiu o status
Commit pendingna semana anterior - A equipe executou o commit e recebeu confirmação de sucesso
- A VM na região de destino está operacional e passou por testes de validação
- A VM na região de origem aparece com status
Stopped (deallocated) - A subscription está dentro dos limites de cota para ambas as regiões
Qual é a causa raiz da cobrança dupla?
A. O Azure Resource Mover falhou silenciosamente no commit e manteve os recursos de origem em estado ativo sem notificar a equipe.
B. VMs no estado Stopped (deallocated) ainda geram cobrança de disco gerenciado, e o disco da VM de origem não foi excluído após o commit.
C. A subscription duplicou os recursos durante o processo de replicação do Resource Mover, criando cópias não rastreadas que precisam ser removidas via suporte.
D. O status Stopped (deallocated) indica que a VM de origem ainda está alocada e gerando cobrança de compute, pois o desligamento não foi iniciado pelo Resource Mover.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte erro ao tentar mover uma VM para outro resource group:
(MoveNotSupported) The move is not supported for the resources of type
'Microsoft.Compute/virtualMachines' that have the following resources
attached or dependent: ['Microsoft.Compute/virtualMachines/vm-db01/extensions/DependencyAgentWindows']
A VM vm-db01 faz parte de um ambiente monitorado pelo Azure Monitor e tem extensões instaladas. A equipe dispõe dos seguintes passos de investigação, apresentados fora de ordem:
- Verificar na documentação oficial quais tipos de recursos e extensões bloqueiam operações de move
- Confirmar se o move é bem-sucedido após a remoção
- Tentar executar o comando de move e observar a mensagem de erro completa
- Identificar todas as extensões instaladas na VM e verificar quais são incompatíveis com move
- Remover a extensão incompatível ou aguardar suporte a move para aquele tipo de recurso
Qual é a sequência correta de investigação?
A. 3 → 1 → 4 → 5 → 2
B. 1 → 4 → 3 → 5 → 2
C. 4 → 3 → 1 → 2 → 5
D. 3 → 4 → 1 → 5 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é explícita: The request did not include all required tags. A Azure Policy configurada na subscription exige a tag CostCenter em todos os recursos. Durante uma operação de move, o Azure valida se os recursos no destino estariam em conformidade com as políticas aplicáveis. Se o resource group de destino não possui a tag CostCenter, os recursos movidos para ele falharão na validação de policy.
A informação sobre o Key Vault era propositalmente irrelevante: o Azure Resource Manager não o detecta como dependência de move, pois a relação é apenas de configuração de aplicação, não de vínculo ARM.
A alternativa A representa um erro clássico de diagnóstico superficial: a ordem dos --ids não tem impacto na validação. A alternativa C inverte a lógica: VMs desalocadas são elegíveis para move. A alternativa D seria o distrator mais perigoso em um ambiente real, pois poderia levar o administrador a tentar mover o Key Vault desnecessariamente, causando interrupção adicional.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e a solução é conhecida: adicionar um RBAC assignment no Key Vault para a managed identity da VM. A restrição crítica é que o time de segurança exige aprovação, mas o processo leva menos de 15 minutos. Dado que o ambiente está em produção e fora do ar, a ação correta é aguardar a aprovação (prazo curto e aceitável) e então aplicar a correção precisa.
A alternativa A representa uma ação tecnicamente válida em outros contextos, mas neste cenário seria um excesso de engenharia: recriar a identidade, reatribuir permissões e reconfigurar a aplicação causaria muito mais downtime do que aguardar 15 minutos. A alternativa C ignora a restrição explícita de que a equipe não tem permissão para mover o Key Vault. A alternativa D é o distrator mais perigoso: agir sem aprovação viola o processo de segurança estabelecido e pode gerar incidentes de compliance, mesmo que a intenção seja resolver uma emergência.
Gabarito — Cenário 3
Resposta: B
O Azure Resource Mover cria uma cópia dos recursos na região de destino durante o processo de replicação. Após o commit, os recursos de origem não são excluídos automaticamente: eles permanecem existentes e precisam ser removidos manualmente. No caso de VMs com discos gerenciados, mesmo que a VM esteja no estado Stopped (deallocated), o disco gerenciado continua sendo cobrado por existir como recurso provisionado, independentemente do estado de execução da VM.
A informação sobre Commit pending e os testes de validação eram relevantes para confirmar que o commit foi executado com sucesso, mas irrelevantes para explicar a cobrança dupla. A alternativa A é falsa porque o commit foi confirmado com sucesso. A alternativa D representa o equívoco mais comum: confundir o estado da VM com a cobrança do disco. A alternativa C seria o distrator mais perigoso, pois levaria a equipe a abrir um chamado de suporte desnecessário, atrasando a resolução simples de excluir os recursos de origem manualmente.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: observar o erro (3), consultar a documentação para entender quais tipos de extensões bloqueiam move (1), identificar todas as extensões da VM e cruzar com a lista de incompatibilidades (4), tomar a ação corretiva de remover ou aguardar suporte (5) e confirmar o sucesso (2).
O diagnóstico progressivo parte sempre do sintoma observado para a validação de hipóteses, nunca de uma varredura genérica. A alternativa B começa pela documentação antes de observar o erro, o que seria ineficiente sem saber o sintoma exato. A alternativa C começa pela identificação de extensões antes de observar o erro ou consultar documentação, desperdiçando esforço. A alternativa D separa a observação do erro da consulta à documentação de forma que a identificação das extensões ocorre antes de saber quais são incompatíveis, o que inverte a lógica de eliminação.
Árvore de Troubleshooting: Move a virtual machine to another resource group, subscription, or region
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (nó raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Resolução ou operação bem-sucedida |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado após a operação de move. Siga as perguntas de diagnóstico respondendo com base no que você consegue observar diretamente: mensagem de erro, estado dos recursos, escopo de destino. Cada ramificação elimina hipóteses até chegar a uma causa identificada em vermelho ou a uma verificação intermediária em laranja que orienta o próximo passo de investigação. Nunca pule etapas para chegar mais rápido a uma causa; a árvore foi construída para que cada pergunta dependa da resposta anterior.