Slackware & Qemu
Ostatnimi czasy sprawdzałem specjalny przypadek użycia Slackware - jako host dla wirtualnych maszyn. Okazało się jednak, że Slackware "niechętnie" współpracuje z najnowszymi rozwiązaniami. Pierwszy wybór padł na Xen, ale po próbach i błędach skompilowałem poprawnie kernel, moduły załadowały się poprawnie i zrobiłem bazowy obraz pod wirtualną maszynę. Nieźle, ale ostatecznie przy uruchomieniu zaczęły pojawiać się błędy na które nie znalazłem (jeszcze!) rozwiązania, więc porzuciłem na chwilę Xen na rzecz Qemu.
Po kolejnych próbach i błędach, kilkunastu artykułach w końcu udało mi się uruchomić wirtualną maszynę. Tutaj muszę podziękować autorowi paczki VMS, który większość konfiguracji środowiska Qemu usprawnił poprzec pliki TOML. Świetna sprawa, jako że robi za użytkownika większość pracy (po prostu wpisujemy w konsoli vms start/stop vm_name zamiast przekazywać wszystkie argumenty ręcznie). Instrukcja zaleca zainstalowanie kilku dodatkowych narzędzi. Tutaj droga staje się bardziej wyboista, bo akurat u mnie, na dwóch systemach w wersji current (jedna czerwiec, druga październik), rezultaty były różne; w najnowszej wszystko udało się zainstalować ze slackbuilds.org, a w starszej musiałem się wspomóc slackpkg. Po tym przygotowałem konfiguracje VM zgodnie z dokumentacją VMS. Udało się uruchomić VM i zainstalować Slackware na niej. Trochę czasu to zajęło, gdyż skonfigurowana VM ma 1 CPU i 512MB Ram. Powód dla tego jest dość prosty - potrzebuje uruchomić 10 VMek na serwerze do dalszych testów, a to zajmie 10 CPU i ponad 5GB Ram. Samą VM udało się jeszcze "odchudzić" i z niemal 10GB po zainstalowaniu systemu udało się zejść do 7.7 GB (Nie potrzebuje perla, rusta, php, mariadb, ruby do testów). Na bieżące potrzeby wystarczy, ale docelowo dobrze byłoby to odchudzić i zejść poniżej 5GB. Wydaje się sporo, ale zawiera wszystkie narzędzia z których korzystam na codzień i to jest spore ułatwienie.
Skąd wogóle pomysł na powyższy eksperyment ? Główny powód, dla którego się podjąłem tego wyzwania, to problem z systemami "legacy", czyli takimi które albo są nieutrzymywane, albo zapomniane i nieutrzymywane. Główna bolączka takich systemów, to upgrade, a już system upgrade z mojego doświadczenia kończy się czasami niepowodzeniem (50/50 - albo się uda, albo nie). Natomiast Slackware nigdy nie robił problemów w tym aspekcie, i to zarówno nowsze wersje jak i starsze (nawet na starym laptopie upgrade po kilku latach nie stanowił problemów). Oczywiście, trzeba pamiętać o kolejności i dobrą praktyką jest upgrade najpierw slackpkg, ale po tym problemy się kończą (o ile można to nazwać problemem). Całe szczęście - dokumentacja Slackware staje się coraz lepsza z każdym rokiem.
Wracając do meritum:
1. Skonfigurowanie VM - OK
2. Run VM - OK
3. Pozbycie się niepotrzebnych paczek - OK
Wygląda, że jestem na dobrej drodze. Pozostały 2 rzeczy do skonfigurowania - jak uruchomić VM w trybie bez monitora, i konfiguracja sieci, żeby można było podłączyć zdalnie sesje do VM bez monitora. Uruchomienie w takim trybie wymagało nieco gimnastyki, gdyż większość sugestii na internecie brzmiała: "uruchom bez trybu graficznego". Oczywiście jest to dobry pomysł, pod warunkiem że ten tryb jest uruchomiony tylko z niego nie chcesz korzystać. Dla servera "bez głowy", tak opcja jest nie do przejścia, gdyż gtk nie został zainicjalizowany. Ale całe szczęście, rozwiązanie problemu jest dość proste - emulacja gtk z poziomu wiersza poleceń. Do tego potrzebne jest narzędzie xvfb-run, które jest również dostępne na slackbuilds.org. Dodajemy tylko dodatkowe polecenie przed "vms..." i po sprawie. Działa. Ostatnia rzecz do skonfigurowania to sieć. Tutaj miałem pewien problem, gdyż natywnie udało się skonfigurować adres IP wewnątrz VM, który za bramę wykorzystuje vde2 (uruchomiony na hoście). To rozwiązanie działa, ale przy większej ilości VMek (>1) to rozwiązanie staje się nie do utrzymania na dłuższą metę. I tutaj na ratunek przybywa AlienBob, który napisał skrypt ułatwiający pracę z wirtualizacją na Slackware. Wykorzystuje on dnsmasq jako serwer DHCP dla interfejsu tap0 (vde2). Po włączeniu ip_forward wszystko działa jak należy. Dodatkowym krokiem jest dodanie odpowiedniej trasy jeśli chcemy mieć dostęp do VMek poprzez inną maszynę w sieci lokalnej. Ta historia to tylko wstęp do następnej części...
Ciąg dalszy nastąpi...
