zar, em primeiro lugar… nunca mova uma máquina que esteja em estado salvo, antes de movê-la você deve desligar o convidado, não apenas salvar o estado.
Certifique-se também de usar a mesma versão da VirtualBOX em ambos os hosts, mas não apenas a versão VirtualBOX, também o pacote de extensão vesion… ou pelo menos o novo host tem uma versão superior, mas nunca uma versão inferior em qualquer um dos dois.
E finalmente, aprendi da maneira mais difícil, apagar a configuração da pasta SHARED na VirtualBOX antes de mover a máquina, depois recriá-la de uma forma correcta… muito importante quando o host é um OS diferente (hosts Windows / Linux).
E apenas como nota lateral…. i sempre usar ficheiros VDI inmutáveis do disco rígido para OS, bem como para VDIs de dados (dessa forma o mesmo VDI DATA pode ser usado para mais do que guest), truque especial para o pagefile 4GiB. sys
Essa última parte, reutilizar um ficheiro VDI inmutável torna as coisas um pouco mais difíceis, a VirtualBOX tem um BIG BUG.
Para ver o Bug em acção:
- Criar um VDI inmutável (como o que uso para pagefile.sys)
- Criar duas ou três VM’s na VirtualBOX
- Mover uma delas para o topo da lista (só para evitar danificar qualquer uma das suas)
- BackUp o . vbox de cada uma das máquinas que criou (para comparar após o BUG acontecer)
- Anexe essa VDI inmutável a mais do que uma dessas máquinas (excepto a que está no topo da lista)
- Agora veja a .vbox da máquina que está no topo da lista
Essa máquina foi editada, tem referências às outras máquinas inmutáveis VDI.
Então o BUG está: Editar uma máquina adicionando um VDI inmutável que é usado por outra afecta a máquina no topo da lista.
Porque diabos eu reutilizo o mesmo VDI 4GiB em todas as máquinas Windows? Fácil, é um disco MBR com uma partição FAT32 onde eu coloco pagefile.sys, uma vez que é inmutável todas as máquinas virtuais irão criar um ficheiro na sua pasta de snapshot onde armazenam as alterações, e que se perdem no próximo arranque, por isso não preciso do 4GiB para cada convidado armazenado no disco host, apenas um… Assim poupo muito GiB já que tenho mais de 20 janelas diferentes para testar aplicações que desenvolvo para a minha própria, todas as combinações de (XP, Vista, 7, 8, 8.1, 10)*(32Bits, 64Bits) * (Tal como na primeira instalação, depois de cada ServicePack, depois da actualização completa das janelas), recebo muito, muito convidados… por isso em todas elas partilho o inmutável 4GiB VDI para o ram virtual (pagefile.sys).
E se você deixar o BUG ir mais longe, tente mover uma das máquinas para outro host VirtualBOX (lembre-se que são apenas máquinas virtuais com uma configuração nelas e nenhum convidado ainda instalado nelas), você verá que a VirtualBox não permite que você as adicione uma vez que alguns VDIs estão faltando (é FALSO e VERDADEIRO, é que essa primeira máquina contém as referências a esses VDIs insteados de estar na máquina correta).
Agora compare o . VBOX de todos eles com Previos BackUp… note como um é modificado erradamente?… sim, é o que está no topo da lista.
Bem, este BUG foi informado à VirtualBOX há alguns anos atrás, ainda não conseguiram corrigi-lo… e está a causar muitos, muitos problemas.
Também mais, se mover o topo das máquinas virtuais para uma posição mais baixa, feche a VirtualBox e relance-a… irá dizer-lhe que algumas máquinas estão danificadas e não podem ser iniciadas… sim a primeira da lista deve ser tratada de uma forma diferente se não quiser arranjar muitos problemas.
É um BUG muito mau que me levou muitos dias a descobrir (há alguns anos atrás) aprendi da maneira mais difícil!
Tinha-o superado ao ter uma máquina que tinha chamado:
Tem uma configuração vazia e apenas um VDI, sim, tem razão, adivinhe, o inmutável VDI que partilho para todas as outras máquinas virtuais.
Bem, quando abro o ficheiro .VBOX vejo dentro dele um monte de linhas na secção <MediaRegistry> <HardDisks>, uma por cada máquina onde uso esse VDI inmutável… tal como uma amostra (retiro dados privados):
<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>
Pretty BUG, não resolvido há anos.
Bem, para mover essas máquinas… tem de editar manualmente o VDI . 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 os ficheiros .VBOX à lista, por isso ao adicioná-los a VirtualBOX tem as referências das VDIs em falta (em falta causadas pelo grande BUG).
A coisa acontece porque cada vez que se liga uma VDI que é usada noutra máquina a VirtualBOX actualiza duas máquinas . Ficheiros VBOX (o que pertence à máquina que está a utilizar) e ao primeiro da lista.
Não estou totalmente certo do que aconteceria quando na lista, o primeiro não tem uma VDI tão comum… é melhor não a experimentar, já vi o que vejo.
Portanto migrar para outro HOST é muito mais complicado do que parece ser devido a uma implementação muito má nos ficheiros .VBOXestrutura interna e por causa de BUGs realmente grandes quando a VirtualBOX os edita.
Falhas:
- Estrutura interna (XML) depende do HOST (Windows ou Linux)
- Editar uma máquina pode alterar outra, não só a que está a ser editada
- … o que mais ?
Precisa de mais… eu sempre migrar máquinas fazendo isso (e não teve nenhum problema, nunca):
- Tome nota da lista de todas as máquinas (encomenda, agrupamento, etc.)
- Tomar nota do primeiro da lista (toda a sua configuração)
- Tomar nota de todas as propriedades das máquinas que pretendo mudar para outro host
- Copie os ficheiros .vbox como ficheiros .txt (o do topo da lista + todas as máquinas que pretendo migrar)
- Recrie todas as máquinas (e tenha uma especial no topo da lista) dentro da VirtualBox no novo host
- Feche a VirtualBox no novo host
- Diff compare o antigo .txt com os novos ficheiros .vbox e copie de .txt para .vbox algumas partes de forma humana, e não apenas Copiar&Colar
- Abra a VirtualBox e anexe todas as VDIs na ordem correcta
- Feche novamente a VirtualBox no novo host
- Diff compare o antigo .txt com os novos ficheiros .vbox e ‘fixe’ de .txt para .vbox algumas partes de forma humana, não apenas Copiar&Colar
Todo o resto (pasta snapshots e ficheiros VDI) copio-os da forma normal (File System Copy&Paste).
Todo esse trabalho manual árduo é causado pela Big BUG VirtualBox: Edita / altera uma máquina que não foi modificada quando se anexa uma VDI inmutável que são utilizadas em mais do que uma máquina, caso contrário uma simples Copiar&Colar o ficheiro .VBOX seria suficiente (depois de corrigir caminhos de pastas partilhadas, etc).
