Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 1

1.1.2015 14:32 | Přečteno: 2758× | Linux | | poslední úprava: 1.1.2015 14:32

Nakonec jsem zápisek rozdělil, dnes tedy: Popis výchozí situace – Hardware – UEFI – Odemykání LUKS přes SSH – KVM síťování – KVM s btrfs a 9pfs. Pokračování zítra a pozítří.

Začalo to koncem září. To jsem se konečně dostal k prvnímu kroku dlouho zamýšlené akce – postavit si domácí servřík. Skončilo to koncem prosince (téhož roku). To jsem mohl první krok prohlásit za dokončený…

Výchozí situace – aby to nebylo tak lehké

Běžel tu starý Kanashimi, který vedle své „hot-spot“ funkce de facto funkci jednoduchého serveru (torrent, CUPS, SSH, Squid pro balíčky) plnil. Jenže hardware byl zneužitý z téměř deset let starého desktopu, včetně tehdy skoro herní grafiky. Bylo to hlučné, žravé a vzniklo to postupnou evolucí a flikováním systému z 32bitového notebooku. Zejména po loňské koupi zrcadlovky se začaly objevovat úkoly, které by se na Kanashimi řešily blbě. Prostě by to chtělo vytvořit archiv fotek, nějak elegantně a řízeně ho nasdílet do zbytku domácí sítě a možná částečně i ven. Časem na to nabalit další služby.

Co tedy s tím?

• Doflikovat Kanashimi – koupit disky a dle aktuální energetické situace to provozovat spíše „on-demand“.
• Sestavit nový server Makoto a současné Kanashimi používat nadále pouze jako „hot-spot“ v „on-demand“ režimu.
• Sestavit nový stroj Maboroshi a virtualizovat na něm jak Kanashimi, tak i Makoto.

Nakonec jsem se rozhodl pro variantu 3). Díky virtualizaci by se měl hardware využít efektivněji (výkon, spotřeba, prostor). Z nového hardwaru budou těžit i domácí uživatelé Kanashimi. A člověk si vyzkouší něco zajímavějšího než v ostatních variantách. Umístěním serveru na místo Kanashimi však bude tento na očích chronických vypínačů všeho blikajícího a běžícího (čti ostatních členů domácnosti). No snad se to podaří překonat domluvou…

Aby se to celé udělalo ještě zajímavější, rozhodl jsem se to celé rozdělit do několika fází:

• Základní hardware (CPU, RAM, deska, SSD) a úvodní konfigurace (Maboroshi, Shin-Kanashimi, Makoto – pouze nyní provozované služby).
• Dodatečný hardware (datové disky) a dodatečná konfigurace (Makoto – věci kolem archivace fotek a jejich sdílení v domácí síti).
• Další rozvoj služeb na Makoto.

Hardware

Mělo by to být úsporné, rozumně výkonné, rozumně levné, prostě takové klasické protichůdné požadavky Virtualizace potřebuje alespoň základní podporu v procesoru. Protože používám diskové šifrování a SSH, hodila by hardwarová akcelerace AES. Poučen z minula politikou Intelu k procesorovým fíčurkám, koukal jsem rovnou po AMD. Jak tak teď koukám, tak se možná i u Intelu blýská na lepší časy.

Co jsem tedy vybral:

• APU: AMD Athlon X4 5350 (4×2,05 GHz, virtualizace, AES),
• Deska: Asrock AM1B-ITX (AM1, 4×SATA 3 – toto moc desek pro AM1 nemělo, tak jsem skousl i to ITX s pouze 1×PCIe, GLAN),
• RAM: 2×4 GB (má to jen jednokanálový řadič, ale mohlo by se to hodit jako posila do desktopu),
• SSD Intel 520 (120 GB na systémy).

Nějakou dobu jsem hardware nekupoval, takže mě zejména ceny RAM nepříjemně zaskočily, jinak bych šel do 16 GB, ať je dost místa na kešky.

Software

Zatímco složit skládačku a přendat ji do bedny od Kanashimi bylo „piece of cake“, při instalaci systémů a jejich nastavení jsem (oprávněně) očekával řadu výzev. Tyto se navíc ukázaly náročnější, než má pesimistická očekávání (ano, tento kognitivní bias nádherně funguje). Samozřejmě, všude bude Arch Linux.

Maboroshi v1

Výchozí idea: Nabootuje to přes UEFI, půjde tomu odemknout LUKS přes síť, bude to používat btrfs (pododdíly a snapshoty), každý KVM host bude pod vlastním běžným uživatelem, KVM hosty budou moct na síť a budou dostupné ze sítě.

UEFI – jde to i „bez zavaděče“

Deska má UEFI, UEFI znamená GPT, nebo legacy mód s MBR. Úkolem nebylo pouze to zprovoznit, ale také se něco naučit… Vzhledem k tomu, že konfigurace GRUB2 s GPT je poněkud specifičtější, rozhodl jsem se vyzkoušet EFIStub – když máte štěstí a přidáte správnou položku do UEFI menu, nabootujete systém bez klasického zavaděče.

Nejprve je potřeba vytvořit EFI oddíl (cca 512 MB FAT32) připojený jako /boot:

# gdisk /dev/sda a typ oddílu EF00
# mkfs.fat -n UEFI-mab -F32 /dev/sda1
# /etc/fstab, genfstab se činí:
LABEL=UEFI-mab  /boot  vfat  rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro  0 2
					

Z EFI CDčka (v mém případě flashky) Archu (při bootu je potřeba vybrat UEFI režim instalačního média) lze pak přidat příslušnou položku do EFI menu (zde již v podobě po všech peripetiích):

efibootmgr -d /dev/sdb -p 1 -c -L "Arch Linux GUI" -l /vmlinuz-linux -u "cryptdevice=/dev/disk/by-uuid/789f95ae-f182-4cab-a5c9-c11bb8c18455:maboroshi_ssd_luks root=/dev/maboroshi_ssd_lvm/btrfs rootflags=subvol=maboroshi_root rw initrd=/initramfs-linux.img ip=192.168.1.20::192.168.1.254:255.255.255.0::eth0:none net.ifnames=0 quiet init=/usr/lib/systemd/systemd systemd.unit=graphical.target"
					

Zádrhel v mém případě ovšem je, že se mi nedaří přidat do EFI více jak jednu vlastní položku.

Odemykání LUKS oddílu pro root přes SSH

Protože používám diskové šifrování (LUKS), hodilo by se, kdyby bylo možné odemknout oddíly vzdáleně. Že to lze, vím díky Bystroushaakovi. V Archu (AURu) je to hezky pořešené, takže není třeba provádět žádné velké harakiri. Stačí nainstalovat dropbear_initrd_encrypt z AURu, nahrát veřejný klíč do dropbearu, přidat ip parametr do konfigurace zavaděče (viz výše) a povolit háčky net, dropbear a encryptssh v /etc/mkinitcpio.conf (opět finální verze):

HOOKS="base udev autodetect modconf net block keymap consolefont keyboard dropbear encryptssh lvm2 btrfs filesystems fsck"
					

Pro odemčení oddílů pak stačí ssh root@maboroshi – používají se systémové klíče z OpenSSH, takže je i jistota, kam se člověk připojuje.

KVM síťování, netctl a systemd

Instalace QEMU/KVM je pokrytá na Arch-WIKI. Pro každého KVM hosta jsem založil vlastního uživatele qemu-kanashimi a qemu-makoto a přidal je do skupiny kvm. Tato skupina se už sice nepoužívá, ale systemd dá odpovídající oprávnění jen přihlášeným uživatelům – tehdy jsem se ještě nechtěl hrabat v UDEV pravidlech.

Protože nepůjde jen o virtuály na hraní, je potřeba vystavit je do sítě přes bridge. V Archu používám na nastavení sítě netctl, který staví na systemd. Pomocí něj lze spustit jak samotný bridge, tak i virtuální síťovky pro KVM hosty (QEMU si sice umí nahodit virtuální síťovky samo, ale to není čisté, navíc pak chce „nemístná“ oprávnění):

#/etc/netctl/bridge-maboroshi 
Description="Bridge connection for maboroshi and VMs"
Interface=br0
Connection=bridge
BindsToInterfaces=(eth0 tap0 tap1)
IP=static
Address=('192.168.1.20/24')
Gateway='192.168.1.254'
DNS=('192.168.1.254')

#/etc/netctl/tap-makoto 
Description='Tap device for makoto'
Interface=tap0
Connection=tuntap
Mode='tap'
User='qemu-makoto'

#/etc/netctl/tap-kanashimi 
Description='Tap device for kanashimi'
Interface=tap1
Connection=tuntap
Mode='tap'
User='qemu-kanashimi'
					

Příslušné zařízení se pak KVM hostovi předá takto (ještě že má Arch dobrá fóra):

-device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:01 \
-netdev type=tap,id=net2,ifname=tap0,script=no,downscript=no
					

KVM, btrfs a 9pfs – první slepá ulička

Zde jsem se poprvé spálil. KVM potřebuje dostat blokové zařízení, ale já měl pouze pododdíl na btrfs. Dát tomu práva na celý btrfs svazek hostitele není dobrý nápad. Existuje však jakýsi 9pfs, který se používá na obousměrné sdílení adresářů mezi hostitelem a hostem.

To by vypadalo nadějně, jenže… Existuje několik módů, jak se v takové situaci vyrovnat s právy:

• security_model=passthrough – jaká práva na hostu, taková na hostiteli (jenže obyčejný uživatel na hostiteli samozřejmě nemůže vytvářet soubory s právem roota z hosta, a pouštět kvůli tomu KVM pod rootem nechceme).
• security_model=mapped – práva z hosta se na hostiteli uloží do rozšířených atributů nebo do skrytých souborů (jenže to bylo jednak šíleně pomalé a aby toho nebylo málo, tak navíc locale-gen na hostu sice bezchybně proběhl, ale žádné lokály nevygeneroval. A co se systémem bez lokálu…).
• security_model=none – stejné jako 1) jen to nehlásí chyby.

Nějaké to googlení neodhalilo nic moc povzbudivého, tak jsem se rozhodl takticky ustoupit.

       

Komentáře

[Špekáček z Intersparu s hořčicí Alba+]

Do toho Athlona bych nešel, radši nějaký Celeron (TDP 55W, reálná spotřeba v zátěži tak 30, v idle to bude skoro stejné) na bázi Haswellu. Sice vás může mrzet, že ten křemík umí AES, HT, turbo a AVX a Intel vám ho uměle vypnul, ale to je jenom pro pocit. Pocit je lepší ignorvoat a koukat jenom na užitnou hodntou. Výkonnostně je Haswell/Celeron mnohem lepší a stojí to taky málo - kdežto ty APU do AM1 jsou na svoje schopnosti trochu předražené. Jo a jako bonus je Intel grafika s otevřeným ovlem.

To říkám jako fanda AMD. Jako úplně špatné to AM1 není (laciné fošny, možná i výkon, kdyby fakt byla čtyřvláknová aplikace nebo vyoužití AES-NI), ale IMHO se to nevyplatí pořizovat. Je to takové blbé že koupíte novej komp, a on má výkon skoro jak něco z před 10 let...

P.S. A někdy za pár let se třeba do té desky s LGA 1150 bude dát čtyřjádro, pokud by bylo třeba - a je z toho skutečný počítač.

[tgm]

...Zádrhel v mém případě ovšem je, že se mi nedaří přidat do EFI více jak jednu vlastní položku...

Myslím, že v tomto případě jich tam víc nedostaneš.

[Nicky726]

No v samotném EFI jsou vidět položky dvě, ale v té druhé zůstává boot přímo z disku. Dynamicky se pak přidají další položky, pokud se připojí flaska. Ještě jsem to prohlížel a zdá se, že žádné magické zatikávátko „přidej víc položek“ nepřehlížím.

[Nicky726]

Zrovna s tím AESem to není pocit. Mám tu desktopové Sandy Bridge i3 @3,30, notebookové Ivy Bridge i3 @1,40 a scp je na nějakých 50–60MB/s (a CPU na notebooku jede naplno), zatímco při kopírování na ten Athlon to saturuje GLAN (a Athlon naplno zdaleka nejede). A řekl bych, že se v mém použití AES-NI užije, protože LUKS a scp.

Stejně tak si myslím, že se užije více jader, protože LUKS z více disků a měla by zbýt jádra na aplikace.

Btw. AMD grafika má též otevřený ovladač. Z mého hlediska (hýbání s okýnky v KDEčkách a přehrávání videjí) stejně dobrý jako ten Intelí.

Jinak jasně, to co jsem nahrazoval byl morálně desetiletý Athlon 64 1×2 GHz, toto je 4×2,05 GHz, a i když jsou lepší paměti, a nějaké nové instrukce (a z hlediska užívání tomu značně pomáhá SSD), tak bych taky čekal trochu víc za těch deset let.

Na rozšiřitelnost jsem zvědavej. Toto je z hlediska APU do daného socketu dnes maximum, jestli tam půjde strčit příští generace nevím. Zas ale můžu říct, že z dosavadních desetiletých desktopových zkušeností jsem upgradoval paměti, disky (+SSD) a do jednoho kompu jsem dodával TV kartu a čtečku paměťovek.

[Špekáček z Intersparu s hořčicí Alba+]

Příští generace tam asi strčit nepůjde, bohužel. A pokud ano, tak to stejně budou jen čtyřjádra, takže nic moc nárůst výkonu se čekat nedá.

S tím AES je to pravda, ta isntrukce má obrovský dopad, pokud se použije při šifrování. Já ji moc neřeším, jelikož je to pro mě dost (hodně) podružná věc a jiné aspekty výkonu jsou mi důležitější (singlethread, SIMD/multimédia...). Ale pokud je šifrování jednou z předních úloh, tak to asi jo.

[trekker.dk]

křemík umí AES, HT, turbo a AVX a Intel vám ho uměle vypnul

A virtualizace zůstala zapnutá?

[Špekáček z Intersparu s hořčicí Alba+]

No, tyjo... http://ark.intel.com/products/78955/Intel-Celeron-Processor-G1820-2M-Cache-2_70-GHz

Skoro to vypadá, že jo. Teda VT-x, na VT-d člověk IIRC potřebuje Core i7/i5 (ale nesmí to zase být odemčený model IIRC).

[trekker.dk]

To mě docela překvapuje, ale na druhou stranu ještě je tu základní deska, která ji může vypnout. Mám tady pod stolem Core 2 Duo - virtualizaci to má, deska od Intelu ji vypíná, aby náhodou zákazník nedostal něco navíc. Je to jeden z důvodů, proč se Intelu vyhýbám, kde to jde.

[pavlix]

Je to jeden z důvodů, proč se Intelu vyhýbám, kde to jde.

To bych i chápal, ale ve prospěch jakého výrobce? Zatím mám dojem, že je Intel bezkonkurenční v oblasti kompatibility s Linuxem.

[Aleš Kapica]

To tedy není. Osobně preferuji AMD. Příznivá cena, žádné problémy a i když to z hlediska výkonu není špička tak na drtivou většinu věcí bohatě stačí. Navíc nemusím řešit otázku zda CPU podporuje virtualizaci, nebo ne.

[pavlix]

Jen CPU nebo i v obecné rovině? Jak je to dneska s grafickými čipy AMD, už je všechno na open source driverech, KMS a funguje to tak hladce jako Intel? A co integrované grafické čipy? Třeba na běžné používání preferuju některý z běžných ThinkPadů s intelovským procesorem, integrovanou grafikou a chipsetem, protože vím, že s tím nebudou potíže. Na serveru toho samozřejmě není tolik co zkazit, takže tam bych to s AMD třeba zkusil.

[Aleš Kapica]

V notebooku mám grafiku co je v jádře, opensource drivery a 3D v pohodě. Dokonce funguje líp než u externí AMD graficke karty co mám v domácím stroji. Bohužel nabídka notebooku s AMD chipsety a bez OS je obecně dost tristní.

[oleg]

Pokud máš v obchodě známýho tak si okna nechají a notebook ti bez problémů prodají se slevou pár tisíc. Tam získáš notebook laciněji a bez OS. A někdy ani nemusíš mít známýho v obchodě a de to taky, ale trošku složitěji.

[xkucf03]

Můžeš být trochu konkrétnější? Zrovna tenhle problém řeším. Můžeš mi poslat třeba e-mail přes zdejší profil. Ale myslím, že taková firma by zasloužila publicitu, takže není třeba to držet v tajnosti.

[xkucf03]

Bohužel nabídka notebooku s AMD chipsety a bez OS je obecně dost tristní.

Ale u těch s Intelem je to snad ještě horší…

[trekker.dk]

No nevim, teď jsem jenom v rychlosti nakoukl na web CZC a 20 notebooků s Intelem vs. 4 s AMD (OS FreeDOS.)

(Taky tam za notebook vydávají tablet s Androidem a klávesnicí, fuj.)

[trekker.dk]

No, s open source ovladačem mi na AMD moc nejdou graficky náročné simulační aplikace (tzv. hry.) Ale musím se přiznat, že jsem se moc nesnažil to zprovoznit, mám koupenou licenci na Zavaděč na hry od MS a dualboot. Všechno ostatní funguje naprosto v pohodě, jádro s klidem ignoruje moje vga= a konzole se automaticky nastaví do nativního rozlišení monitoru. X.org všechno v cajku, přepínání mezi konzolí a X serverem (nebo mezi X servery) bez problémů a bez problikávání.

Co se grafiky týče, Intel u mě uplatnění nenajde, dokud nezačnou vyrábět grafické karty, které zvládnou víc než Word a přehrávání videa, takže nemůžu soudit.

[Dreit]

Před nějakou dobou jsem narazil na stránku, kde někdo testoval VirtualBox na CPU od Intelu. Nejvíc mě fascinovalo, že se zapnutým VT-x to bylo pomalejší než bez něj.