2013-08-18 19:45:47 +0000 2013-08-18 19:45:47 +0000
252
252

Qual a forma recomendada para mover uma VirtualBox VM para outro computador?

Utilizo a VirtualBox 4.1.x na minha máquina Ubuntu e já instalei várias máquinas virtuais. Como existem várias formas de mover uma máquina virtual na VirtualBox para outro computador, estava a pensar qual é a forma recomendada:

  1. Use o “Import/Export utility”.
  2. Copie toda a pasta da máquina virtual, contendo os ficheiros .vdi e .vbox.
  3. Clonar a VDI utilizando o “Virtual Media Manager” e depois recriar uma VM na máquina alvo mas utilizando a VDI clonada como disco rígido.

Utilizei com sucesso o método várias vezes e este sempre funcionou. O problema é que depois de exportar e importar, a imagem do disco é transformada em VMDK e já não em VDI!

O 2º método* é provavelmente o mais fácil mas não tenho a certeza de que a simples cópia dos ficheiros funcione ou não na máquina de destino. Ao pesquisar sobre este método, descobri que algumas pessoas tiveram problemas em editar o ficheiro VirtualBox.xml para o resolver!

Finalmente, existe o 3º método* , mas requer o trabalho extra de criar uma VM semelhante à configuração original da VM, o que não é desejável.

É claro pela explicação acima que o meu método desejado é o 2º, mas preciso de aconselhamento especializado se funcionar ou não. Não quero que nenhuma edição XML se meta no meu caminho!

Qual é o melhor método para transferir com segurança os meus VM’s para outro computador com a VirtualBox?

Respostas (9)

177
177
177
2013-08-18 20:53:14 +0000

Muito bem feito por fazer a sua investigação. Utilizo regularmente as três opções.

  1. (Use o “Import/Export utility”)_. Este é o mais fácil porque combina todo o VM num único ficheiro e transfere-o praticamente sempre sem problemas. Contudo, pela minha experiência ao criar o ficheiro OVA ou OVF para exportação, deita fora todos os instantâneos e se feito de forma incorrecta pode resultar num ficheiro VMDK. Ao reimportar o VM deve poder seleccionar que tipo de ficheiro HDD pretende criar, VDI ou VMDK.

  2. (Copiar toda a pasta da máquina virtual, contendo os ficheiros .vdi e .vbox)_. Esta é a minha opção preferida e embora tenha tido de editar o ficheiro XML algumas vezes, a culpa foi minha por ter estragado alguma coisa. Certifique-se de que quando copia o VM, obtém TODOS os ficheiros associados a ele. Os problemas que encontrei foram quando certos snapshots e ficheiros VDI secundários estavam no directório errado e não foram copiados correctamente. Se copiar todos os ficheiros (e permissões) não deverá ter quaisquer problemas.

  3. (Clone o VDI utilizando o “Virtual Media Manager” e depois recrie um VM na máquina alvo mas utilizando o VDI clonado como disco rígido)._ Isto é menos desejável porque depois tem 2 cópias de um VM, e pode causar problemas de licenciamento, problemas de rede, etc, dependendo de como clona o ficheiro VDI.

Em resumo, eu definitivamente recomendaria a opção 2, apenas certifique-se que obtém todos os ficheiros necessários quando o mover.

54
54
54
2015-09-24 19:35:02 +0000

O método 2 funciona bem agora (com VirtualBox 4.0 e superior), sem qualquer modificação XML necessária:

  1. Pare a sua Máquina Virtual
  2. Sair da VirtualBox
  3. Copie a pasta VM para a nova localização
  4. Reinicie a VirtualBox, e apague a antiga VM.
  5. Vá ao menu Máquina ≥ Adicionar e navegar para a sua antiga pasta.

É isso mesmo!

ps: Eu tenho a VirtualBox 4.3.20 na OSX 10.10

Veja este post do fórum VirtualBox para mais detalhes.

21
21
21
2015-09-25 17:14:10 +0000

A minha opção preferida é também a opção 2:

  1. Copie toda a pasta VM, contendo os ficheiros .vdi e .vbox.

Mas por vezes acontece um descasamento de UUID. Muitas vezes isto acontece se apenas copiar a imagem do disco VDI de uma máquina para outra máquina, mas também já a tive durante cópias rectas de directórios completos.

Por isso, se esta é a mensagem que recebe depois de mover a máquina virtual e tentar ligá-la na nova configuração:

Falha ao abrir o disco rígido .

Não é possível registar o disco rígido porque já existe um disco rígido com UUID.

Basta entrar no directório da sua máquina virtual; é claro que mude o caminho real para corresponder ao caminho real que vai seguir:

cd /full/path/to/virtualbox/virtualmachine/Sandbox

E execute este comando para atribuir um novo UUID ao disco:

VBoxManage internalcommands sethduuid Sandbox.vdi
9
9
9
2014-08-16 12:21:03 +0000

Caso mais alguém esteja à procura de uma resposta para isto, mudei com sucesso 5 Virtual Box VMs para outro Win7 instalado num novo disco rígido na mesma máquina (essencialmente uma mudança de um SO convidado para outro no mesmo PC). Compreendo que os drivers numa máquina completamente nova provavelmente variariam e poderiam ter um efeito negativo na mudança, mas documentei o processo abaixo na esperança de que possa ajudar alguém.

  • Não havia nenhum requisito para clonar VMs ou alterar o ficheiro xml. A versão VB era bastante atual: 4.3.12r93773.
  • Novas cópias de VMs foram criadas em uma nova pasta/unidade compartilhada para manter as VMs existentes/antigas intactas. Ainda posso arrancar a partir do antigo disco rígido que mantive para resolução de redundância/emissão até estar satisfeito com a minha nova configuração; assim posso aceder às antigas VMs no seu estado anterior, se necessário.
  • As letras da unidade irão variar/ não serão necessárias dependendo da sua configuração.

On Old Win7 Host:

  1. Certifique-se que todas as VMs estão desligadas.

On New Win7 Host:

  1. Criar uma nova pasta chamada X:\NewVMs\VirtualBox VMs (da máquina New Win7 para garantir as permissões OK)
  2. Copiar/Colar (não arraste) todos os VMs e conteúdos de pastas relacionadas da pasta antiga para esta pasta (usa novas permissões)
  3. Desinstalar a VirtualBox (se instalada)
  4. Apagar a pasta .virtualbox e todos os conteúdos (se existirem)
  5. REBOOT para confirmar que não restam ficheiros de programas ou entradas de registo (se desinstalar a antiga VirtualBox)
  6. Instalar/Re-instalar a VirtualBox (certifique-se de que está a utilizar a mesma versão da VirtualBox em que as VMs foram criadas no antigo host/machine (no meu caso ver. 4.3.12r93773)) IMPORTANTE: (Não seleccione tickbox para abrir/executar VirtualBox no final da instalação)
  7. Copie/colar (não arraste) .virtualbox folder and contents from Old Win7 Host (normalmente C:\Users[username].VirtualBox
  8. Agora abra a VirtualBox
  9. Defina as preferências para a nova pasta de criação de VMs por defeito para o mesmo caminho de ficheiro que a pasta VirtualBox VMs recentemente criada: X:\NewVMs\VirtualBox VMs
  10. Estado de teste das VMs

Boa sorte.

2
2
2
2016-03-22 03:42:08 +0000

Para o caso especial em que:

  • você só tem um VM** (ou quer mover todos os seus VMs),
  • e o anfitrião é o mesmo hardware com a mesma versão de SO** (ou reinstalar o mesmo SO na mesma máquina)

Se estiver neste caso, então as coisas são fáceis:

  1. Desligue a VirtualBox em ambos os hosts.
  2. Copie as pastas .config/VirtualBox e VirtualBox VMs a partir do host de origem.
  3. Copie estas pastas para o anfitrião de destino.
  4. Inicie a VirtualBox no anfitrião de destino.
1
1
1
2018-06-28 21:44:12 +0000

The 4th Way

Em VirtualBOX:

  1. Desligar o VM
  2. Clique com o botão direito e remova o VM (não elimine ficheiros)
  3. Vá ao ficheiro>Virtual Media Manager e remova o .vdi
  4. Vá a File>Preferences>General e configure a pasta predefinida da máquina para a nova localização
  5. Crie uma nova VM utilize o modo expert para criar a VM sem disco rígido

In File Explorer:

  1. Localize o ficheiro .vdi e copie-o
  2. Vá para a nova pasta padrão da máquina, haverá uma pasta VM dentro do
  3. Colar o ficheiro .vdi na nova pasta VM

Voltar Na VirtualBOX:

  1. Clique com o botão direito do rato na VM e abra as definições
  2. Vá a Storage>Controller: SATA e adicione um disco rígido, clique em choose an existing disk 11.choose the .vdi file in the new VM folder

Note: Se o método 2 quebrar a sua instalação da VirtualBOX vá a C:\Users.VirtualBox e apague o VirtualBox.xml e renomeie VirtualBox.xml-prev para VirtualBox.xml

0
0
0
2016-09-12 21:36:17 +0000

Usei também o método 2 para mover a minha máquina virtual e não tive que fazer nenhuma alteração em nenhum ficheiro XML mas obtive alguns erros com USB e partilha de ficheiros e abaixo é como os corrigi juntamente com o processo:

  1. Copiar a máquina virtual do antigo para o novo pc. Os ficheiros da máquina virtual são diferentes dos da própria máquina virtual Oracle. Estes ficheiros estão tipicamente em _c:\ utilizadores\VirtualBox VMs_. Eu peguei na parte _VirtualBox VMs_ inteira e copiei-a para um local semelhante no novo PC. Isto copia todas as máquinas virtuais que eu tinha no PC original.

  2. Agora no novo PC, execute a caixa virtual e vá ao Menu > Máquina > Adicionar e seleccione o ficheiro .vbox a partir da pasta copiada. É isso mesmo.

  3. Agora quando corro máquina virtual em PC novo, recebi um erro quando estava a arrancar:

  1. Não sei porque é que o controlador USB não estava a funcionar porque o mesmo funcionava no computador original. Fui em frente e instalei VirtualBox Extension Pack

  2. Esta instalação foi um pouco esquisita porque o download da instalação não era um ficheiro executável. Cliquei em Oracle_VM_VirtualBox_Extension_Pack-5.1.4-110228.vbox-extpack e seleccionei ‘Select a program from a list of Installed programs’ e depois seleccionei o Oracel virtualbox e ele instalou a extensão. Isso resolveu o problema, mas outra solução menos desejável é desactivar o usb.

  3. Se tinha pastas partilhadas no VM original, estas podem ser diferentes e receberá um erro. Consulte as que se encontram em Settings >> Shared Folder e apague as que estão quebradas. Uma mensagem de erro será parecida com

.

E é tudo.

-1
-1
-1
2017-01-03 15:03:14 +0000

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:

  • Common Inmutable Disks

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):

  1. Tome nota da lista de todas as máquinas (encomenda, agrupamento, etc.)
  2. Tomar nota do primeiro da lista (toda a sua configuração)
  3. Tomar nota de todas as propriedades das máquinas que pretendo mudar para outro host
  4. Copie os ficheiros .vbox como ficheiros .txt (o do topo da lista + todas as máquinas que pretendo migrar)
  5. Recrie todas as máquinas (e tenha uma especial no topo da lista) dentro da VirtualBox no novo host
  6. Feche a VirtualBox no novo host
  7. 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
  8. Abra a VirtualBox e anexe todas as VDIs na ordem correcta
  9. Feche novamente a VirtualBox no novo host
  10. 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).

-2
-2
-2
2017-04-27 23:51:57 +0000

Copie a pasta que contém a máquina até ao destino, depois a partir do menu: “Máquina” —> “Adicionar”, e depois escolha o ficheiro vbox, NÃO o ficheiro vdi. Para mim isto correu sem falhas. Não tenho a certeza se tive sorte, ou se é suposto funcionar desta forma.