Proxmox Router – Intel-VT vs. AMD-V
A było to tak... Kolega postawił wirtualny router (Slackware) na Proxmox 1.4 na sprzęcie AMD i przepuścił przez to swoją sieć (~150 klientów). Męczył się przeokropnie z dobraniem wersji jądra, iptables oraz iproute aby miało to ręce i nogi. Bezskutecznie. Średnio raz na 6 godzin router "stawał" informując w konsoli nieśmiale, że kernel panic. Doszło nawet do tego, że mamusia również zaliczała zawieszki. W przypadku mamusi pomogła zmiana jaja Proxa na 2.6.30.x. Jestem w pełni przekonany, że kolega zrobił wszystko dobrze ponieważ ma już pokaźny bagaż doświadczenia w te klocki na karku. Po około dwóch tygodniach ciężkiej walki o przetrwanie zrezygnował. Wrócił na fizyczny sprzęt.
Muszę przyznać, że powoli straciłem wiarę w moc i możliwości Proxmoxa jako narzędzia do wirtualizacji z serii Open-Source. Znalazło się jednak troszkę czasu aby przetestować to na sprzęcie Intela. W obroty poszedł quadzik Q9400 2.66GHz na rdzeniu, płyta Gigabyte GA-EG45M-DS2H z 8GB ramu 4 x KVR800D2N5K2/2G. Na tym sprzęcie do tej pory trzymany był zwirtualizowany hosting firmowy oraz kilka innych wirtualek znajomych, które były kontrolowane przez KVM. Zrobiliśmy test, który wydawał się być najgłupszym pod księżycem (btw. dziś ładny rogalik na niebie świeci :P). Zostawiliśmy odpalone te wszystkie maszyny - w sumie 8 sztuk. Następnie dołożyliśmy jeszcze jedną wirtualkę KVM z routerem moim starym postawionym na archaicznym już Slacku 11-tym. Przy okazji znów wielkie pokłony w stronę Kadzbiego, który to pokazał mi jak przez ssh skopiować działający żywy system na inną maszynę i jeszcze odpalić to hehe. Załatwia to linijka:
tar -pcf - ./ | ssh remoteuser@remotehost tar -C /path/to/remote/dir -pxf -
która pakuje fizyczny system, w locie przesyła go na zdalną maszynę i na niej rozpakowuje w wybrany katalog. Wystarczyło więc odpalić wirtualną maszynę, zbootować ją np z Gentoo Minimal, przypisać adres IP, odpalić serwer ssh (/etc/init.d/sshd start) a następnie zmienić hasło na użytkownika root i skopiować. Wcześniej przygotowano odpowiednią partycję, sformatowano i zamontowano w /path/to/remote/dir z powyższego ciągu znaczków. Później wydano 4 magiczne polecenia:
mount -o bind /dev /path/to/remote/dir/dev
mount -t proc /proc /path/to/remote/dir/proc
chroot /path/to/remote/dir/
lilo
które przeteleportowały nas w chrootowane środowisko naszego routera i zaaktualizowały lilo w MBR. Po reboocie ku naszemu zdziwieniu wszystko od razu zadziałało. Sieć śmiga przecudnie przy podobnej ilości użytkowników i transferach przez router rzędu 20Mbps (bo takie łącze mamy). Na razie obserwujemy. Proxmox ani router i inne wirtualki nie dają żądnych negatywnych znaków. Warto dodać w celach informacyjnych, że do maszyny z mamusią zostały dołożone dwie fizyczne karty sieciowe Intel PRO Fast Ethernet, z których utworzyliśmy dwa potrzebne bridże.
Zauważmy również, że zostało tu zamontowane podstawowe jądro 2.6.24.5 ze Slackware 12.1 delikatnie połatane. Jądro to nie obsługuje VIRTIO zatem wirtualka też. Jestem gotów wysnuć pewną hipotezę. Niemożliwe było osiągnięcie celu, który założyliśmy na tanim gównianym sprzęcie firmy AMD. Intel w tym wypadku przeszedł nasze oczekiwania (ostrożna hipoteza). W ramach argumentacji dopowiedzmy, że moduł KVM jądra matki, który odpowiada za kontrolę nad wirtualnym routerem jest inny dla Intel i inny dla AMD. Według mnie ten dla Intela jest "lepszy" bo działa.
