Virtualizáció vs Konténer technológia

UNIX kezdő

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?

  • 938 megtekintés

( sz332 v | 2021. 10. 16., szo – 09:20 )

Tudom, hogy nem segít, de ezt először miért nem lokális gépen próbálod ki?

( Crayon | 2021. 10. 16., szo – 09:27 )

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)

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:

~$ lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
lxc-checkconfig: unable to retrieve kernel configuration

Try recompiling with IKCONFIG_PROC, installing the kernel headers,
or specifying the kernel configuration path with:
  CONFIG=<path> lxc-checkconfig
 

Ha a /proc/version-t nézem meg, és adom át CONFIG változóként az lxc-checkconfignak, akkor ezt kapom:

 CONFIG=/proc/version lxc-checkconfig
WARNING: Unable to detect version from configuration, assuming latest

--- Namespaces ---
Namespaces: required
Utsname namespace: missing
Ipc namespace: required
Pid namespace: required
User namespace: missing
Network namespace: missing

--- Control groups ---
Cgroups: missing

Cgroup v1 mount points: 
/sys/fs/cgroup/systemd
/sys/fs/cgroup/devices
/sys/fs/cgroup/rdma
/sys/fs/cgroup/net_cls,net_prio
/sys/fs/cgroup/cpu,cpuacct
/sys/fs/cgroup/blkio
/sys/fs/cgroup/pids
/sys/fs/cgroup/memory
/sys/fs/cgroup/cpuset
/sys/fs/cgroup/perf_event
/sys/fs/cgroup/freezer

Cgroup v2 mount points: 
/sys/fs/cgroup/unified

Cgroup v1 clone_children flag: enabled
Cgroup device: missing
Cgroup sched: missing
Cgroup cpu account: missing
Cgroup memory controller: missing

--- Misc ---
Veth pair device: missing
Macvlan: missing
Vlan: missing
Bridges: missing
Advanced netfilter: missing
CONFIG_NF_NAT_IPV4: missing
CONFIG_NF_NAT_IPV6: missing
CONFIG_IP_NF_TARGET_MASQUERADE: missing
CONFIG_IP6_NF_TARGET_MASQUERADE: missing
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: missing
CONFIG_NETFILTER_XT_MATCH_COMMENT: missing
FUSE (for use with lxcfs): missing

--- Checkpoint/Restore ---
checkpoint restore: missing
CONFIG_FHANDLE: missing
CONFIG_EVENTFD: missing
CONFIG_EPOLL: missing
CONFIG_UNIX_DIAG: missing
CONFIG_INET_DIAG: missing
CONFIG_PACKET_DIAG: missing
CONFIG_NETLINK_DIAG: missing
File capabilities: 

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

A világ IQ-ja állandó, csak egyre többen vagyunk rá....

( Vamp | 2021. 10. 16., szo – 16:09 )

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...

( tompos v | 2021. 10. 16., szo – 17:34 )

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.

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 42, 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é.

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 42, Thinkpad x280

A futottak még virtualbox, kvm, stb meg type-2. Ez nekem mindent elmond :D

 

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-…

One interesting technology is the KVM hypervisor. This open sourced Linux-based hypervisor is mostly classified as a Type-1 hypervisor, which turns the Linux kernel into a “bare metal” hypervisor. At the same time, the overall system is categorised as a type-2 hypervisor due to the full functional Operating System used. The unique KVM model allows for full virtualization and customized kernels (the core component of computer operating systems), allowing you the opportunity to set limits for the resources used, it also ensures that your virtual machines are more isolated and can host different Operating Systems other than Linux.

 

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

( vl v | 2021. 10. 16., szo – 22:15 )

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.

( kisg v | 2021. 10. 16., szo – 22:33 )

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.