This will change as soon as qemu remove it's gluster support. Which will happen at some point otherwise they wouldn't have deprecated it. And maintaining a qemu fork is a whole different beast than continueing to ship a storage plugin.
Another way is to just pipe a dd read call through tar through ssh from one to the other end where it untar's and dd writes all in a single call, this will minimize bandwidth and also achieve what you're after. I'm pretty sure I had an old backup...
No errors here on a 5950x.
amd64-microcode is already the newest version (3.20251202.1~bpo13+1)
Motherboard is an Asrock x570m pro4 with bios P5.65
Memory is M391A4G4AB1-CWE
It's never too late unless the drive is totally dead. Clone the drive the first chance you get, do NOT disable RO mode, it does that to protect the data, at this point you have no idea what could have caused the ext4 journalling issue, hence...
@Impact, is on the money, if you need it, back it up.
When you say files, do you mean your guests?
What you can do is attach an external storage device, mount it, and then do a
cp -r /etc/pve <your mounted storage device>
(for example)
cp -r...
I just checked all my upgraded nodes, most are less than 0.05% on IO pressure stall, and IO load barely cracks 1%, its at 0% most the time.
I'm running Epyc's (rome/milan) and 5950x's, guests are doing average workloads, storage tiers are all...
Indeed, already have alternative layers in place to provide monitoring, but they are an additional myriad of scripts that in all fairness is a lot of extra legwork that could in theory be avoided to make things more streamlined.
From an...
For this it might make sense to setup a dedicated monitoring software though e.g. Prometheus, Icinga2 or checkmk. pulse is a monitoring software specifically aimed at ProxmoxVE which also publishes it's metrics to prometheus.
It periodically polls the status and metrics and caches them locally so that one can check what was going on before a node got unresponsive or when it got shut down. When you check the UI in some views, and especially the refresh buttons, ensure...
Looks good my end!
Love the ability to just glance at the dashboard and see all is fine across the network of nodes.
Has there been any thoughts regarding adding a sweet notifications layer which can send out notifications when...
Thats good to know! Thanks! I've always just ran a strip of thermal across the lot.
Although in this case it is a U.3 drive, so not really something you think about regarding opening and re-padding, plus with it being a Samsung pm1733, they do...
Sorry to hear about that man.
That really sucks!
(If you ever need me to run the CFD studies for you, just hit me up. I've already studied the optimal placements for thermal pads (on NVMe SSDs), using CFD. (It's better if you place individual...
Right. Again, this is why I tested both, on the same physical box and with six HDDs rather than just three.
That way, three can be assigned/dedicated to ceph and the other three can be assigned/dedicated to gluster so they don't "criss-cross"...
Ok, so I notice something strange after the 9.2.3 upgrade from 9.1.
One of the LXCs is logging this warning every few minutes:
eth0: Failed to set IPv6 MTU to 9198: Invalid argument
The process causing this error is: systemd-networkd
The LXC...
At the end of the day, only you can know what is good for you based on what you have tested, the way you tested it, with the hardware you own and if it made you happy in the sense it performs to your expectations.
The problem is the variables...
I played with gluster3.7 back in like 2018-2019 in an attempt to solve a very specific problem: burning through SSDs because of FEA scratch data.
RAM doesn't have the same kind of finite write endurance limit like NAND flash based SSDs have. (If...
I gave up on all the software-defined storage layers.
Went back to direct-2-nvme, and good old solid backup schedules. I employ hardware-raid1 and 10 where data-uptime criticality applies.
I tend to carry this ethos across to both production...
Upgrade to 9.2.3 from 9.1 went without issue across all my nodes. Didn't need to do any resource remapping, plug-n-play all the way.
Nice to see Proxmox upgrades becoming so streamlined even when migrating kernels, well done Proxmox Team.