Search results

Komische Argumentation. Wenn ich ein storage mit 500TB habe, ist ein passender RAID-Controller natürlich genau die richtige Lösung um Hochverfügbarkeit zu gewährleisten. Wenn ich eine Einzelmaschine betrachte, sieht das anders aus. Richtig. Dabei liegt die Betonung auf gehabt. In...

Ach? du benutzt ZFS auf einer Einzelplatte? Oder sind zwei statt einer Platte nicht doch eine Verdoppelung? Das ist einfach dumm Tüch oder ein sehr sehr obskurer Controller.

Das waren dann wohl netzweit verfügbare Member?

Das ist doch Augenwischerei. Mit ZFS verdoppelst du mindestens die POFs. Zusätzlich erbst du Fehler, die im ZFS-Layer selbst stecken. Es soll sogar HW-Raid-Controller geben, die so ihre eigenen Macken haben. Wenn meine einzelne Platte ausfällt, merke ich das vor ZFS. Das betroffene System ist...

Im Fehlerfall schon mal einen ZFS-Member umgestöpselt, wenn es eben nicht mehr "einfach" seinen Dienst tut? Hau raus wie das geht!

Wenn es sofort auffällt machst du was? ZFS endlich als Lösung aller Probleme? Lösen sich Probleme plötzlich in Luft auf? P.S.: Schweine mit unterschiedlichen Namen werden schon sehr lange durchs Dorf getrieben!

In meinen Augen, ist das seit mindestens 4 Dekaden repetierte Redundanzgeplapper eigentlich eher kontraproduktiv. Selbst ein Raid ist eine Fehlerquelle, die selten nötig ist und eher zu Komplikationen führt. Wer hat denn übrigens noch einen ICP-Raid-controller zur Sicherheit im Regal liegen? Wer...

Nochmal nachgedengelt. Da ich mit dem Script auch meinen DNS/DHCP-Server (Pihole) redundant halte, kann man sich natürlich mächtig ins Knie schießen, falls der nicht aus dem Kreuz kommt. So habe ich nun einen Mischbetrieb zwischen Fester IP und DHCP-clients. Pihole und die PVE-Host haben sowieso...

Keine Hookscripts. Lediglich die vorhin geposteten Scripte mittels systemd. failover.sh läuft in einer Endlosschleife und refreshcoldstandby.sh zeitgesteuert um 15:30

Die Ausgabe der Tasks zeigen nur TASK OK Es gibt nur zwei Scripte, die allerdings auf diversen anderen Hosts laufen, auf den es nicht die seltsamen Taskausgaben gibt: root@pve:~# cat failover.sh #!/bin/bash # Failover für Proxmox-hosts. # Script am besten als systemd-Service auf allen hosts...

Kein Node startet beim Boot. journalctl zeigt keine Auffälligkeiten. root@pve:~# pveversion -v proxmox-ve: 9.0.0 (running kernel: 6.14.11-1-pve) pve-manager: 9.0.6 (running version: 9.0.6/49c767b70aeb6648) proxmox-kernel-helper: 9.0.4 proxmox-kernel-6.14.11-1-pve-signed: 6.14.11-1...

Ist ein Singlehost. root@pve:~# cat /etc/pve/qemu-server/1 103.conf 107.conf 108.conf 109.conf 111.conf 112.conf root@pve:~# cat /etc/pve/qemu-server/109.conf agent: 1 boot: order=virtio0 cores: 4 memory: 2048 meta: creation-qemu=7.0.0,ctime=1664274738 name: seafile net0...

taucht in meiner Taskliste unregelmäßig auf. Gerne 10 mal in 4h. Gestartet wird aber nichts. Wo kann die Meldung herkommen? Auf dem 9.0.6-Host sind zwar 8 VMs/Container installiert aber alle sind standardmäßig ausgeschaltet.

Verstehe ich auch überhaupt nicht, macht mir aber Angst.

Darum prüfe, bevor man sich ein Cluster ans Bein bindet! By design hat man einen ganzen Sack von fetten zusätzlichen Fehlerquellen an Bord.

Reicht verschieben und umbenennen nicht? Also rescan zwangsläufig notwendig?

Die vDisk lümmelt einfach auf einer ext4-Partition als .qcow2-File rum

Danke für deine Aufmerksamkeit. Mir würde aber eher einen Befehl: qm list disks und anschliessend qm move [disk] [toVM] vorschweben-

@UdoB: Nun weiß @Chr_Au wenigstens, dass er womöglich eine Formulierung gewählt hat, die dem Oberlehrer sauer aufstößt! Deine "generischen" Tipps liefert jede Dumm-KI. Oma trat auch immer gegen die Waschmaschine. Manchmal sollte man seine Finger besser einfach im Zaum halten.

Klar. Gewünschte VM/LXC markieren>Optionen>Beim booten starten deaktivieren.