Dotaz: několik linuxových distribucí vedle sebe

[TomasABC32]

Zdravím, mám dotaz. Potřeboval bych mít vedle sebe několik linuxových distribucí. Jednu hlavní na práci, další na testování. Jak na to ? Nikdy jsem neměl na jednom PC 2 různé linuxy. Jak to řešíte vy ?

Odpovědi

[L_l]

A to přesně kolik?

1) jednu na HDD, další ve virtuálce (Virtualbox)

2) dvě distra na HDD, kde potřebujete minimálně tři diskové oddíly. Jeden pro swap, o který se budou obě distra dělit, a další dvě, přičemž v každé z nich bude ta či ona distribuce (/root).

Ale nejlepší asi bude dát si pracovní distro na HDD a testovací mít ve virtuálce. Tam jich můžete mít klidně tucet.

[TomasABC32]

uvazuji o jednom hlavním /asi Ubuntu/, protože zase nejsem ještě kdovíjakej profík. A druhý distro Debian nebo gentoo na testování a učení.

[nobody]

jestli mas CPU s VT-x (HW Virtualizaci) rozhodne (misto VirtualBoxu) doporucju libvirt/qemu/kvm, rychlost dalsiho bude srovnatelna jako bys ho mel nativne nastartovan a nebudes resit reboot, muzes klonovat systemu na tuknuti, delat jim snapshoty...

[pavele]

Virtualbox je podle mne jednodušší, než se patlat s kvm.

[nobody]

jo o chlup jednodusi ale o hrivu dementnejsi ;)

[TomasABC32]

libvirt/qemu/kvm příznám se vůbec neznám, abych se do toho nezamotal. Ta virtualizace mi připadá asi nejzajímavější...

[nobody]

uz si se zamotal...
oboje je virtualizace
virtualbox je closed source proprietarni technologie, potrebuje nainstalovane uzavrene ovladace (na strane hosta i guesta), pri kazde aktualizaci jadra je potreba rucne vyvolat kompilaci pro nove jadro, neumoznuje vytahnout z hw maximum, neumoznuje priradit realne usb zarizeni vyhradne pro guesta (vsechny nevyhody u mnou doporucovaneho padaj padaj)

libvirt je frontend rozhrani na spravu ruznych virtualizacnich a konktejnerovejch technologii
qemu/kvm je opensource virtualizacni technologie ktera je jednoduse naklikavatelna v libvirt-gui, pri pouziti qemu s "volbou" kvm se nejedna o emulaci hw, ale o "predavani" realneho hw ve spolupraci s nativnim kernelem z host systemu, muzes napriklad priradit realnou usb kameru, ctecku otisku prsti, usb flasku vyhradne virtualu, tedy host o tom prestane vedet a virtual s tim pracuje jako by to bylo nastartovane v dualbootu..,
krome klikaciho rozhrani mas az se rozkoukas k dispozici u "terminalove" rozhrani s nekonecnejma moznostma, pak treba automaticky bezi spustenej virtual jako headless(bez potrebneho monitoru), muzes zavrit okno s virtualem a on bezi dal, kdykoliv se pak k nemu vratis, lze naklikat pousteni virtualu rovnou pri startu hosta(hlavni system)

instalace je prosta:

sudo apt-get install qemu-kvm libvirt-bin

nasledne overis ze tvuj HW podporuje kvm (HW virtualizaci) pomoci

kvm-ok

pokud ne, jeste muzes zkontrolovat nastaveni v BIOS (hledej VT-x, VT-d, HW Virtualization)(btw: bez toho i VirtualBox bude slimaaaaakkkkk
no a pak uz muzes naklikavat po pusteni:

"Spravce virtualnich stroju"

[nobody]

vypadlo mi z instalace to klikatko, takze opravenej prikaz pro instlaci:

sudo apt-get install qemu-kvm libvirt-bin virt-manager

[nobody]

ten virt-manager aka klikatko vypada takto...

[Jendа]

virtualbox je closed source proprietarni technologie, potrebuje nainstalovane uzavrene ovladace (na strane hosta i guesta)

Uzavřené ovladače jsou potřeba jen pro USB 2.0.

pri kazde aktualizaci jadra je potreba rucne vyvolat kompilaci pro nove jadro

Na Debianu se to děje automaticky.

VirtualBox používám tak nějak ze setrvačnosti, protože jsem v KVM neuměl např. udělat pro desktop grafiku, která by měla nafukovací rozlišení podle velikosti okna.

[nobody]

s ovladacema mas asi pravdu, mel sem za to ze vboxhost neni uplne open, ale nejspis je a closed je nejspis jen ten pridavnej pack pro usb(2,3) a RDP...

VirtualBox taky nekde pouzivam ze setrvacnosti, ale rozhodne bych ho neradil nekomu kdo by chtel zacit s virtualizaci, preci jen prave ta setrvacnost u horsiho produktu je hrozna :)

na nafukovaci rozliseni u KVM staci balik doinstalovat spice-vdagent do guestu a pak v menu okna "Zobrazit/Scale Display/Auto resize VM with Window"

[cestovatel]

I tak díky za tipy!

Netazatelova otázka: Windows s 3D hrou mi pojede obstojně na těch nevirtualbox řešeních?

[cestovatel]

Nezatelova otázka 2: Jak to vidíte s Boxes (GNOME)?

[Fuky]

Windows s 3D hrou na plný výkon, jako kdyby jsi jen nativně, si můžeš užít díky KVM a "VGA passthrough", podrobnosti.

[lertimir]

virtualbox je součástí repozitářů openSUSE včetně zdrojáků. ale "addon" jsou patrně closed.

[TomasABC32]

díky nobody, to zní velmi zajímavě (i tak děkuji ostatním). Chci se ještě zeptat, zda to kvm pak lze nakonfigurovat, aby to distro vypadalo jako jiný počítač v síti ? Aby se s tím dalo klasicky komunikovat ... porty atd..

[nobody]

jasne, chova se automaticky jako jinej pocitac, vychozi nastaveni sitovky je "virtualni sit NAT", pokud budes chtit aby dostaval IP ze stejneho rozsahu jako host tak mu naklikas sitovku "Host device eth0" a vytvoris most (vyberes Bridge)...

[mkmm]

pokud ne, jeste muzes zkontrolovat nastaveni v BIOS (hledej VT-x, VT-d, HW Virtualization)(btw: bez toho i VirtualBox bude slimaaaaakkkkk

VirtualBox umi paravirtualizaci, takze i na stroji bez VT-x bezi guest s jednim jadrem hodne rychle. Paravirtualizovany guest mi dokonce prisel sviznejsi. Ale je to spis pozustatek minulosti, dnes uz to asi nema vyznam.

[nobody]

jasne, ale hodne rychlej slimak je porad o dooost pomalejsi nez stredne rychlej gepard ;)

[Blaazen]

Míval jsem na jednom HDD i tři distra (Kubuntu, Chakra, openSUSE) vedle sebe, disk rozdělen asi na 13 oddílů (každý distro mělo svůj /home, /, /var a /boot + společný swap). Fungovalo to skvěle, jen občas jsem musel ručně poladit grub, protože si někdy pletl / a /boot při detekci.

[L_l]

Třináct oddílů?! To je ale číslo! A zkoušel jste v multi bootu i nějaké BSD? Když tak přemýšlím, rád bych měl na svém stroji GNU/Linux i BSD.

[nobody]

to je slaby, 3 distra a ~20 oddilu sem mel i na telefonu ;)

[L_l]

Ale jen linuxová, že?

[nobody]

ano, resp. nad linux jadrem... on ma nekdo bsd klidne v singlebootu na nejakem arm telefonu ? :)

[R]

Mal som 3 alebo 4 Debiany. Ozivoval som nejaky historicky out-of-tree driver a k staremu kernelu som potreboval aj stary userspace, aby to vobec nabootovalo.

Detekcia v Grube fungovala - akurat nevie, ze pre stare kernely sa musi pouzit "linux16" namiesto "linux". A "hda" namiesto "sda" - ale to nema ako zistit.

[Andrej]

Instalací distribucí do Btrfs subvolumes. Jeden můj filesystém má například subvolume /fedora_root, /arch_root, /fedora_boot, /arch_boot, /fedora_var, /arch_var a /home. Při bootu si pak každá distribuce namountuje své subvolumes a /home se sdílí. (To někdy zaskřípe při různých verzích software, ale co už, klidně se dá vytvořit taky oddělený /home pro distribuce.) Konfigurace GRUBu je pak trochu komplikovanější, ale dá se zvládnout. V podstatě jde jen o to dát každému kernelu správné rootflags se správným subvolume. Subvolume od ostatních mount pointů už jsou v /etc/fstab. Taky je třeba dát si pozor na nastavení uživatelů a skupin, aby ta čísla byla zkrátka napříč distribucemi konzistentní. A konečně může být nutné mít víc swapovacích oddílů, pokud se má každá distribuce zvlášť uspávat na disk a probouzet. (Je celkem cool mít možnost uspat jednu distribuci, přebootovat do druhé, pak se vrátit zpátky do té původní a pokračovat od minulého stavu. To ale s jedním jediným swapovacím oddílem nepůjde.)

Tento layout má několik zásadních výhod: Zaprvé, veškerý diskový prostor je vždy k dispozici; není ho nikdy potřeba předem dělit. Zadruhé, přístup k diskům ostatních distribucí (třeba kvůli nasísnutí do konfiguračních souborů) je celkem triviální. A konečně zatřetí, jakékoliv změny jsou triviální. Přidání další distribuce je snadné, nemusí se nikde přeorganizovat žádné diskové místo. Odebrání distribuce zase vrátí místo do filesystému, prostě jako smazání čehokoliv jiného.

Problém může nastat snad jedině tehdy, pokud by se verze kernelu v různých distribucích lišily až tak, že by to například působilo problémy s filesystémem. To se ale na rozumných distribucích s aktuálními kernely prostě nestává. Mohlo by to nastat u hrůz typu Ubuntu, ale … no, zkrátka, kdo něco takového má, dobře mu tak.

[Jendа]

Mně by zajímalo, jestli by tazateli nestačil chroot. Já jsem řešil ladění jiných distribucí a jiného userspace prostě v chrootu.

[Andrej]

Mně přijde chroot málo izolovaný. Ale takový LXC kontejner, to už je ono! Je to bare metal, má to na disku obraz v adresáři, přesně jako chroot, ale dá se tomu omezit dostupná RAM a ještě pár dalších věcí. A bezproblémová podpora ve virt-manageru je nejen super, ale i hyper.

Jenom to má dva háčky. Zaprvé, kernel je samozřejmě tentýž jako u hostitelské distribuce, není to virtuální stroj. Takže pokud jedna distribuce má SELinux a druhá ne, pak to jedním směrem fungovat bude, zatímco druhým ne. Zadruhé, spustit si v tom LXC X-server je trochu voser, protože to sice přes virt-manager bez problémů jde, ale samozřejmě to není tak pohodlné jako rovnou do toho nabootovat a mít to s nativní akcelerací.

Taky je klidně možné používat ty Btrfs subvolumes jako kořeny pro LXC stroje, takže by se pak ta distribuce, která zrovna neběží přímo na železe, dala nakopnout v LXC — tedy v případě, že by ji někdo z nějakého důvodu fakt zoufale potřeboval spustit. Ale takovou věc jsem měl hodně krátce, protože mě to věčné tweakování velmi záhy přestalo bavit. Přesvědčit distribuci nainstalovanou na železe, aby nabootovala v LXC (nebo naopak) není use case, na který by někdo někdy něco optimalizoval.

Pak jsem ještě měl partition s OpenSolarisem, která bootovala z BIOSu normálně na železe, ale pod Linuxem v KVM nabootovala taky, protože jsem lineárním RAIDem spojil loopback soubor s předstíranou tabulkou oddílů, následovala partition se Solarisem (ZFS) a končilo to swap partition Solarisu (která pochopitelně byla správně zanesená v té umělé tabulce oddílů v loopback souboru). To ale byl regulární virtuální stroj s kernelem i s userspacem od Solarisu.

A nakonec si říkám, že pro několik dister vedle sebe by se tazateli nakonec nejlépe hodil virtuální stroj. Prostě by si mohl stáhnout klidně deset live médií a každé si spustit a prohlédnout z virt-managera.

[TomasABC32]

díky Andreji, asi bych to viděl na to KVM... sice pro začátečníka to bude asi trochu opruz, ale ve výsledku to stojí za to, podle místních diskutérů :)

[Andrej]

Pomocí libvirt a virt-managera to není až takový opruz. Nejlépe tyhle nástroje fungují například na Fedoře, protože některé z nich sponzoruje a vyvíjí Red Hat, ale na jiných distrech jsou samozřejmě taky k dispozici (více či méně zdařile). Výhoda je, že virt-manager přímo podporuje LXC i KVM (a dokonce i Xen), takže se dá vyzkoušet případně obojí (resp. všechno možné), a samozřejmě taky umí ke konzolím přistupovat vzdáleně. (Na to je protokol spice, který přináší spoustu zlepšení ve srovnání s původním VNC.)

KVM má výhodu v tom, že virtuální stroj má svůj vlastní kernel a že se na něm dají spouštět a instalovat distribuce, jako by to byl fyzický hardware. Tedy bez jakýchkoliv úprav, bez konfigurace filesystémů a bez nestandardních postupů instalace, které někdy vyžaduje LXC, pokud libvirt v dané distribuci instalaci LXC nezvládá. Nevýhoda KVM je, že nesdílí místo na disku tak hezky jako Btrfs subvolumes, tj. musí se mu něco vyhradit. I tady může Btrfs pomoct, protože sparse soubory s loopback „disky“ nově vytvářených virtuálních strojů se dají duplikovat pomocí copy-on-write, což šetří místo i čas, ale už tam není ta elegantní možnost zabrat v jedné distribuci 90% diskové kapacity a pak ta data přesunout bez problémů a bez externích médií „do jiné distribuce“ (do jiného Btrfs subvolume). Zkrátka, všechno má svá pro a proti. Pokud je cílem stáhnout si pár live médií a každé si nabootovat a vyzkoušet, pak ovšem KVM jasná volba.

[Jendа]

I tady může Btrfs pomoct, protože sparse soubory s loopback „disky“ nově vytvářených virtuálních strojů

Je to na FS s CoW rozumné kvůli fragmentaci?

[Andrej]

Ano, je.

Problém s fragmentací je opravdu velmi dávná minulost. Z odkazované stránky cituji: „Auto-defragment (mount option autodefrag) should solve this problem in 3.0.“

Kromě toho, pokud by byl člověk v tomto ohledu hodně paranoidní, nic mu nebrání, aby měl obrazy disků VM an odděleném subvolume — což například Fedora dělá při instalaci automaticky — a ten subvolume aby se například mountoval s nodatacow, pokud už to jde. (Pokud je nodatacow ještě stále globální, musel by být celý filesystém nodatacow, nebo případně by musel existovat pro VM úplně oddělený filesystém, ne subvolume.) Bez nodatacow se ale (pokud se nepletu) ztratí několik výhod, například možnost používání cp --reflink.

Po duplikaci disků virtuálních strojů pomocí CoW (buď cp --reflink nebo snapshot nějakého subvolume) samozřejmě celkem nutně nějaká ta fragmentace vznikne, jak se postupně disky začnou lišit, ale řekl bych, že pokud ten virtuální stroj neplní úlohu NASu (což by bylo hodně překvapivé) nebo databáze, výhody Btrfs nakonec převažují. A na SSD asi v podstatě není co řešit.

Když už jsem zmínil tu databázi, na jednom z mála problémů se už pracuje a ani rok předtím to nebylo tak zlé. („First from a performance standpoint btrfs is a fine choice of filesystem for Postgresql tables, potentially yielding 2x tps gain in space sensitive applications on magnetic disks compared with EXT4.“)

[Andrej]

s/Bez nodatacow/S nodatacow/

[Jendа]

Z odkazované stránky cituji: „Auto-defragment (mount option autodefrag) should solve this problem in 3.0.“

S volbou autodefrag jsem si právě teď pěkně naběhl. Pokud je pod btrfs MD pole, s touto volbou furt seekuje (jak to defragmentuje). Když se to pole rebuilduje/checkuje, tak to běží šííííleně pomalu (jako třeba pětinovou rychlostí). Takže, ne-e.

[Jendа]

(nehledě na to, že bych čekal, že neustálé zběsilé seekování snižuje životnost)