Sziasztok!
Kíváncsi vagyok a véleményetekre. Az egyik VPS szolgáltatótól az alábbiakban is - rész - idézett válasz érkezett, ami meglepett egy kicsit. Lehet, én nem értem eléggé ezt a részét (sem) az IT-nak, ezért kíváncsi vagyok, ki mit gondol.
"Az általad említett LXC pedig KVM platform. Így annak a moduljai nem fognak működni a mi VPS-ünkkel, alma és a körte effektus."
A téma röviden, XEN virtualizációs VPS-re LXC-t szeretnék telepíteni, az lxc-checkconfig hibát ír vissza. Valóban én nézem be ennyire, hogy az LXC - nem LXD - nem képes futni XEN virtualizáció alatt? Én eddig úgy gondoltam, hogy a konténereknek nem kell tudniuk arról, hogy milyen virtualiziációs platform fut alattuk, főleg azért, mert OS szinten valósulnak meg. Rosszul tutam?
Hozzászólások
Tudom, hogy nem segít, de ezt először miért nem lokális gépen próbálod ki?
Mert nem lokál gépen fogom használni. Továbbá lokál gépen megy az lxc, nincs vele gond.
A világ IQ-ja állandó, csak egyre többen vagyunk rá....
Hogyan szeretnéd telepíteni? Mi a hibaüzenet? A leírásod alapján a legvalószínűbb az, hogy valójában az LXD is települni akar, az meg nested virtualization support hiányában valóban nem fog menni (hypervisor-t akarnál futtatni egy vm-en)
How to install LXD container under KVM or Xen virtual machine
Lxd-t nem, csak lxc-t akarok futtatni, ami nem is akarja telepíteni az LXD-t.
Debian 10 Linux, 4.19.0-11-amd64 kernellel.
A hibaüzenet az apt install lxc után:
Ha a /proc/version-t nézem meg, és adom át CONFIG változóként az lxc-checkconfignak, akkor ezt kapom:
A világ IQ-ja állandó, csak egyre többen vagyunk rá....
A kernelt ők adják? Mert ha igen, akkor egyértelműen az okozza a gondot, hogy Cgroups nincs belefordítva. Így egy Dockert se lehet futtatni, nem csak LXC-t. Ahogy lentebb írtam, innen menekülni kell. :)
Van, aki szerint működik az:
https://www.lowendtalk.com/discussion/66596/can-a-xen-pv-instance-run-l…
Mégis, mi az amit az lxc-checkonfig hiányol?
En azt a reszet nem ertem, hogy "KVM platform"... Mi koze van annak a kontenerezeshez, hogy mi fut alatta? En eddig VMware-en es bare-betal-on es kvm-en is gond nelkul futtattam kontenereket...
Na ugye, nekem is itt nyílt a szemem, de lehet, én nézek be valamit...
A világ IQ-ja állandó, csak egyre többen vagyunk rá....
Vmit beneznek.
Es talan a checkconfig is hubas.
checkconfig nelkul megy?
lxd megy?
Miert annal a szolgaltatonal akarsz lenni?
Aki 2021-ben xen-t ajanl, az nekem buzlik.
Tudsz valami érvet előnyt a xen ellenében ?
Fedora 38, Thinkpad x280
Nincs, full szubjektiv velemeny.
Akkor miert baj, ha valaki ezt ajanlja?
Hogy erted, h baj?
Nem baj a szonak abban az ertelmeben, h nem all meg az univerzum tagulasa tole.
Egyszeruen szerintem egy idejetmult technologia es nem bizok olyan szolgaltatoban, amelyik azt hasznalja. Ez egy szubjektiv megallapitas, szubjektiv erzesekre alapozva.
Mejegyzem, ha mellerakom a kvm-es valaszukat, az raerosit a megerzesemre.
Pontosan mi a problémád a Xen-nel, illetve mi az amit helyette, mint abszolút kiválót tudsz ajánlatni és persze ingyenes? A KVM -ről nekem van olyan véleményem, hogy igazából szóval nem biztos, hogy akkor ajándék, ahogyan azt gondolják. Eleve az, hogy egy VM, egy qemu process a hoston, az már bűzlik... :)
Szóval minden virtualizációs technikát lehet, jól és összesvissza, meg akár rosszul is használni. Ez így volt, mindennel eddig, nem csak a virtualizációval. :)
FYI, a KVM már elég régóta != Qemu, sőt a "nagyok" (Google, Amazon) nem is használják. Nyílt forrású megoldásból népszerű a CrosVM (Rust-ban írt) és annak különböző forkjai, mint az Amazon Firecracker.
Sőt, a Google most ARM-ra úgy reszeli a KVM-et, hogy a host kernelnek csak a hypervisor részének kell majd EL2 privilégiumszinten futnia, ami elég egyszerű kód ahhoz, hogy akár a helyességét matematikailag lehessen bizonyítani (vagy mondjuk ASIL-B,C,D-nek is meg tudjon felelni), így a host kernel nem fog belelátni a guest os-ek memóriaterületébe és viszont.
Ez nagyon szép, meg nyilván több mint qemu, de ettől még ha megnézem a CentOS 7-en (őskövület kernel...) akkor bezony egy qemu nevű process látszik per VM. Az más kérdés, hogy a háttérben mik történnek. 7-es proxmoxon nem néztem külön, de emlékeim szerint ott is hasonló, pedig az egy Debian Bullseye. Szal annak örülök, hogy a nagyok ideoda reszelgetik. Ettől még lehet jó, de nem érzem azt az átütő technológiai előnyt, amit máshoz képest tud. Ettől még simán működhet jól, meg lehetnek hozzá jó toolok.
Xen esetén eleve a Xen hypervisor bootol és a dom0 kernel fut emelt szinten. Minden mást a dom0, mint control domain, indít el, és igazából a Xen -en belül futnak, nem a dom0-nak alárendelve. Ez nem most lett ilyen, 10 éve is ez volt a helyzet.
Másrészt a klikkklikkgo mániás megoldások jellemzően Proxmox-ot vagy CentOS-t, esetleg Ubuntu-t támogatnak, és vége. Se CrosVM, se semmi nem merül fel, ráadásul a KVM jó tulajdonságait se mind engedi kiaknázni, hanem valamilyen bevésett default konfiggal indul a VM és kész, ennyi.
Type-1 és Type-2 virtualizáció.
A nagyok hyper-v, vmware ESX, XEN type-1-es. A futottak még virtualbox, kvm, stb meg type-2. Ez nekem mindent elmond :D
Persze van aki virtualbox al virtualizál szerveren is, szíve joga :D
Viszont az amazon pár éve elkezdett áttérni XEN ről KVM-re meglátjuk mi sül ki belőle. Ők ha jól rémlik a jobb managelhetőség/monitorozást hozták fel fő érvként a KVM mellett.
Fedora 38, Thinkpad x280
Hááát. Guglival keresgélve annyi látszik, hogy lettek c5 típusú VM-ek, de nem tűnik olyan frenetikusnak ez az átállás. Azt is írják, hogy KVM based a történet, szóval simán el tudom képzelni, hogy komolyan belenyúltak. A KVM-nek anno az adott óriási lökést, hogy a RedHat beállt mögé.
Igen, akkoriban még a xen nem volt mainline kernel része. Így sokan joggal idengenkedtek tőle.
Megjegyzem itthon én is KVM-et használok :D Persze ennek az a praktikus oka, hogy a mivel teljes OS fut alatt így van pl.: power management és nem mind1, hogy 50W eszik a masina 7/24 ben vagy 80 -at. Bár xenben is vannak powermanagent lehetőségek de sose foglalkoztam vele, szerveren nincsen rá szükségem :D
Fedora 38, Thinkpad x280
https://newbedev.com/is-kvm-a-type-1-or-type-2-hypervisor
https://www.redhat.com/en/topics/virtualization/what-is-KVM
https://medium.com/teamresellerclub/type-1-and-type-2-hypervisors-what-…
A 2. linken lévő kulcs mondatot még azért beidézném az utókornak: "KVM converts Linux into a type-1 (bare-metal) hypervisor."
Az van, hogy hypervisort / VMM-et fejleszteni nem triviális. A Qemu-t soha nem tervezték mission critical workloadra, hanem fejlesztői toolnak, hogy kb. mindent is tudjon emulálni. Ez meg is látszik rajta (kellett csinálnom hozzá patchet, láttam belülről). Nem véletlen, hogy ahol volt keret kicserélni, ott nem használják. És szerencse, hogy most már van alternatív nyílt forrású implementáció, úgyhogy valójában nincs már akadálya mást használni.
A Proxmox fejlesztőknek van egy konkrét elképzelésük, hogy ők mit csinálnak, gyakorlatilag az LXC és a Qemu/KVM fölé tettek egy UI-t. Ez jól működik arra, amire kitalálták, én is használom még 1-2 helyen, de már látszanak a korlátai.
A jövő egyértelműen a Rust alapú virtio-only VMM-ek felé mutat. Itt próbálják a különböző cégektől a fejlesztők összetenni amilyük van, hogy ne 10 inkompatibilis Rust VMM legyen: https://github.com/rust-vmm
Node van a rust-vmm-hez klikkelős felhasználónak kiadható VM menedzser történet, amivel lehet érdemben VPS-t szolgáltatni? Ez a nem mind1, igazából. Nyilván a B opció, hogy valaki nekiáll fejleszteni, de hogyismondjam, nem biztos, hogy hazai méretben valaha megtérül.
Azért szerintem egy Amazon elég jól elvan XEN alapokon (na jó, ők egy kicsit belenyúltak, de a lényeg akkor is az, hogy XEN-en alapszik minden).
LXD-t nem akarok eredetileg, pusztán az LXC-t szeretném. A nyitó kérdés viszont az volt, hogy valóban én tudom rosszul, hogy a konténer technológiának nem sok köze kéne legyen a virtualizációs platformhoz, mert ez önmagában az OS szintén definiálódik. És azt sem akarom nagyon elhinni, hogy az LXC KVM platform lenne, így Xenen nem fog menni.
A világ IQ-ja állandó, csak egyre többen vagyunk rá....
Papíron mennie kéne. Az a KVM+LXC onnan jön szerintem, hogy elég sok plugandplay virtualizációt klikkbajnok rendszer az ezt a kettőt adja, mert az LXC-t tekintik a könnyű megoldásnak, a KVM pedig a teljes virtualizáció. Xen-en adott a PV/PVH, meg a HVM mód. Nekem az rémlik, hogy nálunk volt hasonló kérés, és a gyári Debian kernellel ment a konténeres történet, ráadásul PV/PVH guesttel. Az viszont előfordulhat, hoyg adott Xen verzió vagy beállítás valamilyen guest kernel funkciót tilt, ami kellene az LXC-nek.
Könnyen előfordulhat, hogy CentOS alapon megy valahol a történet (ezt imádják a dobozos jellegű klikkelős virtualizációs cuccok), ami azért meghatározza a Xen és a hoszt kernel verzióját.
Ahogy kollega fentebb is irta tobbfele modban futhat az a xen vm, ha paravirtualizalt a kernel akkor azt eselyes nem tudod modositani es valoszinuleg azert nem legy rajta lxc mert nincs benne kernelben ami kellene.
Pl itt egyszeruen le van irva es hogy ellenorizheted milyen modban fut a vm-ed: https://serverfault.com/a/511938
Az a kérdés, hogy hogyan döntöd el, hogy milyen OS, milyen kernel fusson.
Ha az a válasz, hogy ez egy olyan VPS, ahol nem tudsz kernelt cserélni, nem tudsz OS-t cserélni, akkor egyértelműen rossz helyen próbálkozol.
Itt azt írják, hogy elvileg lehet.
http://leonov.net/posts/2012-12-09-linode-lxc.html
Szerintem szolgáltatót kéne váltanod. Ahol a VM-en nem megy az LXC, és ráadásul ezt a választ adják ott más turpisságok is lehetnek.