Alle machen Proxmox, ich habe mich bisher etwas dagegen gesträubt. Bisher habe ich mich mit der Basis von Proxmox (KVM/QEMU) beschäftigt. Aber diese Verwaltungsoberfläche sieht natürlich gut aus und macht alles sicher einfacher. Also einen neuen passenden Mini-PC NAD9 geholt (später könnte man Clustern) und Proxmox vom ISO Image direkt installiert. Für schnelle und unkomplizierte Beispiele ist diese Seite mit zahlreichen Scripts hervorragend: https://tteck.github.io/Proxmox/
Wenn man damit etwas spielt fällt auf - man arbeitet mit Proxmox "unkompliziert". Manche Dinge gehen in Proxmox viel leichter als zu kompliziert gedacht.
USB wird per "USB Passthrough" und das Netzwerk mit vmbr0 verbunden. Damit sind alle USB Schnittstellen verfügbar, jede Instanz bekommt eine eigene IP und somit sind auch alle Ports verfügbar. Die Umstände mit Profilen und Port Mappings fallen damit weg.
Für existierende VMs unter Libvirt gibt es keinen extra (einfachen) Migrationsweg, man muss es per Hand tun, siehe auch: Link1, Link2.
Vorbereitung
Das Festplatten Image vom alten auf den neuen Server zu kopieren war mir zu umständlich! Ich habe den Pfad auf dem alten Server einfach per NFS zur Verfügung gestellt und gemountet. Damit kann man die qcow2 Dateien ohne extra Kopie direkt importieren.
Inhalt der /etc/exports ergänzen (nur ein Host, uid auf root gemappt)
/mnt/vm-images 192.168.56.42(ro,no_subtree_check,anonuid=0)
/var/lib/libvirt/images 192.168.56.42(ro,no_subtree_check,anonuid=0)
und sudo exportfs -a ausführen.
In der Proxmox Console mounten (/mnt/nfs muss existieren)
mount virthost1:/var/lib/libvirt/images /mnt/nfs
Die VMs vor der Migration auf dem alten System richtig beenden. (Windows Systeme mit Shift + herunterfahren)
Pro VM wichtige Eigenschaften ermitteln und notieren:
- RAM, Anzahl CPU (virsh dominfo <name>)
- Netzwerkkarte, MAC Adresse, VLAN (virsh domiflist <name>)
- BIOS oder EFI (virsh dumpxml <name> |grep firmware)
- Maschinen Type (virsh dumpxml <name> |grep machine)
Ablauf der Migration
- VM in Proxmox analog der alten Umgebung definieren, entweder per Oberfläche oder Kommandozeile (Details in der Beschreibung Proxmox tool qm und API Shell)
- Festplattenimage importieren
- Einzelne Hardware Eigenschaften zuweisen.
Im folgenden ein paar Beispiele, alle mit dem Tool qm in der Konsole vom Host (Achtung: wenn man die Browser Shell arbeitet, wird diese beim Fensterwechsel unter Umständen verlassen und neu geöffnet! Dabei werden die Variablen gelöscht).
Hinweis: Es kann einfacher sein, eine Datensicherung in den Applikationen zu machen und die Container oder VMs mittels Scripts neu anzulegen, Backup einzuspielen und alles läuft wieder. Siehe unten Beispiel Raspberrymatic.
Beispiel VM mit BIOS
Entweder in der Proxmox Oberfläche die VM anlegen, dass Image in der Kommandozeile importieren (siehe unten) und danach
- edit unused Disk, sata auswählen und add.
- Options / Boot Order editieren damit nicht unnötig von anderen Medien gestartet wird.
- OS auf Windows 10 oder Linux setzen
- qemu agent aktivieren (muss im Gast installiert sein)
- Maschinentyp setzen (default oder q35)
Oder gleich alles per Kommandozeile (MAC muss man nicht übernehmen, dann wird per Zufall eine neue erzeugt):
VM_name=win10
VM_ID=$(pvesh get /cluster/nextid)
qm create $VM_ID --name "$VM_name" \
--memory 4096 --cores 2 \
--net0 virtio|e1000e<=aa:bb:cc:dd:ee:ff>,bridge=vmbr0,firewall=1,<tag=1090>
Image importieren in der Kommandozeile
qm importdisk $VM_ID /mnt/nfs/${VM_name}.qcow2 local-lvm
Hinweis: Die Box ist editierbar, man kann die Befehle editieren und dann per copy und paste direkt verwenden.
VM_HDD=sata|virtio
qm set $VM_ID --${VM_HDD}0 local-lvm:vm-${VM_ID}-disk-0
qm set $VM_ID --boot order=${VM_HDD}0
qm set $VM_ID --ostype win10|win11|l24|l26
qm set $VM_ID --agent enabled=1
qm set $VM_ID --machine pc|q35
Hat man sorgsam alles definiert wie im alten System, sollten sowohl Windows als auch Linux System starten.
Achtung: Netzwerkkonfiguration! Das Interface zieht per DCHP keine Adresse mehr? Der Befehl dhclient behebt das Problem?
In meinen Linux Gast Systemen wurde der Name der Netzwerkkarte von enp1s0 zu enp6s18 geändert. Das liegt offenbar an der Struktur der virtuellen Hardware. Über die Bildung der Netzkarten Namen habe ich hier ein Wiki gefunden. Bei einigen VMs ist ein altname in der Ausgabe von ip a aufgetaucht, dazu habe ich hier etwas gefunden.
Damit DHCP weiter automatisch funktioniert, muss man im Gast die entsprechende Datei /etc/network/interfaces (debian) bzw. /etc/netplan/00-installer-config.yaml (ubuntu, oder auch 50-cloud-init.yaml) anpassen und anschließend den service networking (je nach System auch networkd ...) neu starten oder einen reboot ausführen um den Erfolg zu testen.
Beispiel VM mit EFI und TPM
Dafür muss man die BIOS Version auf ovmf setzen, einen Speicher für EFI Informationen und einen TPM 2.0 Emulator erzeugen.
qm set $VM_ID --bios ovmf
qm set $VM_ID --efidisk0 local-lvm:1
qm set $VM_ID --tpmstate0 local-lvm:1,version=v2.0
Mir ist es nicht gelungen die TPM Informationen zu migrieren, d.h. man muss z.B. Windows Hello (PIN) neu setzen.
Beispiel Zigbee2mqtt
Ausgangspunkt: ein Docker Container in einem LXC Container!
Altes System Backup anfordern. lxc shell docker, cp data/* temp/ (error wegen log Pfad ignorieren). Das alte System herunterfahren und den coordinator Stick an die Proxmox Maschine stecken.
Im alten docker Container die Daten nach dem Proxmox Host kopieren (Pfad temp muss existieren)
scp data/* root@192.168.56.42:temp/
Zigbee2mqtt als LXC Container mit Script im Proxmox installieren (der Zigbee Stick sollte schon vorhanden sein um die Schnittstelle /serial/by-id auswählen zu können.)
In der Shell vom Container die gesicherten Daten nach /opt/zigbee2mqtt/data kopieren.
scp root@192.168.56.42:temp/* /opt/zigbee2mqtt/data/
Die serielle Schnittstelle in der configuration.yaml editieren. Den Container neu starten.
Beispiel Raspberrymatic
Ausgangspunkt: VM aus ova Datei per Hand in libvirt integriert.
Altes System Backup über Browser, VM herunterfahren, Stick an neue Maschine stecken.
Raspberrymatic mit Script von der RaspberryMatic Webseite als VM installieren (der Stick sollte schon vorhanden sein)
Im Browser Backup zurückspielen. CCU3 über Web Oberfläche neu starten.
VLAN Bridge
Ich hatte an meinem Virtualisierung Host die Netzwerkschnittstelle mit zwei VLANs verbunden. Proxmox benutzt aber klassisch /etc/network/interfaces . Im Proxmox Wiki findet man ein Konfigurationsbeispiel "Proxmox VE management IP with VLAN aware Linux bridge".
Nach ein paar Tests habe ich die aktive Datei interfaces gesichert und den Inhalt direkt geändert:
auto vmbr0
iface vmbr0 inet manual
bridge-ports enp2s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
auto vmbr0.1056
iface vmbr0.1056 inet static
address 192.168.56.42/24
gateway 192.168.56.1
Ein ifreload -a aktiviert die neue Konfiguration und man kann den Netzwerkanschluss mit dem Trunk Port am Switch verbinden.
Die Bridge wird "VLAN aware", deren IP Konfiguration wandert in ein neues "Linux VLAN". Man kann diese Änderung auch in der Web-Oberfläche tun.
Achtung! Bei einem Fehler verliert man die Netzwerkverbindung, es ist gut wenn man zur Sicherheit den Zugriff über die Konsole vor Ort (KVM Switch) hat.
Final muss man bei allen virtuellen Maschinen in der Netzwerkschnittstelle den VLAN Tag eintragen! Bei der Erzeugung der VM kann man die Option an den Netzadapter Abschnitt anfügen.
Das ganze hat noch einen Haken: Erzeugt man die Gastsysteme z.B. mit den Proxmox VE Helper-Scripts, kann man nicht mehr mit den default Einstellungen arbeiten, man muss die einzelnen Werte bestätigen und das VLAN eintragen. Andernfalls bekommen die Gäste keine IP Verbindung und das Setup-Script wird eventuell beendet.
Ein paar Links
https://github.com/fdcastel/Proxmox-Automation
ToDo?
Überlegen ob man die vmbr0 so definiert, dass sie als default Bridge in ein default VLAN funktioniert und man die "VLAN aware Bridge" anders benennt.
Code Block
ToDo Ende
Keine Kommentare:
Kommentar veröffentlichen