Dotaz: Virtualizace - jen LVM nebo LVM na LV

[Šangala]

Ahoj.
Pokud máte virtualizaci s „LVM hosty“, a potřebujete oddělit jednotlivé fs/adresáře ve virtuálkách (/,/tmp,/var,/home…), tak jsou dvě základní možnosti, jsou to tyto tři:

• A) vytvořit v hostiteli jednotlivé LV a připojit je do virtuálky,
• B) jeden LV pro virtuálku a vytvořit „nested“ LVM ve virtuálce, pro případný swap LV ve virtuálce,
• C) dva LV pro virtuálku a vytvořit „nested“ LVM ve virtuálce, pro případný swap LV v hostiteli.

Naklonovat lze cokoliv ze stejným úsilím a i pro zálohování tam není téměř rozdíl (pominu-li, že rozdíl mezi B a C při „raw“ zálohování celého LV dané mašiny, kde u C není swap zálohován). Pro administraci, se mi A) nelíbí a zatížení „nested“ LVM-kem je snad téměř nula. Kterou možnost prakticky a reálně používáte (na serverech), a proč? …předem dík.

---

---

Odpovědi

[Šangala]

No asi se zas na B a C vykašlu, bo s tím klonováním to není tak úplně pravda, u B a C už nestačí opravit/zkontrolovat síťovku a smazat /etc/ssh/ssh_host_*, ale nabádá to něco udělat minimálně s vg uid a vg name.

[Sten]

virt-manager tohle všechno vyřeší. U B je potom míň klikání.

[Šangala]

Jsem si myslel, že to dělá stejně jako virt-clone, tzn. jen MAC adresu změní a tedy ve VM vznikne nové eth a je třeba si to zpravit, ssh klíče zůstávají, VG, LV uid se ani nedotkne.

[Šangala]

PS: spravuji to během poslouchání zpráv ;)

[Sten]

Spouští to virt-clone.

Aha, vy chcte změnit VG a LV UID uvnitř toho virtuálu? Tak to neumí, mění LV UID jenom na hostiteli.

[Šangala]

Jo to jo jasné, bo to vytvoří nové LV (zarazilo mě, že clone se ani nezeptá, nebo neupozorní, pokud je v konfiguraci klonované mašiny zadán natvrdo port pro VNC, takže předpokládám, že to opravdu jen umí vytvořit nové úložiště, změnit MAC a zkopírovat data).

Jde o to, že po klonování s „nested“ LVM krom změn minimálních, jako eth/nové klíče ssh/hostname, by bylo vhodné změnit alespoň VG UID a VG name - při připojení „nested“ LVM z hostitele by to mohlo způsobit potíže, a vůbec to pak není UID, nebo tedy je to UID, ale jen ve svém malém vesmíru a v jakémkoliv jiném vesmíru je to zdroj problémů…

[Šangala]

Myslím, že to nemůže řešit, bo by rozbil proces boot-ování, podobně jak jsme třeba tady diskutovali. To by musel zasahovat velice sofistikovaně se znalostí OS ve VM.

Jen na vysvětlení:
Zatím si to nemůžu zkusit/ověřit, nikdy jsem ho nepoužíval, terminál stačil (okýnkové managera jsem kdysi dávno, s XEN-em následně s VirtualBoxem, zhodnotil, že je to na nic, ale doba a virt. nástroje se změnili), no a fčul na daném stroji bude virt-manager až v jednom virtuálu, na hostiteli je jen nezbytné minimum. No a na jiném PC s Debian-em při snaze nainstalovat virt-managera se chtěla instalovat snad půlka všech existujících balíčků :( a víc se tím zatím zabývat nehodlám, virt-viewer či přímo jen connect do console v této fázi plně stačí.

[Pev]

Kdysi jsme používali CentOS právě s virt managerem, bylo to dost pohodlné, umělo to KVM i Xen (oboje bylo potřeba) . Myslím, že to na CentOS má méně závislostí než na Debianu.

[Šangala]

Jo, tam je to v pohodě, tam to lze nainstalovat samostatně naprosto bez potíží - a i bude, ale až ve virtuální mašině, na kterou nedošla ještě řada .

[Šangala]

Preferuji B, protože mám jedno LV na virtuál, takže většina operací (zálohování, klonování, přesun, smazání) je snažších. Z hlediska výkonu je to úplně jedno.

[Šangala]

Taktiez preferujem B kvoli operaciam s jednym LV per virtual.

[Šangala]

Zkušenosti mám jen s A), asi u toho zůstaneme - nevidím moc přínos v B) a C), spíš komplikace.

[Šangala]

Zatím prohráváš 2:1, z logiky věci jsou u B),C) počáteční komplikace (vg-uuid, vg-name), ale zas na druhou stranu, mašina se stará sama o sebe a případné úpravy se dějí jen s danou mašinou a není třeba přístup přes hostitele, ten je přidělí zdroje.
Opravu úvodních komplikací lze zařídit, což si ještě zautomatizuji a pokusím se tlačit, až na vyjímky, do B)

[martin]

Pouzivam kombinaci - na hostovi vytvorim lv pro virtualni stroj a ten cely pridelim tomu stroji, v guestovi pak toto lv rozdelim (boot, swap, root). Pro objamna data (napr. databaze) vytvorim na hostovi dalsi lv podle toho kolik jich potrebuji pro guesta (napr. pro Oracle lv pro data, lv pro mirror logy, lv pro archlogy apod.). Vyhoda je, ze se k datum jednoduse dostanu z hosta.

[Šangala]

Takže B , jen s tím, že pro speciální data připojíš další LV - to jsem už nerozepisoval, ale beru to jako B), C) protože je to třeba i na jiném úložišti a tak…, šlo mi hlavně o tu VM a početnější dělení, například z rizika zaplnění /var, či jiné sady mount parametrů apod.

Vyhoda je, ze se k datum jednoduse dostanu z hosta.

Ke kterým?, k těm na speciálním LV, ale to je pak bod spíše pro řešení A), jinak dostat s k datům na nested LVM je jen jeden řádek navíc - což samozřejmě může být důvod…