Proxmox szerver lefagy!

Virtualizáció

Sziasztok!

Az egyik P93 szerver, amelyet a Hetznertől bérelek, random lefagy.

Software:
A legfrissebb Proxmox VE 7.2-4 (kernel: 5.15.35-2-pve) fut rajta, az alatt pedig 13 virtuális gép.

Hardware:
Intel® Xeon® W-2295 18-Core CPU
256 GB (8 x 32 GB DDR4 ECC) RAM,
2 x 3.84 TB NVMe SSD Datacenter Edition -> rendszer és VM-ek, ZFS + compression,
2 x 16 TB SATA Enterprise HDD -> backup, ZFS + dedup (szerk.: azóta kikapcsolva) + compression,
Hardware RAID nincs

Amit eddig tettem a megoldás érdekében:
Kicseréltettem a RAM-okat, a tápegységet, majd az egész szervert,
kikapcsoltam a NUMA-t, az SSD emulation-t (bár ez tudtommal semmit nem csinál) és az IO thread-et is minden VM-nél,
22 CPU mag és 144 GB RAM van most kiosztva a VM-eknek (3 CPU és 32 GB RAM a legtöbb 1 VM esetén)

A "tünetek":
Ha ssh-n bejelentkezve ér a fagyás, akkor a konzolon hasonló üzenetek kezdenek ömleni:
 

Message from syslogd@Server at Jun 12 11:19:57 ...
 kernel:[101078.245390] NMI watchdog: Watchdog detected hard LOCKUP on cpu 26

Message from syslogd@Server at Jun 12 11:19:57 ...
 kernel:[101080.968427] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0

Message from syslogd@Server at Jun 12 11:19:57 ...
 kernel:[101085.584163] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kvm:497638]

Message from syslogd@Server at Jun 12 11:19:57 ...
 kernel:[101085.588163] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kvm:995268]

Message from syslogd@Server at Jun 12 11:20:09 ...
 kernel:[101097.612269] watchdog: BUG: soft lockup - CPU#14 stuck for 22s! [kworker/14:2:1965617]

Message from syslogd@Server at Jun 12 11:20:25 ...
 kernel:[101104.376759] NMI watchdog: Watchdog detected hard LOCKUP on cpu 28

Message from syslogd@Server at Jun 12 11:20:25 ...
 kernel:[101112.091159] NMI watchdog: Watchdog detected hard LOCKUP on cpu 5

Message from syslogd@Server at Jun 12 11:20:25 ...
 kernel:[101112.599352] NMI watchdog: Watchdog detected hard LOCKUP on cpu 31

Message from syslogd@Server at Jun 12 11:20:25 ...
 kernel:[101113.588410] watchdog: BUG: soft lockup - CPU#2 stuck for 52s! [kvm:995268]

Message from syslogd@Server at Jun 12 11:20:25 ...
 kernel:[101113.600410] watchdog: BUG: soft lockup - CPU#9 stuck for 22s! [atop:1970572]

Message from syslogd@Server at Jun 12 11:20:29 ...
 kernel:[101114.959585] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1

Message from syslogd@Server at Jun 12 11:20:29 ...
 kernel:[101117.592445] watchdog: BUG: soft lockup - CPU#4 stuck for 23s! [kvm:835684]

Message from syslogd@Server at Jun 12 11:20:33 ...
 kernel:[101121.628481] watchdog: BUG: soft lockup - CPU#24 stuck for 22s! [kworker/24:2:374]

Message from syslogd@Server at Jun 12 11:20:37 ...
 kernel:[101125.612516] watchdog: BUG: soft lockup - CPU#14 stuck for 48s! [kworker/14:2:1965617]

A VM-ek elérhetetlenekké válnak, a Proxmox WEB UI elkezd "homokozni". A Hetzner felületén indított hardware reset után a gép újra megy.
Van, hogy naponta háromszor fagy le, van hogy megy 8 napig is.

A syslogban nincs semmi furcsa a lefagyás előtt.

Kérlek, segítsetek megtalálni és megszüntetni a lefagyások okát.

( WG | 2022. 06. 12., v – 12:47 )

A szerver cserét úgy kell érteni, hogy a diskeket áttették egy másik, ugyan ilyen gépbe.

( andrej_ v | 2022. 06. 12., v – 12:56 )

Valamilyen monitoringod van? Különös tekintettel a hoszt RAM, IO és CPU használatára Mert ezek a hibák azt jelentik mit mondanak, hogy egy-egy process ennyire beakadt.  Lehet IO probléma, vagy CPU tekerés. Ha megnézed, akkor nincs véletlenül overbooking? Ezt KVM-nél össze lehet hozni, és mellesleg ha 32GB-ot adtál a VM-nek, simán 34-38GB-ot felszippanthat maga a qemu process.

Zabbix monitorozza a hostot és a VM-eket is.
Volt olyan, hogy épp a WEB UI előtt ültem, a load felment 100 fölé a CPU is 30% feletti terhelést mutatott, az IO delay is 30-40% körül, pedig semmi extra nem ment a gépeken.
Olyan is volt, hogy IO delay 0%, CPU 2% körül, load is 2% körül, mégis lefagyott.

Eddig általában hétköznap hajnali 1 és reggel 7 között, ill hétvégeken napközben is történtek a fagyások. Ilyenkor a VM-eket (szinte) senki nem használja.
Én a 16 TB HDD dedupra gyanakszom, de mielőtt beszántanék kb 6-7 TB, 180 napnyi inkrementális backupot, keresnék más megoldást.
A dedup azért gyanús, mert van, amikor 1.05x, később 1.03x, most pedig épp 1.12x dedupot ír a

# zpool list
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
Backup  14.5T  6.59T  7.96T        -         -    24%    45%  1.12x    ONLINE  -

Ha a dedup nem on-the-fly történik, lehet, hogy az idle időben végzett dedup öli meg a vasat.
Az is lehet, hogy az ARC eszi meg a RAM-ot... sajnos ZFS tuningból sem vagyok még profi...

ha tenyleg a zfs dedup a hiba, akkor valts proxmox backup serverre. abban is van "dedup" es nemkell neki csillio ram: ha ket 4 megas chunk ugyanaz, akkor egyszer tarolja. nalam ~10x korul szokott lenni a dedup factor. 100G tarhelyen ~1T backupot (12backup/gep) elfer.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hááttt, gépen belül a backup az necces. A 2x16TB-re mentesz, ott gyakorlatilag nagyon minimális IOPS-ed van, ahhoz hogy csapass jobban. Azt mindenképp látnod kéne, hogy valami valahol megzabálja a RAM-ot, és az meg a diszk IO-t, és aztán meg beakad ettől az élet. Ezek nem a semmiben történnek.

Természetesen ez csak az egyik backup és más gépek is mentenek ide. Minden backup szekvenciálisan követi egymást, tehát akkor indul el az egyik, amikor a másik végzett, hogy ne akarja több processz egyszerre használni a HDD-ket. De ezek a backupok éjjel lemennek, a gép meg ma pl. 11:20-kor fagyott le, amikor minden órák óta "pihent". Senki nem csinált semmit egyik VM-ben sem és a terhelés gyakorlatilag 0 közeli volt.

( debtamas88 | 2022. 06. 12., v – 15:27 )

Szerkesztve: 2022. 06. 12., v – 15:28

Szia!

Amit bemásoltál logokat, azt akkor dobálja ha valami felzabálja a CPU erőforrását / valami nagyon "tekeri" - ha ez egy hosszabb ideig tart - akkor előfordúlhat pl.: egy VM szétfagy/megáll - láttam már ilyet, de amúgy ezek az üzenetek nem jelentenek problémát.

Másik ilyen amitől "keményre fagy" ha van pl.: egy NFS mount-od és kimegy alóla a hálózati interfész/másik oldal hirtelen összefossa magát  - na ilyenkor megáll az egész mint a szög :D
 

Korábban teszteltem ZFS féle dedup=on, sync=always, de azt vettem észre erőforrásigényes, sokkal lassabb a diszk teljesítménye, biztos szükséged van rá ?
 

zfs set dedup=off <pool>
zfs set compression=lz4 <pool>
zfs set sync=standard <pool>

( quash | 2022. 06. 12., v – 18:42 )

Közvetlenül nem lesz megoldás amit írok, de átgondolni érdemes!
Nagyon sok Proxmox-ot üzemeltetünk, az elején a telepítések 99% ZFS alapú volt, ZFS nyújtotta vélt előnyök miatt.
Viszont ZFS alapból egy erőforrást igénylő fájlrendszer, minél több hasznos funkciót kapcsolsz be – compress, dedup – annál többet igényel.
A VM futtatásához szükséges dedikált erőforrásokon kívül, ezeknek is rendelkezésre kell állnia, különben a nálad is tapasztalható anomáliák lépnek fel.
Ez hatványozottan igaz KVM használata esetén, LCX-nél - konténeres mivolta miatt – nem tapasztaltunk ilyeneket.
A megoldás Proxmox megtartása mellett, ZFS-től elköszönés jelentette, sima HW RAID + LVM + KVM, és atom stabilak a proxmox-ok, akkor is ha a fizikai memória és a VM-ek memóriája ki van centizve!

Proxmox már annyira jól fel van építve, hogy pl. ZFS által nyújtott snapshot kezelést teljesen kiváltja a saját block szintű megoldásával. Ezt tudja local-ban, vagy pl. a fent is említett Proxmox Backup serverre.

Ha meg tudod oldani a VM-ek exportálását, újratelepítését, majd importálást – akár úgy is hogy a gépbe kérsz addig egy szükséges nagyságú HDD-t – akkor érdemes lehet megfontolni!

Olyan voltá már nektek, hogy a KVM VM alatt a lemez partíciós táblája eltűnik? Megy a VM szépen, ír/olvas, de már nincs partíció. Kiváncsi lennék mi okozhatja... Szívtam vele más sokat. Most már testdisk-el újra írtatom, ha boot lemez akkor boot repair és megy minden tovább.

Igazából semmilyen problémánk nincsen Proxmox-al! De tényleg, ezért is használjuk sok helyen.

Ahogy írtam, ZFS miatt hajlamos kifutni az erőforrásokból, ha nagyon ki van számolva pl. RAM.
Persze lehet limitálni ZFS memória használatot, de ezzel pont ZFS-t ölöd le, és az sem megoldás mindig.

Van egy hat gépes PVE clusterünk, shared storage nincsen, minden gépen local storage (SSD, HDD vegyesen) ZFS-el. Itt a VM-ek 90%-a LXC, 300-400 napos uptime-ok teljesen természetesek.
Főleg webes kiszolgálást végeznek a VM-ek, kapnak terhelést, így sincsen gond. De a hostok memóriájának átlag 60% van VM-ek részére kiosztva.

KVM VM esetén simán kiosztható 90-95% is.

 

KVM VM-ek jellemzően Windows-ok, nem volt még lemez problémánk.

Szerintem ez nem furcsa. Több RAM több hibalehetőség. Gyorsabban járó CPU szintén nagyobb hibalehetőség. Ráadásul nem igazán összehasonlítható. Az egyik ARM, a másik Intel. Persze ettől még nem kellene lefagynia. Egybként minden CPU-ban hatalmas mennyiségi hardware bug van. Kérdés, hogy ismerjük-e azt, ami a hibát okozza, ha ismerjük, van-e rá workaround, s ha van, azt alkalmazzák-e a kernelben. És akkor ott van egy rakás egyéb chip. Ha valami deadlock állapotba kerül, akkor a kernel legfeljebb szomorúan néz, de nem nagyon tud mit tenni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gondolom ARM-on nem virtualizálsz.

Annó mikor kezdtem a virtualizációt, az volt az alapvetés, hogy a hypervisor, ne csináljon semmi fölöslegeset, egyrészt,  hogy minden erőforrás a VM-eknek legyen meg, valamint kevesebb program kevesebb hibalehetőség, nagyobb stabilitás stb, ehhez képest meg már mindent is csinál a hypervisor ... 

Fedora 38, Thinkpad x280

( pomm v | 2022. 06. 13., h – 05:36 )

Habár engem konzolon bejelentkezve soha nem ért fagyás, viszont nekem a logokban volt jele, hogy az ethernet (eno1) kifagy. Teljesen random következett be. Ezt találtam akkor a proxmox fórumon (interface fájlba beszúrni):

auto eno1
iface eno1 inet static
#teszt a interface kifagyása miatt
        offload-gso off
        offload-gro off
        offload-tso off
        offload-rx off
        offload-tx off
        offload-rxvlan off
        offload-txvlan off
        offload-sg off
        offload-ufo off
        offload-lro off
#teszt rész vége
 

Ennek jó fél éve, azóta kopp-kopp-kopp rendben van

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

Nálam nincs jele a logokban, hogy a hálókártya fagyna le.
Kerestem a "Detected Hardware Unit Hang" kifejezást, de nincs.
A hálókártya egyébként:

# lspci -nnk | grep -A2 Ethernet
06:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
        Subsystem: ASUSTeK Computer Inc. I210 Gigabit Network Connection [1043:8557]
        Kernel driver in use: igb

( bzg | 2022. 06. 13., h – 10:30 )

Szia, esetleg probald meg a 7.2-es upgrade-et. Ettol fuggetlenul ezek a "NMI watchdog: Watchdog detected hard LOCKUP on cpu" jellegu uzenetek nekem majdnem minden DELL es SuperMicro serveren jelentkeznek, csak nincs mellette fagyas. Illetve a vm.swappiness mire van allitva? En levettem 10-re, illetve ahol SSD-m van, ott 0-ra allitom.

-- Soha ne vitatkozz idiotakkal! Lesulyedsz az O szintjukre es legyoznek a rutinjukkal ! --

Elérhetetlenné válik az összes VM, a bejelentkezett felhasználóknak (Windows RDP) megszakad a kapcsolata, a szolgáltatott weboldalak elérhetetlenek, a Proxmox WEB UI elkezd homokotni, majd egy idő után "disconnected", a szerver a 7 IP címe közül egyiken sem elérhető (pl. ssh-n)... Szóval minden szolgáltatás leáll szépen, egymás után.

Van/volt már jópár szerverem, vagy VPS-em sok hoszing cégnél (Kanada, USA, Franciaország, Németország, Svájc, Lengyelország, Litvánia, Csehország, Szingapúr, ...), de eddig Ők tűnnek a legfelkészültebbnek, a legprofibbnak az összes közül.

De attól még lehet igazad... :)

csak arra, hogy kvm-en nézd majd meg hogy amikor a szolgáltatások elérhetetlenek akkor itt moccan-e bármi. Mennyire rendszeres? a legjobb az lenne ha folyamatosan rajta lógna, hogy el tudd kapni kvázi azonnal ha jön a riasztás:

https://hup.hu/comment/2796011#comment-2796011

Nem éppen, IPMI az Intelligent Platform Management Interface  minden valamire való szerveren/alaplapon szokott lenni. Erre vagy ezen felül építi a gyártó a saját cuccait, a Dellnek iDrac, HP nak iLO stbstb

Nagy előnye, hogy akkor is elérhető logol stb ha az oprendszernek kampeca (nagyjából)

Attól hogy asus lapod van, még lehet benne. Tedd fel az ipmitool majd

ipmitool sel list

esetleg

modprobe ipmi_si

Fedora 38, Thinkpad x280

Pontatlanul fogalmaztam. Ha rákattintassz a 2. linkre, ott ezt írja a Hetzner:

Hetzner IPMI information

In 2019, we at Hetzner decided to no longer provide customers with additional IPMI or KVM modules to install on their dedicated root servers. There are two exceptions: DELL servers and DELL servers from the Server Auction. Just in case there is a fault, we have kept a few of these IPMI modules.

# ipmitool sel list
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
# modprobe ipmi_si
modprobe: ERROR: could not insert 'ipmi_si': No such device

Szerintem ezt a feltételezést bizonyítanod / cáfolnod kéne hogy legyen valami tény a kezedben.

Másképp kell hozzáállni egy hálókártya (driver) lefagyáshoz mint egy alaplap/cpu/kernel pusztuláshoz.

Nem irigylem a szituációt - sokáig lehet vele szívni ellenben tanulsága nem sok lesz.

Gábriel Ákos

ha vm.swappiness=0, akkor egyáltalán nem használ swap-et, így ha elfogy a memória, akkor vége a dalnak. Én szerver esetén 1 és 10 között tartom akkor is ezt az értéket, ha történetesen nagyon sok memória vana  gépben, és nem allokálom semmire egy részét (elvelg nem fogyhatna el). Ha meg nincs annyira sok memória és/vagy nagyon ki van centizve, akkor pláne ne legyen nulla.

( Proci85 v | 2022. 06. 13., h – 12:30 )

Szerkesztve: 2022. 06. 13., h – 12:31

Érdemes kikapcsolni a biosban a C-statekeket és egéb energiagazdálkodási funkciókat.

~10 éve engem a C-state szivatott meg. A XenServer random csontra fagyott tőle.

Proxmox alatt történt a fagyás?

Egy kicsit konkretizálnád, hogy pontosan milyen energiagazdálkodási lehetőségeket érdemes / kell kikapcsolni? Most fogok telepíteni Proxmoxot két Dell szerverre is, probléma esetén jó lenne, ha tudom mit kell kikapcsolni.

A választ akár ide is írhatod, de indítottam egy másik fórumot (Proxmox - BIOS energiagazdálkodási beállítások ...) ezzel kapcsolatban, inkább ott (vagy ott is) várnám a választ.

Köszönöm!

( WG | 2022. 06. 14., k – 16:22 )

Szerkesztve: 2022. 06. 14., k – 16:23

Nem ide

( sibike | 2022. 06. 14., k – 20:11 )

 A messages/syslog-ban kellene látnod stacktrace-eket, amikor a soft lockup történik. Abból talán kiderül, hogy mi ragad be olyankor.

Megint lefagyott, feltettem a syslog-ot és a messages-t pastebinre
Már kikapcsoltam a BIOS-ban (UEFI) a CPU Autonomous Core C-State (Alaplap dokumentáció, 60. oldal) beállírást is tegnap 22h-kor.
A deduplikációt is megszüntettem a 16 TB ZFS-en (a eoot poolon nem is volt bekapcsolva), így már az sem lehet a fagyás oka...

Van még valami ötletetek? Én kifogytam.

Szerk.: Utoljára úgy szállt el, hogy a szerver és a VM-ek nagyrésze már riasztott, hogy 5 perce nem elérhetőek, de az egyik Windowsba RDP-n még be tudtam lépni és egy ügyfél még számlázott rajta (Multipoint Dashboardon láttam a képernyőjét), tehát a hozzá tartozó Samba VM is ment még.
Két másik Windows VM-nél (egyik 2016, másik 2022 Windows Server) megugrott a CPU terhelés 40-60% közé (3-5%-ról), az egyik Debian, amit RDP-n használnak, szintén magas COU terhelést jelzett, valamint további 2 Debian VM szintén. Az egyik 100% CPU-t írt a Proxmox grafikonján.

Így a hálókártya(driver) fagyás-teória is megdőlni látszik.

Szia!

Kezdjük sorban:
1., PowerSaving/C-States - opciók kikapcsolva ?
2., AMD SMT letiltva (hyperthreading)?
3., Megnéztem a syslog-t amit felraktál, ha ez egy AMD processzor miért van kvm_intel modul betöltve? Nemhogy ez okozza a problémát?
INTEL-CPU_nál
kvm
kvm_intel
AMD-CPU_nál:
kvm
kvm_amd

Szerintem valamelyik kernel modullal lesz a probléma,
Korábban énis jártam így NVIDIA videókártyával: "nvidiafb" modul blacklistelni kellett, utána már működött a nvidia kártya, előtte szétfagyott a monitor.

Probáld meg ezt:

Ebbe a fájlba "/etc/modprobe.d/kvm.conf" tedd bele ezt:
blacklist kvm_intel

majd
$> update-initramfs -c -d -u
$> update-grub

Már kikapcsoltam a BIOS-ban (UEFI) a CPU Autonomous Core C-State (Alaplap dokumentáció, 60. oldal) beállírást is tegnap 22h-kor.

Intel a CPU, a nyitó posztban a linken meg tudod nézni a gépet.
Intel® Xeon® W-2295 18-Core
Cascade-Lake W

Benéztem, akkor INTEL CPU
Többi akkor is kérdés:

1., PowerSaving/C-States opciók - KIKAPCSOLVA
2., INTEL SpeedSpectrum opciók?
3., INTEL hyperthreading opciók?
4., Belinkelt Syslog alapján:

RIP: 0010:native_queued_spin_lock_slowpath+0x1e4/0x230
RIP: 0010:vprintk_emit+0x1d4/0x270
>> Erre van megoldás, grub-ban a soros-portot le kell tiltani, bővebben:
https://www.suse.com/support/kb/doc/?id=000020516


RIP: 0010:smp_call_function_single+0xe3/0x120
RIP: 0010:smp_call_function_many_cond+0x13c/0x350
>> Passz, ez mi okozza

Következőket, próbálnám még meg:
2., 3., pontban lévőket is kikapcsolnám a BIOS-ba, megnézném úgy kifagy-e.

 

Nézted a BIOS kézikönyvét (fentebb belinkeltem).
Csak azt a C-States-t kapcsoltam ki egyelőre, ami a 60. oldal alján található a kézikönyvben.
A HypreThreading-et miért kellene kikapcsolni (tudatlanságból kérdezem, nem kötekszem. :))
Kicseréltettem az egész gépet alaplapostul, procistul egy másikra, tehát azt kizárnám, hogy ez a CPU is rossz lenne. A régi gép is ugyan ezt csinálta, mint az új.

Szia!

Akkor szivatsz minket, megnéztem kézikönyvet, ezeket kelll beállítani hogy "rendesen" kikapcsolja a C-States -t:
( Ha csak az elsőt tiltottad le, kb semmit nem csináltál ).

CPU Configuration

Autonomus Core C-State: DISABLED
Enchanced Halt State(C1E): DISABLED
CPU C6 report: DISABLED
Package C State: DISABLED
Enhanced Intel Speedstep Technology: DISABLED
Turbo Mode: DISABLED
Hyper-threading: DISABLED*

A "HyperThreading" régi vita téma, hypervisor alatt nem nyersz vele semmit, de gondot tud okozni ( én kikapcsolom minden szervernél ami hypervisor - Desktop PC alatt lehet értelme ):

https://virtualizationreview.com/articles/2016/12/08/should-you-use-hyp…

Szia!

Ha a fentiek egyike se oldotta meg a problémát, akkor van mégegy hiba lehetőség:
> CPU hűtése kevés, azaz túlmelegszik, ezért kifagy (NMI watchdog: Watchdog detected hard LOCKUP on cpu X)

Ez úgy fordulhat elő, pl.: hűtőborda nincsen rendesen rajta CPU-n, ezt csak fizikailag lehet ellenőrizni ( esetleg a CPU hőmérsékletét loggolni ).

Szia!

Legutoljára azt tudom akkor javasolni, hogy használd a korábbi stable verziót a proxmox-ból. ( Proxmox 6.4 )

http://download.proxmox.com/iso/

Aranyszabály, hogy sose használjuk a legújabbat, mindíg az egyel korábbi stable ágat, mert azt már rendesen kikalapálták lehetőleg ( ez igaz az összes LINUX -ra ).
 

https://pve.proxmox.com/wiki/Roadmap

Proxmox 6.4 -ben QEMU 5.2 van
Proxmox 7.x -ben már QEMU 6.x van

( Proci85 v | 2022. 06. 14., k – 20:31 )

Ha nincs meg a fagyás oka, állíts be remote syslog szervert valahol és küldj oda (is) minden logot. Hátha fagyás előtt még elsírja bánatát, de diszkre már nem tudja kiírni. Raid kártyával jártam így.

Korábban eth driverrel is volt szívásom, most hogy említik itt fentebb. Nagyobb terhelésnél, jellemzően backupnál kernel pánikot okozott.

Jaja. Amúgy a net kártya hiba nem tudom már hogy derült ki. Lehet, hogy crash előtt már csipogott a syslogba vagy már csak az IPMI konzolon láttam, hogy hello van. Az tuti nagy szívás volt. Valami (akkor) új fajta broadcom driver volt. Hálókártya csere orvosolta a dolgot, amin intel chip volt.

( gabrielakos v | 2022. 06. 20., h – 22:16 )

Komolyan nem vágom miért kínlódsz egy darab ilyen orbitális konfiggal, miért nem jó ezt 2-3 darabra szedni?
Nekem valahogy nagyon egyensúlytalan az egész.

Gábriel Ákos

Én a leiratod alapján konfiguráltam ez a gépet a szolgáltatódnál, és létezik, hogy ezért ilyen havi 150e HUF nagyságrendet fizetsz?

Csak azért kérdem, mert ilyen költség helyett ha veszel egy használt, de rendes (mondjuk Dell, mert a HP-t utálom) szervert, és Te magad teszed hosting-ba (itthon, ahol könnyen elérhető és kapsz hozzáférést a BMC-hez is), akkor kb. 3-6 havi díjból megvan egy nagyon jó szerver, aztán egy 2U készülék havi hosting díja nem több 30e Ft-nál még mostani villany árak mellett sem (IP címmel, internet szolgáltatással).

Mi anno sokat számolgattunk a VPS, bérszerver, saját szerver hosting-ban kérdéskört, de sehogyan sem jött az ki, hogy VPS-szel vagy bérszerverrel jobban járnánk. Így lett saját HW. Persze ezzel nekem kell tamagocsizni, ha megáll, de arra meg van onsite garink (használt szerverek egyébként), így elvileg oda se kellene mennem ha megállna valami. Ja, meg cluster, szóval ügyfél felé nem áll meg akkor sem semmi.
Nyilván nem való mindenkinek a saját cucc, sima "felhasználó" számára nagyon király a VPS vagy a bérszerver, de aki így üzemeltet és tovább értékesíti szolgáltatásként, annál inkább kényelmes, mint gazdaságos szerintem.

A cluster építéses javaslatra pedig +1000. Ha az lenne, akkor csak VM-ek újraindulásából vennéd észre a szerver halálát (persze ügyfél szemmel az sem az igazi váratlanul, de jobb, mint a határozatlan idejű leállás), nem abból, hogy megáll minden és matekozni kell, mi legyen.

Matekoztam én is és jobban járnék saját szerverekkel, de:
1. Néhány Ügyfelem nem akar Magyarországi szervert, ragaszkodik a külföldhöz, míg másoknak tökmindegy,
2. Ha ez nem lenne, akkor is gond lenne, hogy Bp. 140 km-re van tőlem. Nem szívesen autóznék kicserélni egy tápot, vagy bármit éjjel (nappal  meg pláne)

A HP, Dell témában egy a véleményünk. :) A HP a hardverek Micro$oftja a szememben. :D

Tervben van a cluster és a közös storage szerber is, ha lesz annyi Ügyfelem, hogy gazdaságos legyen.
Sajnos a mostani problémámon a cluster sem segítene. Így is 2-3 perc alatt újraindítom a szervert, de jobb lenne, ha működne terv szerint.

Az átlagos ügyfeleknél pont fordítva szokott lenni, inkább a magyarországi helyszíneket preferálják, meg vannak olyanok (államigazgatás, alapítványok, központi finanszírozású non-profit, stb.), ahol ez előírás is. Ha valaki kifejezetten külföldet preferálja, az bennem kérdéseket vet fel... (mert ugye az manapság már nem indok, hogy sok a külföldi ügyfele és onnan könnyebb kiszolgálni sávszél tekintetében)

Tőlünk is 120 km BP, én sem szeretnék oda szaladni egy tápcserére, ezért vettük onsite garival a gépeket, ezért javasoltam ezt a verziót. Meg ezért is kell a magas fokú redundancia, hogy ha valami megáll, a szolgáltatás ne szenvedje kárát. Ha ilyen üzletbe vágsz, akkor a kezdeti beruházás mindenképp X összeg ha jól akarod csinálni, függetlenül attól, hogy mennyi bevétel van indulásnál. Nem hiszem, hogy az ügyfelek hosszabb távon tolerálni fogják ezeket a leállásokat, záros határidőn belül tovább állnak majd.

Egyébként itt jut eszembe, hogy ha nem szeretnél véletlenszerű jogi problémákat Windows szerver téren, akkor ellenőrizd, hogy a VM-eken futó Windows szerver példányok annyi magra vannak-e licencelve, amennyi a host-ban van. Sokan nem tudják, hogy hiába futtatják VM-ben csak néhány vCPU-val a Windows Server-t, azt mindig a host gép magszámára kell licencelni. Ahogy írod, Te egy 18 magos gépet üzemeltetsz, ahhoz a gyárilag legnagyobb 16 magos licenc kell, meg még egy kiegészítő 2 magos licenc (16 mag felett kettesével lehet CPU magot licencelni). Ráadásul ha cluster-ben futtatod, és migrálni is szeretnéd olykor, akkor a cluster legnagyobb magszámú gépére kell a licencet megvenni (ha nem azonos kiépítésűek a node-ok).

Szerk.: Azt elfelejtettem írni, hogy nekünk Dell R630 node-ok esetében a BIOS majdnem gyári default-on fut (mínusz HíperThreading, az tiltva van), semmilyen C-state vagy energia gazdálkodás nincs variálva. Egyszer sem volt lefagyás. Szerintem neked a szerver gép miatt vannak ezek a gondok. De van ügyfelünknél HP DL385G8-as szerveren is PVE6, 2x32 magos AMD CPU-kon, azon sincs a BIOS semmi módon default-ról elállítva, és eddig (néhány éve megy) nem volt vele gond.

Igazi tudományos/tapasztalati alapja nem volt, csak (amikor a rendszer készült) több, virtualizációval foglalkozó írásban említiették, hogy van olyan sérülékenység, ami a HT letiltásával megelőzhető.

Viszont még csak igazat sem mondtam ezzel kapcsolatban, mert most ránéztem, és engedélyezve van a HT a node-okon... Tehát csak úgy emlékeztem, hogy kikapcsoltuk, de valójában vagy nem kapcsoltuik ki, vagy nem hagytuk kikapcsolva. Biztosan találtunk olyan írásokat, amik azt mondták, hogy azt a sérülékenységet rettentő nehéz kihasználni.

( WG | 2022. 06. 22., sze – 09:18 )

Tegnap visszatettem az 5.13.19-6-pve kernelt.
Üzemeltetek több hasonló gépet, amely nem produkálja ezt a hibát. Ugyan ez a P93 szerver a Hetznernél. Igaz, másik ország, de a szolgáltató cég ua., 128 GB RAM (vs. 256 GB), kevesebb, mint 50% kiosztva a VM-eknek (vs. 60-70%), 3-4 VM (vs. 13), 1 IP (vs. 7), 4x nVME (vs. 2x nVME + 2x HDD), default BIOS beállítás (vs. kikapcsoltuk már a jövő hetet is), Debian 11 + Proxmox LVM-el a root (vs. ZFS root), stb...
Már csak 2 (+1) kérdésem maradt.
1. azok miért nem érintettek ezzel a (tfh.) kernel bug-gal kapcsolatban?
2. ha mondjuk a következő 2 hétben nem jön elő a hiba (eddig 8 napnál többet nem ment egyhuzamban) az érintett szerveren, akkor a többin is downgrade-eljek 5.13.19-6-pve kernelre (és soha többé ne frissítsek kernelt? :D)?
+1. én vagyok ilyen szerencsétlen, hogy az "ez IPARI cucc, nem otthoni játékszer", "ATOMSTABIL", "10+ éve üzemeltetünk végtelen számú Proxmox szervert hiba nélkül", stb. Proxmox élete első hibájába belefutottam, vagy ...?

Hát tudtommal a proxmox, főleg ha ingyé van akkor te vagy a tesztelő, beta channel. Mit vársz ?

Nem ismerem a proxmox policy-t, egy kernel bugot hogyan javítanak. Bár a fentiek ismeretében a javítás egy új kernelt jelent ennek minden előnyével és hátrányával.

Szerencsére a xcp-ng 4.19 patchelgeti ... Atomstabil

Fedora 38, Thinkpad x280

Hát annó volt olyan, hogy szétvált a repo az ingyeneskre és a fizetősökre:

Itt is valami ilyesmit írnak:

https://pve.proxmox.com/wiki/Package_Repositories

Tehát idézet onnan:

Proxmox VE Enterprise Repository

This is the default, stable, and recommended repository, available for all Proxmox VE subscription users. It contains the most stable packages and is suitable for production use. The pve-enterprise repository is enabled by default:

És van a

 

Proxmox VE No-Subscription Repository

This is the recommended repository for testing and non-production use. Its packages are not as heavily tested and validated. You don’t need a subscription key to access the pve-no-subscription repository.

 

Ezek szerint lehet különbség. És eleve ezt mondják production-use ra.

Szóval attól mert nem használom, nagyjából tisztában vagyok vele.

 

Vagy valamit kihagytam ?

Fedora 38, Thinkpad x280

+1: "10+ éve üzemeltetünk végtelen számú...", mert ők üzemeltetik. Azaz az ilyen kernel problémákra (már ha ez a hiba) van belső megoldásuk. Az üzemeltetés erről szól. Te nem üzemelteted, csak használni akarod és szolgáltatást nyújtasz. AZ üzemeltetés azt jelentené, hogy van 1-2 teszt szerver, amelyeket terhelten futtatsz, nézed a működésüket, verzióléptetés előtt komolyabb teszt, a munkaidőd egy része a proxmox fórumok túrása.

üzemeltetést != használat

Tegnap frissítettem 7.2-5 verzióra (Linux 5.15.35-3-pve #1 SMP PVE 5.15.35-6 (Fri, 17 Jun 2022 13:42:35 +0200)).
Az "intel_iommu=off" kernel paramétert beírtam a Systemd-boot-ba... ma 11:47-kor újra megadta magát a technika -> hard reset.
Pin-elem a 5.13.19-6-pve verziót és meglátom, az működik-e!?

( influencer | 2022. 06. 22., sze – 18:20 )

Nekem pár hónapja volt ilyen hiba:  i7-12700K + Windows 11 64 bit + Virtualbox esetén.

Bármilyen VM fut, egy idő után timeout kezd lenni, de néha elsőre sem jó, az a lényeg hogy megbízhatatlan, nem használható. Fut a Linux, majd kezd nem reagálni, vagy be sem kapcsol rendesen. Órákig próbálgattam mindenféle beállítást, HTt kikapcsoltam a processzorban, az E magokat is, meg pár bios beállítást, de nem változott.

Én megoldottam: másik gépen futtatok VMeket, amin nincs ez a bug. Majd valamikor újra megnézem, de roppant idegesítő, hogy az egész guest lehal, nem tud írni, mert a CPU nem végzi el a műveletet. A virtualizáláson kívül minden jól működik és atom stabil. Lehet a Virtualbox nem csinálta meg jól ennek a processzornak a támogatását. Vagy a Windows 11 nem kezeli jól. 

Ez azért radikálisan különböző felállás, bár a tünet hasonló. Ugyanis a legfrissebb Windows plusz legfrissebb VirtualBox, desktop hardveren az nem a stabilitás bástyája soha...

Érdekelne az a verzió, ha a Windows saját Hyper-V-jét használnád az adott VM(eke)t, akkor is jelentkezne-e a probléma, vagy azzal tökéletes lenne. Merthogy a Windows-ban (már a 10-ben is) rengeteg minden működik a háttérben Hyper-V alapokon, és két hípervisor jellemzően nem fér meg egy csárdában, régen is tiltani kellett a Hyper-V-t a VirtualBox hibátlan működéséhez.