zar, a primeira coisa primeiro ... nunca mova uma máquina que esteja no estado salvo; antes da mudança, você deve desligar o convidado, não apenas salvar o estado.
Além disso, verifique se você usa a mesma versão do VirtualBOX nos dois hosts, mas não apenas a versão do VirtualBOX, também a versão do pacote de extensão ... ou pelo menos o novo host tem uma versão superior, mas nunca uma versão inferior em nenhum dos dois.
E, finalmente, aprendi da maneira mais difícil, exclua a configuração da pasta SHARED no VirtualBOX antes de mover a máquina e depois recrie-a da maneira correta ... muito importante quando o host é um SO diferente (hosts Windows / Linux).
E apenas como uma observação ... sempre, sempre use arquivos VDI inmutáveis de disco rígido para SO e para VDIs de dados (dessa maneira, o mesmo DATA VDI pode ser usado para mais de convidados), especialmente truque para 4GiB pagefile.sys
Na última parte, reutilize um arquivo VDI inmutável torna as coisas um pouco mais difíceis, o VirtualBOX tem um GRANDE BUG.
Para ver o bug em ação:
- Crie um VDI imutável (como o que eu uso para o pagefile.sys)
- Crie duas ou três VMs no VirtualBOX
- Mova um deles para o topo da lista (apenas para evitar danos a qualquer um dos seus)
- Faça backup dos arquivos .vbox de cada uma dessas máquinas que você criou (para compará-lo após o erro)
- Anexe esse VDI imutável a mais de uma dessas máquinas (exceto a que está no topo da lista)
- Agora veja o .vbox da máquina que está no topo da lista
Essa máquina foi editada, tem referências às outras máquinas VDI inmutável.
Portanto, o BUG é: Edite uma máquina adicionando um VDI inutável que é usado por outra afeta a máquina no topo da lista.
Por que diabos eu reutilizo o mesmo 4GiB VDI em todas as máquinas Windows? Fácil, é um disco MBR com uma partição FAT32 onde eu coloco o pagefile.sys, pois é inmutável todas as máquinas virtuais criarão um arquivo em sua pasta de instantâneos onde armazenam as alterações e que se perdem na próxima inicialização, por isso não preciso do 4GiB para cada convidado armazenado no disco host, apenas um ... dessa forma, economizo muito GiB, pois tenho mais de 20 janelas diferentes para testar aplicativos que desenvolvo por conta própria, todas as combinações de (XP, Vista , 7, 8, 8.1, 10) * (32 bits, 64 bits) * (Assim como na primeira instalação, após cada ServicePack, após a atualização completa do Windows), recebo muitos convidados ... assim como todos eles eu compartilho o inmutável 4GiB VDI para a ram virtual (pagefile.sys).
E se você deixar o BUG ir além, tente mover uma dessas máquinas para outro host do VirtualBOX (lembre-se de que são apenas máquinas virtuais com uma configuração nelas e nenhum hóspede ainda instalado nelas), você verá que o VirtualBox não permite adicione-os, pois faltam alguns VDIs (é FALSO e VERDADEIRO, é que essa primeira máquina mantém as referências a esses VDIs com o objetivo de ser na máquina correta).
Agora compare os arquivos .VBOX de todos eles com o backup anterior ... observe como um é modificado incorretamente? ... sim, é o que está no topo da lista.
Bem, esse erro foi informado ao VirtualBOX há alguns anos, eles ainda não conseguem consertá-lo ... e está causando muitos, muitos problemas.
Além disso, se você mover a primeira das máquinas virtuais para uma posição mais baixa, feche o VirtualBox e a reinicie ... informará que algumas máquinas estão danificadas e não podem ser iniciadas ... sim, a primeira da lista deve ser tratado de uma forma diferente se você não quiser obter muitos problemas.
É um erro muito ruim que me levou muitos dias para descobrir (alguns anos atrás) eu aprendo da maneira mais difícil!
Eu tinha superado isso por ter uma máquina que eu havia chamado:
Ele tem uma configuração vazia e apenas um VDI, sim, você está certo, você adivinhou, o VDI imutável que eu compartilho para todas as demais máquinas virtuais.
Bem, quando abro o arquivo .VBOX, vejo muitas linhas na <MediaRegistry> <HardDisks>seção, uma por cada máquina em que uso esse VDI inutável ... apenas como uma amostra (removo dados particulares):
<MediaRegistry>
<HardDisks>
<HardDisk uuid="...UUID..." location="D:\VDIs\_Virtual_Memory_.vdi" format="VDI" type="Immutable">
<HardDisk uuid="{...UUID...}" location="Snapshots\{...UUID...}.vdi" format="VDI" autoReset="true"/>
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows001 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows002 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows003 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows004 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows005 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows006 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows007 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows008 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows009 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows010 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows011 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows012 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows013 ... // This belongs to other virtual Machine
... and so on ... // This belongs to other virtual Machine
</HardDisk>
</HardDisks>
</MediaRegistry>
Erro bonito, não resolvido desde anos.
Bem, para mover essas máquinas ... você deve editar manualmente os arquivos .VBOX, para colocar todas essas referências de discos no novo host na primeira máquina (a que está no topo da lista) antes de adicionar o .VBOX arquivos à lista, portanto, ao adicioná-los, o VirtualBOX tem as referências aos VDIs ausentes (ausentes causados pelo grande erro).
O problema ocorre porque cada vez que você conecta um VDI usado em outra máquina, o VirtualBOX atualiza dois arquivos .VBOX das máquinas (aquele que pertence à máquina que você está usando) e ao primeiro da lista.
Não tenho muita certeza do que aconteceria quando na lista, o primeiro não tem um VDI tão comum anexado a ele ... é melhor não tentar, visto o que vejo.
Portanto, migrar para outro HOST é muito mais complicado do que parece ser uma implementação muito ruim na estrutura interna dos arquivos .VBOX e por causa de erros muito grandes quando o VirtualBOX os edita.
Falha:
- A estrutura interna (XML) depende do HOST (Windows ou Linux)
- Editar uma máquina pode alterar outra, não apenas a que está sendo editada
- ... o que mais ?
Precisa de mais ... eu sempre migro máquinas fazendo isso (e nunca tive problemas, nunca):
- Anote a lista de todas as máquinas (ordem, agrupamento, etc.)
- Anote o primeiro da lista (toda a sua configuração)
- Anote todas as propriedades das máquinas que quero mover para outro host
- Copie os arquivos .vbox como arquivos .txt (aquele no topo da lista + todas as máquinas que desejo migrar)
- Recrie todas as máquinas (e tenha uma especial no topo da lista) dentro do VirtualBox no novo host
- Feche o VirtualBox no novo host
- Diff compare o antigo .txt com os novos arquivos .vbox e copie de .txt para .vbox algumas partes da maneira humana, não apenas Copie e cole
- Abra o VirtualBox e anexe todos os VDIs na ordem correta
- Feche novamente o VirtualBox no novo host
- Diff compara o arquivo .txt antigo com os novos arquivos .vbox e 'corrige' de .txt para .vbox algumas partes da maneira humana, não apenas Copiar e Colar
Todo o restante (pasta de instantâneos e arquivos VDI) copia-os da maneira normal (Copiar e colar sistema de arquivos).
Todo esse trabalho manual árduo é causado pelo Big BUG VirtualBox: Ele edita / altera uma máquina que não foi modificada quando você anexa um VDI imutável usado em mais de uma máquina; caso contrário, basta copiar e colar o arquivo .VBOX. fixando caminhos de pastas compartilhadas, etc).
