Publikálva: 2024.11.19
Frissítve: 2026.02.04
Publikálva: 2024.11.19
Frissítve: 2026.02.04
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.
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.
Az éppen aktuális Proxmox VE-t a következő linkről tudjuk letölteni: https://www.proxmox.com/en/downloads
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
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.
A post-install script-ről a következő oldalon tájékozódhattok: https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install
Futtatása (node neve -> Shell):
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"
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. Az erdeti scriptet gondoltam megtartom itt, adózva tteck az emlékének.
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/post-pve-install.sh)"A post-install script-ről a következő oldalon tájékozódhattok: https://tteck.github.io/Proxmox/#proxmox-ve-post-install
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á.
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.
sed -i.backup -z "s/res === null || res === undefined || \!res || res\n\t\t\t.data.status.toLowerCase() \!== 'active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.serviceHa a parancs nem működne, akkor az alábbi oldalon érdemes szétnézni. Az oldal fejlesztője, mindig frissíti a parancsokat, illetve van egy manuális mód is megemlítve. A futtatást követően nem árt törölnünk a böngészőnk cache-ét, vagy inkognítóból tesztelni, hogy tényleg eltűnt-e a felirat.
https://dannyda.com/2020/05/17/how-to-remove-you-do-not-have-a-valid-subscription-for-this-server-from-proxmox-virtual-environment-6-1-2-proxmox-ve-6-1-2-pve-6-1-2/
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.
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.
Első körben nézzük meg a Datacenter -> Permissions -> Realms szekciót.
Illetve, ha szeretnénk ide lehet LDAP szervert, illetve AD szervert is felvenni.
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.
Datacenter -> Permissions -> Groups. Csak csoportot lehet itt felvenni. A Users oldalon kell a felhasználókat a megfelelő csoportba sorolni.
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.
Datacenter -> Permissions -> Roles. Milyen objektumokhoz férhet hozzá az adott felhasználó. Mit csinálhat egy VM-mel. Lehet egyedit is csinálni.
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.
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)
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.
apt install sudo
adduser feketebt sudo
sh -c "echo 'feketebt ALL=(ALL) ALL' >> /etc/sudoers"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 feketebtMi 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.
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.
PS C:\Users\Rendszergazda> Get-ADUser belepek
DistinguishedName : CN=belepek,OU=TechnikaiUsers,OU=FeketeBT OU,DC=fbt,DC=hu
Enabled : True
GivenName :
Name : belepek
ObjectClass : user
ObjectGUID : 3a92a433-eba0-4d5b-a731-842519e86f8f
SamAccountName : belepek
SID : S-1-5-21-3123699748-1752600117-2859962736-1602
Surname : belepek
UserPrincipalName : belepek@fbt.hu
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
Datacenter -> Permissions -> Realms -> "Add" gomb -> Active Directroy Server
Itt fogjuk tudni felvenni az AD szervert a következő módon.
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.
Bind User:
CN=belepek,OU=TechnikaiUsers,OU=FeketeBT OU,DC=fbt,DC=huUser Filter:
(&(memberOf=CN=proxmoxAdmin,OU=Csoportok,OU=FeketeBT OU,DC=fbt,DC=hu))Group Filter:
(&(distinguishedName=CN=proxmoxAdmin,OU=Csoportok,OU=FeketeBT OU,DC=fbt,DC=hu))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.
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-agentAz 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.
systemctl start qemu-guest-agent
systemctl enable qemu-guest-agentBővebben itt olvashattok róla: https://pve.proxmox.com/wiki/Qemu-guest-agent
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.
Innen mindig az aktuálisat lehet letölteni: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
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.
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.
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.
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.
A System fül alatt több minden is magyarázatra szorul.
Graphic card:
SCSI Controller:
Machine:
Qemu Agent:
BIOS:
Add TPM:
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:
Disk size:
SSD emulation:
Backup:
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:
Cores:
Type:
A memory fül. Itt álítjuk be neki, hogy mennyi memóriával rendelkezzen a gép.
Memory:
Minimum Memory:
Ballooning Device:
Bridge:
Model:
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.
Csak a különbségekre szeretnék fókuszálni!
Guest OS:
Add additional drive for VirtIO drivers:
Add TPM:
Model:
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\BYPASSNROA későbbiekben ez a metódus is működhet:
start ms-cxh:localonlyA 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.
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 updateA következő paranccsal fogjuk az elérhető konténer template-ket kilistázni.
pveam availableA 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.zstHa mindennel megvagyunk, akkor a node-on nyomjunk jobb egérgombot, majd "Create CT".
A CPU és a memória fül az nagyjából ugyanaz, mint a VM-eknél.
Itt a két bekeretezett részre érdemes oda figyelni.
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.
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:
Mode:
Protected:
Compression:
Notes:
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.26A backup-ok a következő mappában találhatóak. Lépjünk be az adott könyvtárba:
cd /var/lib/vz/dumpA 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:
scp vzdump-qemu-101-2024_11_02-16_10_27.vma.zst feketebt@192.168.2.43:/home/feketebt/Virtualization/VM_101_Debian_MGMT_backup/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é.
scp vzdump-qemu-101-2024_11_02-17_23_37.vma.zst root@192.168.2.26:/var/lib/vz/dumpFull 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 proxmoxMivel 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.
proxmox:x:1000:1000:Proxmox Backup,,,:/usr/sbin/nologinVegyük fel samba felhasználónak.
smbpasswd -a proxmoxCsinálunk egy backup mappát, aminek a tulajdonosa a proxmox user és group lesz.
mkdir /home/proxmox/backup
chown proxmox:proxmox /home/proxmox/backup/Szerkesszük a "/etc/samba/smb.conf" fájlt
nano /etc/samba/smb.confÉn a következő értékeket vettem fel benne:
[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 = proxmoxA "testparm" paranccsal igény esetén ellenőrizhetjük a konfigot.
Indítsuk újra a Samba-t
systemctl restart smbd.serviceA Datacenter alatt -> Storage -> Add gomb -> SMB/CIFS
A következőekre kell figyelni:
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
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.
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.
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.
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.
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.
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.
Dobjuk ki a cluster-ból mondjuk a hármas node-ot. Ellenőrizzük az aktív node memeber-eket.
pvecm nodesEsetemben a kimenet:
A következő paranccsal tudjuk törölni az adott node-ot. Jelenesetemben a nodename: proxmox3
pvecm delnode [nodename]A kód kimenete:
root@proxmox1:~# pvecm delnode proxmox3
Killing node 3
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-on nyissuk meg a Shell-t és állítsuk meg a cluster folyamatot.
systemctl stop pve-clusterEzt követően adjuk ki a következő parancsot:
/usr/bin/pmxcfs -lA 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 sok mindent kell törölni.
rm -rf /etc/pve/corosync.conf
rm -rf /etc/corosync/corosync.conf
rm -rf /etc/corosync/authkey
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.
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.
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.
A legnagyobb különsbég abban lesz, hogy nem kell config-ot felvenni a többinél.
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.
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.
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.
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é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
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.
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.
mkdir -p /var/lib/ceph/mon/ceph-proxmox3
pveceph mon destroy proxmox3Az egyik jól működő pool-on ellenőrizhetjük a Ceph config-ját, hogy biztosan kikerül-e belőle a node.
nano /etc/pve/ceph.confTöröljük a node-on a shared storage-t.
Copy paste rész, majd reboot. A "pveceph purge" parancsra elképzelhető, hogy hibát dob. Nem kell a pool-t törölni, mert az a többin is törli!
systemctl stop ceph-mon.target
systemctl stop ceph-mgr.target
systemctl stop ceph-mds.target
systemctl stop ceph-osd.target
rm -rf /etc/systemd/system/ceph*
killall -9 ceph-mon ceph-mgr ceph-mds
rm -rf /var/lib/ceph/mon/ /var/lib/ceph/mgr/ /var/lib/ceph/mds/
pveceph purge
apt-get purge ceph-mon ceph-osd ceph-mgr ceph-mds -y
apt-get purge ceph-base ceph-mgr-modules-core -y
rm -rf /etc/ceph/* /etc/pve/ceph.conf /etc/pve/priv/ceph.*
apt-get autoremove -yMeghibá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.
mkdir -p /var/lib/ceph/mon/ceph-[nodename]
pveceph mon destroy [nodename]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 lsA következő paranccsal törölhetjük a node-hoz tartozó OSD-t:
ceph osd purge [id] --forceMajd 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.
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.
Szerkeszteni kell a megfelelő CT konfig fájlt. (100 helyett megfelelő CT id.)
nano /etc/pve/lxc/100.confKeressük meg a lentebb látható sort és tegyünk az elejére #-t.
usb_thin:vm-100-disk-0,size=16GEzt követően Shell allól adjuk ki a következő parancsot a megfelelő paraméterrel. (100 helyett megfelelő CT id.)
pct destroy 100A kiindulási node megfelelő storage-áról pedig töröljük a disk-et.
Szerkeszteni kell a megfelelő CT konfig fájlt. (100 helyett megfelelő VM id.)
nano /etc/pve/qemu-server/100.confItt a virtuális gépünktől függően több sor elejére is kellhet #.
efidisk0: local-lvm:vm-101-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
scsi1: local-lvm:vm-101-disk-2,iothread=1,size=75G,ssd=1
tpmstate0: local-lvm:vm-101-disk-2,size=4M,version=v2.0Ezt követően Shell allól adjuk ki a következő parancsot a megfelelő paraméterrel. (100 helyett megfelelő VM id.)
qm destroy 100A kiindulási node megfelelő storage-áról pedig töröljük a tárolókat.
Törlés előtt fel kell oldani a VM-t.
qm unlock 601Ezt követően törölhetjük a VM-t.
qm destroy 601A kiindulási node megfelelő storage-áról pedig töröljük a tárolókat. Vagy akár WebGUI alól is törölhetjük a VM-t az unlock parancs után.
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-crmAz egyik node-on adjuk ki a következő a parancsot:
rm /etc/pve/ha/manager_statusEzt követően indítsuk újra a pve-ha-crm-et az összes node-on.
systemctl start pve-ha-crmAz é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:
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.
scp librenms-ubuntu-22.04-amd64-vmware-disk1.vmdk root@192.168.2.26:/var/lib/vz/template/iso
scp librenms-ubuntu-22.04-amd64-vmware.ovf root@192.168.2.26:/var/lib/vz/template/isoA következő paranccsal tudjuk importálni az ovf állományt a megfelelő abszolút elérési útvonallal:
qm importovf [vmid] [valami.ovf] [proxmox_tárhelye] --format qcow2Esetemben:
qm importovf 110 librenms-ubuntu-22.04-amd64-vmware.ovf local-lvm --format qcow2Az importált disk, ugyanakkor nem lesz jó. Azt kézzel újra meg kell tennünk. Az első disk-et törölhetjük.
A következő paranccsal tudjuk importálni az vmdk állományt a megfelelő abszolút elérési útvonallal:
qm importdisk [vmid] [valami.vmdk] [proxmox_tárhelye] --format qcow2Esetemben:
qm importdisk 110 librenms-ubuntu-22.04-amd64-vmware-disk1.vmdk local-lvm -format qcow2NIC-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.
Ezt követően megpróbálhatjuk a gépet indítani.
Futtassuk le az ellenőrző szkriptet:
pve8to9 --fullA lista elég hosszú, de a lényeg:
= SUMMARY =
TOTAL: 42
PASSED: 34
SKIPPED: 6
WARNINGS: 1
FAILURES: 1
Amit innen ellenőrizni kell az a FAILURES és WARNINGS rész. Ebből is amit orvosolni kell mindenképpen a FAILURES!
FAIL: systemd-boot meta-package installed. This will cause problems on upgrades of other boot-related packages. Remove 'systemd-boot' See https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#sd-boot-warning for more information.
A system-boot csomag a továbbiakban, ilyen formában nem támogatott Debian 13 alatt: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#sd-boot-warning
apt remove systemd-bootWARN: The matching CPU microcode package 'intel-microcode' could not be found! Consider installing it to receive the latest security and bug fixes for your CPU.
Ensure you enable the 'non-free-firmware' component in the apt sources and run:
apt install intel-microcode
Javítható, de nem kötelező: https://forum.proxmox.com/threads/upgrading-from-8-to-9-cpu-microcode.170319/
Szerkesszük a forrás lista fájlját:
nano /etc/apt/sources.listA legvégére szúrjuk be ezt:
deb http://security.debian.org bookworm-security non-free-firmware main contribAmi még előfordulhat, hogy ilyen hibát tapasztalunk minden parancs futtatásánál:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "hu_HU.UTF-8",
LC_MONETARY = "hu_HU.UTF-8",
LC_ADDRESS = "hu_HU.UTF-8",
LC_TELEPHONE = "hu_HU.UTF-8",
LC_NAME = "hu_HU.UTF-8",
LC_MEASUREMENT = "hu_HU.UTF-8",
LC_IDENTIFICATION = "hu_HU.UTF-8",
LC_NUMERIC = "hu_HU.UTF-8",
LC_PAPER = "hu_HU.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Ennek javítására ez a legegyszerűbb módszer:
apt install locales-allHa mindent javítottunk, akkor futtassuk újra az ellenőrzést. Immárom nem szabadna hibát dobnia.
= SUMMARY =
TOTAL: 42
PASSED: 34
SKIPPED: 6
WARNINGS: 0
FAILURES: 0
Ha nincsen hiba, akkor frissíthetjük a Proxmox rendszerünket a legújabb 8.4-es verzióra.
apt update && apt dist-upgrade -ypveversionA parancs kimenete az írás pillanatában:
pve-manager/8.4.16/368e3c45c15b895c (running kernel: 6.8.12-18-pve)Ezt követően másoljuk be ezt a két parancsot:
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-install-repo.list
A következő parancsokkal frissíteni fogjuk a Proxmox-ot a 9-es verzióra. Csak SSH használatával frissítsük a Proxmox node-okat, vagy KVM alól!
apt update && apt dist-upgrade -yFrissítés során feltett kérdések: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#Upgrade_the_system_to_Debian_Trixie_and_Proxmox_VE_9.0
/etc/issue:
/etc/lvm/lvm.conf:
/etc/ssh/sshd_config:
/etc/default/grub:
/etc/chrony/chrony.conf:
Ha végzett, akkor indítsuk újra a node-t és ellenőrizzük a verziónkat:
pveversionA parancs kimenete az írás pillanatában:
pve-manager/9.1.4/5ac30304265fbd8e (running kernel: 6.17.4-2-pve)A tapasztalatom az, hogy ezután futtatni kell megint a post-install scriptet:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"Amennyiben szeretnénk egy kicsit rendbe rakni a forrás listánkat, akkor egy kicsit érdemes törölgetni a /etc/apt/ mappában.
rm -rf /etc/apt/sources.list.d/ceph.list
rm -rf /etc/apt/sources.list.d/pve-enterprise.list
rm -rf /etc/apt/sources.list.d/pve-enterprise.sources
rm -rf /etc/apt/sources.list.d/pve-test.sources
rm -rf /etc/apt/sources.list.d/ pve-install-repo.listAmire figyeljünk, hogy mindenképpen megmaradjon: "/etc/apt/sources.list.d/proxmox.sources". A többi igazából felesleges sallang, ha nincs enterprise előfizetésünk és nem használunk ceph-t.
A Broadcom pénzéhsége miatt sokan pártolnak el a VMware mellől. Ennek persze sok előnye és hátránya is van, mert tapasztalatom alapján sokan döntenek a Proxmox mellett. Mivel a Proxmox támogatja azt, hogy többé kevésbé direkbte migráljuk át a gépeket VMware alól, emiatt sokan fejest is ugranak ebbe. Az egyetlen probléma ezzel az, hogy Linux-os gépek esetében néha random kernel panic-kal találkozik az ember. Natívan Proxmox alá telepített gépekkel én nem találkoztam ilyen hibával, de migrált gépeknél annál gyakrabban. Erre a legegyszerűbb megoldás az, hogy ha újra telepítjük a migrált gépet Proxmox alá. Persze ezzel akadhatnak problémák. Nálam is vannak csontvázak, amiket inkább csak lélegeztetőgépen kell tartani vagy akkora mennyiségről van szó, hogy addig is valami megoldást kell találni.
Erre megoldásként a watchdog-ot találtam, ami kernel panic esetében rebootolja a gépet. A Proxmox fórumán ezt a leírást találtam: https://forum.proxmox.com/threads/hardware-watchdog-at-a-per-vm-level.104051/. Ez olyan téren egy jó megoldás, hogy csak bizonyos VM-ekre vonatkozik és nem egy globális változtatást jelent. Ugyanakkor a leírás nem teljesen az igazi, emiatt próbáltam egy kicsit finomhangolni PROD környezetre.
Ezt Proxmox node szinten kell elvégezni!
A megfelelő VM configot szerkesszük:
nano /etc/pve/qemu-server/[vm_id].confA konfig legvégére másoljuk be ezt:
watchdog: model=i6300esb,action=resetEzzel létrehoztunk egy virtuális (hypervisor) watchdog-ot.
Ezeket a lépéseket VM szinten kell elvégezni! Tehát magára a VM-re kell belépni.
Először is telepítsük a watchdog-ot:
apt install watchdogSzerkesszük a konfig fájlját:
nano /etc/watchdog.confA végére másoljuk be ezt:
watchdog-device = /dev/watchdog
log-dir = /var/log/watchdog
interval = 10
timeout = 30
realtime = no
priority = 0Jelenleg mi egy userspace watchdog-ot hozunk létre ezzel. Amit érdemes lehet módosítani az az interval és a timeout érték. Jelen beállítások mellett 10 mp-ként van egy check és 30 mp után történik csak reset.
Szerkesszük a következő fájlt:
nano /etc/default/watchdogÍrjuk át a "watchdog_module" részt a lent látható módon:
watchdog_module=i6300esbA VM indulásánál automatán be fogja tölteni a rendszer a megfelelő kernel modult. Így kapcsoljuk össze a userspace watchdog-ot a virtuálissal.
Most már csak annyi a dolgunk, hogy megmondjuk a rendszernek, hogy a watchdog-ot indítsa automatikusan:
systemctl enable watchdogRégi Ubuntu-k esetében ez a parancs működik:
update-rc.d watatchdog enableEzt követően egy teljes "poweroff" kell a gépen. Nem elég egy reboot.
A gép újraindítása után pár dolgot ellenőrizni kell:
Betöltődött-e a megfelelő kernel modul:
lsmod | grep i6300esbA parancs kimenete:
i6300esb 12288 1
watchdog 49152 3 iTCO_wdt,i6300esbHa jobban tetszik, akkor ezt akár dmesg-gel is megnézhetjük:
dmesg | grep i6300A parancs kimenete:
[ 1.118547] i6300ESB timer 0000:06:04.0: initialized. heartbeat=30 sec (nowayout=0)Ezzel igazából hátra is dőlhetnénk, de még beszélhetünk kernel szintű watchdog-ról is. Ha szeretnénk magunkat atombiztossá tenni, akkor érdemes azt is beállítani.
Hozzunk létre egy új sysctl konfig fájlt:
nano /etc/sysctl.d/99-kernel-recovery.confMásoljuk be ezt:
kernel.panic = 10
kernel.panic_on_oops = 0
kernel.watchdog = 1
kernel.softlockup_panic = 1
kernel.hardlockup_panic = 1Lehetne ezt elég hosszan ecsetelni, hogy mi micsoda, de így lényegében csak a kernel oops esetén nincs automatikus reboot.
Ha nem szeretnénk valami miatt "reboot"-t nyomni a gépen, akkor az alábbi paranccsal azonnal életbe is léptethetjük:
sysctl --systemHa szeretnénk tesztelni azt, hogy mit követtünk el, akkor az alábbi paranccsal megtehetjük. Ugyanakkor ez azonnali kernel panic-ot vált ki, szóval óvatosan!
echo c > /proc/sysrq-triggerHa minden jól működik, akkor a VM szépen újraindul és mi boldogok lehetünk. Az alábbi három paranccsal ellenőrizhetünk.
uptime
grep -i panic /var/log/kern.log.1
grep -i watchdog /var/log/syslog.1A watchdog-gal kiküszöbölhető a fagyások nagy része, viszont, mint minden más, ez sem kockázatmentes. Mivel már van userspace, kernel és "hardver" szintű watchdog-unk, emiatt ha bármi lefagy vagy pánikolni kezd, rajtunk kívül, akkor az a rendszer újraindításához fog vezetni. Ami viszont probléma, hogy ha valami miatt a deamon leáll, vagy a külső virtuális watchdog lehal, akkor az a gép újraindításához fog vezetni és adott esetben egy loop-ba is belekerülhet. Emiatt fontos, hogy legyen egy biztos pontunk amire vissza lehet állni, ha olyan (Ilyenkor adatvesztésre kell készülni.). Sajnos a gondot akár egy bug is okozhatja. Nálam PROD környezetben eddig jól vizsgázott egy Ubuntu 14.04-gyel és egy tesztelés miatt szétvert Debian 13-mal, így én sikernek könyvelem el.
Felhasznált linkek:
https://www.proxmox.com/en/
https://forum.proxmox.com/threads/machine-type-query.128923/
https://www.proxmox.com/en/downloads (Proxmox telepítése)
https://tteck.github.io/Proxmox/#proxmox-ve-post-install (Post-install script)
https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install (Post-install script)
https://dannyda.com/2020/05/17/how-to-remove-you-do-not-have-a-valid-subscription-for-this-server-from-proxmox-virtual-environment-6-1-2-proxmox-ve-6-1-2-pve-6-1-2/ (Proxmox subscription felirat eltüntetése)
https://pve.proxmox.com/pve-docs/chapter-pveum.html (Proxmox felhasználó felvétele)
https://www.youtube.com/watch?v=DLh_j1CAj44 (Proxmox lokál felhasználó felvétele)
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso (ISO telepítő importálása Proxmox alá)
https://pve.proxmox.com/wiki/Qemu-guest-agent (Qemu-guest-agent)
https://pve.proxmox.com/wiki/High_Availability (Proxmox High availability)
https://forum.proxmox.com/threads/remove-node-from-cluster.98752/page-2 (Proxmox High availability)
https://www.youtube.com/watch?v=Eli3uYzgC8A (Proxmox HA + Ceph)
https://forum.proxmox.com/threads/pve-remove-one-node-from-ceph-cluster.122456/ (Proxmox HA + Ceph)
https://forum.proxmox.com/threads/removing-ceph-completely.62818/post-675049 (Proxmox HA + Ceph)
https://forum.proxmox.com/threads/how-to-delete-ghost-osds.103887/post-447194 (Proxmox HA + Ceph)
https://github.com/librenms/packer-builds/releases/tag/23.11.0 (OVA fájlok importálása Proxmox VE alá)
https://pve.proxmox.com/wiki/Upgrade_from_8_to_9 (Proxmox 8.4 frissítése 9-re)
https://forum.proxmox.com/threads/hardware-watchdog-at-a-per-vm-level.104051/ (Watchdog Kernel Panic ellen)
!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!