zar, la première chose à faire en premier ... ne déplacez jamais une machine qui est dans l'état enregistré. Avant de déplacer, vous devez arrêter l'invité, pas seulement enregistrer 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, mais également la version du pack d'extension ... ou tout au moins, le nouvel hôte possède une version supérieure, mais jamais une version inférieure sur l'un des deux.
Et enfin, je l'ai appris à la dure, supprimez la configuration du dossier SHARED sur VirtualBOX avant de déplacer la machine, puis recréez-la de manière correcte ... très important lorsque l'hôte utilise un système d'exploitation différent (hôtes Windows / Linux).
Et juste comme note de côté ... i toujours, toujours utiliser des fichiers VDI de disque durs immuables pour OS ainsi que pour les VDI de données (de cette façon, le même DATA VDI peut être utilisé pour plus que l'invité), une astuce spéciale pour 4GiB pagefile.sys
Cette dernière partie, réutiliser un fichier VDI immuable rend les choses un peu plus difficiles, VirtualBOX a un BIG BUG.
Pour voir le bogue en action:
- Créez un VDI immuable (comme celui que j'utilise pour pagefile.sys)
- Créer deux ou trois ordinateurs virtuels sur VirtualBOX
- Déplacez l'un d'eux en haut de la liste (juste pour ne pas vous abîmer)
- Sauvegardez les fichiers .vbox de chacune des machines que vous avez créées (pour les comparer après l'apparition du bogue)
- Attachez ce VDI immuable à plus d'une de ces machines (sauf celle située en haut de la liste)
- Maintenant, voyez la .vbox de la machine qui se trouve en haut de la liste
Cette machine a été modifiée, elle contient des références aux autres machines inaltérables VDI.
Le bogue est donc le suivant: L'édition d'une machine en ajoutant un VDI immuable qui est utilisé par une autre affecte la machine en haut de la liste.
Pourquoi diable ai-je réutiliser le 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 immuable, toutes les machines virtuelles créeront un fichier dans leur dossier de capture instantanée dans lequel elles stockeront les modifications, et qui seront perdues lors du prochain démarrage. pas besoin de 4GiB pour chaque invité stocké sur le disque hôte, juste un ... de cette façon, j’économise beaucoup de GiB puisque j’ai plus de 20 fenêtres différentes pour tester des applications que je développe pour moi-même, toutes combinaisons de (XP, Vista) , 7, 8, 8.1, 10) * (32Bits, 64Bits) * (comme lors de la première installation, après chaque ServicePack, après la mise à jour complète de Windows), je reçois beaucoup, beaucoup d’invités ... ainsi de suite. Je partage l'inégalable VDI 4GiB pour le ram virtuel (pagefile.sys).
Et si vous laissez le bogue aller plus loin, essayez de déplacer l’une de ces machines vers un autre hôte VirtualBOX (rappelez-vous qu’il ne s’agit que de machines virtuelles avec une configuration et qu’aucun invité n’y est encore installé), vous verrez que VirtualBox ne vous laisse pas ajoutez-les puisque certains VDI sont manquants (c'est FALSE et TRUE, c'est qu'une telle première machine contient les références à de tels VDI au lieu d'être sur la bonne machine).
Maintenant, comparez les fichiers .VBOX de tous les fichiers avec previos BackUp ... remarquez comment un fichier est mal modifié? ... oui, c’est celui qui se trouve en haut de la liste.
Eh bien, ce BUG a été informé sur VirtualBOX il y a quelques années, ils ne peuvent toujours pas le réparer ... et cela cause beaucoup, beaucoup de problèmes.
De plus, si vous déplacez le premier des machines virtuelles vers le bas, fermez VirtualBox et relancez-le ... vous dira que certaines machines sont endommagées et ne peuvent pas être démarrées ... oui, le premier de la liste. doit être traité sous une forme différente 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écouvrir (il y a quelques années), je l'apprends à la dure!
Je l'avais surmonté en ayant une machine que j'avais appelée:
Il a une configuration vide et un seul VDI, oui, vous avez raison, vous l'avez deviné, le partage immuable de VDI i pour toutes les autres machines virtuelles.
Eh bien, quand j’ouvre le fichier .VBOX, j’aperçois à l’intérieur de nombreuses lignes de la <MediaRegistry>
<HardDisks>
section, une pour chaque machine sur laquelle j’utilise ce VDI immuable ... juste à titre d’échantillon (j’élimine 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>
Joli bug, pas résolu depuis des années.
Eh bien, pour déplacer de telles machines ... vous devez éditer manuellement les fichiers .VBOX, pour mettre toutes ces références de disques sur le nouvel hôte sur la première machine (celle qui se trouve en haut de la liste) avant d'ajouter le fichier .VBOX. fichiers dans la liste, donc lors de leur ajout, VirtualBOX a les références aux VDI manquants (manquants à cause du gros bogue).
Le problème se produit car chaque fois que vous connectez un VDI utilisé sur un autre ordinateur, VirtualBOX met à jour deux fichiers .VBOX d’ordinateur (celui qui appartient à l’ordinateur que vous utilisez) et au premier de la liste.
Je ne suis pas tout à fait sûr de ce qui se produira lorsque sur la liste, le premier ne comporte pas de VDI commun, mais mieux vaut ne pas l'essayer, vu ce que je vois.
La migration vers un autre hôte est donc beaucoup plus compliquée que ce qu’il semble être du fait d’une très mauvaise implémentation sur la structure interne des fichiers .VBOX et à cause de très gros BUGs lorsque VirtualBOX les édite.
Échoue:
- La structure interne (XML) dépend de l'hôte (Windows ou Linux)
- Modifier une machine peut en modifier une autre, pas seulement celle en cours de modification
- ... quoi de plus ?
Besoin de plus ... je migre toujours les machines en faisant cela (et je n'ai eu aucun problème, jamais jamais):
- Prenez note de la liste de toutes les machines (commande, regroupement, etc.)
- Prendre note du premier sur la liste (toute sa configuration)
- Prenez note de toutes les propriétés des machines que je souhaite déplacer vers un autre hôte.
- Copiez les fichiers .vbox en tant que fichiers .txt (celui situé en haut de la liste + toutes les machines que je souhaite migrer)
- Recréez toutes les machines (et en avez une spéciale en haut de la liste) dans VirtualBox sur le nouvel hôte
- Fermer VirtualBox sur le nouvel hôte
- Diff compare l'ancien .txt avec les nouveaux fichiers .vbox et copie de .txt vers .vbox certaines parties de manière humaine, pas seulement copier-coller
- Ouvrez VirtualBox et attachez tous les VDI dans le bon ordre
- Encore une fois, fermez VirtualBox sur le nouvel hôte
- Diff compare l'ancien .txt avec les nouveaux fichiers .vbox et "corrige" de .txt à .vbox certaines parties de manière humaine, pas seulement copier-coller
Tout le reste (dossier des instantanés et fichiers VDI), je les copie normalement (système de fichiers copier et coller).
Tout ce travail manuel pénible est causé par la Big BUG VirtualBox: elle édite / modifie une machine qui n’a pas été modifiée lorsque vous attachez un VDI immuable qui est utilisé sur plusieurs machines, sinon un simple copier-coller du fichier .VBOX suffira (après fixer les chemins des dossiers partagés, etc.).