migracja kvm do vmware - gość oparty na lvm + wielościeżkowość

Jaki jest zalecany sposób migracji z kvm do vmware w przypadku gościa opartego na lvm z obsługą wielu ścieżek? Odkryłem, że podobne pytania zadawano już kilka lat temu:

Jak migrować maszyny wirtualne oparte na KVM działające w konfiguracji LVM do obrazów Vmdk

konwersja maszyn wirtualnych KVM na VMware-vsphere

Problem z konwerterem vCenter polega na tym, że nie są obsługiwane podstawy linuksa dokumentacji montowane przez wielościeżkę mapowania urządzeń. Jaki jest obecnie właściwy sposób postępowania w przypadku środowiska wielościeżkowego?

vmware-esxi kvm-virtualization device-mapper

— joe33
źródło

Zaraz, VM ma własną wielościeżkową ?!

— Michael Hampton

nie, wielościeżkowość jest używana na hoście kvm

— joe33

W takim razie jaki jest problem?

— Michael Hampton

Myślałem, że jest to przypadek, w którym nie jest obsługiwany. Czy to oznacza, że nie zrozumiałem go poprawnie i że można używać konwertera vcenter tak długo, jak maper urządzeń jest używany na hoście kvm, a nie na hoście-gościu? Jeśli tak, to bardzo dziękuję za wyjaśnienia :)

— joe33

Odpowiedzi:

Konwerter VMware może migrować z dowolnej maszyny źródłowej, niezależnie od typu źródła. (wirtualny / fizyczny / KVM / Hyper-V) Jedynym problemem jest to, że konwerter VMware nie może migrować oprogramowania RAID ani LVM. Tak więc rozwiązaniem jest utworzenie szkieletowego serwera z absolutnym minimum maszyny źródłowej i wypchnięcie wszystkiego za pomocą polecenia tar z serwera źródłowego.

Musiałem skorzystać z tego rozwiązania, kiedy migrowałem całkiem sporo serwerów typu „bare metal” do VMware, a niektóre miały zainstalowany program softraid lub LVM.

Kroki, które należy wykonać w tym celu:

1: Utwórz docelową skrzynkę VM

2: Zainstaluj minimalną wersję tego samego systemu, który ma twoje źródło (sieć, serwer ssh i tar muszą być dostępne)

3: Utwórz listę katalogów, których nie chcemy dołączać

boot proc dev sys etc / fstab etc / lvm etc / blkid mnt / yourexternalhdd

zapisz go pod / tmp / nocopy

4: Zrób migawkę swojego celu na wypadek, gdyby coś poszło nie tak

5: SSH do twojego źródła i jako root: cd /; tar -zcvpf - -X / tmp / nocopy * | ssh target "cd /; tar -zxvpf - --numeric-owner" 6: Zresetuj cel.

NA PRZYKŁAD:

tar -zcvpf - -X / tmp / nocopy * | ssh root@10.0.4.158 "cd /; tar -zxvpf - --numeric-owner"

— Laz
źródło

Kilka dodatkowych aktualizacji dotyczących hostów źródłowych opartych na XEN. Miałem pewne problemy z hostem Windows, gdzie nie mogłem rozebrać komputera źródłowego, ponieważ niewiele z nich miało zapas w różnym procencie. Problem spowodowały narzędzia XEN. Instaluje dostawcę VSS dla hosta, co oczywiście koliduje z Windows VSS i powoduje problemy z migracją komputera. Więc najlepszą rzeczą, jeśli utkniesz w pewnym momencie podczas migracji komputera z systemem Windows opartym na XEN, jest pozbycie się narzędzi XEN z pola źródłowego.

— Laz

Aby przekonwertować istniejące obrazy dysków do formatu VMware vmdk, powinieneś użyć programu qemu-img z pakietu qemu-utils (w Ubuntu).

Proces jest prosty

sudo qemu-img convert -p -i DiskImage.img -O vmdk DiskImage.vmdk

vmkfstools -i /vmfs/volumes/nfs1/DiskImage.vmdk -d thin /vmfs/volumes/datastore1/MyServer/DiskImage.vmdk

Prześlij obraz dysku do ESXi (używając scp (włącz ssh w ESXi)) lub NFS

Utwórz nową maszynę wirtualną z niestandardowymi opcjami i dodaj przekonwertowany dysk

Bagażnik

— Andy Parveen
źródło