Proxmox VE 7 tippek, trükkök

Virtualizáció

Sziasztok!

A tapasztalt Proxmox adminoktól kérdeznék itt néhány dolgot, ill. várok hasznos tanácsokat, tippeket, trükköket, scripteket, amik segítik a mindennapi üzemeltetést.

  • 1006 megtekintés

( WG | 2021. 12. 23., cs – 15:00 )

Szerkesztve: 2021. 12. 23., cs – 15:28

Van arra lehetőség, hogy a noVNC konzolban működjön a vágólap a gépem és a guest között?

Most pl. migrálok Windowst, ami eddig SATA driverrel ment, ezután SCSI-vel fog.
Csökkentett mód, parancssor, RDP még nincs...
Az alábbi parancsokat kell begépelnem:V

drvload g:\vioscsi\2k19\amd64\vioscsi.inf
dism /image:f:\ /add-driver /driver:e:\vioscsi\2k19\amd64\vioscsi.inf

... vagy be is illeszthetném, ha lenne osztott vágólap:

Esetleg meg lehetne próbálni a szöveg beillesztést normál VNC kliensen keresztül. Nem tudom hogyan, de úgy emlékszem valahol láttam hogy van rá mód hogy távolról normál vnc klienssel csatlakozz és azt használd a novnc felület helyett. Rövid guglizás után azt találtam, hogy realvnc-n lehet szöveget beilleszteni, gondolom más vnc kliens is tudhatja ezt, hiszen nincs sok különbség leütött billentyűk elküldése, illetve beillesztett szöveg karaktereinek elküldése között.

Windows-nál nem az a szokás, hogy a működő rendszerre feltelepítem az új/leendő hardver meghajtóját, majd cserélem/hozzáadom a hardvert?

Én még az életben nem csináltam ilyen parancssorból driver betöltést semmilyen eszközhöz Windows esetében...

Működő Windows esetén, VirtIO-nál csak lefuttatod a telepítő CD-n lévő intall EXE-t, az feltesz minden vio driver-t egyszerre, és meg is vagy. Ezen felül én telepítés közben - amikor a tároló driver betöltése szükséges, hogy meglássa a telepítő a virtuális lemezeteket - az összes driver-t betöltöm egyesével (nem csak a viortio-scsi-t), és akkor a telepített Windows első indulásakor már mindennek van meghajtója, él a hálózat, stb. Csak a Guest Agent-et kell telepíteni.

Tegnap kipróbáltam, hogy még a VirtualBox alatt a működő Windowsból unstalláltam a VBoxGuest Addont. Feltelepítettem a Virtio agentet és a vio drivereket.

Átkonvertáltam qcow2-be a vdi-t... ééééés .... nem bootolt ugyan úgy a nyomorék. (SATA módban bootolt, később kipróbáltam)
Megpróbáltam "kézzel" betölteni a drivert. A betöltés még ment, megjelent a "C:", a dism-el állítólag telepítette is a drivert, de a Windows ezután sem bootolt.
Elqrt*m másfél órát az életemből, de legalább kiderült az igazság. :)

Ezután újra megcsináltam úgy, ahogy leírtam (tehát a VBox vdi-r qcow2-be, kézi scsi driver telepítés, majd a működő Windows alol uninstall VBoxGuest és vio telepítése), úgy ismét működött.

( WG | 2021. 12. 23., cs – 15:01 )

Meg lehet valahogy (nem hálózati megosztással) oldani, hogy a host egy adott könyvtárát lássa a guest (mint VirtualBoxban a shared folder)?

A guest lássa? Mit akar a guest a host könyvtárában? Ez szvsz security hole lenne.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Linux-al megoldható ha konténert használsz, ami amúgy is javasolt minden esetben ha csak valami extra elvetemült igény miatt nem kell vm. A windows-al tudtommal nem lehet, de majd kijavítanak ha valakinek sikerült.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

https://pve.proxmox.com/wiki/Linux_Container#_bind_mount_points

De ez sem ajánlott és inkább fordítva fordul elő, a host éri el guest-et. Szerveres környezetben a guest-nek semmi keresnivalója sincs a szerveren.

A doskiból:

For security reasons, bind mounts should only be established using source directories especially reserved for this purpose, e.g., a directory hierarchy under /mnt/bindmounts. Never bind mount system directories like /, /var or /etc into a container - this poses a great security risk.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Világos és értem az aggodalmatokat... :)
Elmondom az eddigi usecase-t

Van egy fájlszerver, amelyen könyvelőprogramokat kell meglehetősen sűrűn frissítgetni.
A néhány MB-os frissítő fájlokat a szerverre töltöttem fel scp-vel egy adott könyvtárba, amit a fájlszerver olvasni tudott.
A fájlszerveren nem kellenek ezek a fájlok és a backupban sem, de jó, ha megvannak a visszakövethetőség érdekében. Sosem kellettek még később, de ki tudja?!

Megvagyok nélküle, kár is erről több szót ejteni. Megoldom másképp. :)

Itt látszik, hogy valaki desktopról jön és szervert akar üzemeltetni. :D

Desktop simán elmegy, hogy van a laptopom minden file al, és azon fut virtualboxban egy másik VM ami el akarja érni.

DE egy szerveren ami hypervisor, igazábol semmi másnak nem kell futnia azon kívül, hogy ku tudja szolgálni a VM-eket. Ezért ilyen kérdés kb fel se kellene, hogy merüljön.

Ha nagyon akarod, akkor szerintem valami network filesystemet (samba, NFS) felhúzol és megosztod a VM-el.

Fedora 41, Thinkpad x280

( WG | 2021. 12. 23., cs – 15:04 )

Ha nem tudom a GUI-n leállítani sem Shutdownal, sem Stop-al a guestet. van rá más megoldás, mint a /run/lock/qemu-server alatt kézzel/scripttel törölni a megfelelő .conf fájlt?

cli$ qm unlock [vmid]

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

10 perc a műveltek timeout-ja Proxmox alatt. Ha valami nem sikerül, akkor ezen az időn belül hiába próbálkozol mással, mert lock-olva van az adott VM, az újabb művelet is csak várakozni kezd. Várd meg a timeout leteltét (a log-ban a GUI-n látni fogod, hogy sikertelenné válik az adott művelet státusza), majd ezután próbálj mást.

Pl. Guest Agent engedélyezve van az opciók között, de a VM-ben nem fut még az agent. Ilyenkor pl. shutdown gombra a PVE a GA-en keresztül szeretné levállítani a VM-et, nem ACPI-vel, ami így nem sikerül. Ilyenkor kivárod a timeout-ot, majd poweroff, ami viszont VM futtató processz megállítás, nem ACPI vagy GA művelet, így sikerülni szokott.

Ha már mindenáron kézzel akarsz hozzányúlni, akkor ne állományokat törölj, hanem az adott VM-hez tartozó qemu processzt lődd le a host-on.

( WG | 2021. 12. 23., cs – 15:08 )

A proxmox frissítését a GUI-n keresztül szoktátok csinálni?
Érdemes teszt szerveren kipróbálni a frissítést (tudom, hülye kérdés)?
Előfordult már, hogy egy frissítés elrontott valamit?
Van rollback lehetőség az előző verzióra, ha valami gallyra megy a frissítéskor?

Én a frissítés mindig ssh + tmux alatt csinálom. Lehet, hogy fölöslegesen mert még sosem volt gondom.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( gyuri23 | 2021. 12. 23., cs – 15:23 )

Használd a PBS-t! (Proxmox Backup Srever)

Elképesztően gyors és hatékony és az image mentés mellett megy a file restore is vele windows-ra is.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( WG | 2021. 12. 23., cs – 15:27 )

Szerkesztve: 2022. 01. 07., p – 11:38

A VM Hard Disk beállításánál az alábbiakat használom:
BUS/Device: SCSI
SCSI Controller: VirtIO SCSI
Cache: Write Back
Discard: Yes
SSD Emulation: Yes
Backup: Yes

A többi off

Biztonságos így, ill. így a lehető leggyorsabb a disk elérés?

Szerk.: NVMe van a szerverben a VM-ek alatt.

( dhary | 2021. 12. 23., cs – 16:22 )

/dev/pve/data -t el szoktam távolítani és a /dev/pve/root -nak odaadni a maradék helyet és engedélyezem ide is a vm létrehozási lehetőséget

( WG | 2021. 12. 23., cs – 17:59 )

A :8006 on figyelő GUI-val mit szokás kezdeni?

Szinte mindent :)

A napi üzemeltetéshez szükséges összes dolog elérhető kényelmesen róla. Ami nincs ott, az már nagyon speciális.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

A PVE GUI-t (meg más admin hozzáférést, API-t, stb.) védeni kell. Nem internet-álló a védelme (ahogyan a Hyper-V és a VMware ilyen irányú védelme sem arra készült, hogy közvetlen internet-re legyen kötve). Használd VPN-en keresztül a menedzsmentjét (akár a Web GUI akár az SSH kapcsolatot), akkor elkerülsz egy csomó fejfájást.

( debtamas88 | 2021. 12. 23., cs – 21:32 )

Szerkesztve: 2021. 12. 23., cs – 21:44

Szia!

Van pár:
1., pveproxy, spiceproxy interface bind fix
Minden interface-re kiteszi magát TCP: 8006,3128 porton, ezt GUI-n nem lehet állítani, ki kell kommentezni a forráskódban, patchelni:

/usr/share/perl5/PVE/Service/pveproxy.pm
	# my $socket = $self->create_reusable_socket(8006, undef, $family);
	my $socket = $self->create_reusable_socket(8006, '127.0.0.1', $family);

/usr/share/perl5/PVE/Service/spiceproxy.pm
	# my $socket = $self->create_reusable_socket(8006, undef, $family);
	my $socket = $self->create_reusable_socket(3128, '127.0.0.1', $family);

Ennek következtében a web felületet pedig ssh-val portforward-al lehet elérni ( vagy valamilyen proxy-val )

ssh -L 8006:127.0.0.1:8006 user@serverip
majd azon a gépen amiről az ssh-val mentél be, megnyitod a https://127.0.0.1:8006 böngészőben.
( Működik Windows alatt is putty -val ).

 

 

2., VM  "native" képernyőjének elérése ssh + VNC-viewer (pl.: TigerVNC ):
Proxmox alatt minden VM-nek van egy "native" képernyője, ezt a képernyőt el lehet érni VNC-keresztűl ( semmit se kell telepíteni a VM-re, ez ugyan az képernyő mint amit a webconsole -n látsz ), ehhez VM.conf kell hozzáadni ezt:

args: -vnc 127.0.0.1:0
keyboard: hu

A ":0" az 5900 TCP portot jelenti, keyboard paraméter is kell mert különben "furcsa karakterek" mennének át, majd a fentiek alapján:

ssh -L 5900:127.0.0.1:5900 user@serverip
majd azon a gépen amiről az ssh-val mentél be, megnyitod a VNC-viewerel 127.0.0.1:5900 -t.
( Működik Windows alatt is putty -val ).

VNC-viewer egér+bill működik, vágólap nem fog működni.
Ha több VM-t is így akarsz elérni, akkor a csak a 127.x.x.x:0 tartományból tetszőlegesen választasz a ip-t amire felrakod a VNC portot.
 

 

3., QEMU USB port emuláció - kiszedése:
Proxmox alapból minden virtuális géphez emulál USB controllert, ami egyes esetekben felesleges és erőforrást visz el.
Ez GUI-ból nem lehet állítani, ki kell kommentezni a forráskódban, patchelni:
 

/usr/share/perl5/PVE/QemuServer.pm
	## my @usbcontrollers = PVE::QemuServer::USB::get_usb_controllers($conf, $bridges, $arch, $machine_type, $usbdesc->{format}, $MAX_USB_DEVICES);
	my @usbcontrollers;

Ennek következtében minden VM.conf fájlban, ezt hozzá kell adni, minden esetben

tablet: no

Ha mégis kell USB a VM-ben akkor pedig ezt kell hozzáadni

tablet: no
args: -device piix3-usb-uhci -device usb-tablet

vagy

tablet: no
args: -device piix3-usb-uhci -device usb-kbd -device usb-mouse

 

 

Röviden ennyi :)

Hálás köszönet! Pont ilyen hasznos tanácsokra számítottam. :)

A 2. ponthoz:
Patchelni minde frissítés után kell?
Lehet ezt valahogy automatizálni, hogy el ne felejtsem?

A 3. ponthoz:
Windows Servert érnek el RDP-vel az egyik VM-ben. Mintha a vékonyklienseken használnának USB pendrive-ot.
Ha jól értem, annak a VM-nek a .conf fájljába kell a

tablet: no
args: -device piix3-usb-uhci -device usb-tablet

bejegyzés?

Én nem értem, miért adsz olyan tanácsot (pláne egy ilyesmibe először belekezdőnek), hogy a PVE forrását módosítgassa... Ha nincs gyakorlata, akkor olyant módosít, amit nem kellene és elmúlik az egész akár (pl. neki nem olyan verziója van fent, ami a Te minta kódod), de legjobb esetben is elmúlik a módosítása az első frissítés alkalmával, ami nem lesz eszébe már, és "védettnek" hiszi magát, holott már minden IP-n és interfészen figyel újra a rendszere...

Sokkal egyszerűbb és profibb VPN-en keresztül elérni a menedzsmentet (egyik hypervisor-nak sem internet-álló a védelme, nem csak a PVE-nek), és tűzfallal korlátozni a hozzáférést ezen felül (meg fail2ban-nal). A PVE host-nak meg nem kell olyan hálózatokba interfészt definiálni és címet adni, amiből nem szeretnéd elérni. A VM-ek mehetnek akár publikus internernetre kötött bridge-en is, ha a host-nak nincs ott lába, akkor nem lesz elérhető a gyári kódbázos mellett sem.

( WG | 2021. 12. 23., cs – 22:33 )

Az rpcbind figyelt a 111-es porton.

Letiltottam. Hiányozni fog? Cluster egyelőre nincs tervben, NFS-t nem használok, főleg nem kifelé...
systemctl stop rpcbind.service
systemctl stop rpcbind.socket
... disable ...
... mask ...

Van még valami meglepetés, amitt érdemes lenne letiltanom?

Szerintem nem jól közelíted meg a biztosnág kérdését. Nem tiltogatni kell a gyári beállításokból (mert 2-3 hónap múlva ha valami nem kel életre, nem fogsz emlékezni, hogy letiltottál egy csomó dolgot, hanem keresni fogod a hibát).

Nem kell semmit letintani vagy átkonfigurálni. Kell egy menedzsment csatlakozás, hozzá tartozó IP címmel a PVE részére, szeparáltan minden mástól, és a PVE rendszer azon él majd. Az összes többi hálózati kapcsolatba egyszerűen nem kell bevonni a PVE menedzsment felületét/kapcsolatát. Ha csak egyetlen fizikai hálózati csatlakozásod van, akkor tedd VLAN-ba a menedzsmentet. Olyant semmiképp se csinálj, hogy egy csatlakozással, pláne egy publikus IP-re kiteszed az egész rendszert, és onnan akarod menedzselni is.

( WG | 2021. 12. 23., cs – 22:34 )

Szerkesztve: 2021. 12. 23., cs – 22:35

Az normális, hogy ~580 process fut a szerveren úgy, hogy még egy VM-et sem hoztam létre?
Egy mezei Debianon kb 200 szokott futni...

Egy sima Debian telepítés olyan üres, hogy igazából nem kellene futnia semminek, ahhoz képest sok a 200, nem a PVE alaprendszeren az 580 :-DDD

Az egyik PVE cluster-ünkön (4 host, Ceph-fel, csak VM-en, nincs konténer), ami kb. 40 VM-et futtat jelenleg, és az érintett host-on ebből 10 VM fut, éppen ~780 processz él, amiből 2-3 fut átlagosam (2-3 között alakul a load tartósan). Ja, minden VM-ben a tárolás és sokszor a hálózat is iothread-del fut (ami jóval több szálat eredményez VM-enként, mintha e nélkül futnának).

( WG | 2022. 01. 07., p – 00:48 )

Szerkesztve: 2022. 01. 07., p – 01:22

Egy Proxmox VE 7 szerveren az egyik VM-ben futó mail szervert kívülről elérem. Megy a küldés és az e-mail fogadás is.
De ha ugyan ezen a vason futó másik VM Thunderbirdjéből próbálom elérni, nem jön létre a kapcsolat. Idűtúllépés után hibaüzenet jön.

Mit ronthattam el?

Szerk.: pingre sem válaszol a mail.domain.tld és IP cím alapján sem Windows VM-ből. Az IP-t jól oldja fel, de "Request timed out".
A pve-ről megy a ping. A Datacenter tűzfalon engedélyeztem az icmpt mindenhonnan.

Ezzel én is szívtam/szívok. Mivel nálam a másik vm egy teszt gép, így ez nekem nem okoz jelenleg gondot, viszont érdekelne engem is egy megoldás, leszámítva a vmbr natolását, mert úgy ugye menni fog levelezés, csak az nagyon nem jó megoldás pl. a log szempontjából sem.

üdv: pomm

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

( gyuszicco | 2022. 01. 07., p – 12:39 )

sub

The worst or stupidest ideas are always the most popular.