Installation Ich habe als Grundlage die Version 4.3 verwendet. Um die Installation durchzuführen lädt man einfach das iso File von der Webseite. Ich habe rufus verwendet um einen USB-Stick damit zu befüllen. Hier muss man jedoch aufpassen das man den dd Mode wählt und nicht den iso Mode da der Stick sonst nicht funktioniert.

Alle Server in einem Cluster müssen die gleiche Zeit haben. Wenn dies nicht der Fall ist kommt zu Problemen. Daher sollte man unbedingt die NTP Einstellungen überprüfen. Es werden automatisch externe NTP Server konfiguriert.

Möchte man die NTP Einstellungen selbst vornehmen sind dies die nötigen Punkte.

vi /etc/systemd/timesyncd.conf
systemctl restart systemd-timesyncd.service
timedatectl set-ntp true
systemctl status systemd-timesyncd.service

Kontrolle ob der NTP nach dem Neustart sich auch wirklich verbinden konnte

journalctl --since -1h -u systemd-timesyncd

Möchte man ein ISO zum Installieren von VMs hochladen kann dies per WebGUI oder per SCP/SFTP gemacht werden. Über das WebGUI funktioniert dies ganz einfach so: Storage View –> Datastore –> Content

Verwendet man NFS Datastores und möchte dies mittels SCP/SFTP hochladen muss man in den Pfad “/mnt/pve” hineinschauen. Dort findet man die NFS Mounts. In meinem Beispiel muss ich ein ISO unter diesen Pfad ablegen: “/mnt/pve/prox_01/template/iso” ablegen.

Die Filesystemstruktur in einem Datastore wird von Proxmox so angelegt bzw. aufgebaut:

• Backups - Dumps von ganzen VM's
• Containers - Ablage von Containern (keine VM's)
• Images - Hier liegen alle VM's
• Templates - Ablege von ISOs und Templates

Dazu muss man im WebGUI angemeldet sein um einen Shared Storage anzubinden. Es gibt verschiedene Protokolle und Möglichkeiten die verwendet werden können. Weiters gibt es auch verschiedene “Content” Möglichkeiten die ein Datastore bekommen kann. Hier eine Liste davon:

• Disk Image - Ablage von VMs auf dem Datastore
• ISO Images - Ablage von ISOs auf dem Datastore
• Container Templates - Ablage von Container Temples auf dem Datastore
• VZDump Backup File - Es können Backups erstellen werden. Jedoch nur bis zur konfigurierten max Marke des Datastores.
• Unordered List ItemContainer - Ablage von Container auf dem Datastore

Mit Max Backups kann man angeben wie viele Backups maximal pro VM auf einem Datastore abgelegt werden dürfen.

Möchte man zu einem bestehenden Cluster auf dem schon Shared Storages gemountet sind einen Host hinzufügen werden alle Datastores auch auf der neuen Node sofort gemountet sofern diese auf der Storage die Berechtigungen dazu hat.

Noch nicht fertig!

Möchte man etwas am Netzwerk ändern und den Host nicht rebooten (so wie es PVE normal machen würde) kann dies über das Webinterface und die Shell gemacht werden. Ein ILO/IDRAC oder sonst ein Interface wo man direkt auf den physischen Server kommt falls ein Fehler entstehen sollte ist von Vorteil:

1. Ändern der gewünschten Änderungen im Webinterface
2. Absetzten eines angepassten CMDs in der Shell. Es muss das Interface das man verändert möchte abgedreht werden. Danach die Konfig interfaces.new über interfaces kopiert werden und danach das Interface wieder aufgedreht werden.

Hier ein Beispiel dazu:

root@pm03:/etc/network# ifdown bond0 ; cp interfaces.new interfaces ; ifup bond0

Globale PVE Cluster Doku
Ein Cluster in Proxmox ist ein Zusammenschluss von mehreren Nodes. Dies bedeutet das alle Nodes in einem GUI zu bedienen sind und alle Shared Datastores automatisch auf alle Nodes gemountet werden. Um einen Cluster zu erstellen muss auf der ersten Node im Cluster dies ausgeführt werden da im GUI kein Cluster angelegt werden kann:

pvecm create <cluster_name>

Achtung! –> Cluster können nicht mehr umbenennt werden. Ein Cluster ist nur ein Zusammenschluss von Hardware Nodes. Diese Nodes betreiben jedoch nicht automatisch ein Failover der VMs. Dieser Punkt wird später angeführt.

Möchte man gleich einen Cluster mit einem gesonderten HA Netzwerk erstellen (empfohlen!) sollte man so vorgehen.
Beschreibung des Netzwerkes:

• Managment Netz - 172.27.9.0/24 → Bond0 (zB. 2x 1Gbit Kupfer) → Globaler IP Traffic
• HA Netz - 172.27.5.0/24 → Bond1 (zB. 2x 1Gbit Kupfer) → Nur HA Traffic
• Storage Netz - 10.27.8.0/24 → Bond2 (zB. 2x 10Gbit Glas) → Storage NFS Traffic

Jetzt muss ein Cluster erstellt werden der den HA Traffic auf Bond1 auslagert jedoch zur Not auf Bond0 laufen kann falls Bond1 nicht schnell genug antwortet oder ausgefallen ist. Dazu muss das Hostfile noch vorbereitet werden um vom DNS Service unabhängig zu sein.

root@pveserver01:~# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost


# PVE Cluster Settings

# IP - HA-Ring 1
172.27.9.41	pveserver01.mgt.domain.loc pveserver01
172.27.9.42	pveserver02.mgt.domain.loc pveserver02
172.27.9.43	pveserver03.mgt.domain.loc pveserver03


# HA - HA-Ring 0
172.27.5.11     pveserver01-ha.mgt.domain.loc pveserver01-ha
172.27.5.12     pveserver02-ha.mgt.domain.loc pveserver02-ha
172.27.5.13     pveserver03-ha.mgt.domain.loc pveserver03-ha


# Storage - Kein Ring
10.27.8.61	pveserver01-storage.mgt.domain.loc pveserver01-storage
10.27.8.62	pveserver02-storage.mgt.domain.loc pveserver02-storage
10.27.8.63	pveserver03-storage.mgt.domain.loc pveserver03-storage

Anlegen des Clusters

pvecm create pvecluster01 --bindnet0_addr 172.27.5.11 --ring0_addr 172.27.5.11 --bindnet1_addr 172.27.9.41 --ring1_addr 172.27.9.41

Danach schadet es nicht einen Blick in die corosync.conf zu sehen. Wichtig dabei ist das wir zwei Ring Netzwerke sehen und ein der “rrp_mode” auf passive steht. Dies bedeutet das immer Ring0 für den HA Traffic verwendet wird. Antwortet Ring0 nicht wird Ring1 verwendet.
Hier eine Config eines neu angelegten Cluster (aktuell nur eine Node)

root@pveserver01:~# cat /etc/corosync/corosync.conf 
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: pveserver01
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 172.27.5.11
    ring1_addr: 172.27.9.41
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: pvecluster
  config_version: 1
  interface {
    bindnetaddr: 172.27.5.11
    ringnumber: 0
  }
  interface {
    bindnetaddr: 172.27.9.41
    ringnumber: 1
  }
  ip_version: ipv4
  rrp_mode: passive
  secauth: on
  version: 2
}

Möchte man weitere Nodes (als die eine) zu dem Cluster hinzufügen muss man in der Shell der Nodes die man hinzufügen möchte dies ausführen:

pvecm add <ip_der_erst_node>

Möchte man eine Node zu einem Cluster mit einen ausgelagerten HA Netz hinzufügen macht man dies ähnlich wie davor beim anlegen.

pvecm add <ip first node of the cluster> --link0 <own ip corosync link 0> --link1 <own ip corosync link 1>

Bespiel:
pvecm add 172.27.9.41 --link0 172.27.5.12 --link1 172.27.9.42

Danach hat man einen Cluster mit x Nodes. Um den Cluster administrieren zu können geht man einfach auf die WebGUI der ersten Node. Die anderen Nodes synchronisieren sich diese Infos bezüglich dem WebGUI Management in den nächsten Minuten. Danach kann man sich auf das WebGUI jeder Node verbinden um den Cluster zu administrieren. Das WebGUI ist damit gegen Ausfälle einer Node geschützt.

Möchte man eine Node aus dem Cluster nehmen und neu installieren (mit der gleichen IP) wird man später ein Problem haben die Node wieder in den Cluster zu nehmen. Man wird den Fehler “unable to copy ssh ID” bekommen. Wenn dies der Fall ist geht man mit SSH auf die erste Node:

pvecm expected <anzahl_der_aktuell_nodes>

Achtung! Die Anzahl muss die Anzahl der aktuell im Cluster verbleibenden Nodes sein. Die Aktuelle Node die hinzugefügt werden möchte darf dabei nicht mitgezählt werden.

Die Node die man entfernen möchte muss davor ausgeschalten werden. Danach auf einem bestehenden Cluster Member anmelden und die abgedreht Node aus dem Cluster entfernen

pvecm delnode <node_name>

Achtung! Die Node muss davon ausgeschalten werden.

Anzeigen wie es dem Cluster geht auf der Shell

pvecm status
pvecm nodes

Um den Multicast zu testen kann man ein einfaches Tool verwenden.
Es ist nur ein Loss von <1% in Ordnung.

omping -c 10000 -i 0.001 -F -q Node1-HA-IP Node2-HA-IP ...
omping -c 10000 -i 0.001 -F -q Node1-MGT-IP Node2-HA-MGT ...

omping -c 600 -i 1 -q Node1-HA-IP Node2-HA-IP ...
omping -c 600 -i 1 -q Node1-MGT-IP Node2-HA-MGT ...

Ist eine Node im Webinterface als Disconnected angezeigt ob sie läuft und kann man auch den Cluster status nicht mehr auf der Node abfragen kann es sein das die Quorum Services nicht laufen. Diese dann einfach versuchen einmal neu zu starten

systemctl status corosync.service
systemctl restart corosync.service

Es gibt eine Datacenter Config in PVE in der ein paar wichtige Einstellungen getroffen werden können.

vim /etc/pve/datacenter.cfg

email_from: <welchen Absender verwendet pve>
keyboard: <Keyboard lang>
bwlimit: migration=<vm migration Speed in Megabyte / Sec >
migration: secure,network=<über welches Netzwerk soll migriert werden>


Beispiel:
email_from: supergeil@heisl.org
keyboard: de
bwlimit: migration=716800
migration: secure,network=10.27.8.0/24

Hier die offizielle Doku

HA ist erst ab einem 3 Node Cluster möglich (Quorum). Alternativ kann man auch eine Quorum Disk auf zwei Nodes mounten. Diese Disk muss ein Block-Device auf einer Shared Storage sein. Näher möchte ich jedoch auf einen 2 Node HA Cluster nicht eingehen.

Über den HA Manager legt man grundsätzlich zwei Punkte fest:

• Welche VMs sollen via HA geschützt werden
• Welche VMs sollen auf welchen Hosts laufen

Um VMs mit HA schützen zu können sind HA Gruppen nötig. In eine HA Gruppe kommen VMs die geschützt werden sollen und auch Hosts auf denen die VMs laufen können bzw. dürfen. Die Hosts in einer Grupp kann man zusätzlich noch mit einer Priorität versehen (Priorität nur via Shell möglich). Hier gilt die Regel der oder die Hosts mit der höchsten Priorität bekommt die VMs zugewiesen. Die Standardpriorität ist 0

HA Gruppen werden zusätzlich zwei Kategorien eingeteilt:

• Restricted - VMs in der Gruppe dürfen nur auf Hosts laufen die der Gruppe zugewiesen sind
• Nofailback - VMs in der Gruppe laufen nur auf Hosts die der Gruppe zugewiesen sind jedoch im Fehlerfall der Hosts in dieser Gruppe dürfen VMs auch auf Hosts laufen die nicht in dieser Gruppe sind. Sprich Fallen allen Hosts der Gruppe aus und es gibt noch weitere Hosts ohne Gruppen bzw. anderen Gruppen so werden die VMs dorthin verschoben.

Weiters gibt es HA-Ressourcen bei denen man angeben kann wie eine VM neugestartet werden soll:

• Max Restart - Gibt an wie oft der Cluster versuchen soll die VM in den gewünschten Status zu bringen
• Max Relocate - Gibt an wie oft der Cluster versuchen soll die VM zu verschieben bis sie den gewünschten Status ist.
• Request State - In welchen Status soll eine VM gebraucht werden.

Diese Schritte kann man via GUI oder Shell durchführen. Hier wird einem gezeigt welche Hosts und VMs in welchem Zustand sind inkl. wie der Status des Quorum ist.

GUI: Klick auf “Datacenter” –> “HA”

Shell:

ha-manager status

Diese Schritte kann man via GUI oder Shell durchführen. In einer Gruppe wird definiert welche Hosts zu einer HA Gruppe gehören. Weiters auch wie sich die Gruppe verhalten soll falls ein Host ausfällt.

GUI: Klick auf “Datacenter” –> “HA” –> “Groups”

Shell: Syntax:

ha-manager groupadd <ha_group_name> -nodes '<node1>:<prio>,<node2>:<prio>,<node3>:<prio>…

In diesem Beispiel legen wir eine HA-Gruppe mit dem Namen “production” an. In dieser Gruppe gibt es zwei stärkere Hosts mit dem Namen big-1/2 und zwei schwächere Hosts lights-1/2/3.

ha-manager groupadd production -nodes 'big-1:2,big-2:2,light-1:1,light-2:1,light-3:1'

Dies würde bedeuten das die VMs wenn möglich auf den big Hosts gestartet bzw. laufen sollen. Wenn dies nicht möglich ist werden die VMs auf den light Hosts gestartet bzw. verschoben.

Diese Schritte kann man via GUI oder Shell durchführen. Hier kann man einzelne VMs zu einer HA Gruppe hinzufügen. Damit versetzt man eine VM in die HA Funktion.

GUI: Klick auf “Datacenter” –> “HA” –> “Resources”

Shell:

ha-manager add vm:100 -group test -state enabled

Es gibt den Fall das VMs nicht via HA gestützt sind im Cluster und eine Node ausfällt. Befinden sich auf dieser Node VMs die nicht via HA geschützt sind bleiben diese VMs auf dem Host “liegen”. Diese kann man auch über das GUI nicht mehr starten bis der Host wieder zur Verfügung steht. In dem Verzeichnis /etc/pve/nodes/<HOSTNAME>/qemu-server liegen die Configfiles einzelner VMs. Möchte man jetzt eine VM von einem verstorbenen Host auf einen verfügbaren Host migrieren damit man diese via dem GUI starten kann so muss man das File einfach auf einen anderen Host moven.

Syntax:
mv /etc/pve/nodes/<hostname>/qemu-server/<vm_id.conf> /etc/pve/nodes/<new-hostname>/qemu-server/

Beispiel:
mv /etc/pve/nodes/pvehost01/qemu-server/9000.conf /etc/pve/nodes/pvehost04/qemu-server/

Migrieren von allen VMs
mv /etc/pve/nodes/pvehost01/qemu-server/*.conf /etc/pve/nodes/pvehost04/qemu-server/

Proxmox bietet um kleines Geld einen Zugriff auf ihre Updates Repos an. Hier starten die Pakete bei ca. 5-6 Euro pro Monat pro CPU. Mehr Infos gibt es auf der Webseite vom Hersteller.

Wenn man ein Update durchführen möchte und keine Updates vom Repo beziehen darf kann man auf die non Sub Repos gehen. Diese sind jedoch nicht für Prod Systeme gedacht.

Ein Upgrade sollte immer

apt-get dist-upgrade

durchgeführt werden.

Hat man mehrere Systeme im Cluster und möchte man diese an verschiedenen Tagen Patchen jedoch überall die gleichen Versionen der Pakete installiert haben kann man wie folgt vorgehen. (ACHTUNG! Hat man den Backup Patch eingespielt muss dieser vor jedem Patchen eines PVE Systems entfernt werden!)

node1: apt-get update
node1: apt-get dist-upgrade
node1: reboot
node1: echo "apt-get update ; apt-get install" > /tmp/up.txt ; dpkg -l | tail -n +6 | awk '{print $2"="$3}' >> /tmp/up.txt ; cat /tmp/up.txt | tr '\n' ' ' > /root/pve_upgrade_`date +%Y-%m-%d`.sh ; rm -f /tmp/up.txt ; chmod +x /root/pve_upgrade_`date +%Y-%m-%d`.sh
node1: scp <filename> root@node2:/root/
node2-n: chmod u+x <filename
node2-n: ./filename
node2-n: reboot 

Live Migration ist so wie man es auch unter VMware vSphere gewohnt ist online wie auch offline möglich. Die CPU's der Hosts müssen natürlich auf einer ähnlichen Ebene sein. Wenn sie dies nicht sind kann man dies in der CPU Optionen unter “Hardware” bei einer VM einstellen. Stichwort EVC Mode unter VMware. Wie bei jeder Live Migration verändert sich die Zeit auf dem Gast. Meine Tests haben ergeben das dies jedoch nur ein sehr kleiner Sprung ist (50-100MS).

Live Storage Migration ist so wie man es unter VMware vSphere gewöhnt ist online sowie auch offline möglich. Nötig ist dafür jedoch das Diskformat raw bzw. qcow2. Eine VMDK VM kann nicht online migriert werden.

Proxmox stellt drei verschiede Formate zur Verfügung. Diese haben natürlich verschiedene Vor- und Nachteile.

In unserem Fall ist qcow2 die beste Variante in Verbindung mit einer NFS Storage. Raw wird gerne verwendet wenn maximale Performance benötigt wird, jedoch sind keine Snapshots möglich. Wenn die Storage darunter Snapshots unterstützt kann auch mit raw diese Funktioniert abgedrekt werden. Die Verwendung von vmdk kommt nicht zum Einsatz aufgrund der schlechten Performance.

Die Formate können untereinander konvertiert werden. Proxmox kann dies im GUI mittels der Funktion Clonen. Dies funktioniert jedoch natürlich auch in der Shell. Das Flag -f ist optional. Normal wird das Source-Format erkannt.

raw zu qcow2

qemu-img convert -f raw -O qcow2 image.img image.qcow2

qcow2 tu raw

qemu-img convert -f qcow2 -O raw image.qcow2 image.img

vmdk zu raw

qemu-img convert -f vmdk -O raw image.vmdk image.img

vmdk zu qcow2

qemu-img convert -f vmdk -O qcow2 image.vmdk image.qcow2

Ein Konvertiert funktioniert natürlich nur offline.

Numa hat Intel mit der Nehalem Serie eingeführt. Wenn Numa aktiviert ist versucht der Hyperviser die CPU Anfragen einer VM immer auf die gleiche physikalische CPU des Hosts zu schicken da jede CPU ihren lokalen Speicher hat und auf diesen schneller zugreifen kann als auf den Speicher der CPUs in den anderen Sockets. Dies ist daher eine Performance Option für CPU und Speicherintensive Applikationen.

Das Windows Setup wird keine Festplatte bei der Installation finden. Hier muss man erst den VirtIO Treiber installieren. Dieser wird bei Windows leider nicht default mitgeliefert.
Um dies Treiber zu bekommen laden wir uns ein ISO runter und legen dies am besten am PVE bei den OS ISOs ab. Windows VirtIO Treiber
Wenn dieses ISO auf einem Storagebereich vom PVE abgelegt ist muss man der VM ein zweites CD-Laufwerk hinzufügen und dieses ISO einlegen.
Man sollte im ersten CD-Laufwerk die ISO für die Installation und um zweiten die ISO für die VirtIO treiber haben. Wenn dem so ist dann kann die VM eingeschalten werden.

Dann klickt an sich im Installer so lange durch bis der Punkt kommt “Which type of installation do you want? und geht auf Custom.
Dort sieht man keine Disk für die Installation. Hier müss erst der VirtIO Treiber geladen werden.

1. Load driver
2. Browser
3. virtio-win-x.x.x
4. vioscsi
5. OS aussuchen (in meinem Fall “w10”)
6. Arch aussuchen (in meinem Fall “amd64”)
7. Ok → Next

Danach sollte die Platte zu sehen sein und man kann die Installation komplett durchführen. Hier noch eine Doku zu VirtIO unter Windows

Jetzt müssen noch diese Punkte erledigt werden

• Netzwerk Treiber
• Balloon Treiber
• Serial Treiber
• Qemu Agent
• Balloon Service

Öffnen vom Computer Management und danach muss der Device Manager gestartet werden.
Other Devices → Ethernet Controller –> Update Driver –> Browser my computer –> CD virtio-win.x.x.x –> Ok

Öffnen vom Computer Management und danach muss der Device Manager gestartet werden.
Other Devices → Ethernet Controller –> Update Driver –> Browser my computer –> CD virtio-win.x.x.x –> Ok

Öffnen vom Computer Management und danach muss der Device Manager gestartet werden.
Other Devices → Ethernet Controller –> Update Driver –> Browser my computer –> CD virtio-win.x.x.x –> Ok

Öffnen vom Explorer und auf die virtio-win.x.x.x CD gehen.
Dort den Folder “guest-agent” öffnen und den Agent installieren.
Ist der Agent sauber installiert und gestartet sieht man im PVE GUI das dieser läuft

Öffnen vom Explorer und auf die virtio-win.x.x.x CD gehen.
Dort unter “Balloon –> win10 –> amd64” gehen. (In meinem Fall w10).
Das Verzeichnis “amd64” unter “C:\Program Files” kopieren und in Balloon umbenennen.
Starten eines Admin CMD Fensters.
Mit diesen Befehlen das Service installieren

cd "C:\Program Files\Balloon"
blnsvr.exe -i

Ist das Service richtig installiert muss man im PVE GUI die gleichen Ram verbrauch wie in der VM sehen. Läuft das Service nicht sieht man fast immer einen höheren RAM Verbrauch. Siehe auch den Screenshot unter dem Qemu Agent. Dort war das Balloon Service noch nicht installiert.

Um Trim Befehle in den VMs abzusetzten und zu kontrollieren gibt es ein paar Möglichkeiten. Voraussetzung dazu ist die Discard Funktion in PVE
Damit dies funktioniert müssen ein paar Voraussetzung gegeben sein:

• SCSI Controller: VirtIO SCSI
• Hard Disk: SCSI (empfohlen) / SATA (möglich)
• Hard Disk: QCOW2
• Hard Disk: Discard → Yes
• Storage: PVE muss dies als Block Device sehen. NFS ist nicht möglich
• Gast OS: Muss Trim Commands unterstützen

Um auch zu kontrollieren ob ein Trim funktioniert geht man am bessten in die Shell von einem PVE Server.
Thick: Anzeigen der Disk Files und dessen Größe (VM mit 32G qcow2 File)

[root@pve 666]$ ls -lah
total 15G
drwxr-----  2 root root 4.0K Feb 27 09:50 .
drwxr-xr-x 16 root root 4.0K Feb 27 09:50 ..
-rw-r-----  1 root root  33G Feb 27 13:32 vm-666-disk-0.qcow

Thin: Anzeigen des gleichen Disk Files und dessen echte gebrauchte Größe.

[root@pve 666]$ du -shxc *
15G	vm-666-disk-0.qcow2
15G	total

Ab Ubuntu 18.04 wird von Systemd jeden Montag ein automatischer Trim Befehl gesendet.
Überprüfen ob Systemd dazu konfiguriert ist:

systemctl list-timers
systemctl list-timers | grep trim

Es kann auch jetzt sofort manuell ein Trim abgesetzt werden.

fstrim -av

Ab Windows 10 und Server 2016 sollte Trim automatisch aktiv sein. Dies kann man mit einer Admin CMD Shell überprüfen

fsutil behavior query DisableDeleteNotify

Achtung! Windows geht hier einen sehr logischen Weg.
0 = Trim ist aktiviert
1 = Trim ist deaktiviert

Es kann auch jetzt sofort manuell ein Trim abgesetzt werden.
Dazu wird eine Admin PowerShell benötigt.

Optimize-Volume -DriveLetter <LAUFWERK> -ReTrim -Verbose

Beispiel:
Optimize-Volume -DriveLetter C -ReTrim -Verbose

Proxmox bietet eine Backup Funktion der VMs an. Die Backups können mit Linux mitteln gezippt werden. Zum Beispiel Gzip. Auch hier kann man auswählen auf welchen Storage Bereich die Backups geschrieben werden sollen.

Möchte man hier einen Automatismus verwenden kann dies via GUI oder auch in der Shell via Cronjob durchgeführt werden. In der GUI geht dies ganz einfach über das “Datacenter” –> “Backup” Hier kann man sich einen Job zusammen bauen.

Will man über die Shell arbeiten funktioniert dies so: Hier die Syntax dazu:

vzdump <vmid> -compress <compress_mode> -storage <storage_name> -mode <backup_mode>

Alle Parameter kann man sich so ansehen:

vzdump help

Beispiel einer VM auf den Storage-Bereich “prox_02” im Snapshot-Mode (online) und Gzip komprimiert:

vzdump 100 -compress 0 -storage prox_02 -mode snapshot

Die Backups sind immer Full-Backups. Es gibt jedoch einen Patch der Community durch den inkrementelle Backups möglich werden. Diese habe ich bis jetzt nicht getestet.

Bei den IO Benchmarks wurde mit iozone3 gearbeitet. Geschrieben wurde auf eine Shared-Storage (FreeNAS) die mit einem Gbit angebunden war.

Es gibt diese drei HDD Formate:

• Raw Disk Image (raw)
• QEMU Image Format (qcow2)
• VMware Image Format (vmdk)

Die Benchmarks haben ergeben das raw und qcow2 gleich schnell beim Lesen und Schreiben sind. Das VMware Format vmdk ist beim Lesen zwar gleich schnell jedoch beim Schreiben um ca. 80% langsamer.

Um Hotplug verwenden zu können muss Numa aktiviert sein und unter den VM-Optionen die Ressourcen die man Hotplugen möchten auswählen.

Möchte man Hotplug verwenden muss man in den Gäste-VMs diese Module geladen haben:

modprobe acpiphp
modprobe pci_hotplug

Weiters startet eine VM wenn Numa und Hotplug aktiv ist nur mit einem Gb Ram. Der restliche Ram ist deaktiviert. Um den restlichen Ram gleich beim Start zu aktivieren gibt es zwei Möglichkeiten.

Möglichkeit 1: Bei Kernels unter 4.7 liegt man einfach eine udev Regel an.

vim /lib/udev/rules.d/80-hotplug-cpu-mem.rules
SUBSYSTEM=="cpu", ACTION=="add", TEST=="online", ATTR{online}=="0", ATTR{online}="1"
SUBSYSTEM=="memory", ACTION=="add", TEST=="state", ATTR{state}=="offline", ATTR{state}="online"

Möglichkeit 2: Für Systeme mit einem Kernel höher als 4.7 muss dies als Boot-Parameter hinzugefügt werden.

memhp_default_state=online

Swap ist oft stören bei PVE da dieser sehr schnell zu swappen beginnt mit den default Einstellungen. Daher sollte man diese Einstellung anpassen.
Wir stellen das System so ein das es erst zum swappen beginnt wenn es keinen freien Ram mehr gibt. Dies ist auch sehr wichtig zu beachten wenn man SD Karten oder SSDs für das OS einsetzt.

free -m
cat /proc/sys/vm/swappiness
sysctl vm.swappiness=0
swapoff -a
swapon -a
cat /proc/sys/vm/swappiness

Update der internen / local Zertifikate

pvecm updatecerts -f

Einfache Commands bzw. Scripts die helfen bei der Administration.

Anzeigen ob eine VM einen Snapshot hat (alle VMs auf einem Host werden angezeigt).

for i in `qm list | awk {' print $1 '} | grep -v 'VMID'` ; do echo "VM ID: $i" ; qm listsnapshot $i ; echo "" ; done

Backup Script für die wichtigen PVE Configs

#!/bin/bash

#############################
#PVE DATA BACKUP SCRIPT
#############################

backupdir="/mnt/pve/pve_backup"
localbackupdir="/root/pve_backup"
retention="+40"

#############################
#Create Backup and TAR
#############################

mkdir -p $localbackupdir/`date '+%Y%m%d'`
cd /var/lib/pve-cluster/
tar -czf $localbackupdir/`date '+%Y%m%d'`/pve-cluster-backup.tar.gz /var/lib/pve-cluster
cd /root/.ssh/
tar -czf $localbackupdir/`date '+%Y%m%d'`/ssh-backup.tar.gz /root/.ssh
cd /etc/corosync/
tar -czf $localbackupdir/`date '+%Y%m%d'`/corosync-backup.tar.gz /etc/corosync
cp /etc/hosts $localbackupdir/`date '+%Y%m%d'`/
cp /etc/network/interfaces $localbackupdir/`date '+%Y%m%d'`/
cd $localbackupdir
tar -czf "${HOSTNAME}_`date '+%Y%m%d'`.tar.gz" $localbackupdir/`date '+%Y%m%d'`

#############################
#Clean old Backups
#############################

find $localbackupdir -ctime $retention -delete

############################
#Check BKP Mount and RSYNC
############################
if [[ $(findmnt $backupdir) ]]; then
                mkdir -p $backupdir/PVE_Backups/$HOSTNAME
                rsync -a --delete $localbackupdir/ $backupdir/PVE_Backups/$HOSTNAME
        else
                echo "Backupshare on $HOSTNAME not mounted"
fi

Qemue Befehle können ohne Problem in der Shell am PVE Server ausgeführt werden.

Einfacher Check vom qcow2 File

qemu-img check <diskfile>

Beispiel:
root@pvehost02:~# qemu-img check /mnt/pve/onstore03n2_ont_pve_sas_01/images/1460/vm-1460-disk-0.qcow2 
No errors were found on the image.
327680/327680 = 100.00% allocated, 5.43% fragmented, 0.00% compressed clusters
Image end offset: 27737522176

Check und reparieren wenn es Fehler gibt Wenn es Fehler auf einem File geben sollte kann dieser Befehl aus 2-3x ausgeführt werden. So lange bis es keine Fehler mehr gibt

qemu-img check -r all <diskfile>

Beispiel:
root@pvehost02:~# qemu-img check -r all /mnt/pve/onstore03n2_ont_pve_sas_01/images/1460/vm-1460-disk-0.qcow2 
No errors were found on the image.
327680/327680 = 100.00% allocated, 5.43% fragmented, 0.00% compressed clusters
Image end offset: 27737522176

Wenn PVE einmal ein Problem hat einen Snapshot zu löschen kann man so kontrolleren ob es noch einen Snapshot auf der VM gibt bzw diesen auch löschen.

Snapshot ansehen
In diesem Beispiel hat die betroffene VM zwei Disk Files. Es sollte zur Sicherheit jedes Diskfile kontrolliert werden.

qemu-img snapshot -l <diskfile>

Beispiel:
root@pvehost02:~# qemu-img snapshot -l /mnt/pve/ont_pve_sata_01/images/9651/vm-9651-disk-0.qcow2 
Snapshot list:
ID        TAG                     VM SIZE                DATE       VM CLOCK
1         test                        0 B 2020-07-30 10:37:23 9089:05:26.964
root@pvehost02:~# 
root@pvehost02:~# qemu-img snapshot -l /mnt/pve/ont_pve_sata_01/images/9651/vm-9651-disk-1.qcow2 
Snapshot list:
ID        TAG                     VM SIZE                DATE       VM CLOCK
1         test                        0 B 2020-07-30 10:37:24 9089:05:26.964

Löschen vom Snapshot
Das löschen eines Snapshots muss immer auf einem Diskfile gemacht werden. Hat eine VM mehrere Disk Files muss dieser auf allen Files gelöscht werden.

qemu-img snapshot -d <snap id> <diskfile>

Beispiel:
root@pvehost02:~# qemu-img snapshot -d test /mnt/pve/ont_pve_sata_01/images/9651/vm-9651-disk-0.qcow2
root@pvehost02:~# qemu-img snapshot -d test /mnt/pve/ont_pve_sata_01/images/9651/vm-9651-disk-1.qcow2

Wurde der Snapshot via CLI erfolgreich entfernt wird dieser im PVE GUI jedoch noch angezeigt. Dies liegt daran das im VM Config File dieser noch drin steht. Hier kann einfach Inbetrieb das Config geöffnet und verändert werden.
Für einen Snapshot wird ein Configblock im File mit dem Namen des Snapshots angelegt. Der komplette Block kann einfach gelöscht werden.

root@pvehost02:~# vim /etc/pve/nodes/pvehost06/qemu-server/9651.conf

Danach ist der Snapshot auch in der GUI nicht mehr zu sehen.

Wozu kann ich das brauchen?

• Single File Restore
• Schnell etwas nachsehen
• Disaster fällen

So spielt man einen komletten mount durch.

modprobe nbd max_part=8

qemu-nbd --connect=/dev/nbd0 /mnt/pve/ont_pve_sata_01/images/1111/vm-1111-disk-0.qcow2

root@pvehost06:~# fdisk /dev/nbd0 -l
Disk /dev/nbd0: 27 GiB, 28991029248 bytes, 56623104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa53b1ed4

Device      Boot Start      End  Sectors Size Id Type
/dev/nbd0p1       2048 56623103 56621056  27G 83 Linux

mount /dev/nbd0p1 /mnt/x/

root@pvehost06:~# cat /mnt/x/etc/hostname 
mattermost

umount /mnt/x
qemu-nbd --disconnect /dev/nbd0
rmmod nbd

Disk Identifzieren zwischen PVE Hardware und Gast OS

lsblk -o +SERIAL

Host und VM Auslastung

pvesh get /cluster/resources