Hejdå, VMware – Hej Proxmox!
Jag har ju uppenbarligen svårt att lära mig av tidigare misstag, eller så är jag bara oerhört envis. Jag har nämligen försökt migrera mitt hemmalabb till Proxmox tidigare. Två gånger till och med. Varje gång har jag ångrat mig, men denna gång gick det faktiskt vägen och detta tack vare två nya faktorer i sammanhanget.
Det ena är det faktum att jag numera endast behöver köra en enda server istället för två som tidigare. Det andra är att jag byggt en ny lagringslösning.
Låt mig förklara
Mina gamla grejer i hemmalabbet byggde på ett SAN som använde Fibre Channel för sin kommunikation. När jag försökte köra Proxmox i ett kluster med en delad lagringslösning baserad på Fibre Channel slutade det inte väl – det hela baserades på att ena klusternoden initierade och “ägde” anslutningen till SAN:et som monterades som en LVM, som man i sin tur sedan delade ut till andra noder i klustret. Problemet var att trafiken till SAN:et då gick från en nod till en annan nod till SAN:et och sedan tillbaka, och prestandan blev därefter. Man kunde lösa det genom att köra Multipath men det blev aldrig riktigt bra, åtminstone inte så bra som det fungerade i VMware ESXi 6.5 som jag var van vid.
Servrarna var inte heller särskilt purfärska men då jag de senaste 18-månaderna samlat på mig modernare grejer (mest genom gåvor och fynd jag gjort) har jag pö om pö uppgraderat mitt hemmalabb med. Detta första faktum har lett till att jag nu har aningen modernare servrar (två Dell R620) som jag migrerat ihop till enda server genom att trycka in allt minne från den ena i den andra. Detta har gett en maskin med 32 CPU-kärnor och 384 gigabyte internminne. Det räcker gott och väl för mina behov.
Det andra är att jag också investerat i ett bättre nätverk där jag kan köra 10GbE mellan alla servrar. Detta, plus det faktum att jag byggt ett nytt SAN med en HP-server (D170 generation åtta, nedklockad till sin lägsta hastighet för att spara ström), åtta 3TB-diskar, tre SSD-diskar och lite mer minne i den maskinen och vips så kunde jag bygga mig en snabb modern lagringslösning baserad på TrueNAS (före-detta FreeNAS).
Varför vill jag då byta bort VMware och mitt gamla FC-SAN?
Problemen är flera: mina Dell R620-servrar stöds inte av något nyare än VMware ESXi 6.5, vilket börjar bli till åren kommet. Det andra är att mitt FC-SAN, som visserligen fortfarande fungerar, är 16-17 år gammalt och inte fungerar något vidare med hårddiskar större än 1TB. Det gör att jag är begränsad till hur mycket yta jag kan få ut från det SAN:et vilket ger drygt 12TB i RAID-5. I takt med att diskarna går sönder, för de gör ju det till slut, så är det heller inte särskilt roligt att behöva köpa 1TB-diskar att ersätta de gamla med.
FC-SAN:et är inte överdrivet snålt när det gäller elförbrukning heller så det vore också trevligt att hyvla bort några watt på elräkningen så det fick bli ett nytt bygge.
Kort sagt: jag ville bygga en ny miljö på modernare hårdvara och mjukvaror som fortfarande uppgraderas och som också är gratis.
Så jag satte igång att åter igen titta på Proxmox. Och om det ska jag berätta om nu.
Migrering
Förr i tiden (det vill säga, i mina två tidigare försök, fick man vackert överföra filerna från VMware i form av VMDK-filer till en annan storage och sedan konvertera dem till qcow2 eller vad man nu ville har för format på sina virtuella diskar. Jag hade helt missat att det finns ett verktyg som heter OVFTool som gör det väldigt enkelt att överföra VMware-maskiner till Proxmox via SSH och HTTPS. Den eller de maskiner du vill överföra måste vara avstängda vid flytten men i övrigt är det bara att på din Proxmox-server, eller på en annan maskin du vill använda köra, kommandot och sedan vänta. För det tar en del tid, i synnerhet om diskfilerna till dina virtuella servrar är flera hundra gigabyte stora.
Efter att man migrerat över sina virtuella maskiner är det dags att importera det hela till Proxmox. Detta sker med fördel i CLI-gränssnittet som du kommer åt genom att SSH:a till din Proxmox-server:
qm importovf vm_id /namn_på_vm/namn_på_vm.ovf namn_på_lagring
Det ovanstående kan behöva en förklaring, så här kommer den:
vm_id = nästa lediga ID i Proxmox. När du skapade din första virtuella maskin i Proxmox fick den ett ID, ett siffervärde, som är 100. Därifrån stiger nummerserien automatiskt för varje ny server du skapar, men om du importerar en virtuell maskin på det ovanstående sättet måste du själv ange ID-numret. Enklast att göra detta är att kolla i Proxmox webbgränssnitt hur läget är – om den sista virtuella maskinen du kör har ID 110 så använder du 111 vid importen, och så vidare.
namn_på_vm/namn_på_vm.ovf = när du exporterar en virtuell maskin med OVFTool skapas en katalog automatiskt som döps till samma namn som den virtuella maskinen. I denna katalog läggs sedan de filer som du ska importera. Om du har exporterat en virtuell maskin från VMware som heter “mail” så kommer sökvägen således vara “/mail/mail.ovf”.
namn_på_lagring = namnet på den lagringslösning du vill placera den importerade virtuella maskinen. Har du ett SAN så kanske det heter “SAN01”. Växla över vyn i Proxmox webbgränssnitt till “Datacenter” och välj sedan “Storage” så ser du vad dina lagringslösningar heter i kolumnen döpt “ID”.
Dags att starta
När du migrerat och senare importerat dina virtuella servrar är det dags att börja starta dem. I mitt fall har jag tre olika typer av virtuella maskiner: FreeBSD, CentOS 7 och Windows Server.
I fallet FreeBSD är det inte svårt att komma igång: lägg till ett nätverkskort till den importerade virtuella maskinen, se till att det är av typen VirtIO, se till att hårddisken/hårddiskarna är satt som en SCSI-hårddisk och sedan är det bara att starta den virtuella servern. Du kommer behöva redigera /etc/rc.conf och ändra namnet på nätverkskortet till vtnet0, ta bort eventuella referenser till VMware och sedan är det bara att starta om och köra vidare.
I fallet CentOS kommer den virtuella maskinen att vägra boota om du sätter hårddiskgränssnittet till något annat än IDE. Det är också det långsammaste gränssnittet och därför vill du väldans gärna kunna köra VirtIO som gränssnitt för det. Innan du startar den virtuella maskinen skapar du ett nätverkskort som du sätter som VirtIO. Därefter konfigurear du hårddiskarna som IDE, starta sedan upp den virtuella maskinen, gå in i nätverkkonfigurationen i /etc/sysconfig/network-scripts och döp först och främst om konfigurationsfilen, som innan kanske heter ifcfg-ens160 till ifcfg-eth0. Därefter öppnar du filen med en vettig editor, raderar raden med UUID-värdet och ändrar sedan dessa två värden till eth0:
NAME="eth0"
DEVICE="eth0"
Med detta klart är det dags att lösa problemet med varför din virtuella maskin inte vill boota med VirtIO som gränssnitt för diskarna:
sudo dracut --add-drivers "virtio_pci virtio_blk virtio_scsi virtio_net virtio_ring virtio" -f -v /boot/initramfs-uname -r.img uname -r
Följt av:
sudo sh -c "echo 'add_drivers+=\" virtio_pci virtio_blk virtio_scsi virtio_net virtio_ring virtio \"' >> /etc/dracut.conf"
Sedan kan du stänga ner den virtuella maskinen, avmontera hårddisken/hårddiskarna och montera upp dem igen och då välja VirtIO som gränssnitt.
Kör du Debian redigerar du filen /etc/initramfs-tools/modules och lägger till följande:
virtio
virtio-blk
virtio-ring
virtio-pci
virtio-net
Därefter kör du kommandot update-initramfs -u -v och sedan kan du stänga ner den virtuella maskinen, avmontera hårddisken/hårddiskarna och montera upp dem igen och då välja VirtIO som gränssnitt.
Windows då? Här blir det lite knepigare. Se till att alla hårddiskar är satta med IDE som gränssnitt. Skapa sedan en ny hårddisk som du kopplar till den virtuella maskinen, den kan vara en gigabyte stor eller så, som du sätter som VirtIO. Innan du startar maskinen ser du till att ha laddat ner denna ISO-fil som du gjort tillgänglig i Proxmox. Denna ISO-fil monterar du som en virtuell CD-ROM-enhet till din virtuella Windowsmaskin. När detta är gjort startar du upp maskinen.
Om du inte avinstallerat VMware Tools från servern så är det dags att göra det nu. När det är avinstallerat går du in i Device Manager, slår på visning av gömda enheter och därefter avaktiverar du eventuella andra nätverkskort som hängt med från VMware. Starta sedan om den virtuella maskinen.
Installera därefter drivrutinerna från ISO-filen med hjälp av installationsprogrammet, och installera också gästagenten som finns i samma ISO-fil. Därefter kan du konfigurera nätverkskortet med rätt IP-adress, och så vidare. Stäng sedan ned den virtuella maskinen. Slutligen avmonterar du alla hårddiskarna, monterar upp de som faktiskt hör till maskinen (du kan radera den lilla extradisken du skapade förut) med VirtIO-gränssnittet och sedan kan du starta din virtuella Windowsmaskin igen och nu ska den fungera finfint.
Övriga intryck och råd
När man går från en beprövad plattform som VMware ESXi till Proxmox och inser att ens virtuella Windowsservrar faktiskt blir snabbare på samma fysiska hårdvara och med samma inställningar i sin virtuella hårdvara så inser man snart att Proxmox och dess underliggande virtualiseringsmotor KVM sparkar stjärt. Det finns inget annat sätt att beskriva det.
Med det sagt så är Proxmox inte bara guld och gröna skogar. Jag fick exempelvis inte kopplingen mot iSCSI att fungera ordentligt i en klusterinstallation, åtminstone inte med TrueNAS som operativsystem på lagringsenheten. Jag fick därför, akompanjerat av åtskilliga svordomar, tömma iSCSI-lagringen, radera den och köra allt via NFS istället vilket har fungerat över förväntan. Om du ändå vill köra iSCSI kan det vara värt att nämna att det inte är en vidare god ide att göra detta över en LACP-trunk där du kombinerar flera 1GbE-gränssnitt till ett enda, då iSCSI vad jag förstår inte reagerar så bra på det. I mitt fall har jag 10GbE-nätverk mellan alla servrar och min lagringsenhet varför det i kombination med NFS har fallit ut extremt väl. 10GbE-switchar är så pass billiga numera så det är varmt rekommenderat att investera i en sådan om du ska nyttja nätverksbaserad lagring, oavsett om det är iSCSI eller NFS-baserad dito.
Det finns mycket annat som jag gillar i Proxmox, som exempelvis att konsolen till de virtuella maskinerna fungerar i de allra flesta webbläsare utan att bråka det minsta. Den inbyggda backuplösningen i Proxmox fungerar också riktigt bra, vilket jag är glad för eftersom backuplösningar för virtuella maskiner i VMware ESXi kan bli en kostsam, och komplicerad, historia.
Huruvida Proxmox är “enterprise ready” som de själva säger ska jag kanske låta vara osagt, men det finns en hel del kvar att jobba på där.
Exempel på det är att en server med redan existerande virtuella maskiner i sig inte kan gå med i ett kluster – rådet från Proxmox-teamet är att ta backup på alla sina virtuella maskiner, ta bort dem från Proxmox, gå med i klustret och sedan importera dem igen. Ett annat exempel är om man kör flera fysiska maskiner i ett kluster så kan samma lagringsenhet visa olika storlek så väl som olika ledig diskyta beroende på vilken nod i klustret du tittar på detta i. Ett exempel för mig var när min NFS-lagring på ena noden i klustret var på 14TB och i den andra noden var på 400GB. Det är kanske en skitsak, men för mig blir det snabbt också en fråga om ett mindre magsår – vilken av noderna visar rätt egentligen, och, kommer något bli helt galet om man skriver data till nätverkslagringen från den nod som visar fel?
En sak som irriterar mig rätt mycket är vad som visas i bilden ovan. Här håller jag på och live-migrerar en virtuell maskins hårddisk till en annan lagring. Samtidigt vill jag ge samma server mer internminne, men tji fick jag – pågår en operation med en virtuell maskin i Proxmox så är den låst för alla andra former av justeringar eller operationer. Det går inte ens att stänga av en virtuell maskin från det grafiska gränssnittet så länge en annan operation på samma virtuella maskin pågår. Tyvärr får man, om man verkligen vill stänga av en virtuell maskin riktigt jävla mycket, SSH:a in på Proxmox-servern och leta fram vilken process som kör den virtuella maskinen i fråga och döda den med kill -9 pid.
Proxmox kostar ingenting att använda, och med tanke på allt man faktiskt får så är det en trevlig lösning. Det är klart det vore trevligt med automatisk balansering i klustret där virtuella maskiner skickas till en viss nod i klustret beroende på belastning och lediga resurser i andra noder i samma kluster men då pratar vi inte bara VMware ESXi utan också VCenter, och det kostar ordentligt med penningar.
Det tog mig en vecka av pillande, meckande och trixande innan hela min VMware-installation med strax över 40 virtuella maskiner var migrerad till Proxmox. Jag kunde använda mig av en extra server jag har i racket som “mellanlandning” medan jag tömde min VMware ESXi-server så nedtiden för sajter och annat blev inte så jobbigt stor som jag först hade fruktat. Jag har inte, så här tredje gången gillt, ångrat bytet eller haft en jobbig känsla i magen som jag hade efter de två första försöken så jag hoppas (ta i trä, med mera) att detta kommer fungera väl i framtiden.