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

Qual è il modo consigliato per spostare una VirtualBox VM su un altro computer?

Uso VirtualBox 4.1.x sulla mia macchina Ubuntu e ho impostato diverse macchine virtuali. Dato che ci sono diversi modi per spostare una macchina virtuale in VirtualBox su un altro computer, mi chiedevo quale fosse il modo consigliato:

  1. 1. Utilizzare l'utilità “Importa/Esporta”
  2. 2. Copiare l'intera cartella della macchina virtuale, contenente i file .vdi e .vbox. 3. Clonare la VDI usando “Virtual Media Manager” e poi ricreare una VM sulla macchina di destinazione ma usando la VDI clonata come hard disk.

Ho usato con successo il 1° metodo più volte e ha sempre funzionato. Il problema è che dopo l'esportazione e l'importazione, l'immagine del disco viene trasformata in VMDK e non più in VDI!

Il 2° metodo è probabilmente il più semplice, ma non sono sicuro che la semplice copia dei file funzionerà o meno sulla macchina di destinazione. Quando ho cercato questo metodo, ho scoperto che alcune persone hanno avuto problemi in cui hanno dovuto modificare il file VirtualBox.xml per risolverlo!

Alla fine, c'è il 3° metodo , ma richiede il lavoro extra di creare una VM simile alla configurazione originale della VM, che non è auspicabile.

Dalla spiegazione sopra riportata è chiaro che il mio metodo desiderato è il 2°, ma ho bisogno di un parere esperto su questo se funziona o meno. Non voglio che nessuna modifica XML mi intralci!

Qual è il metodo migliore per trasferire in sicurezza le mie VM su un altro computer con VirtualBox?

Risposte (9)

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

Ben fatto per aver fatto la tua ricerca. Uso regolarmente tutte e tre le opzioni.

    1. (Utilizza l'utilità “Import/Export”)_. Questa è la più semplice perché combina l'intera VM in un unico file e la trasferisce senza problemi praticamente ogni volta. Tuttavia, nella mia esperienza, quando creo il file OVA o OVF per l'esportazione butta via tutti gli snapshot e se fatto in modo non corretto può risultare in un file VMDK. Quando si reimporta la VM si dovrebbe essere in grado di selezionare il tipo di file HDD che si desidera creare, VDI o VMDK.
    1. (Copiare l'intera cartella della macchina virtuale, contenente i file .vdi e .vbox)_. Questa è la mia opzione preferita e anche se ho dovuto modificare il file XML alcune volte è stata colpa mia per aver sbagliato qualcosa. Assicuratevi che quando copiate la VM, otterrete TUTTI i file ad essa associati. I problemi che ho incontrato sono stati quando alcuni snapshot e file VDI secondari erano nella directory sbagliata e non sono stati copiati correttamente. Se copiate tutti i file (e i permessi) non dovreste avere alcun problema.
  1. (Clonare la VDI usando “Virtual Media Manager” e poi ricreare una VM sulla macchina di destinazione ma usando la VDI clonata come hard disk)._ Questo è meno desiderabile perché così si hanno 2 copie di una VM, e può causare problemi di licenza, problemi di rete, ecc, a seconda di come si clona il file VDI.

In sintesi, raccomanderei sicuramente l'opzione 2, basta assicurarsi di ottenere tutti i file necessari quando si sposta.

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

Il metodo 2 funziona bene ora (con VirtualBox 4.0 e superiori), senza alcuna modifica XML richiesta:

  1. Ferma la tua Macchina Virtuale
  2. 2. Uscire da VirtualBox
  3. 3. Copiare la cartella VM nella nuova posizione
  4. 4. Riavviare VirtualBox e cancellare la vecchia VM.
  5. Andare al menu della macchina ≥ Aggiungi e navigare nella vecchia cartella.

Ecco!

ps: Ho VirtualBox 4.3.20 su OSX 10.10

Vedi questo post del forum di VirtualBox per maggiori dettagli.

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

La mia opzione preferita è anche l'opzione 2:

  1. Copiare l'intera cartella VM, contenente i file .vdi e .vbox.

Ma a volte si verifica un disallineamento UUID. Spesso questo accade se si copia l'immagine del disco VDI di una macchina in un'altra macchina, ma io l'ho fatto accadere anche durante le copie rettilinee di directory complete.

Quindi, se questo è il messaggio che si ottiene dopo aver spostato la macchina virtuale e aver provato ad avviarla nel nuovo setup:

Fallito l'apertura del disco fisso .

Impossibile registrare l'hard disk perché esiste già un hard disk con UUID.

Basta andare nella directory della macchina virtuale; naturalmente cambiare il percorso effettivo per corrispondere al percorso effettivo in cui si sta andando:

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

Ed eseguire questo comando per assegnare al disco un nuovo UUID:

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

Nel caso in cui qualcun altro stia cercando una risposta a questo, ho spostato con successo 5 Virtual Box VMs VMs in un altro Win7 installato su un nuovo disco rigido sulla stessa macchina (essenzialmente uno spostamento da un sistema operativo ospite ad un altro sullo stesso PC). Mi rendo conto che i driver su una macchina completamente nuova probabilmente variano e potenzialmente hanno un effetto negativo sul trasferimento, ma ho documentato il processo qui sotto nella speranza che possa aiutare qualcuno.

  • Non c'era l'obbligo di clonare le VM o di alterare il file xml. La versione VB era abbastanza attuale: 4.3.12r93773.
  • Nuove copie delle VM sono state create in una nuova cartella/un'unità condivisa per mantenere intatte le VM esistenti/vecchie. Posso ancora avviare dal vecchio disco rigido che ho conservato per la ridondanza/risoluzione delle emissioni fino a quando non sono soddisfatto della mia nuova configurazione; così posso accedere alle vecchie VM nel loro stato precedente, se necessario.
  • Le lettere del drive variano/non possono essere necessarie a seconda della configurazione.

On Old Win7 Host:

  1. Assicuratevi che tutte le VM siano spente.

Su un nuovo Win7 Host:

  1. 1. Creare una nuova cartella chiamata X:\NewVMs \VirtualBox VMs (da Nuova macchina Win7 per garantire i permessi OK)
  2. 2. Copiare/incollare (non trascinare) tutte le VM e il relativo contenuto della cartella dalla vecchia cartella a questa cartella (utilizza i nuovi permessi)
  3. Creare una nuova cartella chiamata X:\NewVMs\VirtualBox VMs […] 4. Cancellare la cartella .virtualbox e tutti i contenuti (se esistente)
  4. RIBOOT per confermare che non ci siano più file di programma o voci di registro rimanenti (se si disinstalla il vecchio VirtualBox)
  5. Installare/Rinstallare VirtualBox (assicurarsi di utilizzare la stessa versione di VirtualBox su cui sono state create le VM su un vecchio host/macchina (nel mio caso ver. 4.3.12r93773)) IMPORTANTE: (non selezionare la casella da spuntare per aprire/eseguire VirtualBox alla fine dell'installazione)
  6. Copiare/incollare (non trascinare) la cartella .virtualbox e il contenuto del vecchio host Win7 (di solito C:\ \Users[nome utente].VirtualBox
  7. Installare/ reinstallare VirtualBox (assicurarsi di utilizzare la stessa versione di VirtualBox su cui sono state create le VM su un vecchio host/macchina (nel mio caso ver. 4.3.12r93773))). Ora aprire VirtualBox
  8. 9. Impostare le preferenze per la nuova cartella di creazione delle macchine virtuali di default sullo stesso percorso del file della cartella delle macchine virtuali VirtualBox appena creata: X:\NewVMs\VirtualBox VMs
  9. Stato di prova delle VMs

Buona fortuna.

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

Per il caso speciale in cui:

  • avete solo una singola VM (o volete spostare tutte le vostre VM),
  • e l'host è lo stesso hardware con la stessa versione del sistema operativo (o reinstallare lo stesso sistema operativo sulla stessa macchina)

Se siete in questo caso, allora le cose sono facili:

  1. 1. Spegnete VirtualBox su entrambi gli host.
  2. 2. Copiare le cartelle .config/VirtualBox e VirtualBox VMs dall'host sorgente. 3. Copiare queste cartelle sull'host di destinazione.
  3. 5. Avviare VirtualBox sull'host di destinazione
1
1
1
2018-06-28 21:44:12 +0000

The 4th Way

In VirtualBOX:

  1. 1. Spegnere il VM
  2. 2. Cliccare con il tasto destro del mouse e rimuovere la VM (non cancellare i file)
  3. 3. Andare su file>Virtual Media Manager e rimuovere il .vdi
  4. Premere il tasto destro del mouse. 4. Andare su File>Preferenze>Generale e impostare la cartella predefinita della macchina sulla nuova posizione
  5. Creare una nuova VM utilizzare la modalità esperto per creare la VM senza disco fisso

In File Explorer:

  1. Spegnere la VM
  2. Fare clic con il tasto destro del mouse e rimuovere la VM (non cancellare i file). 1. Individuare il file .vdi e copiarlo
  3. 2. Andare nella nuova cartella della macchina predefinita, all'interno di

sarà presente una cartella VM 3. 3. Incollare il file .vdi nella nuova cartella VM

Back In VirtualBOX:

  1. Selezionare il file .vdi nella nuova cartella VM. 1. Cliccare con il tasto destro del mouse sulla VM e aprire le impostazioni
  2. 3. Andare a Storage>Controller: SATA e aggiungere un disco fisso, fare clic su scegli un disco esistente 11.scegliere il file .vdi nella nuova cartella VM

Nota: Se il metodo 2 interrompe l'installazione di VirtualBOX andare su C:\ \ \ \ Utenti \ \ VirtualBox e cancellare VirtualBox.xml e rinominare VirtualBox.xml-prev in VirtualBox.xml

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

Ho usato anche il metodo 2 per spostare la mia macchina virtuale e non ho dovuto apportare alcuna modifica a nessun file XML, ma ho ottenuto un paio di errori con USB e condivisione di file e qui di seguito è come li ho corretti insieme al processo:

    1. Copiare la macchina virtuale dal vecchio al nuovo pc. I file della macchina virtuale sono diversi dalla macchina virtuale Oracle. Questi file sono tipicamente a _c:\ \ \ \VirtualBox VMs_. Ho preso l'intera parte _VirtualBox VMs _ e l'ho copiata in una posizione simile sul nuovo PC. Questo copia tutte le macchine virtuali che avevo sul PC originale.
    1. Ora sul nuovo PC, eseguire il box virtuale e andare a Menu > Macchina > Aggiungi e selezionare il file .vbox dalla cartella copiata. Questo è tutto.
  1. Ora quando eseguo la macchina virtuale su un nuovo PC, ho ricevuto un errore durante l'avvio:

  1. Non so perché il controller USB non funzionava perché lo stesso funzionava sul computer originale. Sono andato avanti e ho installato VirtualBox Extension Pack

  2. Questa installazione è stata un po’ strana perché il download dell'installazione non era un file eseguibile. Ho cliccato su Oracle_VM_VirtualBox_Extension_Pack-5.1.4-110228.vbox-extpack e ho selezionato ‘Seleziona un programma da una lista di programmi installati’ e poi ho selezionato Oracel virtualbox e ha installato l'estensione. Questo ha risolto il problema, ma un'altra soluzione meno desiderabile è che si può disattivare l'usb.

  3. Se avevate cartelle condivise nella VM originale, potrebbero essere diverse e si otterrà un errore. Esaminate quelle in Impostazioni >>> Cartella condivisa e cancellate quelle che sono rotte. Un messaggio di errore apparirà come

.

È tutto.

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

zar, prima di tutto… non spostare mai e poi mai una macchina che è in stato di salvataggio, prima di spostare è necessario spegnere l'ospite, non solo salvare lo stato.

Assicuratevi anche di utilizzare la stessa versione di VirtualBOX su entrambi gli host, ma non solo la versione VirtualBOX, anche la versione del pacchetto di estensione vesion… o almeno il nuovo host hanno una versione più alta, ma mai una versione più bassa su uno qualsiasi dei due.

E infine, l'ho imparato a fatica, cancellare la configurazione delle cartelle condivise su VirtualBOX prima di spostare la macchina, e poi ricrearla in modo corretto… molto importante quando gli host sono sistemi operativi diversi (host Windows / Linux).

E come nota a margine… i allways, allways use inmutable hard disk VDI files for OS as well as for data VDIs (in questo modo lo stesso DATA VDI può essere usato per più di un ospite), trucco speciale per il pagefile 4GiB. sys

Quest'ultima parte, riutilizzare un file VDI inmutabile rende le cose un po’ più difficili, VirtualBOX ha un BIG BUG.

Per vedere il Bug in azione:

  • Creare un VDI inmutabile (come quello che uso per pagefile.sys)
  • Creare due o tre VM su VirtualBOX
  • Spostare uno di loro in cima alla lista (solo per evitare di danneggiarne uno qualsiasi dei vostri)
  • Fare il backup del . vbox di ciascuna delle macchine che avete creato (per confrontarle dopo il BUG)
  • Allegare quel VDI inmutabile a più di una di quelle macchine (tranne quella in cima alla lista)
  • Ora vedete il .vbox della macchina che è in cima alla lista

Quella macchina è stata modificata, ha riferimenti alle altre macchine inmutabili VDI.

Quindi il BUG è: Modificare una macchina aggiungendo una VDI inmutabile che è usata da un'altra macchina influisce sulla macchina in cima alla lista.

Perché diavolo riutilizzo la stessa 4GiB VDI su tutte le macchine Windows? Facile, è un disco MBR con una partizione FAT32 dove ho messo pagefile.sys, dato che è inmutabile tutte le macchine virtuali creeranno un file nella loro cartella snapshot dove memorizzano le modifiche, e che si perdono al prossimo avvio, quindi non ho bisogno di 4GiB per ogni guest memorizzato sul disco host, solo un… In questo modo risparmio molto GiB, dato che ho più di 20 finestre diverse per testare le applicazioni che sviluppo per le mie, tutte le combinazioni di (XP, Vista, 7, 8, 8, 8.1, 10)*(32Bits, 64Bits) * (così come alla prima installazione, dopo ogni ServicePack, dopo l'aggiornamento completo delle finestre), ottengo molti, moltissimi guest… così su tutti condivido il 4GiB VDI inmutabile per la ram virtuale (pagefile.sys).

E se lasciate che il BUG vada oltre, provate a spostare una di queste macchine su un altro host VirtualBOX (ricordate che sono solo macchine virtuali con una configurazione su di esse e nessun guest ancora installato su di esse), vedrete che VirtualBox non vi permette di aggiungerle in quanto mancano alcuni VDI (è FALSO e VERO, è che tale prima macchina contiene i riferimenti a tali VDI insteediati di essere sulla macchina corretta).

Ora confrontate il . VBOX di tutti i file VBOX con i precedenti BackUp… notate come uno è stato modificato in modo errato?…. sì, è quello in cima alla lista.

Bene, questo BUG è stato informato a VirtualBOX alcuni anni fa, non possono ancora aggiustarlo… e sta causando molti, molti problemi.

Inoltre, se spostate quello in alto sulle macchine virtuali in una posizione più bassa, chiudete VirtualBox e rilanciatelo… vi dirà che alcune macchine sono danneggiate e non possono essere avviate… sì, la prima della lista deve essere trattata in modo diverso se non si vogliono avere molti problemi.

È un BUG veramente brutto che mi ci sono voluti molti giorni per scoprirlo (alcuni anni fa) l'ho imparato nel modo più difficile!

L'avevo superata avendo una macchina che avevo chiamato:

  • Common Inmutable Disks

Ha una configurazione vuota e una sola VDI, sì, hai ragione, hai indovinato, la VDI inmutabile che condivido per tutte le altre macchine virtuali.

Bene, quando apro il file .VBOX vedo al suo interno molte righe sulla sezione <MediaRegistry> <HardDisks>, una per ogni macchina dove uso quel VDI inmutabile… proprio come un campione (rimuovo i dati privati):

<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>
``` &001 


Pretty BUG, non risolto da anni. 


Bene, per spostare tali macchine... è necessario modificare manualmente il . VBOX, per mettere tutti i riferimenti di tali dischi sul nuovo host sulla prima macchina (quella che si trova in cima alla lista) prima di aggiungere i file .VBOX alla lista, così quando li si aggiunge VirtualBOX ha i riferimenti ai VDI mancanti (mancanti causati dal grande BUG). 

La cosa si verifica perché ogni volta che si collega un VDI che viene utilizzato su un'altra macchina VirtualBOX aggiorna due macchine . VBOX files (quello che appartiene alla macchina che si sta utilizzando) e al primo della lista. 

Non sono del tutto sicuro di cosa succederebbe se nella lista, il primo non ha un VDI così comune allegato ad esso... meglio non provarlo, visto quello che vedo. 

Quindi migrare ad un altro HOST è molto più complicato di quello che sembra essere a causa di una pessima implementazione su file .VBOXstruttura interna e a causa di BUG veramente grandi quando VirtualBOX li modifica. 


Fallimenti: 


- Struttura interna (XML) dipende dall'HOST (Windows o Linux) 
- Modifica una macchina può alterarne un'altra, non solo quella modificata 
- ... che altro ? 


Bisogno di più... i allways migrare macchine facendo questo (e non ha avuto problemi, mai e poi mai): 


1. 1. Prendere nota dell'elenco di tutte le macchine (ordine, raggruppamento, ecc.) 
2. 2. Prendere nota del primo della lista (tutta la sua configurazione) 
3. Prendere nota del primo della lista (tutta la sua configurazione) 
3. Prendere nota di tutte le proprietà delle macchine che voglio spostare in un altro host 
4. Prendere nota di tutte le proprietà delle macchine che voglio spostare in un altro host 
4. Copiare i file .vbox come file .txt (quello in cima alla lista + tutte le macchine che voglio migrare) 
5. Ricreare tutte le macchine (e averne una speciale in cima alla lista) all'interno di VirtualBox su nuovo host 
6. 6. Chiudere VirtualBox su nuovo host 
7. Diff confrontare il vecchio .txt con i nuovi file .vbox e copiare da .txt a .vbox alcune parti in modo umano, non solo Copia&Incolla 
8. 8. Aprire VirtualBox e allegare tutti i VDI nell'ordine corretto 
9. 9. Chiudere nuovamente VirtualBox sul nuovo host 
10. Diff confrontare il vecchio .txt con i nuovi file .vbox e 'correggere' da .txt a .vbox alcune parti in modo umano, non solo Copy&Paste 


Tutto il resto (cartella snapshot e file VDI) li copio nel modo normale (File System Copy&Paste). 


Tutto questo duro lavoro manuale è causato dal Big BUG VirtualBox: Modifica / altera una macchina non modificata quando si allega un VDI inmutabile che viene usato su più di una macchina, altrimenti sarebbe sufficiente un semplice Copy&Paste del file .VBOX (dopo aver fissato i percorsi delle cartelle condivise, ecc.).
-2
-2
-2
2017-04-27 23:51:57 +0000

Copiare la cartella contenente la macchina a destinazione, quindi dal menu: “Macchina” —> “Aggiungi”, e poi scegliere il file vbox, NON il file vdi. Per me tutto questo è andato a buon fine. Non so se sono stato fortunato, o se deve funzionare in questo modo.