Sziasztok!
Szeretnék összerakni egy olyan megoldást 64 bites Linux alapon, amibe több mindent nekem kell kézzel fordítani és beállítani. CentOS-t fogok használni. Az a kihívás, hogy miként tudom elérni, hogy a leginkább futtatható legyen a többi 64 bites szerveren is akár, tehát hogy portolható legyen, átrakva más szerverre egyből működjön. Linux shellből fut az egész, nincs grafikus felület, szerver jellegű az egész megoldás.
Alapvetően a Virtualbox alapú virtualizáció a célnak jónak tűnik, azonban a szempontjaim, amiben jobbat keresek, mint a Virtualbox:
- kezelje az összes CPU-t és az összes memóriát, amit megkap, minél hatékonyabban
- minél kevesebb overhead legyen
- minél inkább direktben tudja használni a CPU lehetőségeit a számításoknál
Az LXC tűnik overhead szempontjából sokkal jobbnak, azonban ha egy CentOS LXC-s konténert átrakok máshova, nem tudom, hogy fog-e minden úgy működni, amit direktben fordítok. Nem kell hozzá speciális kernel, csak az alkalmazásokba kell belenyúlnom.
QEMU-KVM tűnik most győztesnek.
Az egész célja, hogy másik, akár később sokkal újabb környezetben is a lehető leghatékonyabban, hibamentesen, GARANTÁLTAN fusson, 64 biten.
Most CentOS LXC-ben tesztelem az egészet, innen akarom majd átrakni a megfelelő virtualizációba.
Ha jól gondolom, akkor a sebesség/overhead mondjuk a bal oldali csúszka végén van (a portolhatóság árán), és jobb oldalt pedig a kompatibilitás és portolhatóság van a csúszkának a sebesség csökkenése és a nagyobb overhead árán. És itt kell választani...
Tehát összefoglalva:
- olyan virtualizációt keresek, ami több 64 bites platformon is fut, bár elég a Linux rész is
- a futtatott virtuális gép (guest) meg tudja kapni akár az összes memóriát és az összes CPU-t, a host működéséhez szükséges erőforrásokon felül
- hogy ez a felépített virtuális gép akár évek múlva is fusson majd egy sokkal újabb kernelen és akár újabb processzorokon, tehát kompatibilis legyen
- ingyenes a virtualizációs szoftver
A QEMU-KVM ennek elvileg mindennek megfelel, csak ha van ennél jobb alternatíva, az érdekelne.
Sok triviálisnak tűnő dolgot leírtam, de így tisztábban láttok talán.
Köszönöm előre is a javaslatokat.
UPDATE: QEMU-KVM mellett döntöttem, tökéletesen működik eddig. Köszönöm mindenkinek a segítséget!
Hozzászólások
Miért épp VirtualBox? Ha már CentOS, akkor inkább qemu-kvm.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azért zártam ki a qemu-kvm-et, mert később, ha x év múlva már jóval újabb Linux verziók lesznek, nem látom biztosnak, hogy a qemu-kvm-ban lévő szerver biztosan működni fog. Szerinted ez garantálható? Virtualbox esetén meg a DOS is működik, és fog is elvileg x év múlva is. Ezért húzok a Virtualbox irányába, és azért is, mert kevésbé ismerem a qemu-kvm-et, nem használtam még.
Sakk-matt,
KaTT :)
Miért ne működne? Hardware-t virtualizál. Szerintem jobbak a lehetőségei a qemu-kvm-nek. Épp most managelek egy távoli gépen virtualizáltan futó oprendszert VirtManager segítségével. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Semmi nem garantálja, hogy a Oracle nem hagy fel a VBox fejlesztésével, illetőleg hogy nem kezd el 2 év múlva pénzt kérni érte. Ezen felül a VirtualBox _nem_ server-virtualizációs eszköz. Ha nem ismered a qemu-kvm-et, miért gondolod, hogy a meglátásaid helytállóak? (Én a helyedben a megvalósítandó feladatra koncentrálnék, azt próbálnám meg talán máshogy megközelíteni; leginkább patchelném a software forráskódját és szabályosan csomagolnám, telepíteném automatizálva, ezzel ellenőrizhetővé és reprodukálhatóvá, ezáltal időtállóvá téve azt. Ezen felül a portolhatóság, portolás fogalma nem a hordozhatóságot jelenti, legalábbis nem ebben a kontextusban és értelemben.)
------------------------
{0} ok boto
boto ?
Igen, jogos, amit a Virtualboxról írtál és hogy helytelenül következtettem a qemu-kvm mélyebb ismerete nélkül.
Ezt az egészet alapvetően főként magamnak és egy szűkebb körnek csinálom. Itt fontosabb az, hogy kompatibilis legyen és működjön az a virtuális gép később is, mint hogy más is fel tudja telepíteni és létrehozni (egyszerűen).
Sakk-matt,
KaTT :)
Nem más, leginkább Te magad, akár kézzel, de leginkább automatizáltan. A "halhatatlan" VM nem jó ötlet, és a rossz ötletet ezúttal - szerintem - nem menti fel óhatatlan igény. Tanácsolom a probléma újraemésztését! Hiába "csak kicsiben" kell most, máskor kellhet "nagyban" is, és akkor már nem mindegy a mindset.
------------------------
{0} ok boto
boto ?
+1
Nezd, a kvm (es a paravirtualizalt driverek) resze a mainline kernelnek amit nem sok virtualizacio mondhat el magarol.
Ezen felul az alapja a a Red Hat Enterprise Virtualizacionak illetve az egyetlen hypervisor típus amit a Red Hat supportal. Es meg az openstack-ben is a legtobbet hasznalt virtualizacios forma.
Ezeket ha osszeadod akkor lathatod hogy jelenleg a kvm-nek van a legkisebb esélye a kihalasra az osszes free/open source virtualizacio kozul.
Az, hogy melyikben lehet majd dos-t futtatni a jovoben pedig egy olyan kerdes amit ebben a vilagban kevesen tudnak megvalaszolni.
+1
És ha már DOS: vajon a dosbox nem jó a kérdezőnek?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
FYI, a DOSBox egyik fejlesztője szerint nem ajánlott a DOSBox-ot játékon kívül más alkalmazás futtatására használni.
Ezt én elhiszem, csak nem értem. Kiszimatolja, hogy az alkalmazás nem játék, és akkor hibázik? Egyáltalán mi minősül játéknak? Mellesleg az Autotrax nevű DOS-os nyáktervezőt évekkel ezelőtt futtattam dosboxban, működött. (Nosztalgiáztam, most is elindítottam, most is működik.)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem... úgy gondolom, azt jelenti, hogy a fejlesztésnél egyedül a DOS-os játékok kompatibilitása volt a cél. Ettől még futhat a DOSBox-ban nem-játék alkalmazás is, csak előfordulhatnak nem várt problémák.
Lehet, nem voltam érthető. Technikailag mi a különbség egy játék és egy nem játék között? Az int 21h-t hirtelen másképp kell hívni játékból, mint nem játékból? Vagy a CPU a xor ax, ax utasítás hatására fog mást csinálni?
Érted, mi a gondom? Ha a játékban jó valami, az a nem játékban is jó lesz, továbbá az, ami a nem játékban rossz, az a játékban is rossz lesz.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
DosBox egy csomó hardver típust nem támogat, amik megszokottak voltak akkoriban. Kiemelten soros port, párhuzamos port, egyéb bővítő kártyák. Egyszerűen amikor írták, abból a feltételezésből indultak ki, hogy a hangkártya/videó kártya kombón kívül más bővítés nincs a gépben (mivel játékoknak nem is kell más). Ennek megfelelően ki is hagytak belőle néhány dolgot, ami teljes dos kompatibilitás esetén még kellhetne.
Ezért mondjuk egy ősöreg bemérő program (még ha csak rápróbál a portra) könnyen elhasalhat, vagy instabillá válhat. Mondjuk pont ezeknek készült a dosemu, ahol akár cím szerint még valós hardvert is átadhatsz vezérlésre. Igazából egy dosnavigátorral már lehetnek gondok db alatt az alacsony lemezkezelésnek köszönhetően.
Zavard össze a világot: mosolyogj hétfőn.
Így már világos, a hardware támogatásra valamiért nem is gondoltam.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem vállalnak garanciát a stabilitására, sem a teljesítményére. Ha játszol, nem is kell. Máshoz kellhetne.
------------------------
{0} ok boto
boto ?
Garancia software-nél manapság? Minden úgy kezdődik, hogy használhatod, ennek örülhetsz, de a használatból fakadó károkért semmilyen felelősséget nem vállalnak. Szóval teljesen mindegy, hogy játék közben vagy a legújabb Duna-híd tervezése közben hasal el.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ez nagyon régóta így van.
Bocsánat, rosszul fogalmaztam, az a „manapság” valóban nem illik oda. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
(Lehet, hogy rosszul emlékszem, de kettővel ezelőtt pedig mintha a XEN lett volna a RedHat üdvözölt, támogatott virtualizációja - azaz erre alapozni bármit is, legalábbis kérdéses. Természetesen ha rosszul emlékszem, kérem valaki okos ember javítson ki!)
Reszben igazad van, de nem teljesen. Termeszetesen mindig csak a jelen allas szerint lehet "legjobbat" valasztani. RHEL5 (egeszen a RHEL5.4-ig, release date 2009-09-02) idejeben valoban a Xen volt a preferralt hypervisor es valoszinu azt valaszoltam volna a kerdezonek.
Azert azt is eszre kell venni, hogy hatalmas kulombsegek vannak a 2 eset kozott:
* eloszor is eltelt 7 ev ami alatt rengeteget valtozott a Virtualizacio vilaga. Es lefogadom, hogy sokkal tobben hasznalnak ma KVM-et mint akkoriban Xen-t beleertve projecteket, mint az OpenStack oVirt/RHEV.
* mivel engem nagyon erdekelt a tema, folyamatosan figyeltem a hireket a Xen-KVM valtasrol (meg belso informaciokat is kaptunk annak idejen). Egyik legfobb oka az volt, hogy a Xen akkoriban nem volt resze a mainline kernelnek (a project vezetoi/fejlesztoi nem gondoltak ezt fontosnak) es nagyon nehezen (nem is igazan, meg 2 Red Hat full time developer segitsegevel sem) tudtak lepest tartani az uj kernel releasekkel. A KVM architecturaja sokkal egyszerubb/jobb volt (es ez nem azt jelenti hogy gyorsabb is volt egyben mielott valaki elkezdi itt a flame haborut) es ugye roviddel a megjelenese utan a Red Hat felvasarolta a ceget aki fejlesztette. Ez egyenes utat jelentett a mainline kernelbe (kesobb a Xen csapata eszrevette a hibas dontest es nagyobb figyelmet szentelt a beolvasztasra es ennek meg is lett a gyumolcse: a domU majd kis idovel kesobb a dom0 komponensek is bekerultek, de akkorra mar keso volt a Red Hat-nak )
All in all, termeszetesen siman lehet, hogy valami mas fogja levaltani a KVM-et a jovoben, de az lenyegesen nehezebb lesz mint anno a Xen-t volt.
(Kéne szavazás, hogy X86-os linuxos desktop esetén ki mit használ: Mondjuk én csak odáig jutottam, hogy KVM, XEN, Oracle VBox, VMware Player/mittudoménmahogyhívják. Mondjuk az jó kérdés, hogy
- van-e más
- hogy lehetne úgy megfogalmazni, hogy mondjuk egy Dosemu vagy egy LXC egyértelműen ne hiányozhasson senkinek :-)
Esetleg készítesz egy live iso-t is, például pendrive-ra, amit nagy valószínűséggel évek múlva is be tud bootolni valamelyik virtualizációs szoftver. Persze plusz munka lesz, ha a programod változtatása miatt ezt az iso-t újra és újra le kell gyártani.
________________________________________
https://sites.google.com/site/eutlantis/
Kb. 2 hetente készítek magamnak live image-et. Ha scriptekkel autamatizálva van a készítése, akkor már nem olyan nagy munka. Az elején az, amíg ezek a scriptek, konfigok előállnak, utána már csak a lényegre kell figyelni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
ezek a scriptek amiket osszecsiszoltal mennyire publikusak, milyen os az alapod, vagy csak ugy altalaban errol tudnal meg irni ? ( akar pm )
Itt írtam róla. Jelenleg Fedora 23 alapú, mindig követem az aktuális Fedora release-t. Ugyan Fedorára léteznek kész live-ok is, nekem ezekből mindig hiányzik valami. Például egyes alkalmazások, helyesebben szólva egy épp olyan alkalmazás set, ami nekem fontos.
Aztán a másik, hogy megvalósítottam azt, hogy noha live Linux, mégis majdnem úgy használható, mintha telepített lenne. Ezt úgy érem el, hogy a pendrive elején van live image, utána egy általam - illetve a scriptjeim által - ismert offsettel van egy ext4 filerendszer. Ez a filerendszer nincs a partíciós táblában, hiszen új image készítését követően annak pendrive-ra másolásakor felülíródna az MBR, benne a partíciós táblával. Viszont senki sem mondta, hogy filerendszernek partíción kell lennie, elég byte-ra pontosan ismerni a helyét.
Ezt a filerendszert boot alkalmával mount-olom, majd a rajta lévő tömörített backup-ból helyreállítom a /home alatti két felhasználó személyes cuccait, ami a használat alatt RAM disk-ben (tmpfs-en) van. A gép leállításakor viszont a /home alatt lévő dolgokat tömörítve visszaírom a pendrive-ra. Mindig az utolsó 3 backup van meg.
Ebből az következik, hogy a legközelebbi boot alkalmával - akár másik fizikai gépen - még a böngészési előzmények is meglesznek. Természetesen van egy template arra az esetre, ha a pendrive-on nem lenne backup.
Ezt a save, restore dolgot egy bash-ben írt daemon intézi, root joggal fut, a felhasználó felöl named pipe-on keresztül tud parancsot fogadni. Nyilván nem bármit, lényegében csak a save és restore parancsokat, ehhez van egy picike dialógus amivel le lehet állítani a gépet.
Kezelem a dual monitort, beleértve a bal és jobb oldali monitorok billentyűzetről történő felcserélését. Openbox a felület, alul és bal oldalon van egy egy panel (fbpanel). A bal oldalin alkalmazások vannak, az alsó a szokásos, system tray, window buttons, vagy hogyan hívják. Az alsó tálca felülre is tehető egy billentyűkombinációval.
Néha találok benne apróbb bugokat, kidolgozatlanságokat, ilyenkor kicsit hozzányúlok, de ettől függetlenül kellemesen használható.
Az image most nagyjából 1.3 GiB méretű, de nagyon sok alkalmazás, utility benne van. Egy virtuális gépben állítom elő, jelenleg 32 bites i686 architektúrára. A scriptjeim nem titkosak, de a teljes image azért nem publikus, mert tartalmaz személyes adatot a template-ben, valamint jelszót is.
Tehát úgy fogalmaznék, szívesen segítek, ha érdekel, megoldásokat örömmel megosztok, de kész virtuális gépet nem adok oda a benne található személyes adatok miatt.
Ez különben is olyan műfaj, hogy akkor érdemes foglalkozni vele, ha valóban érdekel, áldozol rá időt, ekkor jól jön a segítség, de úgyis lesznek saját ötleteid, s akkor azokat elkezded megvalósítani. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nagyon jó ötlet ez így. Le a kalappal a kivitelezésért.
Ha nem ramdisk-en, hanem egy temp mappában a HDD-n, és eleve a HDD-ről/SSD-ről bootolna, valamint boot után fel tudná dolgozni a temp mappában lévő adatokat, ha mondjuk kifagyott, akkor így egy igazi portable Linux lenne, napi használatra (ha nem nézzük a frissítéseket :D ). Az emberek többségének megfelelő lenne, általános célra, netezni, zenét hallgatni.
A live CD-k használatakor én is gondoltam ilyenekre, de nem foglalkoztam, hogy testre szabjam, mint te. Gratulálok hozzá.
Egy kérdés: miért nem 64 bites? Látsz esélyt, hogy nem 32 bites gépen kapcsolod be, vagy más az oka?
Sakk-matt,
KaTT :)
Az én véleményem: még mindig elképesztő mennyiségű 32-bites procis gép van a világban (pl. a netbookok tömege pl., de "rendes" laptopok és asztali gépek is).
Eredendően szerviz toolnak álmodtam meg, amolyan, jaj, jaj, nem működik a gépem, ugye tudsz vele valamit csinálni, lellenének az adatok is esetekre. :) Sokszor 32 bites, öreg gépekről van szó. Tény, hogy nem vagyok következetes magamhoz, mert a sok RAM meg kellene - felhasználói profilok ugye RAM-ban -, aztán amelyik gépben van elég RAM, az meg legtöbbször már 64 bites.
Ugyanakkor, ha a /home alá semmit sem tud bemásolni, konzolon root-ként akkor is beléphetek, egy midnight commandert indítva, vagy simán parancsokat írogatva is megoldható egy rakás dolog.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
VirtualBox nagyon jó, én is sok helyen használom. Azonban van egy elég komoly limitációja, amibe bármikor belefuthatsz: nem tud nested virtualizációt.
A kérdés az, hogy neked tényleg egy virtuális gép kell-e, vagy pedig egy "szolgáltatáscsomag"? Ez utóbbi esetben a vagrant/docker környékén
lenne érdemes nézelődni.
- hogy ez a felépített virtuális gép akár évek múlva is fusson majd egy sokkal újabb kernelen és akár újabb processzorokon, tehát kompatibilis legyen
Csaxólok, hogy az LXC csak egy "chroot on steroids", NEM virtualizácós megoldás, NEM virtuális gépet kapsz, továbbá nincs saját kernele (nem is tud lenni, ez az architektúrájának az egyik lényege). Tehát semmi nem garantálja, hogy 10-15 év múlva az aktuális Linux kernelen el fog futni a most összeállított LXC-s kupacod.
Nem csak chrootolt. Azert ott van accgroup s a namespaces. Az LXC joval tobb, mint chroot. Olyannyira, hogy nem is az. :)
Az lxc-vel szemben a docker konnyebben szallithato viszont.
En megis inkabb egy sima kickstartos telepitot hasznalnek infrastructure as a code-kent itt. Igy kb. csak az anaconda valtozasait kell figyelembe venni, a tobbi mjndig ugyanaz lesz, tok mindegy a hardware, vagy hogy virtualizalt e. Ez barmire ugyanugy huzza fel amit szeretne a delikvens.
Én is a dockert javasolnám barátunknak, bár inkább egy csupasz jail-t és faragásra fel :P. Viszont a titok azt gondolom az idő. Ha magára lesz hagyva ugyanazon vason(vasakon) gondolom még száz év múlva is ketyeg. Viszont emlékszem kedvenc kis játékomra {Int karate] még C64-en :D azt ma már bár nem próbáltam, de gondolom faragnom kéne picit mindenféle emulátort, hogy újra tépjem a joystick-al az asztallapot :D.
Szóval arra utalok, ma egy felkapott trend a docker, gondolom sok évig talpon lesz elvégre még mindig felfutó pályán van, de ha nem tartja karban a csomagot folyamatosan libek, binárisok, struktúrák stb., eltiporja az idő, nem talál hozzá hardvert, kompatibilitási problémák a hoszt környezetben stb.
Emléxem amikor xen 3.2-ről próbáltam feljebb topogni öreg vason, az életben nem láttam még annyi kernel panic-ot :D Hiába. Öreg vasnak öreg szoftver :D (ezt akár magamra is érthettem volna hehe :D)
Hyper-V
.
.
.
.
.
.
.
Csak vicc volt :D
De amúgy nekem eddig kopp-kopp müxik rendben, igaz fürtözés meg iSCSI nélkül sima role-ként használva. Kérdés, mennyire költöztethető. De ugye a Windows 10 pro is tartalmazza és az elvileg az utolsó Windows :D, ha így haladnak tényleg az lesz, de sokáig támogatva lesz. Vagy nem.
Qemu-kvm lett a győztes. Köszönöm.
Sakk-matt,
KaTT :)