"A Proxmox Virtual Environment (röviden: Proxmox VE, PVE vagy proxmox) egy szerver virtualizációra optimalizált nyilt forráskódú Debian alapú Linux disztribúció. Lehetővé teszi a virtuális gépek és konténerek egyszerű telepítését és kezelését web konzol és command line felülettel. A programcsomag két LXC és OpenVZ konténerek, valamint a KVM alapú virtualizáció kezelését támogatja" (Wikipédia)
Hivatalos oldal: https://proxmox.com/en/
Hivatalos fórum: https://forum.proxmox.com/
Véreshurka hozzászólásából

ESXi -> Proxmox migráció

Windows VM telepítéshez és driverezéshez szükséges VirtIO

Rendszerkövetelmény:
CPU: Intel VT/AMD-V képes CPU
RAM: 2GB az OS-nek minimum
Disk: Bármilyen, ajánlott server grade SSD/HDD, de egy jobb minőségű SSD (Samsung PRO/EVO, SM/PM), vagy WD RED, Purple HDD is megfelelő.
NIC: Szinte bármelyik supportált, akár USB-ethernet átalakító is.
Törekedni kell mindenből a redundanciára!
Az alábbi linken lehet többet olvasni: [link]

Fogyasztás csökkentés:
apt-get install powertop -y &&
powertop --auto-tune vagy powertop --auto-tune --html

A parancsi finom hangolja a nodeot, és minél magasabb C state elérésére törekszik. Van olyan gép, aminél csak C0 és C6 van, vagy C8, ilyenek például az N-es intel CPU-k egy része.
Optimalizálás single node-ra és SSD-re:
Először is fontos tudni, hogy 3 különböző csoportba oszthatjuk a proxmox service-eket. A linkekek tartalmazzák, hogy melyik servicek melyik verziókban érhetőek el. Értelemszerűen az újabbakban ezek már hiányoznak.
-Proxmox VE services: Proxmox saját működéséhez szükséges service-i.
-Cluster Services: Clusterhez szükséges servicek.
-Standard Services: Debian alapok miatt ezek a debian részei.

Hosszabb angolnyelvű leírás

Az SSD gyorsabban degradálódik, ha folyamatosan írunk rá, és emiatt a Proxmoxot optimalizálni ajánlott, főleg ha single nodet használ az ember, azaz nincs clusterben a gépe (Nincs több gép összekötve egy csoportba). Emiatt az alábbi serviceket érdemes lekapcsolni, hogy fölöslegesen ne írjanak SSD-re:
systemctl stop pve-ha-crm pve-ha-lrm pve-firewall pvefw-logger corosync spiceproxy && systemctl disable pve-ha-crm pve-ha-lrm pve-firewall pvefw-logger corosync spiceproxy
Az felsorolt servicek javarészt HA (High Availability) serviceket érintenek, ami ugye nekünk nincs, és cluster-wide tűzfalat, ami szintén nincs, és ennek a logolását, majd a Proxy-t. A proxy az egyéni preferencia.

PVE Enterprise:
A frissen telepített Proxmox VE-n be van kapcsolva az enterprise repository, ami miatt nem fog tudni napota repot updatelni a proxmox és nem is mindig enged bármit telepíteni emiatt, mert hibás/nem elérhető a repo. Ezt is ki lehet kapcsolni: [kép]

TurnKey LXC containerek:

Általában már működő és előre összerakott környezetet és serviceket tartalmaznak, amelyekhez nem is feltétlen kell nyúlni. Nem kell feltalálnunk újra a kereket, le kell tölteni, deployolni, megy. [kép]
Ha nem sorolja fel a Proxmox a listában a TurnKey LXC-ket, az alábbi commandot kell kiadni console-ban: pveam update

Egyéb LXC Containerek:
[link]

UPS (Szünetmentes táp) vezérlő Proxmoxhoz:
https://www.kreaweb.be/diy-home-server-2021-software-proxmox-ups/

LXC vs VM használata:
-LXC: Ha single servicet szeretne az ember használni headless módon, pl deployol egy Ubuntu 22.04 LTS server LXC-t, telepíti a servicet, pl print servert (CUPS + samba), vagy Adguardot. Alacsony memória, CPU és Disk használat. Annyira nem stabil, mint a VM.

-VM: Ha nagyobb resourcet szeretne az ember és stabilabb gépet akar. Torrent/NAS VM-et fog tudni csinálni, míg ugyan ez LXC-vel islehetséges, de ne csodálkozzunk, ha valami probléma lép fel a kernelek miatt. Desktop LXC-t nem lehet csinálni, míg VM-et igen.

Egyéb leírások:

Egy rövidebb összefoglaló az alábbi linken található a LXC és a VM közötti különbségekről: [link]

Hogyan migráljuk az on-prem szervert VM-be: [link]

PiMox: [link]

Hálózat debug:

Probléma: nem érjük el a netet.

Feltételezzük, a kábelek jók, a switch is műxik, emiatt ugrunk a transportation layer-re, ami az IP címeket "tartalmazza".

divide-and-conquer alapján kezdjünk neki először.

Pingeljünk meg pár dolgot. Kezdjük pl a google dns-el, (Míg nem említem, hogy hogy kell külön linuxban és win-ben, ugya azt a commandot kell kiadni) "ping 8.8.8.8". Ha tudjuk pingelni, kilát az internetre. Ha nem tudja pingelni, menjünk 1 kicsit lentebb. Ha 1 routerünk van, akkor pingeljük meg azt a routert, ugyan így a ping commandal. Ha őt látja, akkor a routerünkben keressük a probléma forrását.

Ha több routerünk van, vagy komplikált a hálózatunk, akkor használjuk a tracetroute commandot. Ha a moden/routerünk kilát a netre, akkor nézzük meg őt.
windows: "tracert 192.168.0.1", linux: "traceroute 192.168.0.1"
A traceroute kiírja, meddig tudja az adott devicet elérni, azaz ha köztünk és a pingelni kívánt device között van pl 100 másik eszköz, akkor látni fogjuk. Ha nem éri el, kiírja az utolsó elért eszközt, ahonnan kezdhetjük a debugot.
Ezt azért nem fogom elírni, mert minden gyártó más és más. A TP link annyira primitív, hogy a reservation is hulladék benne, míg egy cisco esetében kicsit durvább a tudása és egyszerűbb is a debug emiatt. Azt csinálja, amit kérnek tőle.

Probléma: A L1 layer és L2 layer jó (kábelek és switch), mégsincs L3 (IP), ...
Nézzük meg, van-e IP collision. Egyszerűen belépünk a routerbe, és megnézzük a logokban, ha van (khm khm tplink), hogy milyen eszköz milyen IP címet akart lekérni. Ez akkor állhat fenn, ha static IP címet állítunk be az eszközön, és nem a routerben van reservation.
...vagy néha van, néha nem.
Előfordulhat az is, hogy 2 eszközre befoglaljuk ugyan azt az IP címet, és ahogy a lease time újra kér IP-t, átugrik másik devicera az IP cím, majd vissza.
Orovoslni egyszerű, a 2 gép közül az egyikre adjunk meg másik static IP címet.

Probléma: Továbbra sincs hálózat/net, pedig pingelni tudok.
default gateway nem jó, több, mint valószínű. Ez legyen a legközelebbi routered címe.

Probléma: Cannot resolve....bármi
Nem tudja feloldani a címet. DNS/DHCP cím nem jó. Állítsuk be a legközelebbi routeren, vagy adjunk meg 1 létező DNS szervert. Ha saját, akkor azt, pl privát FQDN esetében, ha nem, akkor google DNS.

Probléma: Mókoltam a reservation-el, de nincs internet a hoston, esetleg a DHCP jó, de nincs net, vagy az IP cím nem az, ami a reservationben.
A lease time defaultban elég sok, emiatt a végéig a régi cím marad meg. Amíg le nem jár, meggyorsíthatjuk a kérést a DHCP-től az alábbi commandal:
Linux: "dhclient -v"
Windows: "ipconfig /release" majd "ipconfig /renew"