Kilóméteres beveztőt nem szeretnék írni, ehhez a témához. A pontos virtualizációs technológiáról nagyon jó videók találhatóak az interneten, ahol részletekbe menően elmagyarázzák a Proxmox VE működésést. Én csak azt szeretném kiemelni a témában, hogy az ESXi fizetőssé tételét követően, szerintem az egyik legjobb ingyenes alternatívává vált a Proxmox. Egyszerűen, gyorsan telepíthető, és kellőképpen nagy community áll mögötte, hogy ne tűnjön el a süllyesztőbe.
A Proxmox VE-vel jelenleg még én is csak ismerkedek. Ez a cikk inkább azt szolgálja, hogy mik azok amikre én rájöttem, illetve, hogy összeszedjem, hogy mire kell figyelni a konfigurálása során.
Proxmox telepítése
Bemutatás szintjén csak egy alap telepítést szeretnék ismertetni. Lényegében "a mire figyeljünk oda" kategória inkább. Ez otthoni környezetben megfelelő lesz sokunknak. Persze más ember, más igényekkel rendelkezik, szóval mindenki saját meglátása szerint járjon el. Otthoni felhasználásnál nem nagyon kell túlzásba vinni a dolgokat szerintem, vállalati környezetben meg teljesen mások az igények és a körülmények. Lokál diszk helyett ott nagy valószínűséggel SAN hálózatból iSCSI-val kapunk majd tárhelyet, vagy NFS-ről.
A letöltött ISO-ból csináljunk egy boot-olható médiát. Ez lehet CD vagy pendrive is.
A boot-ot követően válasszuk az "Install Proxmox VE (Graphical)" lehetőséget:
A telepítő indulását követően, el kell fogadni a végfelhasználói licencet.
Ha szeretnénk választhatunk xfs, zfs, btrfs fájlrendszert is. Ugyanakkkor ezeknek akkor van értelme, ha több boot meghatjóval is rendelkezünk. Én olyankor szeretem a zfs (RAID1)-t választani. Ha nincs több meghajtónk, akkor a sima ext4 is megfelelő.
Válasszuk ki a megfelelő opciókat. Ha beírjuk az orszángukat, akkor automatikusan kitölti a többi opciót is annak megfelelően. Ezeket szabadon módosíthatjuk.
A root felhasználónak kell itt jelszót beállítanunk, illetve egy valid e-mail címet. A mail címmel sok mindent nem fog tudni kezdeni, ha az SMTP relay-t nem állítjuk be neki.
A beállítások egy részét automatikusan megcsinálja, ha DCHP-vel kap IP-címet. Arra kell figyelni, hogy ha több hálózati csatoló felülettel rendelkezünk, akkor lehetőleg a management interfésznek adjunk IP-címet. A subnet-nek megfelelően kell mindent bekonfigurálni. A hostname-re, mindenképpen FQDN-t kell beállítani.
Végül kapunk egy összefoglalót.
Az install végeztével a gép újraindul (ha az opció be volt pipálva) és a következő shell fog fogadni minket a sikeres boot procedúrát követően.
Magát a Proxmox felületét a cli-n mutatott webes felületen tudjuk elérni. https://szerver-IP-cime:8006. Esetemben https://192.168.2.44:8006.
WebUI
Post-install script
Erre amiatt van szükség, mert nem rendelkezünk előfizetéssel és emiatt különféle apt repository-kat kell engedélyezni/tiltani, illetve a bejelentkezésnél azt a tolakodó üzenetet is kikapcsolhatjuk vele, ami emlékeztet minket, hogy ingyen élők vagyunk és fizetnünk kéne a Proxmox használatáért. Istenigazából, ezt kézzel is megtehetnénk a megfelelő menüpontokban, de így egyszerűbb. Lényegében a Linux örökévényű közmondása itt is igaz: "Ha nem tudjuk, hogy az adott rész mit kérdez, akkor jobb az alapértelmezett lehetőséget választani!" Nagyjából, amúgy is majdnem mindenre igen lesz a válasz.
Képeket csak arról csatolok, ahol nem az alapértelmezett választ érdemes kiválasztani.
Éles üzemben a test repo nem mindig jó. Én itt a "no"-t javaslom.
Ha szeretnénk HA-t, akkor itt sem az alapértelmezett válasz a jó. Mondjuk otthon jó eséllyel nem lesz minimum 3 node-os működésünk, ami kell a HA-hoz.
A szkript végeztével ajánlott újraindítani a szervert. Ezt a lehetőséget fel is kínálja.
Az eredeti szkript írójának a halálával, a community vette át a post-install script fejlesztését. Mivel ezt még nem próbáltam, emiatt nem tudok róla nyilatkozni.
Az emberben mindig benne van a félsz, hogy nem szeret idegen script-et futtatni a gépén. Ez rendben is van. Én nem tapasztaltam rendellenes működést a szkript futattásától és ajánlás előtt átnyálaztam a forráskódot is. Nem találtam benne olyat, ami miatt le kéne izzadnom, szóval részemről rendben van. Ugyanakkor, ha szeretnénk kézzel elvégezni a repo hozzáadást, azzal sincs semmi probléma.
A repo hozzáadást a node nevére kattintva -> Repositories menüpont -> Add gombbal tudjuk megtenni. Amit pedig nem szeretnénk használni (Enterprise), annak a nevére kattintva jelöljük ki, majd felül az "Add" gomb mellett lévő "Disable"-re kell nyomni (A képen Enable van. Az változik át Disable-re.).
A "No-Subscription"-re nyomjunk rá.
Proxmox subscription felirat eltüntetése
A "No valid subscription" ablakot el lehet tünteni egy paranccsal, ha szeretnénk. Ugyanakkor tapasztalatom az, hogy kernel frissítést követően előszeretettel visszamászik (Nem mindig). A szkript ilyen téren hatékonyabban tünteti el ezt nekünk.
Időről időre muszáj frissíteni a rendszerinket. Nincs ez másképp itt sem. A node nevére kattintva -> Updates menüpont -> "Upgrade" gomb-ra nyomva tudjuk ezt megtenni. Ha a felugró CLI ablak kéri, hogy a frissítést követően indítsuk újra a rendszert, akkor igyekezzünk eleget tenni ennek a kérésének.
Proxmox felhasználó felvétele
Alapértelmezetten csak a root felhasználót hozza létre a telepítő. Otthon ez többé-kevésbé rendben van. Ugyanakkor a "Network Hardening" fogalmát ismerjük és személy szerint én sem szeretem azt, ha valahova root és jelszó párossal tudunk csak belépni.
Ha szeretnénk felvenni egy új admin felhasználót, akkor azt simán megtehetjük. Viszont el kell döntenünk, hogy mi a fontos számunkra. Lokál felhasználó legyen, ami mindenhez hozzáfér, vagy a HA node-ok között replikálódjon és a Proxmox-ot tudja teljes mértékben kezelni. Sajnos ez a kettőség van jelen az esetünkben. Emiatt szükséges pár dolgot tisztázni.
Realms:
Első körben nézzük meg a Datacenter -> Permissions -> Realms szekciót.
PAM - Linux PAM standard authentication - Lokális felhasználó kezelésre szolgál. Nem replikálódik a node-okra.A rendszer teljes egészéhez hozzáférése van. (Shell-t is beleértve.)
PVE - Proxmox VE authentication server - Proxmox node-ra is szinkronizálódik. Csak a Proxmox-ot fogja tudni kezelni.
Illetve, ha szeretnénk ide lehet LDAP szervert, illetve AD szervert is felvenni.
Users:
Datacenter -> Permissions -> Users. Nekünk kell eldönteni azt, hogy mit tartunk fontosabbnak és aszerint kiválasztani a Realm-t. Az alapértelmezett a PAM. Igazából azt leszámítva, hogy itt felvettük a user-t, még semmit nem fog tudni csinálni.
Groups
Datacenter -> Permissions -> Groups. Csak csoportot lehet itt felvenni. A Users oldalon kell a felhasználókat a megfelelő csoportba sorolni.
Two Factor
Datacenter -> Permissions -> Two Factor. Kétlépcsős hitelesítést lehet beállítani a felhasználókhoz. Akkor lehet értelme, ha vállalati környezetben nincs menedzsment tűzfal mondjuk.
Roles
Datacenter -> Permissions -> Roles. Milyen objektumokhoz férhet hozzá az adott felhasználó. Mit csinálhat egy VM-mel. Lehet egyedit is csinálni.
Pools
Datacenter -> Permissions -> Pools. A gépeket és a storage-ket pool-okba rendezhetjük és ezekhez engedhetjük hozzá a felhasználókat. A létrehozott pool a node alatt jelenik meg. A "Members" résznél adhatunk hozzá VM-t és storage-t. Egy VM csak egy pool tagja lehet. Amit érdemes észben tartani, hogy az adott pool-ban a felhasználó szabadon garázdálkodhat, ha megfelelő jogosultságot kap. Hasonló az ESXi-hez.
Permissions
Datacenter -> Permissions. Léynegében ezzel tesszük fel a pontot az i-re, ha minden beállítást megcsináltunk, amit akartunk. A felhasználónk ennél a résznél lesz az, aki.
Path: (A teljesség igénye nélkül)
/ - mindenhez hozzáférhet
/nodes - node-okhoz adhatunk hozzáférést
/pool - adott pool-hoz adhatunk hozzáférést
/sdn - Software Defined Networking - Hálózat kezeléshez
/storage - milyen tárhelyhez férhet hozzá
/vms - adott vm-ekhez adhatunk hozzáférést
A fenti példa egy lokális admin felhasználót mutat be, aki mindenhez hozzáfér.
Kicsit tovább tetézve a lokál user kérdését. Igazéból ezzel nem ért véget a beállítása. Hiszen ő rendszer szinten egyébként még nem létezik. A Shell rész alatt adjuk ki az alábbi parancsot, majd megfelelő helyre írjuk be a megfelelő paramétereket. Azon kívül, hogy létre van hozva shell szinten ugye nem sok mindent fogunk tudni vele csinálni megfelelő csoporttagságok nélkül. Ha szeretnénk, akkor telepíthetjük a sudo csomagot root user-ként, majd hozzá kell adni a felhasználót a sudo csoporthoz és a sudoers fájlhoz.
Ha ezt a felhasználót el szeretnénk távolítani a rendszerünkről, akkor azt a következő paranccsal tudjuk megtenni, valamint ne felejtsük el a Proxmox alól is törölni.
deluser feketebt
Proxmox Windows AD autentikációval
Mi van, akkor ha van egy Windows AD szerverünk és innen szeretnénk felhasználókat beengedni. Történetesen ezt is meg lehet oldani. High availability esetében a node-okon szinkronizálódik, így elég egy node-on felvenni. Shell jogosultságot nem kapnak az AD autentikációval belépő user-ek.
Windows Server
AD oldalon 3 dologgal rendelkezek a belépéshez. Van egy technikai felhasználóm a TechnikaiUsers OU-ban, akivel a szinkronizálási, illetve belépési tevékenységeket végzem. Ez a felhasználó, az egyszerűség kedvéért: belepek. Létrehoztam egy csoportot a Csoportok OU-ban proxmoxAdmin néven. Ennek a csoportnak az egyedüli tagja a feketebt user.
Annak érdekében, hogy a szinkronizációs folyamat gond nélkül le tudjon futni, arra figyelni kell, hogy az OU-k nevében ne legyen ékezet és lehetőleg szóköz sem. A szerveren PowerShell segítségével adjuk ki az alább látható "Get-ADUser belepek" parancsot. Innen a "DistinguishedName" lesz számunkra a fontos a Proxmox-nál. Ezt mindenképpen másoljuk ki.
Csoportok szűréséhez a következőre lesz szükségünk. Szintén PowerShell alatt adjuk ki a következő parancsot: "Get-ADgroup proxmoxAdmin". Csak az a user fog tudni bejelentkezni, aki ennek a csoportnak a tagja és csak ezt a csoportot fogjuk behúzni a Proxmox szerverünk alá. Szintén a "DistinguishedName" mező a fontos.
PS C:\Users\Rendszergazda> Get-ADgroup proxmoxAdmin
DistinguishedName : CN=proxmoxAdmin,OU=Csoportok,OU=FeketeBT OU,DC=fbt,DC=hu
GroupCategory : Security
GroupScope : Global
Name : proxmoxAdmin
ObjectClass : group
ObjectGUID : fca5a144-c250-437a-a251-1cd6a2efd627
SamAccountName : proxmoxAdmin
SID : S-1-5-21-3123699748-1752600117-2859962736-2102
Proxmox
Datacenter -> Permissions -> Realms -> "Add" gomb -> Active Directroy Server
Itt fogjuk tudni felvenni az AD szervert a következő módon.
Realm: Tetszőleges nevet adhatunk neki. Bejelntkezésnél ezt fog kelleni kiválasztani.
Domain: Tartománynév. (Esetemben fbt.hu)
Server: Lehet DNS név vagy IP-cím is. De megadhatunk Network Load Balancer nevet is. Domain Controller IP-címére kell, hogy mutasson.
Fallback Server: Másodlagos DC IP-címe vagy DNS neve.
Mivel ezek nem igazán látszódnak a képeken, emmiatt külön kiemelem őket. A szűréseket, a lentebb látható módon kell, a megfelelő adatokkal feltölteni.
Ezeken kívül a Scope-nál mindenképpen válasszuk ki a "User and Groups"-t, és az ACL-nél található pipát érdemes bepipálni. Végül nyomjunk az "OK" gombra.
Nyomjunk rá az új Realm-re, majd az "Add" gomb sorában található "Sync" gombra.
Itt először nyomjunk a kék "Preview" gombra, majd ha "TASK OK"-ot kaptunk, akkor a Sync gombra.
Ezzel itt még nem ért véget a munkánk, ugyanis ez így egyszer lefutott és kész. Annak érdekében, hogy a szinkronizálás állandó legyen, fel kell venni egy job-ot, ezen az oldalon a Realm Sync Jobs alatt.
Igazából, itt csak a Schedule-t kell egy tetszőleges értékkel feltölteni. Az én esetemben 30 percenként fog lefutni.
A végső állapot hasonlóképpen fog kinézni.
Ezt követően még fel kell vennünk a csoportot, akik számára szeretnénk egedélyezni a bejelentkezést. Mint mondtam, aki a proxmoxAdmin csoport tagja, az fog tudni bejelentkezni. Ezt a Datacenter -> Permissions alatt fogjuk tudni megtenni.
Teljes admin jogosultsággal vesszük fel őket.
Próbáljunk meg bejelentkezni. Bejelentkezésnél nem kell a tartomány nevet megadni, de a megfelelő Realm-et kell kiválasztani.
Qemu-guest-agent
Lényegében a guest agent egy deamon. Segítségével nyerünk teljes kontrollt a VM felett. Információcserét valósít meg a VM és a host között. Például ennek hatására jelenik meg a "Summary" résznél a VM IP-címe. Parancsokat adhatunk ki a segítségével a VM-eknek, például leállítással kapcsolatosan. Illetve nem elengedhetetlen tény, hogy ha a backup-ot snapshot-ra rakjuk, akkor muszályok vagyunk a VM-en guest agent-tel rendelkezni. Összefoglalva egy nagyon hasznos kis eszköz, ami elengedhetetlen a VM-eken. A VM-ek létrehozásánál mindig pipáljuk be.
Windows alatt, csak a VirtIO driver csomagból lehetséges a telepítése. Erről egy későbbi fejezetben beszélek bövebben. Linux alatt friss telepítés esetében jó eséllyel automatikusan telepítődik. Amennyiben nem, az alábbi paranccsal telepíthető Debian alapú rendszerek esetében.
apt install qemu-guest-agent
Az alábbi parancsokkal tudjuk elidítani és a rendszer indításnál az automatikus indítást biztosítani. Sok esetben nem árt a rendszernek egy teljes leállás, majd indítás is.
ISO fájlokat a local -> ISO images menüpont alatt lehet feltölteni.
Felül kattintsunk az "Upload" gombra, tallózzuk ki a gépünkről a feltölteni kívánt image-t és várjuk meg, amíg a feltöltés megtörténik. A feltöltött image-ket a következő mappában találjuk meg: /var/lib/vz/template/iso.
Ettől egy kicsit futurisztikusabb megoldás a "Download from URL" lehetőség. Személy szerint én csak Linux esetében, illetve a VirtIO driverek letöltésénél szeretem ezt használni. A VirtIO driver csomag amúgy is egy sarkalatos pontja a Windows VM-eknek.
Miután bemásoltuk a fent említett URL-t, nyomjunk a kék "Query URL" gombra. Ilyenkor történik meg az ellenőrzése a letölthetőségnek. Ha sikeres, akkor az ISO neve meg is a jelenik "File name" mezőben. Ha minden klappol akkor a letöltéshez nyomjunk a kék "Download" gombra és várjuk meg a letöltés befejezését.
Linux-os VM létrehozása
Windows és Linux telepítése között van különbség. Így ezt két külön részre szedem inkább. A Linux az egyszerűbb.
General
Kezdjük azzal, hogy az "Advanced" lehetőséget pipáljuk is be jobb alul a "Back" gomb mellett. Majd a Name mezőnél adjunk egy tetszőleges nevet a VM-nek. Ha szeretnénk egyedi VM ID-t beállítani, akkor akár azt is csinálhatjuk. A VM-eket 100-tól felfelé kezdi el számozni a Proxmox és mindig a soronkövetkező értéket kapja meg az új VM.
OS
Az OS fül alatt Guest OS értékei alapértelmezetten a Linux-os környeztre vonatkoznak. Jelen esetben nem kell őket piszkálnunk. Egyedül a telepíteni kívánt ISO-t kell kiválasztanunk.
System
A System fül alatt több minden is magyarázatra szorul.
Graphic card:
Nagyon ritkán kell változtatni. Max, akkor, ha tudjuk, hogy kompatibilitási problémánk lesz.
SCSI Controller:
Nagyon ritkán kell változtatni. Max, akkor, ha tudjuk, hogy kompatibilitási problémánk lesz.
Machine:
i440fx: Alapértelmezett. Régi és megbízható.
q35: Újabb. Plusz támogatásokkal. Csak ő kezeli a PCIe passtrough funkciót.
Qemu Agent:
Mindenképpen pipáljuk be. A korábbiakban már kitértem rá.
BIOS:
SeaBIOS: hagyományos BIOS
OVMF (UEFI): Mint neve is jelöli a modernebb UEFI. Csak ez támogat Secure Boot funkciót. Ebben az esetben kell EFI storage-t is adnunk neki, illetve figyeljünk arra, hogy a "Pre-Enroll keys"-nél ott legyen a pipa.
Add TPM:
Windows alatt fontos. Linux alatt volt már gondom vele.
Disks
A Disks fül alatt tudunk tárhelyet adni a VM-nek. Itt leginkább azokról esik csak szó, amiket én szoktam használni.
Bus/Device:
IDE
SATA
VirtIO Block
SCSI: Alapértelmezett és VM-ek esetében még mindig a leggyorsabb.
Disk size:
Tetszőleges tárhely méretének megadása.
SSD emulation:
Emulálja az SSD működését.
Backup:
Ha kiszedjük a pipát, akkor a VM tárhelye, nem kerül mentésre. Lényegében csak a VM beállításai fognak bekerülni a backup-ba.
CPU
A CPU fül. Itt álítjuk be neki, hogy hány magon fusson az adott VM, több processzoros működés esetén hány processzort használhat. Valamint magát a processzor típusát is itt határozzuk meg.
Sockets:
Hány processzoron fusson a VM.
Cores:
Hány magot használhat fel a futása során.
Type:
A processzor típusát határozza meg. Lényegében, hogy milyen utasításkészlettel rendelkezzen a processzor.
x86-64-v2-AES/x86-64-v3/x86-64-v4: A v2-AES az alapértelmezett. A másik kettő ettől újabb és bővített utasításkészlettel rendelkezik. Én a v3-t használom.
host: Ha nem akarunk emulált processzort használni, akkor használhatjuk a host gépünk processzorát is. Windows alatt nem annyira szerenécs, bár a legnagyobb kompítibilást így érhetjük el vele. Migrálásnál viszont gondot okozhat.
A memory fül. Itt álítjuk be neki, hogy mennyi memóriával rendelkezzen a gép.
Memory
Memory:
MiB-ben kell megadni. Mondjuk 2048 MiB, az 2 GB RAM.
Minimum Memory:
Ez a Ballooning Device-hoz köthető. Ha ez be van kapcsolva, akkor egy kisebb értékkel mondhatjuk azt neki, hogy ne a megadott 2 gigát allokálja, hanem mondjuk, csak 512 MiB-et.
Ballooning Device:
Érdemes bepipálni.
Network
Bridge:
Ez lesz a kimeneti interfésze, amivel kilát a hálózatra Ez a Proxmox szerver interfésze. Ha több bridge-dzsel is rendelkezünk, mert több csatolónk is van a szerveren, akkor a megfelelő subnetben lévőt válasszuk ki. Valamint ha szükséges, akkor az alatta lévő "VLAN Tag"-et is írjuk be.
Model:
VirtIO (paravirtualized): Alapértelmezett. Linux alapértelmezetten támogatja, A Windows nem. 10 gigás interfészt kapunk vele, de ez ugye belső kommunikációra van csak. Az internet felé a valós hardverünk hálózati kártyája határozza meg a sebességet.
Intel E1000 és Intel E1000E: Bizonyos esetkben Windows alatt jobb ezt használni. Gigás interfészet kapunk vele.
Végül kapunk egy confirm ablakot. Itt csak a "finish"-re kell rányomni és a node alatt egy kis idő elteltével meg is jelenik az újonnan létrehozott VM-ünk.
Windows-os VM létrehozása
Csak a különbségekre szeretnék fókuszálni!
OS
Guest OS:
Type: Microsoft Windows
Version: Pl: 11/2022/2025
Add additional drive for VirtIO drivers:
Storage: local
ISO image: virtio-win.iso
System
Add TPM:
Windows 11 telepítéséhez elengedhetetlen. Lásd fenti kép.
Network
Model:
VirtIO (paravirtualized): Alapértelmezett. Linux alapértelmezetten támogatja, A Windows nem. Ha network boot-ot szeretnénk, akkor felejtsük el.
Intel E1000 és Intel E1000E: Bizonyos esetkben Windows alatt jobb ezt használni.
A telepítés során használnunk fog kelleni a VirtIO drivereket, emiatt is érdemes a VM létrehozása során plusz egy meghajtó segítségével felcsatolni ezt az ISO-t is a VM alá.
Amiatt nem szerepel itt semmi, ugyanis a Windows nem tartalmazza a szükséges SCSI driver-t. Ezt fel kell telepítenünk a VirtIO driver-ek közül. Illesztőprogram -> Tallózás -> VirtIO drivereket tartalmazó ISO -> vioscsi mappa -> w11 -> amd64 -> OK gomb -> Tovább, ha megtalálta a driver-t. A telepítést akadályozó problémát ezzel el is hárítottuk.
Ami Win 11-nél még probléma szokott lenni, az az, hogy mindenáron online fiókra akarja kényszeríteni a felhasználót. A telepítést követően a beállítások során vonjuk meg a hálózatát a gépnek. Ehhez Proxmox alatt a Hardware -> Network Device -> Disconnect részénél a checkbox-ot be kell pipálni. Ezt ugyanakkor csak leállított VM mellett lehet megtenni (VirtIO NIC esetében nincs hálózatunk még). A telepítőnél Shift+F10-t kell nyomni. Ekkor bejön a CMD és írjuk be az alább látható parancsot. A parancs hatására újra fog indulni gép.
OOBE\BYPASSNRO
A beállítások befejeztével ugyanakkor még van dolgunk. Többek között szükséges s qemu agent-et telepítenünk, a NIC-et és a ballooning device-hoz szükséges dolgokat is.
A fájlkezelőből válasszuk ki a VirtIO dirver-eket tartalmazó ISO-t és telepítsük a virtio-win-guest-tools-t.
Igazából így lehet Windows 11-t telepíteni Proxmox VM-re. Nem egy túl borzalmas valami. Csak a Windows aktiválása a kérdés innentől kezdve.
LXC konténer létrehozása
Mivel nincsen lokálisan letöltve a kezdeteknél egy template sem, emiatt először ezzel kell kezdenünk. Kiválasztjuk a node-ot, majd rámegyünk a "Shell" opcióra és adjuk ki az alábbi parancsot.
pveam update
A következő paranccsal fogjuk az elérhető konténer template-ket kilistázni.
pveam available
A listából keressünk egy számunkra tetszőlegeset és azt a következő paranccsal tudjuk letölteni a lokális tárhelyünkre.
pveam download local debian-12-standard_12.7-1_amd64.tar.zst
Ha mindennel megvagyunk, akkor a node-on nyomjunk jobb egérgombot, majd "Create CT".
General
Node: tetszőleges node neve
CT ID: 100-tól kezdődik, de adhatunk neki egy tetszőleges számot is.
Hostname: tetszőleges név
Password: tetszőleges jelszó
Confirm password: Tetszőleges jelszó megismételve
Unprivileged container: Ha szeretnénk ott hagyhatjuk a pipát. Én ki szoktam szedni.
SSH keys: SSH kulcsot adhatunk meg.
Template
Storage: Melyik tárhelyre kerüljön létrehozásra a CT.
Template: Letöltött tetszőleges template.
Disks
Disk Size: Tetszőleges tárhely méret megadása.
CPU és Memory
A CPU és a memória fül az nagyjából ugyanaz, mint a VM-eknél.
Network
Itt a két bekeretezett részre érdemes oda figyelni.
DNS
Az egész még pluszba kiegészül egy DNS füllel. Ide olyan DNS-t adunk meg, amilyet szeretnénk.
Végezetül itt is van egy confirm fül, ahol leellenőrizhetünk mindent, majd a kék "Finish" gombra kell rányomni.
Backup készítése VM-ről
Mentést úgy tudunk legegyszerűbben készíteni egy VM-ről, ha az adott virtuális gépet kiválasztjuk és rámegyünk a Backup-ra. Itt már csak a "Backup now" gombra kell rányomnunk.
Megpróbálom pontokba szedni, hogy milyen opcióink vannak.
Storage:
local: A belső local-ra készíti el a backup-ot. Ellenőrzés: local -> Backups.
külső általunk felcsatolt tárhely: Ezt a Datacenter -> Storage részénél tudjuk hozzáadni.
Mode:
Snapshot: Futó rendszerről is tud mentést csinálni. Rövid időre felfüggeszti a futást. Kell hozzá az agent. Leggyorsabb.
Suspend: Felfüggeszti a VM-t a backup idejére. Hasonlóan működik, mint a snapshot, csak nem kell az agent hozzá.
Stop: Legtisztább, ugyanakkor leállítja a VM-t a elkészültéig.
Protected:
checkbox bepipálása: Megakadályozható vele a véletlen törlés.
Compression:
ZSTD: Alapértelmezett és legjobb.
LZO: lzo tömörítés.
GZIP: gz vagy tgz fájlt eredményez.
Notes:
Ide azt írunk be amit szeretnénk. Érdemes a template-t megnézni. Saját szöveges megjegyzéshez nem kell a zárójel.
Ezeken kívül mást én nem nagyon szoktam piszkálni. Ha mindent beállítottunk, akkor nyomjunk a kék "Backup" gombra és várjuk meg amíg végez.
Ha szeretnétek letölteni az elkészült backup-okat a saját gépetekre, mert mondjuk a mentés nem külső NFS vagy CIFS szerverre készült és hirtelen kezd elfogyni a hely, akkor azt egyszerűen meg lehet tenni. Illetve amiatt is van értelme külön helyen tárolni a mentéseket, mert mindannyian ismerjük azt a meme-t, amikor benyőgi a kolléga, hogy a backup azon a szerveren van, ami összeomlott.
SSH-val lépjünk be a Proxmox szerverünkre. Esetembe az IP-cím: 192.168.2.26.
ssh root@192.168.2.26
A backup-ok a következő mappában találhatóak. Lépjünk be az adott könyvtárba:
cd /var/lib/vz/dump
A következő parancssal kilistázhatjuk a tartalmát. A parancs jelenleg a kimentet is tartalmazza.
Terminálba a következő output fog megjelenni:
root@feketebt:/var/lib/vz/dump# ls -lah
total 53G
drwxr-xr-x 2 root root 4.0K Nov 2 17:25 .
drwxr-xr-x 5 root root 4.0K Sep 13 18:02 ..
-rw-r--r-- 1 root root 6.4K Nov 2 16:13 vzdump-qemu-101-2024_11_02-16_10_27.log
-rw-r--r-- 1 root root 39G Nov 2 16:13 vzdump-qemu-101-2024_11_02-16_10_27.vma.zst
-rw-r--r-- 1 root root 20 Nov 2 16:13 vzdump-qemu-101-2024_11_02-16_10_27.vma.zst.notes
-rw-r--r-- 1 root root 3.5K Nov 2 17:24 vzdump-qemu-101-2024_11_02-17_23_37.log
-rw-r--r-- 1 root root 15G Nov 2 17:24 vzdump-qemu-101-2024_11_02-17_23_37.vma.zst
-rw-r--r-- 1 root root 16 Nov 2 17:24 vzdump-qemu-101-2024_11_02-17_23_37.vma.zst.notes
Ebből a kupacból igazából a legfontosabb nekünk a .vma.zst állomány. A .vma.zst.notes amiatt lehet fontos, hogy tudjuk az adott backup mit is tartalmaz.
A legegyszerűbb módja az állományok letöltésének, Linux alatt, talán az scp parancs. Az scp parancs felépítése a következő: scp honnan_milyen_fájlt hova_[username@IP:/pontos/mentési/hely]. Windows alatt akár valamilyen SFTP kliens is használható (WinSCP, FileZilla). Nálam a következőképpen néz ki a parancs:
Ezt követően igazából, csak ezt a parancsot kell ismételnünk a megfelelő, menteni kívánt, fájllal. Ha a mentés megtörtént, akkor törölhetjüka a fájlokat WebUI alól, vagy akár helyben parancssorral "rm -rm"-fel is.
Mi van, ha szükségünk van ezekre a backup fájlokra a Proxmox szerverünkön, de már töröltük őket róla? Nos akkor visszatölthetjük a fájlokat, ugyanabba a mappába, csak az scp parancs változik az inverzére. Ebben az esetben a saját gépünkről kezdeményezzük a kapcsoltatot a Proxmox felé.
Full leírást nem akarok csinálni, hogy hogyan kell Samba megosztást csinálni. Mondjuk azt, hogy már rendelkezünk egy Debian szerverrel, amire telepítve van a samba.
Debian oldalon
Vegyünk fel egy user-t, akit kizárólag a backup-ra fogunk használni. Esetemben proxmox lesz felhasználóneve. A kérdésekre adjunk megfelelő választ.
adduser proxmox
Mivel ez inkább egy technikai user lesz, ezért tiltsuk számára a logint. A "/etc/passwd" fájl szerkesztésével. Írjuk át a sorát a következőre.
[proxmoxbackup]
comment = Backup for Proxmox VM's/CT's
browseable = yes
writable = yes
guest ok = no
read only = no
path = /home/proxmox/backup
create mask = 0660
dir mask = 0770
valid users = proxmox
A "testparm" paranccsal igény esetén ellenőrizhetjük a konfigot.
Indítsuk újra a Samba-t
systemctl restart smbd.service
Proxmox oldalon
A Datacenter alatt -> Storage -> Add gomb -> SMB/CIFS
A következőekre kell figyelni:
ID: tetszőleges név (Ez lesz a storage neve).
Server: Samba szerver IP-címe.
Username: Létrehozott felhasználónév.
Password: Megfelelő jelszó.
Share: Samba megosztás neve.
Subdirectory: Ha nem az alapértelmezett útvonalat használnánk. (Előre létre kell hozni.)
Content: Mindenképpen vegyük fel a VZDump backup file-t is a listába.
Igazából ezzel meg is van a CIFS szerverünk, amire backup-ot tudunk készíteni.
Tesztképpen készítsünk backup-ot egy LXC konténerről.
A Storage-nál válasszuk a CIFS tárhelyünket.
Sok bosszúságtól tud minket megkímélni, ha a Backup fülön a Storage menünél kiválasszuk a Samba megosztás nevét. Így nem keressük feleslegesen, hogy hová lett a backup.
A megosztás mappa felépítése így fog kinézni. Ezen belül a dump könyvtárban vannak a backup fájlok.
root@MGMT:/home/proxmox/backup# ls -la
összesen 16
drwxr-xr-x 4 proxmox proxmox 4096 dec 2 20.25 .
drwx------ 3 proxmox proxmox 4096 dec 2 19.50 ..
drwxr-xr-x 2 proxmox proxmox 4096 dec 2 20.26 dump
drwxr-xr-x 2 proxmox proxmox 4096 dec 2 20.05 images
VM visszaállítása backup-ból
Backup-ot kétféleképpen lehet visszaállítani. Vagy a VM-re kattintva -> Backup menüpont alatt -> Backup kijelölése -> Restore gomb, majd a felugró ablakban is Restore.
A másik módszer, ha a storage-k közül a local-ra megyünk -> Backups és ott választunk ki egy backup-ot.
Mindkettő esetében az alapértelmezett beállítások felülírhatóak. Megváltoztathatjuk a nevüket, a felhasználható magok számát, a foglalatot (melyik CPU, több processzoros működés esetén) és a felhasználható memória nagyságát. Mindezt az "Override Settings:" alatt. A "Start after restore"-ral a visszaállást követően automatán elindíthatjuk a VM-t. A "Unique" checkbox-szal pedig egyedi értékkel ruházhatjuk fel a VM-t (pl: MAC-address).
A kettő abban különbözik, hogy az utóbb emlegetett visszaállítást általában akkor használjuk, ha nem az eredeti VM-t akarjuk felülírni, hanem az eredeti backup-ból egy új VM-t szeretnénk csinálni. Például tesztelési célokkal, hogy a frissítést követően hogyan viselkedik egy rendszer. Amit viszont fontos megjegyezni, hogy a "Unique"-t érdemes ilyenkor bepipálni, főképp, ha fix IP-vel dolgozunk.
Proxmox High availability
Kettő vagy több Proxmox rendszert futtató szerver kell hozzá. A Proxmox weboldala minimum 3 node-os működést ajánl. A minél nagyobb fokú redundancia hozta életre. Ha az egyik szerver meghibásodik, akkor az éppen azon futó VM-ek migrálódnak egy másikra. Amit tudni kell róla, hogy plusz tárhellyel kell rendelkeznünk azon a tárhelyen kívül, amire telepítve van a Proxmox. A tárhelyeknek ugyanazzal a névvel kell rendelkezniük, de azon kívül teljesen függetlenek egymástól. Igazából egy replikéciós job segítségével érjük el a migrációt.
Cluster létrehozása
Az elsőnek szánt node-on menjünk a Datacenter -> Cluster menüponthoz és nyomjunk a "Create Cluster" gombra.
Adjunk a cluster-nek egy tetszőleges nevet.
Belépés a cluster-be
Az immáron első node-on nyomjunk a "Join information" gombra.
Nyomjunk a "Copy Information" gombra.
A vágólapon lévő adatokkal fogunk tudni belépni a cluster-be.
A másodiknak szánt node-on a Datacenter -> Cluster menüpont alatt válasszuk a "Join Cluster" gombot.
Az "Information" részhez másoljuk be a vágólapon lévő adatokat.
Be kell írni a peer root jelszavát (az első node-ét), majd rá kell nyomni a "Join" gombra és várni.
Érdemes visszamenni az első node-ra és megnézni, hogy megjelent-e már a második node, mivel nincs visszajelzés azzal kapcsolatban, hogy sikerült-e a join. Ha igen, akkor a második node-nál nyomjunk CTRL+F5-t az oldal frissítése miatt. Azt követően már a megfelelő információt fogjuk látni.
Amennyi node-dal rendelkezzünk, annyiszor kell ezt a folyamatot megismételnünk.
A cluster-t így létrehoztuk, de a migrálás még nem fog megtörténni magától. Szóval egy cluster kiesése esetén az adott VM is megy a levesbe.
A plusz tárhely létrehozása
Az adott node -> Disks menüpontja alatt ellenőrizhetjük a plusz tárhelyünket. Az én esetemben ez a /dev/sdb. Mint látható, akkor jó, ha a "Usage" oszlopnál "No" szerepel.
Csak ZFS-sel működik a migráció, így egy olyan tárhelyet kell létrehozni minden node-on, azonos névvel. Kell egy nevet adni neki, illetve mivel egyetlen lemezről van szó, így Single Disk-et válasszunk a RAID level-nél. Valamint ne felejtsük el kiválasztani a diks-et sem. Pár videósnál láttam, hogy ők kiszedik az első node-ot követően az Add Storage-nál a pipát. Nekem úgy nem működött a replikáció. Szóval nem javaslom.
Ha elrontanánk valamit, akkor a ZFS menüpontnál jelöljük ki a tárhelyet, majd a "More" gombra kattintva nyomjunk a "Destroy"-ra, valamint a Datacenter -> Storage -> Létrehozott ZFS név kijelölését követően nyomjunk a "Remove"-ra. Majd a node nevére kattintva -> Disk -> megfelelő disk kijelölése -> "Wipe Disk" gomb. Ezzel töröljül a partíciókat.
Az előző fejezetben létrehozott konténert migráljuk a node-ok között, annyi különbséggel, hogy egy új lett létrehozva az alapján és a tárhelyét az új ZFS-ről kapja.
Először is hozzuk létre a replikációt a két másik node-ra. Kattintsunk a konténerre, majd a Replication menüpont alatt az "Add" gombra. Az alább látható egy példa, hogy érdemes felvenni.
Ezt az esetemben mégegyszer meg kell tennem a proxmox3 céllal. Ilyenkor a disk a másik két node-ra is replikálódik.
Ha mindent jól csináltunk, akkor a "Status" oszlopnál "OK" bejegyzés áll.
Annak érdekében, hogy a migráció működjön a Datacenter -> HA menüpont alatt a Resources résznél fel kell venni a konténert még.
Ha tesztelni akarjuk a migrációt megtehetjük azzal, hogy lecsapjuk a szerver hálózati interfészét. Lehetőleg switch oldalon, ahol vissza is tudjuk adni neki a teszt után a hálózatot. Maga a migráció nem azonnali, kis időbe beletelik és a Proxmox dönti el, hogy melyik node-ra történjen meg a konténer átmozgatása. Esetemben megvontam a hálózatát az egyes node-nak. Ezt követően a migrációs folyamat automatikusan lezajlott és átkerült a kettes node-ra a konténer. Ennek a kimenetele szerepel a képen.
A probléma ezzel az, hogy a VM-ek/konténerek disk-jeit többszörösen is tároljuk, valamint mikor újra elindul a kiesett node, nem kerül rá vissza a konténer, hanem marad a migrációt követő állapotában. Ettől függetlenül a redundancia nagy mértékben biztosított.
Node eltávolítása a cluster-ből
Dobjuk ki a cluster-ból mondjuk a hármas node-ot. Ellenőrizzük az aktív node memeber-eket.
pvecm nodes
Esetemben a kimenet:
A következő paranccsal tudjuk törölni az adott node-ot. Jelenesetemben a nodename: proxmox3
A node továbbra is ott marad a GUI alatt, szóval törölni kell a nodes-ok közül a Shell alól. Ezt követően töltsük újra a cluster-ben maradt node-ok webes felületét.
rm -rf /etc/pve/nodes/[nodename]
Ezzel el is távolítottuk a proxmox3 node-ot a clusterből. Innentől kezdve rajtunk múlik, hogy az eltávolított node-ot újratelepítjük, vagy standalone-á tesszük.
Az eltávolított node standalone-á tétele
Az eltávolított node-on nyissuk meg a Shell-t és állítsuk meg a cluster folyamatot.
systemctl stop pve-cluster
Ezt követően adjuk ki a következő parancsot:
/usr/bin/pmxcfs -l
A kód kimenete:
root@proxmox3:~# /usr/bin/pmxcfs -l
[main] notice: resolved node name 'proxmox3' to '192.168.2.46' for default node IP address
[main] notice: forcing local mode (although corosync.conf exists)
Ezt követően lépjünk be a lentebb látható mappába és töröljük azokat a node-okat, amik nem ehhez a node-hoz tartoznak.
cd /etc/pve/nodes
rm -rf proxmox1
rm -rf proxmox2
Indítsuk újra a node-ot.
Proxmox HA + Ceph
Minimum 3 node-os működés kell hozzá. A HA node-ok a CEPH miatt megosztotják egymás között a tárhelyet (shared storage) a hálózaton. Értelemszerűen nagyban függ a hálózat sebességétől.
Ceph telepítése az első node-ra
Kiindulási alap, hogy rendelkezünk, egy 3 node-os cluster-rel. Jelen esetben ez nálam az előző fejezetben létrehozott cluster lesz a ZFS tárhely nélkül. Mindegyik node-ra külön fel kell rakni első sorban a Ceph-t. Válasszuk ki az első node-ot, majd keressük meg a Ceph-t és nyomjunk a kék "Install Ceph" gombra.
Figyeljünk arra, hogy a Repository résznél a No-Subscription-t válasszuk ki.
Várjuk meg amíg végez az install. Ez idő alatt kapunk egy konzol ablakot, ahol kell nyomni egy y-t. Ha végzett, akkor nyomjunk a kék "Next" gombra.
A telepítést követően ki kell választani a publikus hálózatunkat, illetve a cluster hálózatunkat. Itt igazából elég a csak az elsőt kiválasztani, a másodikat automatikusan kitölti.
Az első node telepítése ezzel igazából meg is van.
Ceph telepítése a maradék node-okra
A legnagyobb különsbég abban lesz, hogy nem kell config-ot felvenni a többinél.
OSD létrehozása
Amit tudni kell, hogy itt is követelmény az, hogy legyen plusz tárhelyünk.
A node neve alatt található Ceph-hez hozzáadásra került egy legördülő lista. Itt találjuk az OSD-t.
Sok mindent nem kell változtatni. Lehet alapértelmezett hagyni mindent a folyamat során. Az összes node-on meg kell ismételni ezt a folyamatot.
A végeredmény hasonlóan fog kinézni.
Monitor beállítása
Adott node nevénél -> Ceph -> Monitor résznél tudjuk beállítani.
Az összes node-on meg kell ezt tenni az elsőt leszámítva.
Pool létrehozása
Adott node nevénél -> Ceph -> Pools.
A létrehozásnál pár dologról beszélni kell. Ha a lentieket jól megadtuk, akkor a kék "Create"-re kell nyomni.
Name: Tetszőleges lehet.
Size: Megegyező a node-ok számával a cluster-ben.
Min. Size: Hány node-ra replikálódjon az adat.
Végeredményként megjelenik minden node-nál egy új storage. A tárhelyek méretei nem adódnak össze, hanem marad az eredeti egyenkénti méret. Tehát a három tárhely egyként kezelődik, de mégis függetlenek.
Tesztelés
Tesztelésként hozzunk létre ismételten az új storage-ra egy konténert. Majd adjuk azt hozzá a HA-hoz.
Próbáljuk ki az alap migrációt. Ez kimaradt az előző fejezetből.
Válasszunk egy tetszőleges node-ot, ahová szeretnénk elvégezni a migrációt.
Failover-t is lehet tesztelni, ha megvonjuk jelen esetben a hármas node-tól a hálózatot. A Proxmox dönti el, hogy melyik node-ra kerüljön át a konténer. Mivel időbe telik a migráció emiatt, pár percbe beletik ez a folyamat. Függ a hálózatunk sebességétől is.
Mint látható a hármas node kapcsolata megszűnt és emiatt átkerült a konténer az első node-ra
Node törlése Ceph használatánál
Az alap lépések igazából ugyanazok. A kérdés igazából az, hogy amiatt szállt el az egyik node, mert maga a host gép meghibásodott, vagy amiatt mivel host-ot cserélnénk.
Tervezett host csere esetén:
Először is érdemes az OSD-ben out-ra tenni a törölni kívánt node OSD-jét.
Várjunk amíg a Ceph átmigrálja az adatokat, majd nyomjunk a "Stop" gombra. EZt követően a "More" alatt találjuk a "Destroy" opciót.
Ha az OSD-vel végeztünk töröljük a node-ot a Monitor-ból is. Először "Stop", majd Destroy.
Ezt követően az előző fejezetben leírtak szerint törölhetjük a node-ot.
Ha az adott node, soha nem tér vissza a cluster-be, akkor a következő paranccsal tudjuk törölni az OSD-ből az egyik jól működő node-on.
ceph osd crush remove [nodename]
Ha valami miatt beragadna a Monitor alatt a törölt node neve, akkor azt a következő módon tudjuk törölni. Az egyik node-on, hozzuk létre a következő mappát, majd az alábbi paranccsal töröljük azt.
Meghibásodott host esetén igazából nincs választásunk, hogy mit tegyünk. A VM-ek és a konténerek nem vesznek el, hisz azok migrálódnak egy másik node-ra. A probléma az, hogy mind a configba, mind a Monitor-ba, mind az OSD-ben ott marad a meghibásodott node. Ezekből némi trükközéssel el tudjuk távolítani.
Monitor-nál az előzőekben is taglalt módon törölhetjük.
OSD törléshez, adjuk ki az alábbi parancsot és nézzük meg melyik ID tartozik az adott node-hoz. Esetemben, mivel a hármas a tetszhalott, emiatt kettes ID-t kell majd törölni.
ceph osd ls
A következő paranccsal törölhetjük a node-hoz tartozó OSD-t:
ceph osd purge [id] --force
Majd töröljük a node-ot is:
ceph osd crush remove [nodename]
Ezzel kiszedtük a hibás node-ot a Ceph-ből. Már csak annyit kell tenni, hogy az előző fejezetben leírtak alapján eltávolítjuk a hibás node-ot a clusterből.
Hibás migrációból eredő problémák javítása
Mert, hát a tapasztalati úton szerzett tudás sajnos hibákkal is jár. Legtöbb esetben nekem a VM-hez/konténerhez tartozó diszk nem került át a másik node-ra és ez egy olyan állapotot okozott a Proxmox-nál, hogy maga a VM/CT ott volt a node-on, de törölni és beindítani nem lehetett. Mivel ezek csak teszt gépek voltak, emiatt bátran törölhettem az eredeti node-on a hozzájuk tartozó meghajtót. Jelen esetre is igaz, hogy mindig érdemes mentéssel rendelkezni.
Hibás migrációból eredő konténer törlése
Szerkeszteni kell a megfelelő CT konfig fájlt. (100 helyett megfelelő CT id.)
nano /etc/pve/lxc/100.conf
Keressük meg a lentebb látható sort és tegyünk az elejére #-t.
usb_thin:vm-100-disk-0,size=16G
Ezt követően Shell allól adjuk ki a következő parancsot a megfelelő paraméterrel. (100 helyett megfelelő CT id.)
pct destroy 100
A kiindulási node megfelelő storage-áról pedig töröljük a disk-et.
Hibás migrációból eredő VM törlése
Szerkeszteni kell a megfelelő CT konfig fájlt. (100 helyett megfelelő VM id.)
nano /etc/pve/qemu-server/100.conf
Itt a virtuális gépünktől függően több sor elejére is kellhet #.
Ezt követően Shell allól adjuk ki a következő parancsot a megfelelő paraméterrel. (100 helyett megfelelő VM id.)
qm destroy 100
A kiindulási node megfelelő storage-áról pedig töröljük a tárolókat.
Hibás migrációból eredő HA Resources törlése
Előfordulhat egy olyan állapot, hogy a ct 100 id-val rendelkező konténer törlése került, viszont beragadt a rendszerbe HA -> Resources résznél. Ezt egy hiba jelzéssel tudatja is a Proxmox, hogy már nem kerül menedzselésre a HA által. Ezt a következőképpen tudjuk törölni. Shell alatt adjuk ki az összes node-on az alább látható parancsot.
systemctl stop pve-ha-crm
Az egyik node-on adjuk ki a következő a parancsot:
rm /etc/pve/ha/manager_status
Ezt követően indítsuk újra a pve-ha-crm-et az összes node-on.
systemctl start pve-ha-crm
OVA fájlok importálása Proxmox VE alá
Az én esetemben a LibreNMS packer builds miatt jött szembe ez a probléma. Ez már ugyan, egy nem támogatott projekt, viszont kiindulási alapnak jó volt. A következő linken érhető el a legutóbbi release: https://github.com/librenms/packer-builds/releases/tag/23.11.0
Ebből én a VMware ESXi-hez tartozó librenms-ubuntu-22.04-amd64-vmware.ova-t töltöttem le.
Első lépésben az OVA állományt ki kell csomagolni. Windows alatt érdemes a 7z-t használni, Linux alatt meg amit szeretnénk.
A librenms-ubuntu-22.04-amd64-vmware.ova tartalma:
librenms-ubuntu-22.04-amd64-vmware-disk1.vmdk
librenms-ubuntu-22.04-amd64-vmware.mf
librenms-ubuntu-22.04-amd64-vmware.ovf
A fent említett három fájlból nekünk csak a követekző kettőre lesz szükségünk: "librenms-ubuntu-22.04-amd64-vmware-disk1.vmdk"-ra és a "librenms-ubuntu-22.04-amd64-vmware.ovf"-re.
Linux alól scp-vel felmásoltam a két állományt. Ezt a két fájlt tetszőleges helyre is fel lehet másolni, nem kötelező az általam használt helyre.
NIC-vel nem fog rendelkezni az importált VM, így azt még utólag adjuk hozzá. Ha minimal telepítéssel rendelkezik a rendszer, akkor érdemes a "VMware vmxnet3" NIC-et használni.
!Figyelem!
Mindenki a saját maga meglátása és megítélése szerint cselekedjen az itt olvasottakkal és látottakkal kapcsolatban. Felelőléssget NEM válalok semmi iránt amit leírok, ez szimplán csak annak a dokumentálása, ami számomra működött.
Senkit nem buzdítok arra, hogy illegális forrásból szerezzen be bármit is. A lehetséges adatvesztésért felelősséget nem vállalok. A SAJÁT CSELEKEDETEIDÉRT, SAJÁT MAGAD FELELSZ!
