[Sammelthread] Proxmox Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
weil ich dann wohl etwas falsch mache
1. Du clonst das hier verlinkte Repo mit git clone: https://github.com/fenrus75/powertop
2. Du installierst wie in der README.md beschrieben die build dependencies
3. Du baust dir die aktuelle powertop Version
4. Fertig

Wenn dir das zu komplex ist kannst du sonst auch einfach auf Proxmox VE 8.0 warten, da wird dann auch ne aktuellere Version mitgeliefert.
 
Schritte 1-3 habe ich soweit ausgeführt.
Beim 'make' gab es aber noch einen Fehler, den ich jetzt nicht als fehlende Dependency eingeordnet hatte.
Habe gestern Abend wieder "zurückgerollt", so dass ich den jetzt nicht auf die schnelle reproduzieren kann.

Heute Abend kann ich evtl etwas mehr Licht ins Dunkel bringen bzw. Details liefern.
 
Der Output von 'make' sieht folgendermaßen aus:
1679515441533.png


Mittlerweile habe ich aber auch ein "fertig gebautes" powertop 2.14 im Unraid-Forum gefunden und "installiert".
Mit der Version wird nun auch die CPU etc. richtig erkannt.
 
 
ch glaube ich habe die Lösung für mein Problem. Sie heißt Clonezilla. Damit soll man ganze Harddisks Clonen können.
Hat bei mir nicht funktioniert, wollte auch auf ne größere SSD wechseln. Clonezilla kann aber mit den LVMs nix anfangen und hängt dann in einem Loop beim klonen.
 
Hat bei mir nicht funktioniert, wollte auch auf ne größere SSD wechseln. Clonezilla kann aber mit den LVMs nix anfangen und hängt dann in einem Loop beim klonen.
Hast du disk to disk oder part to part gemacht?

Disk-Clone sollte auch mit LVM funktionieren, muss die neue Disk nur größer als die alte sein.

Bin mir sicher, das vor paar Jahren mal bei meiner alten Ubuntu Disk gemacht zu haben, da hab ich mein verschlüsseltes LUKS-LVM Konstrukt von einer 1 TB auf ne 2 TB NVMe geclont.
 
Ich war jetzt eigentlich der Meinung Disk to Disk, hab das aber mal aufgenommen um die Meldung lesen zu können und da stand jetzt Partclone 🤔 war von einer 240GB auf ne 512GB. Nach „Informing OS of partition table changes“ ging das ganze dann wieder von vorne los. War im Endeffekt kein wirkliches Problem weil die Ziel-SSD ne SATA war und der Port aber nur NVME kann, aber ja. Zukünftig wird das schon wieder n Thema.
 
Moin, ich würde gern für mehr VM-Storage für meinen Proxmox-Server sorgen. Bisher boote ich von einer Intel D3-S4610 240GB und habe meine VMs auf ihrem großen Bruder, einer D3-S4610 480GB. Beide haben (E)PLP. Außerdem habe ich noch eine Samsung 980 pro für 2 VMs die schnell ausliefern müssen (lokaler Archmirror und jellyfin). Die 240er Intelplatte hat einen "defekten" Sataport - das Plastik ist abgebrochen und steck im Kabel. Ich habe keine Sataplätze mehr frei, aber noch 3 m.2 slots und Notfalls einen PCIe x16 Slot.
Jetzt geht mir der VM-Storage-Platz aus und ich überlege die "defekte" gegen die nicht defekte Intel auszutauschen, eine weitere Intel dazu zu nehmen und einen Mirror zu haben und meine VMs komplett auf einen weiteren Mirror mit "billigen" 2TB PCIEx3 m.s SSDs (970+?) auszulagern - ich glaube nicht das ich bei denen ELP brauche, ist nichts Missionskritisches und hat regelmässige Backups aufs NAS. Was meint ihr?
 
Zuletzt bearbeitet:
Ich kann mir vorstellen, dass es nach einem Stromausfall schwierig ist festzustellen, ob etwas kaputt ist und somit das Backup aktiviert werden muss. Wenn man hier Probleme übersieht, die erst später offensichtlich werden, wird es unangenehm.
 
Moin,
ich bin beim Thema Proxmox noch ganz frisch und wollte (ohne mich jetzt Stundenlang in das Thema eingelesen zu haben) Informieren, um wenigstens zu wissen ob ich nicht ganz auf dem Holzweg bin.
Ich habe vor einen (sehr kleinen) Server zum testen aufsetzen. Darauf sollten VMs mit PiHole, Printserver etc. laufen.
Nun habe ich eine NUC ähnliche Kiste mit Pentium N5030, 8GB RAM und 64GB eMMC. Ich habe mir überlegt Proxmox auf die eMMC zu installieren. Das dürfte eigentlich keine Nachteile haben, außer dass die eMMC irgendwann Mal tot geschrieben sein wird?
Die wichtigste Fragen für mich ist aber die Storage. Sollte man hier zu SSD greifen, oder reicht eine 2.5" HDD aus? Die VMs die darauf laufen sollen, werden alle Linux/BSD basiert sei (Ohne X/Wayland).
Was meint ihr, würde eine HDD noch Sinn machen oder sollte man direkt zu einer SSD greifen?
 
Für VMs würde ich zu SSDs greifen. Gebrauchte Enterprise SSDs mit 1.92tb gibt's mittlerweile für ca 100€.
 
Billige SSD für VMs _kann_ nach hinten losgehen.
Auch teure SSDs für VM können nach hinten losgehen. So what?
Ich kann mir vorstellen, dass es nach einem Stromausfall schwierig ist festzustellen, ob etwas kaputt ist und somit das Backup aktiviert werden muss. Wenn man hier Probleme übersieht, die erst später offensichtlich werden, wird es unangenehm.
Also meine Reaktion auf einen Stromausfall ist die folgende:
Alles hochfahren. Proxmox testen. Läuft alles: TrueNAS VM (diese startet von der SSD mit PLP und wird dies auch immer tun) starten, läuft nicht alles: letztes Proxmox Backup von externe Platte holen und damit booten. Sobald TrueNAS oben ist wir der Snapshot von der letzten Nacht eingespielt, entweder vom BackupNAS oder von der externen Platte. Auf dem NAS liegen alle Snapshots und Backups der VMs, und davon wird dann wieder hergestellt - hier halte ich mich nicht lange mit Prüfungen auf.
Mit diesem DEsaster REcovery Plan fühle ich mich eigentlich ganz sicher - habe jetzt bei den Frühlingsangeboten von Amazon bei einer 970 Evo Plus zugegriffen, die kriegt als Bald eine SChwester und dann hab ich einen 2TB Mirror - sollte erst einmal reichen.
Ich suche immer noch nach einer guten bezahlbaren USV die mich das alles loswerden lässt, aber das nur am Rande.
 
wie gehe ich denn am schlausten vor in folgender situation:

Umfeld: 2 node cluster (mit q-device, aber ohne HA, also nur ein mgmt-cluster), wichtige VM 100 läuft auf node1, alle disks werden repliziert auf node2.
Situation: node1 fällt unerwartet aus. Disks sind repliziert, aber die vm befindet sich laut clusterconfig noch auf node1.

wie bekomme ich die VM jetzt auf node2 am einfachsten zum laufen mit den dort vorhandenen disk images? einfach die vm config von /etc/pve/nodes/node1/qemu-server/100.conf nach /etc/pve/nodes/node2/qemu-server/100.conf verschieben?
 
Auf mein Szenario geht der Plan gar nicht ein. Ist natürlich ganz klar deine Abwägung.
Doch natürlich. Ich minimiere das Risiko eines korrputen Dateisystems indem ich ZFS und die inhärenten Selbstheilungskräfte des selbigen nutze - ich spiele grundsätzlich Backups in Form von Snapshots ein. Hast du das irgendwie überlesen?
 
Hallo zusammen,

ich versuche mich gerade am IOMMU Passthrough von Devices mit einem J3455. Habe IOMMU jetzt aktiviert, bin mir aber unsicher ob ich nur ein Geärt aus einer IOMMU Gruppe (hier 5) weiter reichen kann oder nicht.
Ich will den SATA Controller an eine VM (TureNas Scale) weitergeben, die beiden NICs sollen beim Proxmox bleiben.

1680184925431.png


Besten Dank
 
Doch natürlich. Ich minimiere das Risiko eines korrputen Dateisystems indem ich ZFS und die inhärenten Selbstheilungskräfte des selbigen nutze - ich spiele grundsätzlich Backups in Form von Snapshots ein. Hast du das irgendwie überlesen?
Nein nicht überlesen. Das Problem ist, dass alles was das Dateisystem nutzt (Programme, OS-Komponenten) in einem ungünstigen Zustand von dem Stromausfall erwischt werden könnten und mit den (korrekt vom ZFS gespeicherten) Daten nicht mehr korrekt funktionieren, weil jemand beim Programmieren nicht daran gedacht hat, dass genau an der Stelle ein Stromausfall passieren könnte und das ungünstige Folgen hat. Dein Problem wird das dann, wenn du diesen Zustand nicht erkennst, weil scheinbar alles läuft. Arbeitest du so weiter und bemerkst das Problem, mal relativ ungünstig gedacht, beim nächsten OS-Upgrade 1,5 Jahre später, hast du die Qual der Wahl zwischen einem uralten Backup und einem kaputten System. Ich will nicht sagen, dass dieses Szenario extrem wahrscheinlich ist und dass es für dich die bessere Wahl ist auf PLP zu setzen. Ich möchte nur sagen, dass die Sache komplizierter ist, alles seinen Sinn und Zweck hat und man nicht davon ausgehen sollte, dass einem nix passieren kann.
 
Erm. Einen Stromausfall meines Virtualisieres soll ich nicht merken? In welchem realistischen Szenario soll das passieren? Mir ist es völlig egal welchen Status die Geschichte dann hat, ich spiele dann grundsätzlich ein Backup ein - diesen Fakt überliest du tapfer oder es mangelt dir an Textverständnis. Ich gehe das Risiko eines korrupten Dateisystems gar nicht erst ein, ich spiele das letzte bekannte nicht korrupte ein, von jeder VM. Den von mir beschriebene Desaster-Recovery Ansatz habe ich genau so wie beschrieben hart getestet. Mit Hilfe des Steckers. Und ich hab mir aufgeschrieben (von Hand, in ein Buch, da stehen auch meine Ports und Kabel und so drin) was ich in welcher Reihenfolge wie machen muss. Das von dir beschriebene Szenario kann nicht eintreten. Mit deinen sonstigen Anmerkungen hast du zwar durchaus prinzipiell und im allgemeinen Recht, aber in diesem Fall ist es schlichtweg nicht relevant...
 
Keiner einen Hinweis für mich zu den IOMMU-Gruppen und dem durchreichen einzelnes Gerätes in einer Gruppe mit mehreren?
 
TL;DR: Ja das geht ;)

Versuch es mal mit der CLI statt der WebGUI. Ich habe meinen HBA und zwei NICs zum FreeNAS durchgereicht. Beide sind via PCI-E angeschlossen:

Die NICs:
Code:
#$ lspci
...
05:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
05:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
05:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
05:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
...

Der HBA:
Code:
#$ lspci
...
01:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
...

Die config in der VM.cfg im Ordner /etc/pve/qemu-server/ sieht dann so aus:
Code:
...
hostpci0: 05:00.2,pcie=1
hostpci1: 05:00.3,pcie=1
hostpci2: 01:00,pcie=1
...
Das findet man dann auch in der WebGUI unter Hardware wieder.

Zum Nachlesen:
 
Uhm, hab gerade eine VM verschoben auf einen anderen Storage, danach startet sie nicht mehr mit folgender Fehlermeldung:
Code:
TASK ERROR: start failed: command '/usr/bin/kvm -id 100 -name 'TrueNAS,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/100.qmp,server=on,wait=off' -mon 'chardev=qmp,mode=control' -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' -mon 'chardev=qmp-event,mode=control' -pidfile /var/run/qemu-server/100.pid -daemonize -smbios 'type=1,uuid=cef71529-2920-47e9-a3ef-443519ac7968' -global 'ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off' -smp '8,sockets=1,cores=8,maxcpus=8' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/100.vnc,password=on' -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep -m 65536 -readconfig /usr/share/qemu-server/pve-q35-4.0.cfg -device 'vmgenid,guid=e080d9e2-9602-4f40-b547-70a9368f55ac' -device 'usb-tablet,id=tablet,bus=ehci.0,port=1' -device 'vfio-pci,host=0000:61:00.1,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0' -device 'vfio-pci,host=0000:63:00.2,id=hostpci1,bus=ich9-pcie-port-2,addr=0x0' -device 'vfio-pci,host=0000:22:00.0,id=hostpci2,bus=ich9-pcie-port-3,addr=0x0' -device 'VGA,id=vga,bus=pcie.0,addr=0x1' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:665c8218f8' -drive 'if=none,id=drive-ide2,media=cdrom,aio=io_uring' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=101' -device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' -drive 'file=/dev/zvol/VM_Storage/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -machine 'type=q35+pve0'' failed: got timeout
Ich könnt jetzt natürlich einfach ein Backup einspielen, aber bevor ich hier weiter rumexperimentiere erstmal hier gefragt: Wie ist das weitere Vorgehen zur Analyse, was läuft hier falsch?

Sodele, mal auf die Konsole gegangen und da gestartet, mehr Infos:
qm start 100
kvm: vfio: Cannot reset device 0000:63:00.2, depends on group 86 which is not owned.
kvm: vfio: Cannot reset device 0000:63:00.2, depends on group 86 which is not owned.

63 ist ein Kanal des onboard Sata Controllers, von diesem Controller ist eben nur ein Kanal an die VM durchgereicht, und bisher gab es damit nie Probleme - warum auf einmal jetzt? Wie so oft LAyer8 aka meine eigene Dummheit oder was?
 
Zuletzt bearbeitet:
Hat hier jemand eine GPU an eine Windows VM durchgeschoben?
Ist das grob aufwändig?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh