Bravo pour vos recherches. J'utilise régulièrement les trois options.

1. (Utilisez l'utilitaire “Import/Export”)_. C'est le plus simple car il combine toute la VM en un seul fichier et le transfère sans problème à peu près à chaque fois. Cependant, d'après mon expérience, lors de la création du fichier OVA ou OVF pour l'exportation, il jette tous les instantanés et, s'il est mal fait, peut donner lieu à un fichier VMDK. Lorsque vous réimportez la VM, vous devriez pouvoir choisir le type de fichier de disque dur que vous voulez créer, VDI ou VMDK.

2. (Copiez l'intégralité du dossier de la machine virtuelle, contenant les fichiers .vdi et .vbox)_. C'est l'option que je préfère et bien que j'aie dû modifier le fichier XML à plusieurs reprises, c'est ma propre faute si j'ai raté quelque chose. Assurez-vous que lorsque vous copiez la VM, vous obtenez TOUS les fichiers qui lui sont associés. Les problèmes que j'ai rencontrés étaient que certains instantanés et fichiers VDI secondaires se trouvaient dans le mauvais répertoire et n'étaient pas copiés correctement. Si vous copiez tous les fichiers (et les autorisations), vous ne devriez avoir aucun problème.

3. (Clonez la VDI en utilisant “Virtual Media Manager” puis recréez une VM sur la machine cible mais en utilisant la VDI clonée comme disque dur)._ Ceci est moins souhaitable car vous avez alors 2 copies d'une VM, et cela peut causer des problèmes de licence, de réseau, etc, selon la façon dont vous clonez le fichier VDI.

En résumé, je recommande vivement l'option 2, assurez-vous simplement d'obtenir tous les fichiers nécessaires lorsque vous le déplacez.

La méthode 2 fonctionne bien maintenant (avec VirtualBox 4.0 et plus), sans qu'aucune modification XML ne soit nécessaire :

1. Arrêtez votre machine virtuelle
2. Quittez VirtualBox
3. Copiez le dossier VM au nouvel emplacement
4. Redémarrez VirtualBox, et supprimez l'ancienne VM.
5. Allez dans le menu Machine ≥ Ajoutez et naviguez dans votre ancien dossier.

C'est tout !

ps : J'ai VirtualBox 4.3.20 sur OSX 10.10

Voir ce post du forum VirtualBox pour plus de détails.

L'option que je préfère est également l'option 2 :

1. Copiez tout le dossier VM, contenant les fichiers .vdi et .vbox.

Mais il arrive parfois qu'un décalage d'UUID se produise. Cela se produit souvent si vous copiez simplement l'image disque VDI d'une machine dans une autre machine, mais je l'ai déjà vu se produire lors de copies directes de répertoires complets également.

Donc, si c'est le message que vous obtenez après avoir déplacé la machine virtuelle et essayé de la démarrer dans la nouvelle configuration :

Echec de l'ouverture du disque dur .

Impossible d'enregistrer le disque dur parce qu'un disque dur avec UUID existe déjà.

Allez simplement dans le répertoire de votre machine virtuelle ; bien sûr, changez le chemin d'accès réel pour qu'il corresponde à celui dans lequel vous allez :

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

Et exécutez cette commande pour attribuer au disque un nouvel UUID :

VBoxManage internalcommands sethduuid Sandbox.vdi

Au cas où quelqu'un d'autre chercherait une réponse à cette question, j'ai réussi à déplacer 5 Virtual Box VMs vers une autre installation Win7 sur un nouveau disque dur de la même machine (essentiellement un déplacement d'un OS invité vers un autre sur le même PC). Je réalise que les pilotes d'une toute nouvelle machine varieraient probablement et auraient potentiellement un effet négatif sur le déménagement, mais j'ai documenté le processus ci-dessous dans l'espoir qu'il puisse aider quelqu'un.

• Il n'était pas nécessaire de cloner les VM ou de modifier le fichier xml. La version VB était assez récente : 4.3.12r93773.
• Les nouvelles copies de VM étaient créées dans un nouveau dossier/lecteur partagé pour conserver les VM existantes/anciennes intactes. Je peux toujours démarrer à partir de l'ancien disque dur que j'ai conservé pour la redondance/résolution des problèmes jusqu'à ce que je sois satisfait de ma nouvelle configuration ; je peux donc accéder aux anciennes VM dans leur ancien état si nécessaire.
• Les lettres du lecteur varient/peuvent ne pas être nécessaires selon votre configuration.

Sur l'ancien hôte Win7 :

1. Assurez-vous que toutes les VM sont éteintes.

Sur le nouvel hôte Win7 :

1. Créer un nouveau dossier appelé X:\NewVMs\VirtualBox VMs (à partir de la nouvelle machine Win7 pour s'assurer que les permissions sont OK)
2. Copier/coller (ne pas faire glisser) toutes les VM et le contenu du dossier correspondant de l'ancien dossier vers ce dossier (utilise les nouvelles permissions)
3. Désinstaller VirtualBox (si installé)
4. Supprimer le dossier .virtualbox et tout son contenu (si existant)
5. REBOUT pour confirmer qu'il ne reste plus de fichiers de programme ou d'entrées de registre (si vous désinstallez l'ancien VirtualBox)
6. Installer/Réinstaller VirtualBox (assurez-vous que vous utilisez la même version que celle de VirtualBox sur laquelle les VM ont été créées sur l'ancien hôte/machine (dans mon cas, ver. 4.3.12r93773)) IMPORTANT : (Ne pas cocher la case pour ouvrir/exécuter VirtualBox à la fin de l'installation)
7. Copier/coller (ne pas faire glisser) le dossier .virtualbox et son contenu à partir de l'ancien hôte Win7 (généralement C:\Users [nom d'utilisateur].VirtualBox
8. Ouvrez maintenant VirtualBox
9. Définissez les préférences pour le nouveau dossier de création des VM par défaut sur le même chemin d'accès que le dossier des VM VirtualBox nouvellement créé : X:\NewVMs\VirtualBox VMs
10. Testez le statut des VMs

Bonne chance.

Pour le cas particulier où :

• vous n'avez qu'une unique VM (ou vous voulez déplacer toutes vos VM),
• et l'hôte est le même matériel avec la même version d'OS (ou vous réinstallez le même OS sur la même machine)

Si vous êtes dans ce cas, alors les choses sont faciles :

1. Fermez VirtualBox sur les deux hôtes.
2. Copier les dossiers .config/VirtualBox et VirtualBox VMs de l'hôte source.
3. Copier ces dossiers sur l'hôte de destination.
4. Démarrer VirtualBox sur l'hôte de destination

The 4th Way

Dans VirtualBOX :

1. Eteignez la VM
2. Cliquez avec le bouton droit de la souris et supprimez la VM (ne supprimez pas les fichiers)
3. Allez dans le fichier >>Virtual Media Manager et supprimez le .vdi
4. Aller dans Fichier>Préférences>Général et définir le dossier de la machine par défaut au nouvel emplacement
5. Créer une nouvelle VM utiliser le mode expert pour créer la VM sans disque dur

Dans l'explorateur de fichiers :

1. Localisez le fichier .vdi et copiez-le
2. Allez dans le nouveau dossier de la machine par défaut, il y aura un dossier VM à l'intérieur de
3. Collez le fichier .vdi dans le nouveau dossier VM

Dans VirtualBOX :

1. Cliquez avec le bouton droit de la souris sur la VM et ouvrez les paramètres
2. Allez dans le dossier Storage>Controller : SATA et ajoutez un disque dur, cliquez sur choisir un disque existant 11.choisissez le fichier .vdi dans le nouveau dossier VM

Note: Si la méthode 2 interrompt votre installation de VirtualBOX, allez dans C:\Users.VirtualBox et supprimez VirtualBox.xml et renommez VirtualBox.xml-prev en VirtualBox.xml

J'ai également utilisé la méthode 2 pour déplacer ma machine virtuelle et je n'ai pas eu à modifier de fichier XML, mais j'ai eu quelques erreurs avec l'USB et le partage de fichiers et voici comment je les ai corrigées en même temps que le processus :

1. Copiez la machine virtuelle de l'ancien PC vers le nouveau. Les fichiers de la machine virtuelle sont différents de la machine virtuelle Oracle elle-même. Ces fichiers se trouvent généralement à _c:\users\NVirtualBox VMs_. J'ai pris la partie _VirtualBox VMs_ entière et l'ai copiée à un emplacement similaire sur le nouveau PC. Cela copie toutes les machines virtuelles que j'avais sur le PC d'origine.

2. Maintenant, sur le nouveau PC, lancez la VirtualBox et allez dans le menu > Machine > Ajouter et sélectionnez le fichier .vbox dans le dossier copié. C'est tout.

3. Maintenant, lorsque j'exécute la machine virtuelle sur un nouveau PC, j'ai une erreur au démarrage :

1. Je ne sais pas pourquoi le contrôleur USB ne fonctionnait pas parce qu'il fonctionnait sur l'ordinateur d'origine. Je suis allé de l'avant et j'ai installé VirtualBox Extension Pack

2. Cette installation était un peu bizarre car le téléchargement de l'installation n'était pas un fichier exécutable. J'ai cliqué sur Oracle_VM_VirtualBox_Extension_Pack-5.1.4-110228.vbox-extpack et j'ai sélectionné “Select a program from a list of Installed programs” puis j'ai sélectionné Oracel virtualbox et l'extension a été installée. Cela a réglé le problème, mais une autre solution moins souhaitable est de désactiver l'usb.

3. Si vous aviez des dossiers partagés dans la VM d'origine, ils peuvent être différents et vous obtiendrez une erreur. Passez en revue ceux qui se trouvent dans les paramètres >> Dossier partagé et supprimez ceux qui sont cassés. Un message d'erreur ressemblera à

C'est tout.

zar, première chose à faire… ne jamais déplacer une machine qui est en état sauvegardé, avant de la déplacer vous devez éteindre l'invité, pas seulement sauvegarder l'état.

Assurez-vous également que vous utilisez la même version de VirtualBOX sur les deux hôtes, mais pas seulement la version de VirtualBOX, également la vesion du pack d'extension… ou au moins le nouvel hôte a une version supérieure, mais jamais une version inférieure sur aucun des deux.

Et enfin, je l'ai appris à la dure, supprimer la configuration du dossier SHARED sur VirtualBOX avant de déplacer la machine, puis la recréer correctement… très important lorsque les hôtes sont différents (hôtes Windows / Linux).

Et juste pour info… j'utilise toujours des fichiers VDI de disque dur inmuables pour les OS ainsi que pour les VDI de données (de cette façon la même VDI de données peut être utilisée pour plus qu'un invité), spécialement pour le fichier de page 4GiB. sys

Cette dernière partie, la réutilisation d'un fichier VDI inmuable rend les choses un peu plus difficiles, VirtualBOX a un GRAND BUG.

Pour voir le Bug en action :

• Créer une VDI inmutable (comme celle que j'utilise pour pagefile.sys)
• Créer deux ou trois VM sur VirtualBOX
• Déplacer l'une d'entre elles en haut de la liste (juste pour éviter d'endommager l'une des vôtres)
• Sauvegarder le fichier . vbox de chacune des machines que vous avez créées (pour les comparer après le BUG)
• Attacher cette VDI inmutable à plus d'une de ces machines (sauf celle en haut de la liste)
• Voir maintenant le .vbox de la machine qui est en haut de la liste

Cette machine a été éditée, elle a des références aux autres machines VDI inmutables.

Donc le BUG est : Modifier une machine en ajoutant une VDI inmutable qui est utilisée par une autre affecte la machine en haut de la liste

Pourquoi diable je réutilise la même VDI 4GiB sur toutes les machines Windows ? Facile, c'est un disque MBR avec une partition FAT32 où je mets pagefile.sys, puisqu'il est inmuable toutes les machines virtuelles vont créer un fichier sur leur dossier de snapshot où elles stockent les modifications, et qui se perdent au prochain démarrage, donc je n'ai pas besoin de 4GiB pour chaque invité stocké sur le disque hôte, juste un seul… De cette façon, j'économise beaucoup de GiB puisque j'ai plus de 20 fenêtres différentes pour tester les applications que je développe pour moi, toutes combinaisons de (XP, Vista, 7, 8, 8.1, 10)*(32Bits, 64Bits) * (Comme à la première installation, après chaque ServicePack, après la mise à jour complète de Windows), j'ai beaucoup, beaucoup d'invités… donc sur tous je partage l'inmuable VDI 4GiB pour la RAM virtuelle (pagefile.sys). Et si vous laissez le BUG aller plus loin, essayez de déplacer une de ces machines vers un autre hôte VirtualBOX (rappelez-vous que ce sont seulement des machines virtuelles avec une configuration sur elles et aucun invité encore installé sur elles), vous verrez que VirtualBox ne vous permet pas de les ajouter puisque certaines VDIs sont manquantes (c'est FAUX et VRAI, c'est que cette première machine contient les références à de telles VDIs insérée d'être sur la bonne machine). VBOX de tous ces fichiers avec les BackUp précédents… notez comment on se trompe de modification ?… oui, c'est celui qui est en haut de la liste.

Eh bien, ce BUG a été informé à VirtualBOX il y a quelques années, ils ne peuvent toujours pas le réparer… et il cause beaucoup, beaucoup de problèmes.

De plus, si vous déplacez celui du haut sur les machines virtuelles vers une position plus basse, fermez VirtualBox et relancez-le… vous verrez que certaines machines sont endommagées et ne peuvent pas être démarrées… oui le premier de la liste doit être traité différemment si vous ne voulez pas avoir beaucoup de problèmes.

C'est un très mauvais BUG qui m'a pris beaucoup de jours à découvrird (il y a quelques années) je l'apprends à la dure ! Je l'ai surmonté en ayant une machine que j'avais appelée :

• Common Inmutable Disks

Elle a une configuration vide et une seule VDI, oui, vous avez raison, vous l'avez deviné, la VDI inmuable que je partage pour toutes les autres machines virtuelles.

Eh bien quand j'ouvre le fichier .VBOX je vois à l'intérieur beaucoup de lignes sur la section <MediaRegistry> <HardDisks>, une par machine où j'utilise cette VDI inmutable… juste à titre d'exemple (j'enlève les données privées) :

<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, non résolu depuis des années.

Eh bien, pour déplacer de telles machines… il faut éditer manuellement le fichier . VBOX, afin de placer toutes les références de ces disques sur le nouvel hôte de la première machine (celle qui est en haut de la liste) avant d'ajouter les fichiers .VBOX à la liste, de sorte que lorsque vous les ajoutez, VirtualBOX a les références des VDI manquantes (manquantes à cause du gros BUG).

Le problème se produit parce que chaque fois que vous connectez une VDI qui est utilisée sur une autre machine, VirtualBOX met à jour deux machines . VBOX (celle qui appartient à la machine que vous utilisez) et à la première de la liste.

Je ne suis pas totalement sûr de ce qui se passerait si, dans la liste, la première n'avait pas de VDI aussi commune… mieux vaut ne pas essayer, vu ce que je vois.

Donc la migration vers un autre HOST est beaucoup plus compliquée que ce qu'elle semble être à cause d'une très mauvaise implémentation sur les fichiers .VBOXstructure interne et à cause de très gros BUGs lorsque VirtualBOX les édite.

Echecs :

• La structure interne (XML) dépend de l'HOST (Windows ou Linux)
• Editer une machine peut en modifier une autre, pas seulement celle qui est éditée
• … quoi d'autre ?

Besoin de plus… je migre toujours les machines en faisant cela (et je n'ai jamais eu de problème, jamais) :

1. Prendre note de la liste de toutes les machines (ordre, regroupement, etc)
2. Prenez note de la première de la liste (toute sa configuration)
3. Prendre note de toutes les propriétés des machines que je veux déplacer vers un autre hôte
4. Copier les fichiers .vbox en fichiers .txt (celui du haut de la liste + toutes les machines que je veux migrer)
5. Recréer toutes les machines (et en avoir une spéciale en haut de la liste) dans VirtualBox sur un nouvel hôte
6. Fermer VirtualBox sur le nouvel hôte
7. Différer comparer l'ancien .txt avec les nouveaux fichiers .vbox et copier de .txt à .vbox certaines parties de manière humaine, pas seulement copier-coller
8. Ouvrir VirtualBox et joindre toutes les VDI dans le bon ordre
9. Une fois de plus, fermer VirtualBox sur le nouvel hôte
10. Diff comparer l'ancien .txt avec les nouveaux fichiers .vbox et “réparer” de .txt à .vbox certaines parties de manière humaine, pas seulement par copier-coller

Tout le reste (dossier des instantanés et fichiers VDI), je les copie de la manière normale (Copier-coller du système de fichiers)

Tout ce travail manuel difficile est causé par le Big BUG VirtualBox : Il édite / modifie une machine non modifiée lorsque vous joignez une VDI inmuable utilisée sur plus d'une machine, sinon un simple copier-coller du fichier .VBOX suffirait (après avoir fixé les chemins des dossiers partagés, etc).

Copiez le dossier contenant la machine à destination, puis dans le menu : “Machine” —> “Ajouter”, puis choisissez le fichier vbox, et NON le fichier vdi. Pour moi, cela s'est passé sans problème. Je ne sais pas si j'ai eu de la chance, ou si c'est censé fonctionner ainsi.