Search results

ok, so the errors occur while you tried to update to the current PVE 7. That's fine, but then your topic is a little bit misleading. so far I can't see any no-subscription repo. To be sure, please also post the output of cat /etc/apt/sources.list. can you also post a screenshot of the webGUI...

Welcome to the Proxmox community! :) to be sure: You have an onboard NIC and added some PCI card with a further NIC? Can you login at the console? If yes, the output of ip addr would be interesting.

What exactly did you do that lead to this output? Did you follow these instructions? what PVE repo do you use? please post the output of ls -al /etc/apt/sources.list.d/ cat /etc/apt/sources.list.d/*

yes, there is dedicated BMC which I didn't mention.

yes, you can: https://pve.proxmox.com/wiki/Manual:_datacenter.cfg At the moment our live migrations use the switches and so the (cross-room) connections between the switches. These are 2x 10G and can easily be saturated by live migrations. That leads to higher latency between the switches, which...

I still didn't get the point. I try to clarify the network setup: these are connections to our switches: 1x 10G management (PVE WebGUI) 1x 10G Corosync 2x 25G VM network (bonded) and these are direct connections, no switches involved: 4x 25G for Ceph "bonded full mesh" 2x 25G VM Migration...

Yes, it is. What exactly do you mean by this?

Yes, we already took this into account. Networking is planned like this: available: 2x 10G onboard 10x 25G Broadcom cards usage: 1x 10G management (PVE WebGUI) 1x 10G Corosync 4x 25G for Ceph "bonded full mesh" 2x 25G VM network (bonded) 2x 25G VM Migration (full mesh) 1x 25G Backup

any other opinions? (first and last bump :D)

thanks for this - as far as I understand, you're right: When an OSD fails, the pool becomes degraded, which means: Pool is working, but no more redundancy left. But I think that's ok for us. Three times the usable storage must be enough. :D

Hi, after almost five years with our three node PVE/Ceph cluster now it's hardware renewal time! Core requirements are: - about 24 TB of usable storage (fast and scalable) - about 512 GB RAM per node (scalable) Unfortunately we can't go with AMD EPYC CPUs because of Oracle. Together with...

If I were in this situation I wouldn't waste time trying to upgrade such an outdated installation. I would try to backup the VMs, make a new installation of the whole environment and then restore the VMs.

Seit der defekte RAM-Riegel aus dem Spiel ist, kamen keine Fehler mehr. Das ist mir fast ein bisschen peinlich. :D Vielen Dank!

Das ist ein erster Test auf der Basis gewöhnlicher Desktop-Hardware zzgl. der finalen PCIe-Karte - also ohne ECC-geschützten RAM.

So, ich habe nochmal von vorne angefangen: Erster "full sync", sowie die anschließende Verifikation waren erfolgreich. Wir syncen und verifizieren täglich - sollte das nun die nächsten zwei Tage keine Fehler mehr werfen, würde ich sagen, dass das Problem gelöst ist. :)

wow, eines der RAM-Module ist defekt. :rolleyes: Dann bin ich nun gespannt, ob das tatsächlich die Lösung ist. Danke erstmal!

Danke für den Input - memtest läuft. Könnte auch zu wenig RAM die Ursache sein? In der Kiste sind derzeit 32 GB RAM verbaut, und das PBS-Datastore ist ein 12,8 TB großes ZFS. Passt das?

Der sync besagter VM wurde letzte Nacht erfolgreich verifiziert, dafür schlugen fünf andere Verifikationen fehl. Die Quellen wurden zuvor erfolgreich verifiziert, und auch der Sync-Job selbst lief ohne Fehler. Wo können sich da die Probleme reinschleichen?

Danke für die schnelle Antwort! Dann schauen wir mal, ob sich das heute Nacht von alleine zurechtruckelt.

Hallo zusammen, wir sichern unsere ca. 60 VMs auf einen dedizierten PBS. Nun würden wir gerne einen weiteren PBS als Offsite Backup an den Start bringen, der einmal am Tag das jeweils jüngste Backup aller VMs zu sich holt. Sowohl die Einrichtung, als auch der initiale Sync haben prima geklappt...