Another vendor to take a look at is https://multiportal.io/
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
I don't know if it is a bug, adding some extra information may help others/staff:
qm config 121
ha-manager status
ha-manager rules list
Cheers
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox -...
You can also try:
qm disk rescan [OPTIONS]
Rescan all storages and update disk sizes and unused disk images.
--dryrun <boolean> (default = 0)
Do not actually write changes out to VM config(s).
--vmid <integer>...
Hi @Chetna , welcome to the forum.
The log snippet you posted is not nearly enough to suggest a meaningful troubleshooting direction. We do not know where the log originated, what associated task was running on PVE at the time, what initiated...
This is a home setup; you are not running critical infrastructure. You already have a backup plan in place.
If you want to experiment with a mirrored configuration, use a flexible option such as ZFS and configure it on your boot drives. If, a...
Hi @starstrk , welcome to the forum.
Keep in mind that disk Mirror is not a backup. It only protects you from a physical disk failure. Are all NVMe of the same type? Is one older than then others? Do they have different used percentage?
You may...
Hi @rkrick99 , welcome to the forum.
Congratulations on embarking on a new technology journey. Your post is mostly hardware oriented but does not contain an explicit question.
The hardware is certainly more than sufficient for a home experiment...
For lab purposes you can achieve QCOW sharing by forcing QCOW disk assignment to two VMs via "qm set". However, this would be against both standard PVE practices and certainly against the MSFT cluster qualification, and as such - not suitable for...
I would review the upgrade logs/output, if still available, for any errors.
I would then reboot the server and closely review the logs starting from fresh boot, both journalctl and /var/log/pve/*
I would also run:
- dpkg -V
- apt install debsums...
Hi @ravem0n , welcome to the forum.
Have you checked the Console of the browser for errors? Have you previously run any scripts that may have modified the code?
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox -...
The hardware availability may depend on the region, but as a general approach - if one thinks they need 100G for "service" (user/app access?), having a 10G for backing storage may introduce an unnecessary bottleneck from day one.
Blockbridge ...
Hi @cemil.heyderov , welcome to the forum.
At the first glance it seems like an installation media problem. There is nothing in the error to suggest that modifying PVE config would help.
Cheers
Blockbridge : Ultra low latency all-NVME shared...
Hi @Malavudeen , welcome to the forum.
Is there a particular challenge that you are trying to solve? We've had WSFC running on PVE, in the lab, successfully.
Cheers
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox -...
Migration across heterogeneous storage is handled by a client-side process. The client has no awareness of the internal layout or implementation details of the virtual disk - it simply reads logical data blocks. Whether those blocks originate...
Hi @William Edwards ,
It looks like your new storage is "local" directory type storage. The old one is "ZFS block" type storage. The name changes are not semantic - they are completely different formats.
There is also no way for you to...
Right, 69TiB is 75TB, which perhaps is 25x3? But then Op says that they only have 25TB _total_.
@Taledo , its all speculation until hard supporting data is provided.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox -...
Hi @rosiecharles,
25GbE is really the starting point for modern greenfield business deployments. If you are planning for future growth, starting with 100GbE infrastructure and using breakout cables to provide 25GbE connectivity may be a good...
Hi @Taledo,
Perhaps adding a few more full page screenshots would help here. Its unclear where this data came from exactly, or how it correlates to your actual hosts. Providing exact CLI metrics data from the hosts would be helpful as well...
One of the questions - when was the chunk corrupted. Perform a test backup that represents your normal workload, then verify it immediately.
Also, check "dmesg" output for any disk error indications around the time when you ran previous verify...