Virtualisering + ZFS + VGA passthrough? För desktop/arbetsstation

Jag planerar ett bygge av en arbetsstation att ha som desktop med Linux/unix i "botten" samt virtualiserad windows. Jag vill också experimentera med VGA passthrough till windows för att kunna komma åt 3d-hårdvaran, och samtidigt köra ZFS med spegling på diskarna. Så jag vill gärna ha input från er som har koll på virtualisering!

Jag har tänkt bygga runt Asus KGPE-D16 alternativt Tyans motsvarande med samma chipset (AMD sr5690).

Idealsetupen vad gäller diskarna är:
2x ssd/10krpm-diskar för systemet + virtuella images för guests
2x större diskar för lagring
Spegling på allt (även systemdiskarna), helst ZFS-baserat så långt det går.

Jag tänker mig en linuxbaserad XEN/KVM med två guests: Windows 7 (HWM) + Solaris 11 express (pv). Två alternativ:
Alt. 1) Använda linuximplementationen av ZFS och låta hypervisorn (linux med XEN eller KVM) hantera diskarna, alltså köra ZFS åtminstone på lagringsdiskarna men helst också på systemdiskarna (om det går?).
Alt. 2) Moderkortets sata-raid1 och ext4 på systemdiskarna, och ZFS på lagringsdiskarna genom Solaris (mha pci-passthrough eller iSCSI).

Alt. 1 hänger på hur långt gången linuximplementationen av ZFS är. Hur "mår" ZFS på linux i dagsläget? Går det öht att köra XEN + ZFS i samma linuxkärna? Finns det förslag på andra lösningar som kombinerar ZFS och virtualisering med VGA passthrough?
Alt. 2 borde gå men gör att systemet blir mer beroende av Solaris-gästen samt att jag inte får checksummning av data på systemdisken. Så jag föredrar alt 1.

Jag hade helst kört Solaris i botten, men Oracle verkar ha lagt ner xVM som var OpenSolaris XEN-implementation, plus att VGA passthrough nog aldrig haft stöd där. Men misslyckas jag med VGA passthrough så kör jag nog istället Solaris 11 express direkt på hårdvaran och Windows 7 under virtualbox. Så får jag spela på sambons dator, eller leva med det klena 3d-stödet i virtualbox.

Engelska wikipedia har en lista på zfs-portar med zpool-versionsnummer: http://en.wikipedia.org/wiki/ZFS (längst ner). KQ-implementationen verkar ha zpool version 28, vilket jag antar är rätt ok. Återstår att se om den är så funktionell och stabil som phoronix-artikeln antyder, det vore ju trevligt isf!

I samma tabell på wikipedia står att den fungerar med kärnor upp till 2.6.32. Jag antar att det är för att den är en 3rd-party-modul, varför de inte kan garantera att den funkar med alla kommande kärnor. Det finns ju licensproblem att inkludera ZFS "native" i linuxkärnan tyvärr.

Dock verkar ju XEN 4.0.1 vara baserad på samma kärna, 2.6.32. (http://wiki.xensource.com/xenwiki/XenDom0Kernels). Det kan ju vara ett gott tecken, så långt.

Basse: FreeBSD har ju haft ZFS-stöd ett tag, problemet där är att det inte har något vidare stöd för att vara virtualiseringsvärd. Så det faller bort av den anledningen.

NetBSD däremot har ju XEN, men deras ZFS var visst experimentell för ett år sedan och jag vet inte om den fortfarande utvecklas...

saddam: Jag har varit försiktig med att hoppas för mycket på OI så här tidigt, men det verkar absolut på det du beskriver som att potentialen finns. Tyvärr är det ju alltid lite skakigt med nya forks och jag har fattat det som att de delvis är beroende av oracle ännu. Men det är absolut lovande, på sikt. Fixar de tillbaka XEN och dessutom får till VGA passthrough så är nog OI mitt första alternativ, den dagen.

Dualboot körde jag med i många år, men det var rätt irriterande eftersom jag fyllde alla mina X-desktops med fönster som alla hade diverse ”projekt” i, vilka jag fick starta om efter varje boot. Så nu när jag igen ska bygga en lite mer seriös maskin så vill jag gärna kunna köra båda parallellt. Jag kommer absolut att hålla er uppdaterade om hur det går, inte minst blir det en till tråd inför att hårdvaran ska beställas.

Som det ser ut nu så verkar alltså XEN/linux2.6.32 med KQ-infotech’s tredjepartsmoduler vara det som är närmast en lösning. Återstår att se om de spelar tillsammans (och i förlängningen om jag alls får ordning på VGA passthrough)!

ronnylov: under zfs-web/dev-ref i källkodslänken hittade jag en pdf - om det är så enkelt som den beskriver så är det bara att köra ett script som laddar ner allt och kompilerar. Det hela verkar hyffsat välstrukturerat, så det skulle kunna funka out-of-the-box.

Jag vet inte hur petigt det är med kernel-versioner dock, det finns ju en stor risk att det är viktigt. Wikipediasidan för zfs hävdar ju att KQ-versionen funkar med kärnor upp till 2.6.32, men jag vet inte om det är för att det är vad den är testad med eller om det finns någon anledning varför den inte ska funka med 2.6.37 tex. Men funkar det inte så visar det sig nog vid kompileringen eller åtminstone när modulen ska laddas in, så testa gärna! Jag ska också testa vid tillfälle, måste bara installera linux någonstans först.

Av deras korta FAQ under git så framgår också att de inte stöder root-fs på ZFS och att de inte planerat detta inom överskådlig framtid. Vilket man ju kunde misstänka också...

Nu har jag testat KQ-infotechs zfs-implementation i Ubuntu Server 10.04 under virtualbox. Jag har testat med mirror över två virtuella diskar och zraid över tre, samt kollat att den fixar om man tar bort en disk från vardera array. Jag har inte testat runt särskilt mycket alls, bara kollat att det funkar. Några prestandatester har jag inte gjort heller då det inte känns så meningsfullt under virtualbox.

En grej som jag upptäckte när jag testade ta bort diskar i virtualbox var att även om man kan specifiera sata-kanal för varje virtuell disk, så möblerar linux om diskarna i /dev baserat på hur många som finns. Om disk1 sitter på sata1 och disk2 sitter på sata2 (i virtualbox) så blir disk1 = sda och disk2 = sdb (i linux). Men tar jag då bort disk1 i virtualbox, och låter disk2 sitta kvar på sata2, så kommer linux ändå att räkna upp befintliga diskar från början så att disk2 blir sda istället för sdb (eftersom disk1 som var sda inte längre finns). Det ställde till vissa problem i zfs-poolen eftersom zfs väntar sig att sda, sdb etc. motsvarar fysiska inkopplingar (sata-kanaler). Jag har inte varit med om problemet i linux förr, möjligen kan det vara specifikt för sata, eller någon bug i virtualbox (jag använder version 3.1.8, inte den nyaste). Det kan i alla fall vara värt att tänka på om man testar.

Installation och kompilering:

Jag installerade Ubuntu Server 10.04 (LTS) med de mest generiska inställningarna, inga konstigheter. För kompileringen följde jag instruktionen på https://github.com/zfs-linux/zfs-web/raw/master/dev-ref/documentation.pdf. Det visade sig att instruktionen redan byggde på exakt den kärna som är default i Ubuntu Server 10.04 (2.6.32-24), så det var nog närmast optimala förhållanden. Scripten i instruktionen talar om hyffsat pedagogiskt ifall man saknar något paket. Utöver gcc fick jag installera bland andra gawk, zlib1g-dev och uuid-dev (kan ha glömt någon).

Två saker jag behövde göra som inte var enligt instruktionen rakt av:

1) På två ställen i instruktionen finns en rad:
> ./configure --with-linux=/lib/modules/2.6.32-24-server/build --with-spl<här tar raden slut, antagligen en bug från när PDF:en genererades>
Raden ska sluta med: --with-spl=/sökväg/till/spl (spl = sun portable layer, första programmet man bygger i instruktionen)

2) 'make install' i katalogen lzfs (längst ner på sid 6 i instruktionen) misslyckades för mig först och klagade på att libspl.so.0 inte kunde hittas, jag fick köra 'ldconfig' och sedan fungerade det. Antagligen så har något tidigare steg uppdaterat filerna i /etc/ld.so.conf.d men utan att köra ldconfig så att linkern läser in informationen. (libspl och de andra libbarna installeras i /usr/local/lib).

Slutsats: Man kan närapå säga att det funkar out-of-the-box, med reservation för att jag inte testat andra linuxkärnor och inte heller mer avancerade zfs-features än jag beskriver ovan. Root på ZFS verkar som sagt inte finnas stöd för och är inte heller planerat.

Det börjar vara hög tid att avrapportera detta projektet, som jag lovade här ovan. Det har ändå varit igång i över ett år, hårdvaran köptes dec 2011, med undantag av några mindre ingivelser av "fixing what works" så har den varit min primära allt-i-allo maskin sedan juni 2012. (Jan 2012 - juni 2012 ägnades mest åt testande, första stabila konfen som hade all funktionalitet jag ville ha med var från juni).

Nov-dec 2011 beställde jag:

• Supermicro H8DG6 (versionen med SAS-controller)

• 32Gb ecc-ram

• 2st Opteron Magny-cours 6134 (8core@2.3GHz) dvs 16 cores totalt.

Sedan innan dess hade jag:

• Radeon 6850

• Seasonic X750

• snikigt Geforce

• diverse hdd

• hembyggd låda i MDF med fläktkanaler för ljuddämpning, 2 + 2 schyte gentle typhoon 120mm i push-pullkonfiguration.

Processorerna hittade jag till hyfsat pris på ebay, jag hade först tänkt använda Interlagos (bulldozer-opteron) men då desktopmodellerna hade issues vid lanseringen så valde jag att vänta och se. Jag är dock inte så beroende av hög klock i det jag gör så jag kör nog på dessa två ett bra tag till. Mobo + minne drog jag från Mullet. Ovanstående byggdes ihop i januari (2012), därefter tillkom diverse prylar allt eftersom. Nuvarande conf:

Hårdvara

• Mobo, proppar, ram, nätagg: samma som ovan

• Intel 320 ssd 120Gb (systemdisk)

• 8st fujitsu/toshiba 300Gb sas 2,5" 10krpm hdd (lagring)

• 1st Radeon 6850 (som ovan)

• 1st firepro v4900

• Texas instruments USB controller

Hårddiskarna och firepro-kortet är köpta begagnade på blocket/tradera.

Mjukvara

• xen 4.1.3 (virtualiseringsplattform)

• Xubuntu 12.10 (egentligen en vanlig ubuntu där jag bytt skrivbordsmiljö), med zfs-ppa

• Windows 8 64bit (virtualiserat med dedikerat 6850 samt USB-controller)

Radeon-kortet och USB-controllern är dedikerade till windows med PCI/VGA passthrough. Xubuntu är dom0 samt desktop, win8 används i första hand för spel. Sedan kör jag en KVM-switch för att kunna hoppa mellan OSen. Alla mekaniska diskar kör på zfs, jag har en spegel 1 + 1 samt en zraid2 4 + 2. SSDn kör ext4. Win8 bootar från en sparse volume som ligger på zfs-spegeln. Denna konf har varit igång sedan november 2012, och den funkar felfritt till allt jag vill göra.

Tidigare mjukvara
Ovanstående conf är dock sedan november 2012. Innan dess hade jag en något mer komplicerad config med xen 3.1.2, gentoo linux som dom0, virtualiserad freebsd med SAS-controllern via PCI passthrough för att hantera zfs, och virtualiserad windows 7 med passthrough av 6850 samt usb-controllern. Win7 bootade då från en SSD-partition men fick en sekundär disk via iSCSI från freebsd (zfs-volym). Denna konf övergav jag dock, av huvudsakligen två anledningar:

1. FreeBSD frös ca 1 gång /månad så att jag fick resetta den. Eftersom den servade den mesta datalagringen (tex hemkataloger) så var det handikappande att starta om den, den krävde också några besvärliga fulhack för att boota ordentligt. Frysningen fick jag aldrig någon förklaring till, men en anledning kan vara att jag körde originalfirmware på SAS-kontrollern trots att folk med liknande conf på nätet rapporterade mer framgång med en annan firmware. Men jag iddes aldrig byta firmware.

2. Windows 7 fungerade visserligen bra efter första boot, men om windows rebootat utan att hela maskinen bootat om så tappade jag grafikprestanda pga att kortet inte resettas som det ska. Då visste jag inte vad problemet var, dock strax efter att jag bytt till nuvarande setup så fick jag reda på lösningen från andra med samma problem. Jag har funnit dels att felet beror av valet av toolstack för xen (xl har problemet men inte xm, ni som kör xen vet vad jag menar), dels att det finns en workaround som fungerar. Men när jag märkte det hade jag redan bytt.

Utvärdering (nuvarande conf)
Nu med Xubuntu och win8 fungerar dock allt som jag vill. En anledning att jag bytte till *buntu var att jag visste att zfs fungerade bra och är välsupportat. Även om zfs fungerar med gentoo så är det alltid ett orosmoment med rolling-release dist ju mer komplex konf man har. Det enda jag saknar just nu är att xen har problem med proprietära grafikdrivare, vilket gör att mitt firepro i linux presterar under vad det borde (men opensource-drivarna är såklart politiskt trevligare). KVM hade varit mer flexibelt vad gäller drivare i linux, men det enda grafikkort jag känner till som fungerar felfritt med PCI passthrough under KVM är ett radeon 6770, vilket är lite för långsamt för min smak i spel. Jag testade KVM i samband med bytet till xubuntu, det fungerade fint förutom med vga passthrough (vilket är ett krav för mig).

Grafikprestanda (radeon 6850 i windows 8, 4 cores, 8Gb ram):

• Cinebench 11.6 opengl: ca 38fps

• Unigine heaven 4.0 (1920x1080 max settings): 320-330p

• Unigine heaven 4.0 (1600x900 max settings): 410p

I win7 hade jag jämförbar prestanda. Har inte testat windows baremetal på denna maskinen, men samma kort i sambons phenom2 910e 4x2.6GHz ger 422p i 1600x900 extreme. Alltså 12p mer, det kan bero på virtualiseringen men det kan också bero på 300 fler MHz per kärna.

Temperaturer (idle): Nordbryggor 50-60 C, cpuer 40-50 C. De 10 gradernas skillnad beror på om jag dammsugit luftintaget nyligt, vilket jag gör ca 1 gång / månad. Jag har ett filter där som i princip håller lådan dammfri. Vid belastning är nordbryggorna de som blir varmast, som en följd av att temperaturen stiger i lådan och de har sämst kylning. Jag har fått hänga upp en fläkt för dem, vilket normalt inte ska behövas.

Diskprestanda: Har inga exakta siffror men det är acceptabelt rakt igenom. Specialiserade drivrutiner (GPLPV under windows) gör stor skillnad dock, både för diskaccess och nätverk. Motsvarande under freebsd heter PVHVM och funkar bra det också.

Lärdomar från projektet hittills:

1. Xen utvecklas mycket snabbare än det dokumenteras, det är inga problem att hitta information, det som är svårt är att avgöra om informationen är uppdaterad. Jag råkade ut för en hel del trial and error innan jag hade läst ikapp maillistorna där den mest aktuella informationen ibland uteslutande finns. Det är lätt hänt att ta något man läser på en wiki för sanning utan att veta om det gäller nu eller om det gällde 2010.

2. Xen 4.1 duger gott till vga passthrough. Man måste köra xm-toolstacken, som är den gamla, om man vill slippa besvär med reset av grafikkort vid omboot av VM. Den nyare xl-toolstacken har problem med reset, även i xen 4.2 (jag vet inte hur det är i 4.3).

3. Xen har problem med proprietära grafikdrivare i dom0 (eller mer korrekt: proprietära grafikdrivare har problem med xen). Relevant om man använder linux till något som helst grafikintensivt. Undantaget om man har grafikhårdvara från intel, då intel själva levererar open-source-drivare som är bra.

4. TRIM mot virtuella diskar fungerar inte från windows under xen, även om den virtuella disken ligger på en ssd. Därför är det o-optimalt att ha windows på en ssd om man kör virtualiserat via xen. Jag hade så först men då jag inte kunde få TRIM att funka så flyttade jag windows till en volym på zfs-spegeln. (Däremot ext4 på en virtuell disk fungerar med TRIM, åtminstone om den virtuella disken utgörs av en LVM-volym.)

5. AMD-hårdvaran för virtualisering, IOMMU, som är ett krav för PCI passthrough, är tyvärr ofta buggig. Diverse workarounds och biosuppdateringar kan behövas.

Slutligen, skulle jag börja om från början med detta projektet så hade jag inte försökt ha filserver i samma maskin som linux/win desktop. Jag hade satsat på ren desktop med XEN, linux och windows på enklare hårdvara med endast en CPU-sockel, kärnorna räcker. SAS-diskarna hade jag skippat och kört SSD + hybriddisk för VMar. Jag hade också skippat den hemmabyggda lådan och satsat på konventionellt metallchassi med svaga fläktar och stora kylflänsar. Det sista eftersom trots 180 graders fläktkanaler så har jag svårt att få hemmabygget tyst, med dagens komponenter så vinner man inte på att ljudisolera. Ljudet från 10krpm-diskarna släcks effektivt men dovare frekvenser som fläktarnas brummande kommer igenom. Det man vinner på ljudisolering måste man ta igen i luftflöde.

Du förstår rätt, ett dedikerat kort till varje. Ffa för att det är bekvämast och jag då kan växla mellan mina båda desktops fritt. Just radeon-drivaren (open-source drivaren för radeon-kort) har också det problemet att den inte kan "unbinda" kort, har drivaren väl bundit kortet så kan den inte släppa det utan kernel panic. Det är en bugg i drivaren, men tillsammans med att radeon är den enda drivare som fungerar i dom0 med xen så är det svårt att växla radeon-kort mellan dom0 och en domU. Detta leder också till att man kan behöva lite moduljonglering vid boot för att inte radeon-drivaren ska claima kortet innan xen reserverat det för passthrough. Däremot, om man vill slippa detta problem eller använda den proprietära fglrx-drivaren, så går det förmodligen att ha en minimal dom0 med passthrough av kortet till en domU med linux. En möjlig setup är alltså dom0 + (linux domU + kort nr1) + (win domU + kort nr2), denna setup har jag inte testat men skulle vilja någon gång när jag har tid.

I början av 2011 var det dåligt med AMD-grejer som hade IOMMU, det var bara sr5690-nordbryggan som endast fanns till Opteron-socklarna. Men jag tror att sedan Bulldozer så finns även AM3+kort som har det.

saddam: SmartOS ser mycket lovande ut, jag testade det tillfälligt ganska nyligt. Som du säger körs det från USB-sticka, dock tar den lite plats på diskarna i anspråk för swap, inställningar mm. Det kräver minst en disk vid installationen som den gör till sin, skapar en pool och några filsystem. Resten av poolen kan såklart användas till vad man vill. Men jag testade egentligen inte mer än att installera, så jag vet inte så mycket om systemet i övrigt. Hade SmartOS klarat VGA passthrough hade jag kört det istället, men det är knappast något de kommer att prioritera givet att det är skräddarsytt för servervirtualisering. Jag testade det på min nas-burk i jakt på något som klarar zfs feature flags och inte är linux (för variationens skull). Men eftersom burken ska vara nas så fann jag få poänger med SmartOS, så nu drar jag in Freebsd 8.4 istället. Den ska i princip bara ta emot snapshots via ssh från den andra maskinen.