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

Jaki jest zalecany sposób przeniesienia maszyny wirtualnej VirtualBox do innego komputera?

Advertisement

Używam VirtualBox 4.1.x na mojej maszynie Ubuntu i skonfigurowałem kilka maszyn wirtualnych. Ponieważ istnieje kilka sposobów na przeniesienie wirtualnej maszyny w VirtualBoxie na inny komputer, zastanawiałem się, który z nich jest zalecany:

  1. Użyj narzędzia “Import/Eksport”.
  2. Skopiuj cały folder maszyny wirtualnej, zawierający pliki .vdi i .vbox.
  3. Sklonuj VDI używając “Virtual Media Manager”, a następnie odtwórz VM na maszynie docelowej, ale używając sklonowanego VDI jako dysku twardego.

Z powodzeniem użyłem 1. metody kilka razy i zawsze działała. Problem polega na tym, że po wyeksportowaniu i zaimportowaniu, obraz dysku jest przekształcany na VMDK, a nie na VDI!

2. Metoda jest prawdopodobnie najłatwiejsza, ale nie jestem pewien czy po prostu skopiowanie plików zadziała czy nie na maszynie docelowej. Podczas wyszukiwania na temat tej metody, znalazłem kilka osób miał problemy, w których musieli edytować plik VirtualBox.xml, aby go rozwiązać!

Nareszcie jest 3. metoda , ale wymaga to dodatkowej pracy tworzenia VM podobne do oryginalnej konfiguracji VM, co nie jest pożądane.

Z powyższego wyjaśnienia wynika, że moja pożądana metoda jest 2. metoda, ale potrzebuję porady ekspertów w tej sprawie, czy to działa, czy nie. Nie chcę, aby jakakolwiek edycja XML stanęła mi na drodze!

Jaka jest najlepsza metoda bezpiecznego przeniesienia mojej maszyny wirtualnej na inny komputer z VirtualBoxem?

Advertisement

Odpowiedzi (9)

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

Dobra robota za twoje badania. Regularnie używam wszystkich trzech opcji.

  1. (Użyj narzędzia “Import/Eksport”). Jest to najłatwiejsze, ponieważ łączy całą maszynę wirtualną w jeden plik i przenosi go bez problemu za każdym razem. Jednak z mojego doświadczenia wynika, że podczas tworzenia pliku OVA lub OVF do wyeksportowania wyrzuca on wszystkie snapshoty i jeśli zrobione nieprawidłowo może spowodować powstanie pliku VMDK. Kiedy ponownie importujesz maszynę wirtualną, powinieneś mieć możliwość wyboru typu tworzonego pliku HDD, VDI lub VMDK.

  2. (Skopiuj cały folder maszyny wirtualnej, zawierający pliki .vdi i .vbox). Jest to moja preferowana opcja i chociaż kilka razy musiałem edytować plik XML, to jest to moja własna wina, że coś popsułem. Upewnij się, że kiedy kopiujesz maszynę wirtualną, otrzymujesz WSZYSTKIE pliki z nią związane. Problemy, na które natknąłem się, to takie, kiedy pewne migawki i drugorzędne pliki VDI były w złym katalogu i nie zostały poprawnie skopiowane. Jeśli skopiujesz wszystkie pliki (i uprawnienia) nie powinieneś mieć żadnych problemów.

  3. (Sklonuj VDI używając “Virtual Media Manager”, a następnie odtwórz VM na maszynie docelowej, ale używając sklonowanego VDI jako dysku twardego). Jest to mniej pożądane, ponieważ wtedy masz 2 kopie VM, i może to spowodować problemy z licencją, problemy z siecią, itp. w zależności od tego jak sklonujesz plik VDI.

Podsumowując, zdecydowanie polecam opcję 2, po prostu upewnij się, że dostaniesz wszystkie potrzebne pliki, gdy je przeniesiesz.

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

Metoda 2 działa teraz dobrze (z VirtualBox 4.0 i wyższą), bez konieczności modyfikacji XML:

  1. Zatrzymaj swoją maszynę wirtualną
  2. Wyjdź z VirtualBoxa
  3. Skopiuj folder VM do nowej lokalizacji
  4. Uruchom ponownie VirtualBoxa i usuń starą maszynę wirtualną.
  5. Przejdź do menu maszyny ≥ Dodaj i przeglądaj do starego folderu.

To jest to!

ps: Mam VirtualBoxa 4.3.20 na OSX 10.10

See ten post na forum VirtualBoxa po więcej szczegółów.

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

Moja preferowana opcja to również opcja 2:

  1. Skopiuj cały folder VM, zawierający pliki .vdi i .vbox.

Ale czasami wystąpi niedopasowanie UUID. Często zdarza się to, jeśli po prostu skopiujesz obraz dysku VDI jednej maszyny na inną, ale zdarzyło się to również podczas prostych kopii pełnych katalogów.

Tak więc, jeśli jest to wiadomość, którą otrzymasz po przeniesieniu maszyny wirtualnej i próbie uruchomienia jej w nowej konfiguracji:

Nie udało się otworzyć dysku twardego .

Cannot register the hard disk becuase a hard disk with UUID already exists.

Just go into the directory of your virtual machine; of course change the actual path to match the actual path you are going into:

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

And run this command to assign the disk a new UUID:

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

W przypadku, gdy ktoś inny szuka odpowiedzi na to pytanie, udało mi się przenieść 5 wirtualnych maszyn wirtualnych do innej instalacji Win7 na nowym dysku twardym na tej samej maszynie (zasadniczo jest to przeniesienie z jednego systemu operacyjnego gościa do innego na tym samym komputerze). Zdaję sobie sprawę, że sterowniki na zupełnie nowej maszynie prawdopodobnie różniłyby się i potencjalnie miałyby negatywny wpływ na przeprowadzkę, ale udokumentowałem ten proces poniżej w nadziei, że może komuś pomóc.

  • Nie było wymogu klonowania maszyn wirtualnych ani zmiany pliku xml. Wersja VB była dość aktualna: 4.3.12r93773.
  • Nowe kopie maszyn wirtualnych zostały utworzone w nowym folderze/na wspólnym dysku, aby zachować istniejące/sprzedane maszyny wirtualne w stanie nienaruszonym. Mogę nadal uruchamiać komputer ze starego dysku twardego, który zachowałem dla nadmiarowości/rozdzielczości emisji, dopóki nie będę zadowolony z mojej nowej konfiguracji, więc w razie potrzeby mogę uzyskać dostęp do starych maszyn wirtualnych w ich poprzednim stanie.
  • litery dysku będą się różnić/nie będą konieczne w zależności od konfiguracji.

Na starym hostie Win7:

  1. Upewnij się, że wszystkie maszyny wirtualne są wyłączone.

Na nowym hostie Win7:

  1. Utwórz nowy folder o nazwie X:\NewVMs\VirtualBox VMs (z nowej maszyny Win7, aby upewnić się, że uprawnienia są OK)
  2. Copy/Paste (don’t drag) all VMs and related folder contents from the old folder to this folder (uses new permissions)
  3. Odinstaluj VirtualBox (jeśli jest zainstalowany)
  4. Usuń folder .virtualbox i całą jego zawartość (jeśli istnieje)
  5. REBOOT aby potwierdzić, że nie pozostały żadne pliki programu lub wpisy rejestru (jeśli odinstalowałeś starego VirtualBoxa)
  6. Zainstaluj/ponownie zainstaluj VirtualBoxa (upewnij się, że korzystasz z tej samej wersji co VirtualBox, na której zostały utworzone maszyny wirtualne na starym hoście/maszynie (w moim przypadku ver. 4.3.12r93773)) IMPORTANT: (Nie zaznaczaj tickboxu aby otworzyć/uruchomić VirtualBoxa po zakończeniu instalacji)
  7. Skopiuj/wklej (nie przeciągaj) .virtualbox folder i zawartość ze starego hosta Win7 (zwykle C:\Users[username].VirtualBox
  8. Teraz otwórz VirtualBox
  9. Ustaw preferencje dla nowego Domyślnego folderu tworzenia maszyn wirtualnych na tę samą ścieżkę, co nowo utworzony folder maszyn wirtualnych VirtualBox: X:\NewVMs\VirtualBox VMs
  10. Stan testów VMs

Powodzenia.

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

For the special case where:

  • you only have a single VM (or want to move all of your VMs),
  • and the host is the same hardware with the same OS version (or reinstalling same OS to the same machine)

If you are in this case, then things are easy:

  1. Wyłączenie VirtualBoxa na obu hostach.

  2. Skopiuj foldery .config/VirtualBox i VirtualBox VMs z hosta źródłowego.

  3. Skopiuj te foldery do hosta docelowego.

  4. Uruchomienie VirtualBoxa na hoście docelowym.

1
1
1
2018-06-28 21:44:12 +0000

The 4th Way

In VirtualBOX:

  1. Power off the VM
  2. Kliknij prawym przyciskiem myszy i usuń maszynę wirtualną (nie usuwaj plików)
  3. Wejdź do pliku →Virtual Media Manager i usuń .vdi
  4. Przejdź do menu File>Preferences>General i ustaw domyślny folder maszyny na nową lokalizację
  5. Utwórz nową maszynę wirtualną Użyj trybu eksperta, aby utworzyć maszynę bez dysku twardego

In File Explorer:

  1. Zlokalizuj plik .vdi i skopiuj go
  2. Przejdź do nowego domyślnego folderu maszyny, wewnątrz znajdzie się folder maszyny wirtualnej 3. Wklej plik .vdi do nowego folderu maszyny wirtualnej

Back In VirtualBOX:

  1. Kliknij prawym przyciskiem myszy na maszynie wirtualnej i otwórz ustawienia
  2. 2. Przejdź do Storage>Controller: SATA i dodaj dysk twardy, kliknij na istniejący dysk 11.wybierz plik .vdi w nowym folderze maszyny wirtualnej

Uwaga: Jeśli metoda 2 przerywa instalację VirtualBOX przejdź do C:\Users.VirtualBox i usuń VirtualBox.xml oraz zmień nazwę VirtualBox.xml-prev na VirtualBox.xml

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

Do przeniesienia mojej wirtualnej maszyny użyłem również metody 2 i nie musiałem dokonywać żadnych zmian w żadnym pliku XML, ale miałem kilka błędów z USB i współdzieleniem plików i poniżej znajduje się sposób, w jaki je naprawiłem wraz z procesem:

  1. Skopiuj maszynę wirtualną ze starej na nową PC. Pliki maszyny wirtualnej różnią się od samej maszyny wirtualnej Oracle. Pliki te znajdują się zazwyczaj w _c:\użytkownicy \VirtualBox VMs_. Odebrałem całą część _VirtualBox VMs _ i skopiowałem ją do podobnej lokalizacji na nowym komputerze. To kopiuje wszystkie wirtualne maszyny, które miałem na oryginalnym PC.

  2. Teraz na nowym komputerze uruchom wirtualną skrzynkę i przejdź do Menu >Maszyna >Dodaj i wybierz plik .vbox z kopiowanego folderu. To jest to.

  3. Teraz, gdy uruchomiłem wirtualną maszynę na nowym komputerze, popełniłem błąd podczas uruchamiania:

  1. Nie wiem dlaczego kontroler USB nie działał, ponieważ to samo działało na oryginalnym komputerze. Poszedłem dalej i zainstalowałem VirtualBox Extension Pack

  2. Ta instalacja była trochę dziwna, ponieważ pobieranie instalacji nie było plikiem wykonywalnym. Kliknąłem na Oracle_VM_VirtualBox_Extension_Pack-5.1.4-110228.vbox-extpack i wybrałem ‘Select a program from a list of Installed programs’, a następnie wybrałem Oracel virtualbox i zainstalował rozszerzenie. To naprawiło problem, ale innym mniej pożądanym rozwiązaniem jest wyłączenie usb.

  3. Jeśli miałeś współdzielone foldery w oryginalnej maszynie wirtualnej, mogą się one różnić i otrzymasz błąd. Przejrzyj te w Ustawieniach >> Folder współdzielony i usuń te, które są uszkodzone. Komunikat o błędzie będzie wyglądał jak

.

To wszystko.

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

zar, pierwsza rzecz po pierwsze… nigdy nie ruszaj maszyny, która jest w stanie zapisanym, przed ruszeniem musisz zamknąć gościa, a nie tylko zapisać stan.

Upewnij się, że używasz tej samej wersji VirtualBOX na obu hostach, ale nie tylko wersji VirtualBOX, również pakiet rozszerzeń vesion… lub przynajmniej nowy host ma wyższą wersję, ale nigdy niższą wersję na żadnym z tych dwóch.

I na koniec, nauczyłem się tego w twardy sposób, usuń konfigurację folderu SHARED na VirtualBOX przed przeniesieniem maszyny, a następnie odtwórz ją w poprawny sposób… bardzo ważne, gdy hosty są różne systemy operacyjne (hosty Windows / Linux).

I tak na marginesie… zawsze używam nieprzemijalnych plików VDI na dysku twardym dla systemu operacyjnego, jak również dla danych VDI (w ten sposób te same DATA VDI mogą być używane dla więcej niż gościa), specjalnie trick dla pagefile 4GiB. sys

Ta ostatnia część, ponowne użycie nieprzemiennego pliku VDI sprawia, że sprawy idą nieco trudniej, VirtualBOX ma DUŻY BUG.

Aby zobaczyć błąd w akcji:

  • Utwórz jeden nieprzemienny plik VDI (jak ten, którego używam dla pagefile.sys)
  • Utwórz dwie lub trzy maszyny wirtualne w VirtualBOX
  • Przenieś jedną z nich na górę listy (tylko po to, aby uniknąć uszkodzenia którejkolwiek z Twoich)
  • BackUp the . vbox na każdej z utworzonych przez Was maszyn tho (w celu porównania po uruchomieniu BUG'a)
  • Dołącz tę nieprzemijalną VDI do więcej niż jednej z tych maszyn (z wyjątkiem tej na górze listy)
  • Teraz zobacz .vbox maszyny, która znajduje się na górze listy

Ta maszyna została edytowana, ma odniesienia do innych maszyn nieprzemijalnych VDI.

Tak więc BUG jest: Edytuj jedną maszynę, dodając wbudowane VDI, które jest używane przez inną, ma wpływ na maszynę znajdującą się na górze listy.

Dlaczego, do diabła, ponownie używam tego samego 4GiB VDI na wszystkich maszynach z systemem Windows? To proste, jest to dysk MBR z partycją FAT32, na której umieściłem pagefile.sys, ponieważ jest nieprzyjmowalny, wszystkie maszyny wirtualne stworzą plik w swoim katalogu migawkowym, w którym przechowują zmiany, które zostaną utracone podczas następnego uruchomienia, więc nie potrzebuję 4GiB dla każdego gościa przechowywanego na dysku hosta, tylko jeden… W ten sposób oszczędzam dużo GiB, ponieważ mam ponad 20 różnych okien do testowania aplikacji, które opracowuję dla swoich własnych, wszystkich kombinacji (XP, Vista, 7, 8, 8.1, 10)*(32Bity, 64Bity) * (Tak jak przy pierwszej instalacji, po każdej aktualizacji ServicePacka, po pełnej aktualizacji okien), dostaję dużo, dużo gości… więc na wszystkich z nich współdzielę wbudowane 4GiB VDI dla wirtualnego ram'a (pagefile.sys).

A jeśli pozwolisz BUGowi przejść dalej, spróbuj przenieść jedną z tych maszyn do innego hosta VirtualBOX (pamiętaj, że są to tylko maszyny wirtualne z konfiguracją na nich i nie ma jeszcze zainstalowanego na nich gościa), zobaczysz VirtualBox nie pozwala na ich dodanie, ponieważ brakuje niektórych VDI (jest to FALSE i TRUE, jest to, że taka pierwsza maszyna posiada odniesienia do takich VDI insteed pszczoły na właściwej maszynie).

Teraz porównaj . Pliki VBOX wszystkich z prefiksami BackUp… zwróć uwagę, jak jeden z nich jest nieprawidłowo modyfikowany?… tak, to ten na górze listy.

Cóż, ten BUG został poinformowany do VirtualBOX kilka lat temu, nadal nie mogą go naprawić… i to powoduje wiele, wiele problemów.

Również więcej, jeśli przesuniesz górną część wirtualnych maszyn na niższą pozycję, zamknij VirtualBox i uruchom go ponownie… powie ci, że niektóre maszyny są uszkodzone i nie mogą być uruchomione… tak pierwszy na liście musi być traktowany w innej formie, jeśli nie chcesz dostać dużo kłopotów.

To naprawdę zły BUG, który zabrał mi wiele dni do odkrycia (kilka lat temu) i nauczyć się go w trudny sposób!

Przezwyciężyłem go mając maszynę, którą nazwałem:

  • Common Inmutable Disks

Ma pustą konfigurację i tylko jedno VDI, tak, masz rację, masz zgadywankę, niezbywalne VDI, które udostępniam dla wszystkich pozostałych maszyn wirtualnych.

Cóż, kiedy otwieram plik .VBOX widzę w nim wiele linii w sekcji <MediaRegistry> <HardDisks>, po jednej na każdą maszynę, gdzie używam tego nieprzyjaznego VDI… tylko jako próbkę (usuwam prywatne dane):

<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, nie rozwiązany od lat.

Cóż, aby przenieść takie maszyny… musisz ręcznie edytować . VBOX, aby umieścić wszystkie takie referencje dysków na nowym hoście na pierwszej maszynie (tej, która znajduje się na górze listy) przed dodaniem plików .VBOX do listy, więc przy ich dodawaniu VirtualBOX ma referencje do brakujących VDI (brak spowodowany dużym BUGiem).

Rzecz w tym, że przy każdym podłączeniu VDI, które jest używane na innej maszynie VirtualBOX aktualizuje dwie maszyny . Pliki VBOX (ten, który należy do maszyny, której używasz) i do pierwszej z nich na liście.

Nie jestem do końca pewien, co by się stało, gdyby na liście, pierwsza nie miała takiego wspólnego VDI dołączonego do niej… lepiej nie próbować, zobacz co widzę.

Więc migracja do innej HOST jest znacznie bardziej skomplikowana niż to, co wydaje się być z powodu bardzo złej implementacji na plikach .VBOX.internal structure and because of really big BUGs when VirtualBOX edits them.

Fails:

  • Internal structure (XML) depends on the HOST (Windows or Linux)
  • Edit one machine can alter another one, not only the one beeing edited
  • … what more ?

Need more… i allways migrate machines doing this (and had no problem, never ever):

  1. Zwróć uwagę na listę wszystkich maszyn (porządek, grupowanie, itp.)
  2. Zwróć uwagę na pierwszą maszynę na liście (cała jej konfiguracja)
  3. Zwróć uwagę na wszystkie właściwości maszyn, które chcę przenieść na innego hosta
  4. Skopiuj pliki .vbox jako pliki .txt (ten na górze listy + wszystkie maszyny, które chcę przenieść)
  5. Odtwórz wszystkie maszyny (i miej specjalną na górze listy) wewnątrz VirtualBoxa na nowym hoście
  6. Zamknij VirtualBox na nowym hoście
  7. Porównaj stare pliki .txt z nowymi plikami .vbox i skopiuj z .txt do .vbox niektóre części w ludzki sposób, a nie tylko Kopiuj&Wklej
  8. Otwórz VirtualBox i dołącz wszystkie VDI w prawidłowej kolejności
  9. Ponownie zamknąć VirtualBox na nowym hoście
  10. Porównać stare .txt z nowymi plikami .vbox i ‘naprawić’ z .txt do .vbox niektóre części w ludzki sposób, nie tylko Copy&Paste

Cała reszta (folder snapshoty i pliki VDI) i skopiować je w normalny sposób (File System Copy&Paste)

Cała ta ciężka ręczna praca jest spowodowana przez Big BUG VirtualBox: Edytuje on/zmienia maszynę, która nie została zmodyfikowana, gdy dołączysz niewywoływalne VDI, które są używane na więcej niż jednej maszynie, w przeciwnym razie wystarczy zwykły plik Copy&Paste .VBOX (po naprawieniu ścieżek folderów współdzielonych, itp.).

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

Skopiuj folder zawierający urządzenie do miejsca docelowego, a następnie z menu: “Machine” —> “Add”, a następnie wybierz plik vbox, a nie plik vdi. Dla mnie poszło to bezbłędnie. Nie jestem pewien, czy miałem szczęście, czy ma to działać w ten sposób.

Advertisement