Om du vill skicka mig elektronisk post så går det bra.
Och om du vill tillbaks till huvudsidan ska det nog också gå för sig.
DilOS är ett Solaris-derivat med flera på pappret lockande egenskaper. Precis som med alla andra Solaris-derivat borde jag egentligen skriva att det är Illumos-baserat, men risken känns överhängande att bara den redan intresserade har hört talas om Illumos.
Nå, DilOS är alltså en slags Solaris. Det betyder att det har fungerande ZFS, vilket alla som läser den här bloggen borde veta är något jag gillar. Sen har det också stöd för att vara Xen dom0, vilket andra någorlunda moderna Solaris-derivat inte verkar tro på att vara längre. Och dessutom använder det samma pakethanteringsverktyg som Debian. Hur skulle det kunna vara dåligt?
På nästan alla sätt visar det sig. Såklart. När jag ursprungligen testade det var det absolut enda sättet att lyckas installera det att ha det på en snurrande plastbit. Läsare för dylika är inte något jag typiskt har i mina datorer. Inget problem vid dom allra första testerna, då jag körde under VirtualBox. Men på riktig hårdvara var det klart opraktiskt. (En USB-inkopplad CD fungerade inte, även om jag ska erkänna att jag senare fick det att fungera med en annan sådan enhet.) Men för närmare två veckor sedan nu kom det en version som kan installeras från en USB-sticka. Framtiden, redan 2014!
Nå, installerar OSet gör man ju inte så ofta, det är väl inte så farligt om den proceduren suger lite. Eller mer än lite om man verkligen vill ha in det på en maskin utan CD, för ett annat litet problem ökar på svårigheterna här: Så som är typiskt för Solaris-derivat gillar den inte alls om hårdvaran ändrar sig (PCI-IDt på SATA-kontrollern t.ex.). På alla andra Solaris-derivat bootar man i räddningsläget (som har ett minimalt system i en ramdisk) och kör hårdvaru-magi-scriptet. I DilOS fungerar tyvärr inte räddningsläget (på någon hårdvara, vad jag kan märka). Tur att USB-installationen (inklusive ett fungerande (eller iaf bootbart) räddningsläge) finns numera.
Och sen var det det här med paket-hanteringen. Jag råkade köra
apt-get update && apt-get upgrade. Vilket ju är en utmärkt sak
att köra på en normal Debian. Men inte på DilOS alltså. Den försökte
uppgradera libc, vilket misslyckas (för Solaris låter dig inte ersätta
libc-filen). Tyvärr misslyckas den på ett sätt som raderar allt den kommer
åt ur paketet som misslyckades. Tror jag. Systemet bootade iaf inte
efteråt.
Den korrekta hanteringen är att göra dina uppgraderingar i en icke-körande bootmiljö. Tyvärr gjorde jag det där uppgraderingsförsöket precis när jag installerat, så jag hade ingen tidigare bootmiljö att gå tillbaks till och fick installera om maskinen. Annars är en tidigare bootmiljö ett helt okej alternativ till fungerande räddningsläge så länge du är kvar på samma hårdvara och har sett till att skapa en extra bootmiljö.
Och apropå bootmiljö så gjorde jag misstaget att installera på speglade diskar. Detta är nämligen något installationsprogrammet har stöd för. Det är bara bäst att inte använda det stödet, för då kan man inte skapa nya bootmiljöer. Att däremot lägga till en disk att spegla systemet på efter installationen fungerar smärtfritt. Så där blev jag tvungen att installera om igen.
Men lite lidande får man tåla. Jag vill verkligen gärna ha en Xen dom0 med välfungerande ZFS. Så jag biter ihop och försöker köra DilOS ändå. Jag installerar Xen (eller xVM som det naturligtvis heter i det här fallet) och tänker optimistiskt att den här biten säkert fungerar perfekt!
Tyvärr fanns det några små skönhetsfläckar även här.
Mitt första problem är att nätverket (för hela maskinen) dör när jag startar en
domän. Det är faktiskt ett helt fatalt problem, som det är svårt att gå vidare
från. Riktigt varför detta händer vet jag inte, men det går faktiskt att komma
runt: Rör inte nätverkskortet i dom0, och ge det till exakt en domU. Denna kan
sedan vara brandvägg för både dom0 och andra domU. (Skapa virtuella
nätverkskort för denna kommunikation med dladm create-etherstub
xenswitchN, och kör även dladm set-linkprop -p mtu=1500
xenswitchN om du gillar att det fungerar.)
Tyvärr menar jag inte PCI passthrough när jag säger att jag ger
nätverkskortet till en domU, om detta stöds under DilOS så saknas all
dokumentation som skulle låta mig faktiskt använda det. Men att bara köra
ut den som vif = ["bridge=bge0 ... fungerar iaf fint så länge
inget annat redan rört nätverkskortet (eller senare rör nätverkskortet).
När jag senare satte i ett till nätverkskort i datorn kunde jag också konstatera att detta problem inte drabbar det nätverkskortet (rge0). Vilket ju är både bra och förvirrande.
Och sen ville jag få mina domäner att starta automatiskt vid boot. Detta
görs med xm new konfigfil, och så oroar man sig inte över var
informationen lagras (för det är bäst så under Solaris). Bara ett enda
litet problem: xm new fungerar inte. xm create
fungerar fint, så jag kan skapa domäner bäst jag vill, men dom försvinner
vid omstart. Lyckligtvis är problemet trivialt: Tydligen används en annan
XML-parser (PyXML) vid new än vid andra xm-kommandon. Denna finns inte
paketerad för DilOS, men jag kan installera den för hand, inga problem.
Och sen vore det fint om domänerna fungerade ordentligt också, det vore det. Men nej. I NetBSD (som är det jag vill köra) får jag oroväckande meddelanden i stil med
xbd0: WARNING: cache flush not supported by backend
vilket betyder att jag ska oroa mig över vad som händer med min data om strömmen går.
Kör jag däremot Debian (med dess vanliga Linux-kernel) får jag inga liknande klagomål. Däremot ser jag något relaterat och ganska förvånande i min dom0 när Linux använder disken:
WARNING: non-BLKIF_OP_FLUSH_DISKCACHE is seen from domain 5 with zero length data buffer!
Va? Var det inte just den operationen NetBSD klagade på att den inte fanns? Och vad är det Linux skickar som inte är FLUSH_DISKCACHE men som Linux nog tror är det?
Dags att gräva i sourcen. Jag gör det på NetBSD-sidan, för den är lättast
för mig att förstå mig på. Jag tittar i
sys/arch/xen/xen/xbd_xenbus.c och hittar i funktionen
xbd_connect att den läser ut
<disk>feature-flush-cache ur xenstore, och bara om den
finns och inte är 0 kommer den skicka BLKIF_OP_FLUSH_DISKCACHE.
Givetvis finns den inte. Med viss svårighet lyckas jag lista saker i min xenstore och titta efter vad som faktiskt finns där. (Jag tittar i dom python-script xen själv använder, men när jag försöker göra samma saker fungerar det inte. Det visar sig att dom inte fungerar med systemets standardpython, man måste köra /usr/bin/amd64/isapython2.7 istället.)
Så jag listar alltså vad som finns under
/local/domain/0/backend/vbd/1/51712 i xenstore. Där finns
mycket riktigt ingen feature-flush-cache, men där finns
feature-barrier. Jag testar att läsa ut den på NetBSD-sidan.
Jodå, den syns även där och är 1.
I sys/arch/xen/include/xen-public/io/blkif.h så finns det inte
bara BLKIF_OP_FLUSH_DISKCACHE utan även
BLKIF_OP_WRITE_BARRIER. Jag testar att läsa
feature-barrier och skicka BLKIF_OP_WRITE_BARRIER
istället. Det ger absolut intryck av att fungera, fsync blir
mycket långsammare. Och jag får samma meddelanden i dom0 som jag fick från
Linux.
Men dom0 verkar ju faktiskt tro att den stödjer
BLKIF_OP_FLUSH_DISKCACHE, eller hur? Lösningen är nog att
lyckas få in detta i xenstore istället. Så hur skriver man till den? Varför
finns inte feature-flush-cache redan där? Jag ändrar på
/usr/lib/xen/scripts/vbd-default:
--- vbd-default.orig Tue Apr 22 00:47:29 2014
+++ vbd-default Sun May 11 14:06:58 2014
@@ -55,6 +55,10 @@
exit 1
fi
+ if [ "${type}" = "phy" ]; then
+ xenstore-write ${path}/feature-flush-cache 1
+ fi
+
do_permissions "${file}" "${mode}"
vbd_connect
;;
Och nu kan jag använda en omodifierad NetBSD-kernel utan att den klagar, och cache-flushning verkar faktiskt fungera också.
Inspirerad av att det där scriptet tydligen har tillgång till ett
xenstore-write-kommando hittar jag
/usr/lib/xen/bin/amd64/xenstore-ls som är klart praktiskare än
python-modulen. Använd den om du själv vill titta i xenstore.
Snart vågar jag nog köra något på riktigt på den här maskinen. Alldeles jättesnart, så fort jag kan lura mig själv att det inte finns fler idiotiska problem med den.
| Föregående | Nästa |