K-NET s.c.

Migracja maszyn wirtualnych z VMware ESXi do Proxmox VE

Wstęp

Migracja maszyn wirtualnych z jednego hypervisora do innego to ważny proces w zarządzaniu IT, umożliwiający lepsze wykorzystanie zasobów i optymalizację kosztów. Proxmox VE, będąc potężnym narzędziem do wirtualizacji, oferuje efektywne środowisko do przenoszenia istniejących instalacji VMware ESXi. Proces ten został przetestowany na takich systemach operacyjnych jak Debian 10, Windows 10 Pro oraz Windows Server 2016 Standard.

Eksportowanie maszyny wirtualnej

Przy użyciu GUI VMware ESXi:

Przejdź do wirtualnej maszyny w drzewie lewym interfejsu VMware ESXi. Wybierz opcje “Actions > Export”. To spowoduje pobranie obrazów dysków i informacji o maszynie wirtualnej w formacie OVF bezpośrednio przez przeglądarkę. Przenieś pobrane pliki do lokalizacji dostępnej dla hosta Proxmox VE.

Przy użyciu CLI na hoście Proxmox VE:

Zainstaluj narzędzie ovftool na hoście Proxmox VE. Ovftool w wersji 4.4 współpracuje z ESXi w wersji 6.5 i 6.7, podczas gdy inne wersje mogą powodować błędy. Użyj polecenia:

ovftool vi://root@<ip-esxi>/<nazwa-maszyny-wirtualnej>

Pamiętaj o konieczności wypakowania archiwów .ova przed kontynuacją.

Importowanie maszyny wirtualnej

Przejdź do linii komend Proxmox VE i użyj polecenia:

qm importovf <VM-ID> <ścieżka/do/pliku.ovf> <storage> 

Na przykład:

qm importovf 200 /tmp/exported-vm.ovf local-lvm

Polecenie utworzy nową maszynę wirtualną używając rdzeni, pamięci oraz VMID z pliku OVF.

Dodatkowe kroki dla gości systemu Windows

Jeśli importujesz maszynę z systemem Windows, musisz dodatkowo wykonać poniższe polecenia, zakładając że ID wirtualnej maszyny to 130:

qm set 130 --bios ovmf

Systemy Windows wymagają sterowników SCSI, więc czasowo użyj interfejsu SATA. W poniższym przykładzie ‘scsi0’ powinno być zastąpione napędem, z którego uruchamiany jest Windows:

sed -i 's/scsi0/sata0:/' /etc/pve/qemu-server/130.conf

Podsumowanie

Artykuł ten omawia kroki potrzebne do migracji maszyny wirtualnej z VMware ESXi do Proxmox VE, w tym eksportowanie z VMware oraz importowanie do Proxmox. Dla użytkowników systemu Windows wymagane są dodatkowe kroki konfiguracyjne w celu zapewnienia prawidłowego działania maszyny po migracji.

Pproces może znacznie poprawić efektywność zarządzania zasobami IT, umożliwiając korzystanie z zaawansowanych funkcji Proxmox VE takich jak klastry, wysoka dostępność i zarządzanie zasobami.

GR

Tagi: KVM, migracja, Proxmox, VMWare

Wirtualizacja KVM – przekierowanie ruchu

Wielokrotnie pisałem o mojej ulubionej wirtualizacji czyli środowisku VMware. Pomimo doświadczeń z innymi rodzajami hostów nadal uważam, że jest to naprawdę bardzo dobrze zrównoważone rozwiązanie. Drugą istotną cechą jest wsparcie techniczne, które pod postacią dokumentacji elektronicznej oraz komentarzy użytkowników jest uporządkowane i pieczołowicie utrzymywane przez samego producenta. Wszystko to sprawia, że nawet jeżeli spotka nas jakiś ezoteryczny problem to od razu wiadomo gdzie szukać rozwiązania.

Jednak jak zwykle życie wymusza często zmiany w rozwiązaniach i ostatnio zmierzyłem się z maszynami wirtualnymi KVM. Posiadając działający i w pełni skonfigurowany serwer zbudowany na bazie np. Debiana, nie ma raczej innego wyjścia chociaż można spróbować tzw. poor man virtualization czyli Virtualbox w trybie headless. Przyznam, że do tej pory mam pod opieką jeden taki wynalazek. Wracając do KVM to warto zaznaczyć, że nawet jeżeli nie lubisz konfiguracji z użyciem komend to możesz zaistalować chociażby pakiet Cockpit i uzyskać tym samym zarządzanie przez webinterface.

Niezależnie w jaki sposób będziemy korzystać z KVM warto zadbać o bezpieczeństwo konfigurując swoje węzły wirtualne w dedykowanej wirtulanej sieci za NATem. W ten sposób odetniemy możliwość bezpośredniego atakowania usług sieciowych. Z kolei na potrzeby chociażby testowania mamy wygodne rozwiązanie na kształt prywatnej sieci lokalnej z dostępem do Internetu.

Załóżmy następnie, że będziemy chcieli wystawić wybraną usługę, może to być np. serwer www na zewnątrz sieci LAN. Powinniśmy użyć mechanizmu forwardowania pakietów pod wskazany wewnętrzny adres IP, na wskazany port. Jest to powszechnie wykorzystywana metoda w wielu domowych (i nie tylko) routerach z firewallem. W tym miejscu dochodzimy do głównego wyzwania bo przecież interfejs sieciowy KVM oraz interfejs fizyczny nie są ze sobą wprost związane. Żeby przekazywać komunikację między jednym a drugim trzeba skorzystać z dodatkowej konfiguracji za pomocą iptables.

Biorąc za przykład przekazywanie ruchu do serwera www (via HTTPS) będą potrzebne dwie reguły:

iptables -t nat -I PREROUTING -p tcp -d 1.2.3.4 --dport 443 / 
-j DNAT --to-destination 10.0.0.1:443
iptables -I FORWARD -m state -d 10.0.0.1/24 /
--state NEW,RELATED,ESTABLISHED -j ACCEPT

Domyślny konfiguracja KVM NAT zapewnia regułę podobną do drugiej linijki, ale pomija stan NEW, który jest niezbędny do akceptacji połączeń przychodzących. W przykładzie 1.2.3.4 jest adresem publicznym (zewnętrznym) zaś 10.0.0.1 adresem prywatnym. Należy je zmienić według potrzeb i konfiguracji własnej sieci.

Dopiero wpisanie z linii poleceń powyższych dwóch komend pozwoli nam skomunikować się z maszyną wirtualną KVM. Jako zadanie domowe polecam sprawdzenie jak można dodoac reguły do konfiguracji tak aby nie trzeb było ich za każdym razem ręcznie podawać po starcie systemu.

MG

Tagi: iptables, KVM, Linux, wirtualizacja