зар, перше, що спочатку ... ніколи не переміщуйте машину, яка перебуває в збереженому стані, перед переміщенням ви повинні закрити гостя, а не лише зберегти стан.
Також переконайтеся, що ви використовуєте однакову версію VirtualBOX для обох хостів, але не тільки версію VirtualBOX, а також пакунок з розширенням ... або принаймні новий хост має більш високу версію, але ніколи не має нижчої версії для будь-якого з двох інших.
І нарешті, я навчився цього важким способом, перед тим, як перемістити машину, видаліть конфігурацію розділеної папки на VirtualBOX, а потім заново створіть її правильним способом ... дуже важливо, коли хостом є різні ОС (хости Windows / Linux).
І як бічна примітка ... я завжди використовую незмінні файли VDI на жорсткому диску як для ОС, так і для VDI даних (таким чином, той самий DATA VDI можна використовувати більше, ніж для гостей), спеціально трюк для 4GiB pagefile.sys
Ця остання частина, повторне використання незмінного файлу VDI, робить щось трохи складніше, VirtualBOX має BIG BUG.
Щоб побачити помилку в дії:
- Створіть один незмінний VDI (як той, який я використовую для pagefile.sys)
- Створіть два або три VM на VirtualBOX
- Перенесіть одну з них у верхню частину списку (щоб уникнути пошкодження будь-якого вашого)
- Створіть резервні копії файлів .vbox кожної із створених вами машин (для порівняння після появи помилки)
- Приєднайте цей інтуїтивний VDI до декількох із цих машин (крім тієї, що знаходиться вгорі списку)
- Тепер дивіться .vbox машини, яка знаходиться вгорі списку
Ця машина була відредагована, вона містить посилання на інші машини, що інтуїруються VDI.
Таким чином, BUG: Редагування однієї машини, додаючи незмінний VDI, який використовується іншим, впливає на машину вгорі списку.
Чому, на пекло, я повторно використовую той самий 4GiB VDI на всіх машинах Windows? Легко, це диск MBR з розділом FAT32, куди я поміщаю pagefile.sys, оскільки це незмінне всі віртуальні машини створюватимуть файл у папці знімків, де вони зберігають зміни, і вони втрачаються при наступному завантаженні, так що я роблю не потрібен 4GiB для кожного гостя, що зберігається на хост-диску, лише один ... таким чином я економлю багато GiB, оскільки у мене є більше 20 різних вікон для тестування програм, які я розробляю для себе, всі комбінації (XP, Vista , 7, 8, 8.1, 10) * (32Bits, 64Bits) * (Так само, як під час першого встановлення, після кожного ServicePack, після повного оновлення Windows), я отримую багато, багато гостей ... так що про всіх Я поділяю незмінний VDI 4GiB для віртуального оперативної пам’яті (pagefile.sys).
І якщо ви відпустите BUG далі, спробуйте перенести одну з машин на інший хост VirtualBOX (пам’ятайте, що це лише віртуальна машина з конфігурацією на них і на них ще не встановлений гість), ви побачите, що VirtualBox не дозволяє вам додайте їх, оскільки деякі VDI відсутні (це ЛІЖНЕ і ПРАВИЛЬНЕ; це означає, що така перша машина містить посилання на такі VDI, які намагаються отримати на правильній машині).
Тепер порівняйте файли .VBOX усіх них із попередніми BackUp ... зауважте, як неправильно модифіковано? ... так, це той, який знаходиться у верхній частині списку.
Що ж, про цю BUG повідомляли VirtualBOX кілька років тому, вони все ще не можуть виправити це ... і це викликає багато, багато проблем.
Крім того, якщо ви перемістите верхню частину віртуальної машини на нижчу позицію, закрийте VirtualBox і повторно запустіть ... скаже вам, що деякі машини пошкоджені і не можуть бути запущені ... так, перша в списку треба ставитися в іншій формі, якщо ви не хочете отримати багато клопоту.
Це дійсно поганий БУГ, який зайняв у мене багато днів, щоб відкрити (кілька років тому), я навчився цьому важким шляхом!
Я подолав це, маючи машину, яку я зателефонував:
Він має порожню конфігурацію, і лише один VDI, так, ви маєте рацію, ви здогадуєтесь, незмінний VDI, який я поділяю для всіх інших віртуальних машин.
Добре, коли я відкриваю файл .VBOX, я бачу всередині нього багато рядків у <MediaRegistry> <HardDisks>розділі, по одному на кожній машині, де я використовую цей незмінний VDI ... просто як зразок (я видаляю приватні дані):
<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>
Досить БУГ, не вирішений роками.
Ну, щоб перемістити такі машини ... ви повинні вручну редагувати файли .VBOX, щоб усі перші посилання на диски ставити на новий хост на першій машині (той, що знаходиться вгорі списку), перш ніж додати .VBOX файли до списку, тому при додаванні їх у VirtualBOX є посилання на відсутні VDI (відсутні, викликані великою BUG).
Ця річ виникає тому, що кожного разу, коли ви підключаєте VDI, який використовується на іншій машині, VirtualBOX оновлює два машини .VBOX файли (той, що належить машині, яку ви використовуєте), і першу в списку.
Я не зовсім впевнений, що станеться, коли у списку перший не має такого загального VDI, що додається до нього ... краще не пробувати його, бачив те, що я бачу.
Тож перехід на інший HOST набагато складніший, ніж те, що, здається, є дуже поганою реалізацією внутрішньої структури файлів .VBOX і через дійсно великі помилки, коли VirtualBOX редагує їх.
Помилки:
- Внутрішня структура (XML) залежить від HOST (Windows або Linux)
- Редагування однієї машини може змінити іншу, не лише таку, яку редагували
- ... що ще ?
Потрібно більше ... я завжди мігрую машини, роблячи це (і не було проблем, ніколи):
- Візьміть до уваги список усіх машин (замовлення, групування тощо)
- Візьміть на замітку першу в списку (всю її конфігурацію)
- Зверніть увагу на всі властивості машин, які я хочу перенести на інший хост
- Скопіюйте файли .vbox у формат .txt (той, що знаходиться вгорі списку + всі машини, які я хочу перенести)
- Відтворити всі машини (і мати спеціальну у верхній частині списку) всередині VirtualBox на новому хості
- Закрийте VirtualBox на новому хості
- По-різному порівняйте старий .txt з новими файлами .vbox і скопіюйте з .txt у .vbox деякі частини по-людськи, а не лише Copy & Paste.
- Відкрийте VirtualBox і приєднайте всі VDI в правильному порядку
- Знову Закрийте VirtualBox на новому хості
- По-різному порівняйте старий .txt з новими .vbox-файлами та 'виправте' з .txt до .vbox деякі частини по-людськи, а не лише Copy & Paste
Всі інші (папки знімків та файли VDI) я копіюю їх у звичайний спосіб (Копіювання файлів і вставка файлової системи).
Вся ця важка ручна робота викликана великим BUG VirtualBox: він редагує / змінює машину, не модифіковану, коли ви приєднуєте безперебійний VDI, який використовується на більш ніж одній машині, інакше буде достатньо простого копіювання та вставки .VBOX-файлу (після виправлення шляхів спільного використання папок тощо).
