Fórum Root.cz
Hlavní témata => Server => Téma založeno: Rike 24. 09. 2024, 13:09:06
-
Zabýval se tu někdo v poslední době porovnáním, která virtualizace je z hlediska výkonu, spotřeby zdrojů (paměť apod.), ale i UX efektivnější? Jestli ve Windows 11 virtualizovat (např.) Ubuntu, nebo v Ubuntu prostřednictvím VM Windows 11?
Moc jsem se Windows v poslední době nezabýval, ale všímám si, že jejich tah na implementaci (WSL) či provoz (Hyper-V) Linuxových distribucí stojí za povšimnutí, a nechci opakovat již prozkoumané chyby ;)
-
Osobne odporúčam na železe Linux, a v tom QEMU/KVM (virt-manager) s Windows. Hyper-V je dosť problematický a mnohé veci nedotiahnuté. U WSL1 je to len "obmedzený" kontajner, ani nie virtuálna machina, a neumožňuje beh mnohých nízkoúrovňových Linux programov. WSL2 je už skutočná virtuálna machina, a má svoje výhody. Najväčšou výhodou sú manažment okien (ktoré sa tvária ako natívne app Windowsu), premostenie súborového systému ako aj siete, kedy môžeš ľahko pristúpiť ku kontajnerom na WS spojení z Linuxu vo Windows. Na druhú stranu, čo sa týka prostriedkov a manažovania virtuálky ako takej, tak virt-manager je výrazne pokročilejší. Samozrejme by default, je riešenie QEMU/KVM pomalšie v prípade Windows (musíš povoliť určité špecifické konfigurácie), ale po nastavení je to fakt asi to najlepšie čo môžeš teraz mať.
-
Volil bych ten zaklad podle toho, co je tvuj "matersky jazyk" - jako duverne znama / stabilni platforma, coz by melo byt stejne jako - kde se odehrava vetsina tve prace s pocitacem. To druhy pak patri do virtualky, ktera se bude vyuzivat mene a experimentalne - takze nedava smysl to mit naopak a proti srsti.
-
hledas porovnani na doma nebo do firmy? Pokud do firmy tak zalezi na tom jake sluzby provozujes. Jina situace bude kdyz budes mit 10 serveru na kterych ti bude bezet nejaky windows a k tomu 300 VDI stroju s windows a 5 linuxu a jina situace bude kdyz budes mit 10tis linux serveru a 2 windows 10 stroje....
-
pouzivam oboje, s obojim nemam problemy, ale detailni porovnani vykonu jsem si nedelal.
-
Volil bych ten zaklad podle toho, co je tvuj "matersky jazyk" - jako duverne znama / stabilni platforma, coz by melo byt stejne jako - kde se odehrava vetsina tve prace s pocitacem. To druhy pak patri do virtualky, ktera se bude vyuzivat mene a experimentalne - takze nedava smysl to mit naopak a proti srsti.
hledas porovnani na doma nebo do firmy?
Je to do práce, na vývoj. Potřebuju kus odtud a kus odtamtud. Těžko se mi opouští třeba M$ Outlook (ten starej, ne ten 365; Linux nabízí jen velmi slabé záplaty), stejně jako potřebuju pro práci víc a víc Debianu. V zásadě je mi tedy jedno, které prostředí poběží jako hlavní, a které ve virtualizaci (než mne doběhne nějaký problém, který mi tu ideu zhatí), ale po měsíci jsem dospěl k závěru, že dva stroje (nedejbože dualboot) jsou prostě blbost a situaci je nutné vyřešit elegantněji. Dal jsem si tedy spíš kritéria obecnosti a perspektivnosti dalšího směřování (vyvěštit, co bude za rok, pět let) vybraného řešení.
-
Pokud jsi zvyklý na Win a nepotřebuješ v tom Debianu dělat nějaké složitosti (záleží, jestli Ubuntu, nebo Debian?), tak bych asi koukl po kombinaci Win + WSL2 s výchozím Ubuntu, nebo si doinstaloval Debian (https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows/SubsystemForLinux). Efektivně to znamená, že pracuješ ve Windows ale pouštíš to, co děláš, v Linuxu. A až když se ukáže, že to nestačí, tak začít řešit klasické virtuálky.
Edit, ještě mě napadla varianta dvou strojů s remote access. Nevím, jak moc to je či není vhodné řešení a co přesně ti na dvou strojích vadí, ale jednak můžeš mít vzdálenou plochu a druhak na spoustu scénářů stačí nějaká forma síťově sdíleného disku + ssh do linuxu. Ale možná jsi tohle už zkusil a zavrhl.
-
Pokud jsi zvyklý na Win a nepotřebuješ v tom Debianu dělat nějaké složitosti (záleží, jestli Ubuntu, nebo Debian?), tak bych asi koukl po kombinaci Win + WSL2 s výchozím Ubuntu, nebo si doinstaloval Debian (https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows/SubsystemForLinux). Efektivně to znamená, že pracuješ ve Windows ale pouštíš to, co děláš, v Linuxu. A až když se ukáže, že to nestačí, tak začít řešit klasické virtuálky.
Mají ty věci jako WSL2, Hyper-V budoucnost? M$ do toho dost šlape, co jsem tak sledoval chronologii. Nerad bych vsadil na mrtvého koně. Ono to třeba bude fungovat, ale utrhne to větráček chladiče:-)
Dva stroje/remote access fakt ne. Nelíbí se mi to a výrazně to snižuje celkovou mobilitu resp. zvyšuje nároky na přenos, který v některých situacích nemusí být zrovna ideální.
-
Edit, ještě mě napadla varianta dvou strojů s remote access. Nevím, jak moc to je či není vhodné řešení a co přesně ti na dvou strojích vadí, ale jednak můžeš mít vzdálenou plochu a druhak na spoustu scénářů stačí nějaká forma síťově sdíleného disku + ssh do linuxu. Ale možná jsi tohle už zkusil a zavrhl.
Remote access delam v kombinaci s virtualkou WinXP. Tahle VM bezi na stroji ktery se jeste menekrat restartuje nez muj bezny desktop, takze tam muze zustat rozdelana prace, resp. nejaky vynuceny pad desktopu neohrozi ty precitlivele win.
Ale vzniklo to spis historicky - remote jsem pouzival prave ve smyslu jaky navrhujete, jako prechodne obdobi. Ale krok po kroku to doputovalo nakonec do VM, a je o dalsi notas, adapter, kabely mene neporadku.
-
Dlouhý léta dělám s VirtualBoxem, HyperVčkem, posledních asi 10let s VMw ESXi, a začínám s QEMMU/Proxmox.
Dost záleží, jestli to musíš mít v noťasu, nebo jestli na to máš k dispozici server:
a) jestli tam máš chodící Windows, hoď to do HyperV a neřeš ztrátu výkonu
b) neřeš rozdíly ve výkonu, protože jsou zanedbatelný. Zajímá tě hlavně, jestli potřebuješ PCIpassthrough grafiky. Pak je v podstatě nejlepší volba VMw. Ten má ale problém, že pokud nemáš existující free licenci ESXi, tak máš smolíka pacholíka, musíš se zaregistrovat do VMGU programu, a každých tuším 90 dní budeš hypervisor reinstalovat, nebo si zaplatíš svinsky drahý předplatný. Pokud se obejdeš bez PCIpassthrough, jdi do Proxmoxu/QEMMU/KVM. Pokud už máš platnou licenci free ESXi (ideálně 8čkovou), můžeš si nainstalovat ESXi bez integrace do vCenter, a jseš omezenej jen na 240 fyzických jader a 8vCPU v jednom virtuálu, a nemáš k dispoziti automatizační a StorageAPI, a veškerou administraci budeš dělat přes webový rozhraní nebo SSHčkem.
Další věc je, že VMw ESXi ti neumožní dělat přímo na konzoli, takže na noťasu je VMw naprostej nesmysl; potřebuješ extra server. Jediný, co má od VMw na noťasu smysl používat, je VM Workstation Pro, což je v podstatě výrazně vyspělejší VirtualBox.
Klíčová je ve tvým případě IMO odpověď na následující otázku:
- jestli se s tím chceš teprve (a primárně) učit, nebo jestli to potřebuješ rychle rozjet a dělat především něco na těch virtuálech: v tom případě bych neřešil rozdíly ve výkonu, protože tvým primárním zájmem je fungovat a dělat svoji práci.
-
Pokud se obejdeš bez PCIpassthrough, jdi do Proxmoxu/QEMMU/KVM.
To je blbost. PCI passthrough funguje na Qemu/KVM, jsme na tom uspesne preportovali drivery z linuxu na win.
Host byl Proxmox (ale na tom nezalezi, je to stary kripl, dnes bych volil ciste qemu)
Guest byl Linux i Windows
HW zarizeni nase PCIe FPGA karta s vlastnim DMA.
-
Tak to je supr zpráva, já se s tím v tom minimu volnýho času co mám seznamuju teprve pár týdnů, a zatím jsem narazil jen na (asi starší) zmínky, že to lidem moc nefungovalo. Jestli už to není aktuální problém, tak tím líp.
Ad QEMMU vs Proxmox: co se v tom šťourám, tak mi Proxmox přijde především jako nadstavba nad QEMMU, spíš než něco významně jinýho.
-
Pridavam hlas za QEMU/KVM, s bezproblemovym passthrough pouzivam par roku. Prave fungujici passthrough a moznost pritom normalne pouzivat tucnaka jako OS s GUI pro mne byly naprosto rozhodujici ficury oproti ESXi nebo Hyper-V.
Samo, je to na takovy domaci zvykani, laborovani, kuteni s kdecim, co se mi zrovna dostane pod ruce. Takze si dam jako passthrough treba celej USBckovej radic a nemusim se mrcasit s tim, ze mi zarizeni nekoilkrat zmeni USB identifikatory (pri zmene rezimu) na neco, u ceho jeste passthrough nemam.
-
Ad QEMMU vs Proxmox: co se v tom šťourám, tak mi Proxmox přijde především jako nadstavba nad QEMMU, spíš než něco významně jinýho.
V Linuxu virtualizace prakticky znamená KVM+QEMU. KVM řeší tu virtualizaci v jádře proti procesoru, QEMU pak řeší "virtuální počítač" - SATA řadič/síťovka/myš/klávesnice/atd. Spouštět si to ručně už jde v terminálu pomocí qemu-kvm a hromady parametrů, kdo to chce spravovat nějakými dalšími nástroji, jsou nad tím pak další vrstvy. Jedna z nich je třeba libvirt a nad ním je pak třeba GUI virt-manager. Proxmox je na úrovni toho libvirt, na jedné straně má KVM+QEMU, na druhé straně svoje webové rozhraní a hromady skriptů a procesů co tam něco dělají sami.
V Linuxu je ještě virtualizace postavená na XEN, což je na stejné úrovni jako KVM+QEMU. XEN není součástí upstream jádra, musí se patchovat/binární stahovat někde jinde. Ale asi bych to zkrátil tak, že XEN je mrtev...
-
PCI passthrough tam je největší kámen úrazu HW a UEFI samotného serveru, proto tolik problémů okolo toho.
Proxmox a KVM lidi rozjíždějí na kdejakém starém šrotu a pak se nelze divit, že naráží na zádrhely.
Pokud se obejdeš bez PCIpassthrough, jdi do Proxmoxu/QEMMU/KVM.
To je blbost. PCI passthrough funguje na Qemu/KVM, jsme na tom uspesne preportovali drivery z linuxu na win.
Host byl Proxmox (ale na tom nezalezi, je to stary kripl, dnes bych volil ciste qemu)
Guest byl Linux i Windows
HW zarizeni nase PCIe FPGA karta s vlastnim DMA.
-
PCI passthrough tam je největší kámen úrazu HW a UEFI samotného serveru, proto tolik problémů okolo toho.
Proxmox a KVM lidi rozjíždějí na kdejakém starém šrotu a pak se nelze divit, že naráží na zádrhely.
Pokud se obejdeš bez PCIpassthrough, jdi do Proxmoxu/QEMMU/KVM.
To je blbost. PCI passthrough funguje na Qemu/KVM, jsme na tom uspesne preportovali drivery z linuxu na win.
Host byl Proxmox (ale na tom nezalezi, je to stary kripl, dnes bych volil ciste qemu)
Guest byl Linux i Windows
HW zarizeni nase PCIe FPGA karta s vlastnim DMA.
Nejvetsi problem starych systemu je, ze nemaji dost male IOMMU grupy, ale to vetsinou resi ACS patch do kernelu.
Samozrejme s dopadem na bezpecnost.
-
Záleží na tom, jaký systém chcete používat primárně, jaké aplikace z jakého systému využívate nejvíc.
Předpokládám, že mluvíme o koncové stanici (desktop, notebook).
Na pracovním stroji mám Windows 10 a v něm WSL2 pro docker a další. Je to firemní image s restrikcemi, ale WSL2 naštěstí použít lze. Funguje to, ale neustále hledám ideální pracovní workflow a jsem ve stavu "jde to, ale dře to".
Hlavní problém: diskové operace jsou *výrazně* rychlejší pod WSL. Kompilace velkého projektu mavenem, build docker image (přes maven fabric8 plugin)... Nejsou to procenta, ale násobky! Takže se snažím co nejvíc práce směrovat do WSL a nativní Windows nechat ideálně jako podvozek na aplikace pro sekretářky (powerpoint apod.), proprietární VPN etc. No jo, ale: IntelliJ IDEA ale velký projekt z linuxu neotevře (nebo už jo, zlepšují to, ale žere to *opravdu hodně* RAMky a lepší stroj než 32 GB nezískám, navíc je to pak celé pomalejší). IntelliJ z linuxu spustit lze (WSLg), ale má to problémy. Skončil jsem na tom, že mám kód (checkout gitu) pod WIndows (edituju to normálně v IDE spuštěném pod Windows) mirror zdrojáků ve WSL (a zautomatizovaný sync) a nějak to jde, celkem se to zajelo a nějak jsem schopný takhle pracovat, ale je to drbání se loktem za opačným uchem.
Různé antiviry a "šmírovací" agenti, kteří nevidí, nebo omezeně vidí do virtuálního disku (ale zpomalují všechny operace nad nativním NTFS) budou hrát roli. Na tom firemním stroji je rozdíl v rychlosti diskových operací fakt tragicky v neprospěch Windows vs. WSL. Ale i když jsem si zkoušel porovnání (dualboot na stejném stroji) s "čistým" systémem, vždy mi Linux vycházel co do rychlosti lépe. Dokonce kompilace javy byla rychlejší ve virtuální mašině (VirtualBox) spuštěné pod Windows než přímo na Windows. Defender, indexing apod. jsem měl povypínané, ale nedokázal jsem docílit toho, aby to bylo stejně rychlé. Linux vedl, o parník. Může to být issue skill, třeba se nekamarádím s Windows a ony se mnou :-)
No na soukromém ntb mám Ubuntu a WIndows 11 pod VirtualBox VM (a tu ani nestartuji moc často) a jsem spokojen.
-
IntelliJ IDEA ale velký projekt z linuxu neotevře (nebo už jo, zlepšují to, ale žere to *opravdu hodně* RAMky a lepší stroj než 32 GB nezískám, navíc je to pak celé pomalejší).
Offtopic: Co je velký projekt? Stovky tisíc souborů, stovky modulů (počítáno jako výskyt build.gradle) se v Idea na Linuxu používat dá. Jo, když to člověk chce mít puštěné dvakrát, k tomu virtuálku, kde to běží... tak 32 GB ramky přestane stačit. Ale dají se dělat i kouzla se scopováním idea projektu a různým fine-tuningem, pokud nepotřebuješ celý codebase najednou. A tohle fungovalo i před pěti lety. Ale mluvím o nativním Linuxu, ne o WSL.
-
IntelliJ IDEA ale velký projekt z linuxu neotevře (nebo už jo, zlepšují to, ale žere to *opravdu hodně* RAMky a lepší stroj než 32 GB nezískám, navíc je to pak celé pomalejší).
v Idea na Linuxu používat dá.
Možná nedorozumění, IDEA na Linuxu běhá perfektně, vše (indexace, build...) je rychlejší než pod Windows.Na WSL jsem ji nakonec rozchodil přes WSLg. Bohužel to má drobnosti, od otravné kosmetiky (dekorace oken, občas zlobí pop-upy, font-scaling) až po bohužel překážky (clipboard má omezenou kapacitu a po překročení - delší text - to zamrzne; delší dobu neopravený bug, obecně to čas od času prostě spadlo a bylo nutné ideu zabít a nastartovat znovu). Kolega se s tím naučil žít a používat to tak dodnes :) Skřípe zuby nad bugy grafického WSL ale na oplátku to má velice rychlé.
IDEA má "remote develop" režim, backend si spustí ve WSL, frontend na Windows. Efektivně tak ale běží 2x. Mám Xmx tuším už na 8GB. Běžně mám otevřeno více projektů a 32 GB je bohužel pod hranicí použitelnosti. Navíc je to pomalejší než native (což se ale kontinuálně zlepšuje a problémem se pomalu stává opravdu už jen ta paměť). Takže řešení, kdybych měl k dispozici 64 GB by bylo používat to takto.
Co se týká velikosti projektů, tak mám více služeb, 2 nodejs, ca 10x java. Ta java je různá od relativně jednoduché malé servisy po bumbrlíka (který čeká na zasloužený refaktor :)), 60 mvn modulů a cca 15 000 tříd. Přes různé profily editujeme co je nutné a máme layered image. Čas od času je potřeba to přebuildit všechno. Tam je potom rozdíl ca 1,5 min vs 5 min. (U docker image buildu je rozdíl desítky s versus několik minut, tam je to ještě brutálnější).
Jádro problému je, že vlastně chceme linux, ale nelze si vybírat. (Mj. čím dál přísnější procesy kolem VPN vylučují i virtuálku, nehledě na to, že BYOD je už neslušné slovo.)
-
Jo takhle, Intellij Gateway myslíš, s klientem i serverem na stejném železe. Takovouhle konfiguraci jsem nezkoušel, to používám jen místo VNC po síti, a jako čistě klient to žere méně zdrojů, než plnohodnotná idea s tím samým projektem. Ale dává smysl, že dohromady jako klient+server to je naopak.
-
Tak děkuji všem za názory a pohledy. Spolehněte se, že si nejprve vyberu to nejhorší řešení, abych se postupně propracoval k tomu lepšímu :D
-
V Linuxu je ještě virtualizace postavená na XEN, což je na stejné úrovni jako KVM+QEMU. XEN není součástí upstream jádra, musí se patchovat/binární stahovat někde jinde. Ale asi bych to zkrátil tak, že XEN je mrtev...
Xen je hypervisor, běží tedy nad Linuxem.
Pachovat – jaké patche? Kdysi dávno tu byl Xenlinux, znamenalo to separátní patche, ale to bylo do kernelu verze 2.6.18. Tedy docela dávno. Dnes místo toho máme pvops, které jsou součástí upstreamu. Navíc ne vždy jsou potřeba.
Navíc Xen má dnes mnoho způsobů virtualizace (původní legacy PV, plná virtualizace HVM a pak různé mezistupně, zejména PVH), pro HVM není potřeba speciální kernel, tam rozjedete třeba i Windows.
Druhá věc je, jak rozumně a uživatelsky přívětivě Xen nastavit. Přímo upravovat konfiguráky jsem nezkoušel. Umí to Qubes OS, ale je tam docela znát, že Windows pro ně není priorita.
-
Na Windowse este mozes vyskusat :
1. VirtualBox https://www.virtualbox.org/
2. VMware Player, najdes free download ...
-
VMware Workstation je už pár měsíců zdarma pro domácí použití. Snad jediná pozitivní věc po převzetí VMware Broadcomem. Jenom se člověk musí zaregistrovat na tom jejich hrůzowebu, aby si to mohl stáhnout.
Na ESXi jde na internetu najít jak free tak ostrý čísla pro všechny verze a jsou normálně funkční. Ale předpokládám, že funkční limit je verze 8, nová verze bude mít předělaný registrační systém, aby to nešlo takto snadno a Broadcomu v tom netekly prachy.
-
No, nenasedal bych na mrtvého koně. Pokud novější verze ESXi nejsou k dispozici (resp. jsou, ale za peníze, které nechcete platit), stáhnout někde starší verzi sice lze, ale:
1. Věříte tomu zdroji, že ESXi nijak nemodifikoval.
2. Nemáte opravy zranitelností.
U něčeho, co bude fungovat jako hypervizor, bych si na to dával bacha, má přístup v podstatě ke všemu, co na počítači děláte.
-
Ono se to do určité míry dá omezit tím, že hypervisor bude v izolované VLAN, takže ze strany managementu se do něj půjde dostat jen ze správcovské stanice, ale to samozřejmě nechrání před útokem cestou "vyskočení ze sandboxu" v důsledku nějaké neopravené chyby.
-
Bych to nekomplikoval a na desktop uziti doporucil mainstream - Ubuntu, QEMU/KVM a windows strcit do virtualky.
Dalsi krok muzete brat jako ze VM budou na serveru, tak to je pak ukol pro Proxmox.
Rozhodnuti ciste z toho pohledu - ze pokud uz hodlate Win opustit a koketujete s alternativami, je lepsi vzit lepsiho kone a postupne se s nim seznamovat - dokud nejste pod tlakem. Jakmile bude totiz zmena nutna/zadouci, tak bude pozde uvazovat o te zmene.. ty zkusenosti jste uz mohl davno nabyt.
-
Žádná nová verze ESXi zatím ani neexistuje, teprve teď byla představená. Takže mrtvý kůň to úplně není. Aktualizovat jde samozřejmě i free verzi a podporu má (myšleno aktualizace) verze 7 a 8. Ale v tuto chvíli je to opravdu spíš na vyzkoušení nebo naučení se, pokud s tím člověk bude pracovat, verze 8 bude použitelná ještě tak 4-6 let.
Já pořád doufám, že Broadcom si to rozmyslí a nabídne rozumnou licenční politiku do menších firem. Každopádně nelze počítat s další free verzí.