Jak udělat klonovanou VM opravdu novým strojem (KVM)

20.12.2013 10:15 | Přečteno: 2015× | Linux | | poslední úprava: 21.12.2013 19:27

Pokud se VM naklonuje, a to v zásadě na jakémkoliv virtualizačním řešení, tak je to jen někdy až nebezpečná kopie té mašiny původní. Aby s ní byla opravdu jiná mašina, je třeba udělat různé zásahy, které se liší případ od případu. Hezké je například pokud klonované stroje používají stejné klíče pro ssh server, bo někdo je zapomněl přegenerovat (nebo schválně to neudělal…). A taky díky mému (ne)smyslu pro nevím co, jsem mučen, pokud vidím stejné vg jména v různých strojích, a co teprve, že uuid není unikátní.

No a protože, jak mám ve zvyku, když nenajdu nic uspokojivého, tak něco stvořím. Tentokrát jsem stvořil něco jako post-klonovací script, řekněme modulární formou.

Zaměřil jsem se na věci, které momentálně potřebuji/chci měnit:

• hostname - změna jména stroje (neřeší věci „pošťáků“)
• postfixname - změna jména stroje - postfix (doplněno 2013-12-21 19:15)
• mac - aby síťovka zůstala a naběhla (udev atd.)
• sshd - zmíněné klíče ssh serveru
• ps1set - nastavení PS1 (promptu)
• rootPasswd - změna hesla root-a
• vgname - změna vgname
• vguuid - změna vguuid
• sshRootClear - known_hosts a authorized_keys
• swapiness - nastavení hodnoty swapiness
• sshdIpv4only - ssh naslouchat jen na ipv4
• postfixIpv4only - postfix jen na ipv4 (doplněno 2013-12-21 19:15)
• ipv6disable - nepovolit ipv6 komunikaci
• ip6tablesBlock - blokovat vše na ipv6

Pokud někoho vnitřně znepokojuje odřezávaní ipv6, prosím nekamenovat, ale ignorovat (o to primárně nejde, stejně tak to může odřezávat ipv4 když se to připraví).

No a bo píšu modulární, tak tím myslím, že cokoliv lze použít a cokoliv vyřadit a taky cokoliv doplnit.

Řekl jsem si, že udělám, co rozumě lze „z venku“, tak „z venku“, tedy než se stroj vůbec pustí. Což je hezké, ale nutí to pak pracovat na root-a, což na hostiteli není moc příjemné a uklidňující - nu což, budou Vánoce, smířil jsem se s tím. Disk daného stroje připojím poměním co najdu, a co je komplikované nebo až téměř nemožné změnit z venku, vygeneruji do skriptu, který se spustí na první přihlášení root-a (,a který na svůj závěr odstraní svoje spuštění a sám sebe).

Zatím to zkouším, ale vypadá že to něco dělá a dokonce to co jsem chtěl. V úvahu jsem bral jen CentOS a Debian, jiné mě zatím nezajímá, uvádím, že centos, rhel, fedora stejně jako debian, ubuntu, mint je totéž, ale nijak jsem to nezkoušel. Zkoušel jsem jen a pouze centos a debian, tipl bych, že fedora by si svou novostí oproti centos vynucovala nějaké úpravy. Zavaděče to upravuje jen grub a grub2. Ssh klíče se pro centos jen mažou (bo se samy vytvoří při spuštění), u debian se smažou a na root login, se balíček překonfiguruje, pro jiné (což jsem nijak nezkoušel), by se měly vygenerovat pomocí ssh-keygen. VG name se mění až po prvním přihlášení na root-a, kdy se přegeneruje i initrd.

A použil jsem i již zmiňovanou věc na XML dokumenty, takže není třeba instalovat žádný balíček navíc, používá si to na čtení XML vlastní, vlastními chybami postižené a neudržované řešení :). No a taky jsou tam použité ty barvičky a generování PS1.

Opět úplně někde jinde jsem to uložil ke stažení.

Myslel jsem si, že je skvělý nápad udělat ukázkové video - není (už to vím) - ale už je hotové a těch 20+ minut jen tak nezahodím, tak jsem ho nahrál i na trubku (i se záměnou never mind za never mine). Upozorňuji, že je zbytečně dlouhé, zbytečně rozvláčné (tedy nudné) a moc se musí dávat pozor aby „člověk“ pochopil, co tam „autor“ dělá.

2013-12-21 19:15 - doplněno druhé video jen s CentOS, které už lze shlédnou, je krátké - stručné.

Spustit cizí skript na produkčním stroji/hostiteli na root-a (bo jinak to moc nelze) vyžaduje velký kus odvahy. Byť jsem se snažil to hlídat, a ošetřit na několika úrovních, aby nedošlo k nějakým zvláštním událostem, neznamená to, že k nim nedojde…

V module.conf jsou dvě pole:
VPI_MODULES, které definuje použité moduly
VPI_BAN_VGS je jeden z bezpečnostních prvků, je to pole VG názvů, které jsou vždy po připojení disku VM a prohledání nových VG ignorovány - vyplní se VGs hostitele, ale není nutné pole vyplňovat.

       

Komentáře

[GandY]

Prečo meníš názov volume group-y? Má to nejaký zmysel pri "interných" diskoch?

[Šangala]

Protože pak si je můžu libovolně přehodit (což se může hodit třeba u datové části, asi ne přímo u systémové VG) a můžu si danou VG (potažmo LV) připojit i do hostitele nebo kdekoliv jinde bez rizika, že dojde ke konfliktu jmen, což je vždy potíž (navíc pokud mají i stejné UUID).

[Aleš Kapica]

Ehm..

Já mám už všechny virtuály udělané jako diskless. Vytvoření nového stroje znamená zhruba tolik..

• Na straně NFS serveru udělám snapshot subvolume kde je systém. Změním hostname a podle potřeby upravím fstab
• Zkopíruji spouštěcí skript pro qemu, ve kterém upravím parametry sítě
• Veškerou konfiguraci řeším přes puppet, takže do něj přidám bový nod a upravím export NFS
• Nabootuji, vygeneruji nový klíč pro puppet agenta a je vymalováno.

[Šangala]

Je jedno, jak se se mašina naklonuje, jestli přes managera, virsh, kopií LV a spoustou dalších možností - to není předmětem ani jestli jsou na NFS či LVM based či raw disky.

Předmětem jsou právě ty ostatní body a může jich být víc a je třeba je všechny udělat.
Takto je to automatizované a během 2.5min (fčul jsem si to stopl 155 sec) vše provedeno od stavu „existuje vypnutý klon“ do stavu „vše potřebné je nastaveno a běží nový stroj“ (vše potřebné = viz výše uvedené) v čase jsou zahrnuty i zadávání jména či dvojí zadávání nového hesla (bez definice vlastních barviček, jen zvolení typu PS1).

[Aleš Kapica]

Zásadní rozdíl je v jedné věci - historie stroje. Já ji mám tímto podchycenou od bodu nula. Veškeré změny a úpravy konfigurace lze pak dohledat přes historii v gitu. Trvá to sice o něco déle, ale až jednou někomu budu stroje předávat nebude v situaci jako jsem byl před pěti lety já, kdy nikdo nevěděl nic.

[Šangala]

Zásadní rozdíl je jinde, porovnáváš jak to děláš a co daný skript (ne)řeší. Nechci znít jako gramofonová deska, ale to s tím nijak nesouvisí, sám píšeš

…Změním hostname a podle potřeby upravím fstab… …Zkopíruji spouštěcí skript pro qemu, ve kterém upravím parametry sítě…

…chybí tam třeba „upravím udev pravidla“ pro síťovky…

A to to řeší, ne to, jak ty změny zachytáváš. Často ty změny zachytit ani vůbec potřebuješ, protože se jedná jen o template stroje a de-facto je to pak výsledný stav stroje „nula“.

[Aleš Kapica]

Chybí to tam proto, protože to není třeba.

Jen pro ilustraci ukázka toho spouštěcího skriptu..

qemu-system-x86_64 \
-daemonize -machine accel=kvm -cpu kvm32 \
-m 512 -monitor unix:/tmp/7006.monitor,server,nowait \
-kernel /boot/x32bit/vmlinuz-2.6.32-4-686 \
-append root=/dev/nfs boot=nfs \
ip=10.0.0.106:10.0.0.3:10.0.0.255:255.255.255.0:x32bit:eth0 \
nfsroot=10.0.0.3:/srv/share/virtual_machines/x32bit,tcp,rw \
console=ttyS0 -initrd /boot/x32bit/initrd.img-2.6.32-4-686 \
-drive file=/dev/mapper/data-swap--x32bit,if=virtio,index=0,cache=none,media=disk,format=raw \
-net nic,vlan=1,macaddr=be:be:be:00:70:06,model=virtio \
-net vde,vlan=1,sock=/tmp/virtual_switch_0 \
-net nic,vlan=2,macaddr=00:0c:29:9e:1d:61,model=virtio \
-net vde,vlan=2,sock=/tmp/virtual_switch_4 \
-serial file:/var/log/x32bit.log

Síťové rozhaní do interní sítě vůbec žádnou konfiguraci uvnitř virtuálu nemá. Po startu se spustí puppet agent, který si skrz ni ze serveru stáhne všechno ostatní a mimo jiné také nahodí síť do vnějšího světa na druhém ethernetovém zařízení.

V případě že chci stroj instalovat od naprosté nuly, tak nepoužiju btrfs snapshot, ale nakrmím adresář pro systémový disk přes debootstrap.

[Šangala]

No vidiš a jsi spokojený. Já ne, já su téměř spokojený z toho co sem zrobil, z toho uváděného mi naskakuje husí kůže (pro správné pochopení „z představy, že bych to tak musel dělat pokaždé“).

Stroj udev pravidla dle MAC mají by default a chci je tam a jsou ve strojích nested LVM (stroje jsou na LV), protože je ho tam třeba a nechci mít všude stejné vgname a spoustu dalších uvedených i neuvedených věcí. Stejně jak nemám (a nechci) btrfs, tak nemám puppet či něco podobného (protože po zralé úvaze to nevyhovuje), nechci se zabývat na první pohled složitou definicí, ale jen používat před-připravené template strojů - ve finále bude jen clone template_name newname, který lze spustit s 3 promile.

Prostě moc nechápu o čem se bavíme, děláš si to jak potřebuješ a myslíš si že je to tak nejlíp, možná je, to já nevím, a neřeknu ti to, ale určitě to tak dělat nebudu , dělám to jinak a evidentně z toho cítím, že úplně s jinými potřebami.

[Aleš Kapica]

Proč se o tom bavíme? Vždyť je to přeci jasné. Každému vyhovuje něco trochu jiného a takhle se může dozvědět jak to děláš ty, i jak to dělám já. Sám se pak rozhodne co v konečném důsledku pro něj může být výhodnější řešení. Jen pro úplnost bych uvedl že pro postup co děláš ty existuje rovněž již hotové řešení - vagrant.

[Šangala]

Tak to potom jo, to je pak jasné ;), měl jsem pocit, že se úplně míjíme a každý chceme mluvit jen o svém...

Vagrant mi unikl, dík, a není jen na hraní děckám (provokace vyjadřující antipatie k VirtualBox-u :o) ), existuje plugin, myslím, že to neposkytne to, co bych chtěl, ale musím si to projít detailně.

[Agent]

Co máš proti Virtualboxu? Nemyslím to nikterak provokativně, já mám zkušenost jen s nim. Ale já provozuju jen 2 virtuály a tohle klikátko mi stačí.

[Šangala]

To by bylo na dýl, ale zjednodušeně několikrát jsem si s ním v minulosti chtěl nahradit VMWare Workstation a několikrát nejen, že mě mě zklamal, a (ne)fungoval ve srovnání s VMWW tak jak bych očekával a možnosti byly omezující (USB, Grafika, Unity mode, sitě), tak jsem si s ním i naběhl a rozhodil si další věci (třeba i proto, že správce balíčku měl špatně vyřešené závislosti, což sice nebyla přímo chyba VB, ale pro mě to byly „problémy“ s VB). Prostě ho mám zařazený pod čáru rozdělující „na hraní“ a „na práci“, ale věřím, že spoustě lidí vyhovuje.

[citanus]

Moc pekne. Mohl byste sem/nebo nekam hodit ukazku konfiguraku pro puppet? Chystam se zrovna resit neco podobne, uvazoval sem kickstart, ale todle vase reseni vypada taky moc pekne vcetne nfs nad btrfs snapshotem.

[Aleš Kapica]

Rád bych, ale řešení je natolik komplexní že to dost dobře nelze. Mohu akorát odkázat do manuálu k Puppetu v naší wiki, kde se snažím ty věci dokumentovat.

Ale určitě bych mohl být nápomocen při vytvoření vaší vlastní konfigurace. Ve zkratce - využívají se při tom moduly:

1. network - který se stará o to aby každý stroj měl správnou konfiguraci
2. basic - který instaluje základní sadu balíků a stará se o vytvoření administrátorských účtů, přičemž spolupracuje s modulem..
3. ssh - co instaluje ssh server, klíče atp.
4. nfs - se stará soubor exports a nfs-kernel-server

A pak jsou tam další moduly, které řeší vlastnosti konzole (prompt a uložení historie příkazů) aj. Řeším přes to nejenom virtuály ale také ty virtualizační a datové stroje. Některé moduly jsou vyloženě specifické pro naše prostředí.

[citanus]

diky za odpoved i odkaz. Moc rad se podivam..

[David Jaša]

Zní mi to jako cloud-init (btw nedávno zaintegrovaný do oVirtu ).

[Šangala]

Na první pohled ano, ale na druhý je to sice řešení obdobného problému oblečeného v jiném kabátě, nicméně tímto jsem nechtěl modifikovat balíčky a pod. (i když by to také šlo), ale nastavení. Terminálově a s minimální možností omylu, ale zas ve výrazně větší šíři možností.

Přístupem mám 'template VM' tak, jak potřebuji, tzn. ze vším už připravený/udržovaný, naklonuji jej a změním specifické nastavení - jistě a rychle.

Jinak toto je mnohem jednoduší, ale velmi jednoduše lze dodělat jakoukoliv další věc a už fčil to dělá o kus víc věcí.

[Šangala]

Video porovnáni cloud-init vs. virt-post-install (mimo zvuk jsou tam rozdíly i jiné :)).