Zabbix – Monitorowanie Proxmoxa

Aby monitorować Proxmoxa instalujemy na każdym nodzie Agenta Zabbix i dodajemy go do Zabbixa wskazując Templates „Linux by Zabbix agent”, „Proxmox VE by HTTP”.

Teraz w Proxmoxie dodajemy użytkownika zabbix oraz token.

Datacenter > Permissions > User > Add
Wypełniamy:

  • User name: zabbix
  • Realm: Linux PAM
  • Expire: never
  • Enabled: checked
  • First Name: dowolny
  • Last Name: dowolny

Datacenter > Permissions > Api Tokens > Add
Wypełniamy:

  • User: Wybieramy utworzonego
  • Token ID: Dowolny (np: ZabbixMonito01)
  • Privilege separation: checked

Po kliknięciu Add zapisujemy sobie Token ID oraz Secret, gdyż później Secret nie będzie już dostępny.

W Proxmoxie dodajemy uprawnienia do użytkownika i tokena
Datacenter > Permissions > Add > User Permission
Wypełniamy:

  • Path: /
  • User: Wybieramy utworzonego
  • Role: PVEAuditor
  • Propagate: no checked
  • Path: /nodes
  • User: Wybieramy utworzonego
  • Role: PVEAuditor
  • Propagate: checked
  • Path: /vms
  • User: Wybieramy utworzonego
  • Role: PVEAuditor
  • Propagate: checked
  • Path: /storage
  • User: Wybieramy utworzonego
  • Role: PVEAuditor
  • Propagate: checked

Datacenter > Permissions > Add > Api Token Permission

Dla tokena ustawiamy identyczne uprawnienia jak dla użytkownika

Wracamy do konfiguracji Zabbixa aby ustawić wygenerowany Token

Data collection > Hosts > <Proxmox name> > Macros

  • {$PVE.TOKEN.ID} value: Token ID
  • {$PVE.TOKEN.SECRET} value: Secret

Proxmox klaster – zmiana adresów ip lub nazwy hosta

Procedura zmiany adresów ip lub nazwy hosta w nodach klastra Proxmox.

Przed zmianą adresów musimy zapewnić aby nody widziały się używając nowych ip.
Na zmienianym nodzie przygotowujemy konfigurację interfejsów z nowym adresem i sprawdzamy czy jest komunikacja między pozostałymi nodami a tym nowym ip.

Ja dodałem nowy interfejs VLAN do którego przypisałem adres 192.168.8.3:

# ip a
. . . . . . .
vmbr0.255@vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.3/24 scope global vmbr0.255
. . . . . . .

Wyłączamy lub przenosimy wszystkie vm z noda którego zmieniamy.

W shell na zmienianym nodzie, sprawdzamy status klastra.

# pvecm status
. . . . . . 
Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 192.168.1.1
0x00000002          1    A,V,NMW 192.168.1.2
0x00000003          1    A,V,NMW 192.168.1.3

Następnie w pliku /etc/pve/corosync.conf zmieniamy ip lub nazwę hosta naszego noda oraz config_version. Musimy to zrobić bardzo ostrożnie gdyż każdy zapis zostanie od razu rozpropagowany na pozostałe nody klastra. Teraz na pozostałych nodach sprawdzamy czy naniesione zmiany są widoczne w pliku /etc/pve/corosync.conf.

Na każdym nodzie restartujemy corosynca.

# systemctl restart corosync

Ponownie sprawdzamy status klastra

# pvecm status
. . . . . . 
Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 192.168.1.1
0x00000002          1    A,V,NMW 192.168.1.2
0x00000003          1    A,V,NMW 192.168.8.3

Powinniśmy nadal obserwować quorum, a nasz nod będzie miał zmieniony ip.

Pozostało nam zaktualizować adres ip lub nazwę hosta w pliku /etc/hosts.

Jeżeli chcemy zmienić ip lub nazwę hosta następnemu nodowi postępujemy dokładnie tak samo.

Proxmox VE (PVE), Proxmox BS (PBS) – konfiguracja powiadomień email

Ustawiamy serwery Proxmox, aby wysyłały maile z powiadomieniami.

  1. Ustawiamy w www GUI adres email z którego będzie wysyłana poczta:
    PVE: Datacenter > Options > Email from address
    PBS: Configuration > Others > Email from addresss
  2. W opcjach użytkownika ustawiamy adres email na który mają być wysyłane powiadomienia.
  3. Do /etc/hosts jeżeli brak, to dodajemy wpisz z adresem ip naszego noda, nie wystarczy localhost.
  4. Konfigurujemy Postfixa jako root. Musimy to zrobić na każdym nodzie klastra PVE.

(Zmieniamy lub dodajemy opcje do konfiguracji postfixa)
# nano /etc/postfix/main.cf

relayhost = [adres.serwera.poczty]:465
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

(dla konfiguracji ssl/tls(port465) dodajemy dodatkowo wpisy)
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt

(Dodajemy dane potrzebne do uwierzytelnienia na serwerze poczty)
# nano /etc/postfix/sasl_passwd

[adres.serwera.poczty]:465    NAZWA_UZYTKOWNIKA:HASLO

(Zmieniamy uprawnienia)
# chmod 600 /etc/postfix/sasl_passwd
# postmap /etc/postfix/sasl_passwd

(Instalujemy bibliotekę)
# apt-get install libsasl2-modules

(Restart Postfixa)
# systemctl restart postfix.service

(Test)
# echo "Subject: Testa"| sendmail -f adres@email.zrodlowy -v adresat@maila

W razie niepowodzenia wysyłki czytamy logi Postfixa i modyfikujemy konfigurację
PVE: NazwaNoda > System > Syslog
PBS: Administration > Services > Postfix (podwójne kliknięcie)s

Proxmox – Usunięcie klastra – usunięcie ostatniego noda z klastra

Poinformowanie naszego ostatniego noda, że ma pracować bez kworum
# pvecm expected 1

Zatrzymanie klastra
# systemctl stop pve-cluster

Uruchomienie noda w trybie lokalnym 
# pmxcfs -l

Usunięcie wszystkich plków konfiguracyjnych klastra
# rm -f /etc/pve/cluster.conf /etc/pve/corosync.conf 
# rm -f /etc/cluster/cluster.conf /etc/corosync/corosync.conf 
# rm /var/lib/pve-cluster/.pmxcfs.lockfile

Zatrzymanie klastra
# systemctl stop pve-cluster

Przenoszenie VM z ESXi do Proxmox

Aby przenieś VM z ESXi do Proxmoxa wyłączamy na ESXi VM i kopiujemy pliki VMDK do Proxmoxa. W Proxmoxsie zakładamy nową VM nie wskazując nośnika instalacyjnego ani dysku.

Konwertujemy przekopiowane plik VMDK na Proxmoxie

qm disk import <vmid> <source> <storage> [options]

# qm importdisk 100 ./dysk.vmdk local-zfs

Możemy wskazać dodatkowo format do jakiego będziemy importować
–format <raw | qcow2 | vmdk>

Po przekonwertowaniu dysków wchodzimy do ustawień sprzętu VM (Hardware) i na każdym Unused Disk wykonujemy Edit a następnie Add.

Jeżeli dysk się nie pojawił w menu Hardware to w shellu uruchamiamy:

# qm rescan

W Options > boot order, ustawiamy z którego dysku system ma się bootować.

VMWare Player/Worstation. Kernel Module Updater failed

Skrypcik pobiera kompiluje i instaluje moduły jądra do VMWare Player/Worstation

VMWARE_VER=workstation-16.2.4
FOLDER=/tmp/patch-vmware
rm -fdr $FOLDER
mkdir -p $FOLDER
cd $FOLDER
git clone https://github.com/mkubecek/vmware-host-modules.git
cd $FOLDER/vmware-host-modules
git checkout $VMWARE_VER
git fetch
make
sudo make install
sudo rm /usr/lib/vmware/lib/libz.so.1/libz.so.1
sudo ln -s /lib/x86_64-linux-gnu/libz.so.1 /usr/lib/vmware/lib/libz.so.1/libz.so.1 

Proxmox – ZFS użycie pamięci

ZFS domyślnie wykorzystuje 50% pamięci hosta na Adaptive Replacement Cache (ARC). Przydzielanie wystarczającej ilości pamięci dla ARC ma kluczowe znaczenie dla wydajności IO, więc należy ją zmniejszać ostrożnie. Ogólną zasadą jest przydzielenie co najmniej 2 GiB + 1 GiB na 1 TiB przestrzeni dyskowej. Na przykład, jeśli masz pulę z 8 TiB dostępnej przestrzeni dyskowej, powinieneś użyć 10 GiB pamięci dla ARC

Możesz zmienić limit wykorzystania ARC dla bieżącego rozruchu (ponowne uruchomienie resetuje tę zmianę ponownie), wpisując bezpośrednio do parametru modułu zfs_arc_max:

# echo "$[10 * 1024*1024*1024]" >/sys/module/zfs/parameters/zfs_arc_max

Aby na stałe zmienić ilość pamięci ARC wpisujemy do /etc/modprobe.d/zfs.conf

options zfs zfs_arc_max=10737418240

W przypadku, gdy ustawiana wartość zfs_arc_max jest mniejsza lub równa zfs_arc_min (co domyślnie wynosi 1/32 pamięci systemowej), zfs_arc_max zostanie zignorowane, chyba że ustawisz również zfs_arc_min na co najwyżej zfs_arc_max – 1.

# echo "$[10 * 1024*1024*1024 - 1]" >/sys/module/zfs/parameters/zfs_arc_min

lub zapisując na stałe do /etc/modprobe.d/zfs.conf

options zfs zfs_arc_max=10737418239

Jeśli głównym systemem plików Proxmoxa jest ZFS, musisz aktualizować initramfs i rebootować Proxmoxa za każdym razem, gdy zmienisz te wartości:

# update-initramfs -u
# reboot

Notatka na podstawie: https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_limit_memory_usage

ESXi – Usuwanie snapshotów z CLI

Logujemy się do ESXi przez ssh.

Wyświetlamy listę wirtualnych maszyn aby uzyskać Vmid interesującej nas maszyny.

# vim-cmd vmsvc/getallvms

Vmid Name File Guest OS Version Annotation
1 vm2 [datastore1] vm1/vm1.vmx windows7 vmx-02
3 vm3 [iscsi1] testvm/vm2.vmx Linux vmx-04

Sprawdzanie snapshotów dla maszyny o wybranym Vmid

# vim-cmd vmsvc/snapshot.get [Vmid]
Get Snapshot:
|-ROOT
--Snapshot Name : Snapshot1
--Snapshot Desciption :
--Snapshot Created On : 04/27/2022 10:22:01
--Snapshot State : powered on

Usunięcie wszystkich snapshotów dla maszyny o wybranym Vmid

# vim-cmd vmsvc/snapshot.removeall [Vmid]

vSphere – problem z konsolidacją

vSphere czasem wyświetla komunikat o konieczności konsolidacji dysku. Może się zdarzyć, że wykonanie konsolidacji nie daje efektu. Mimo, że na liście snapshotów nie ma, żadnych pozycji, to w katalogu VM istnieją pliki *0000x.vmdk, oraz w konfiguracji dysków maszyny widzimy, że maszyna używa pliku *0000x.vmdk.

Możliwe rozwiązania:

  1. Tworzymy snapshot z opcją „Quiesce guest file system”, po utworzeniu usuwamy wszystkie snapshoty „Delete all”. Sprawdzamy w konfiguracji VM czy nadal jest używany dysk *0000x.vmdk
  2. Możemy również spróbować migrować maszynę wirtualną do innego datastorage.
  3. Jeżeli problem nadal istnieje to zatrzymujemy VM, tworzymy kopię maszyny „Clone > Clone to virtual machine”. Następnie uruchamiamy skopiowaną maszynę, sprawdzamy czy działa prawidłowo, i usuwamy oryginalną VM. ESXi bez vCenter nie pozwala klonować maszyn VM. Musimy w cli użyć polecenia „vmkfstools -i” do zrobienia kopii virtualnego dysku z którym mamy problem.

GNS3 – podłączenie do fizycznej sieci

Często podłączenie GNS3 do sieci fizycznej z użyciem komponentu Cloud może sprawić duże problemy.

Jeżeli w naszym przypadku występuje problem, możemy dodać do GNS3 VM dodatkową kartę sieciową ustawioną w trybie Bridged.

Teraz przy wstawianiu komponentu Cloud do projektu wybieramy jako serwer maszynę GNS3 VM

Podłączając komponent wirtualnym kablem, wybieramy dodaną kartę sieciową, która pracuje w trybie Bridged na GNS3 VM.