Hi @tuttle333 , welcome to the forum.
Veeam does not perform storage-integrated snapshots with any type of storage when combined with PVE. The functionality you are thinking of is VMware specific.
Cheers
Blockbridge : Ultra low latency...
The dump option only has a view into internal PVE CI, it does not reflect custom configuration.
Booting your VM is the best way to check whether the ID was applied, and if it was not - check ci log inside the VM.
Cheers,
Blockbridge : Ultra low...
Hi,
yes, I have now verified the path mapping again, and the sporadic NOP timeouts always affect the same iSCSI/SCSI path.
The connection number changed over time because the iSCSI sessions were recreated (connection2:0, later connection4:0...
Hi @huganega ,
Are you sure that you looked at the correct network interface? The one used by iSCSI?
If you've confirmed that there are no network layer errors, then issue is likely in the higher layer of the stack. A rolling network trace would...
I'll drop this here: https://pve.proxmox.com/wiki/Multipath
We are currently also working on getting iSCSI, LUN and multipathing integrated into the Proxmox VE tools and web UI. So keep an eye out for it in future release notes.
The best place for recommendation on multipath file is your vendor's documentation. I think this may be what they want, but I'd check with them first:
devices {
device {
vendor "Lenovo"
product "DS4200"...
There is no built-in way to assign user-friendly names to the devices, if you want to continue using DATASTORE* - you have to continue doing it manually.
You didnt specify what version of PVE you are using. In PVE9, for example, ...
How @adrianovf ,
Proxmox VE does not, currently, deal with Multipath at all. The management is done at the OS level which is Debian. There are Kernel and Userland parts to multipath.
Generally, you should not need to edit the configuration in...
Hello everyone,
We have been working with Proxmox for 15 years, designing, developing, and maintaining software for hosting providers that use the platform.
Proxmox VE has always been the main focus of this work. Over time, we have developed...
Whatever you do - don't clobber the original VM and its files. Clone it by whatever means work with your particular installation and experiment with the clone until you get it working.
Blockbridge : Ultra low latency all-NVME shared storage for...
Someone has to maintain it, which means proper testing and release management. If the goal is Microsoft certification/WHQL, that also means establishing the appropriate relationship with Microsoft, going through their certification process, and...
The mechanics and politics of software creation could be gleaned from the GitHub issue referenced in the original thread.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
You'll be pleased to know Windows Server 2022 and SQL server is indeed stable (so far) on the virtstor drivers for 0.1.271 - cloned the machine, tested offline with new "old" drivers and everything stable and no issues even when running...
Here is a link that I've recently came across that may be useful: https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers#0.1.285:_VirtIO_SCSI/VirtIO_Block:_Read_errors_and_performance_issues_with_IO-heavy_Windows_Server_2025_VMs
Blockbridge ...
This section of Wiki may be useful:
https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers#0.1.285:_VirtIO_SCSI/VirtIO_Block:_Read_errors_and_performance_issues_with_IO-heavy_Windows_Server_2025_VMs
Blockbridge : Ultra low latency all-NVME shared...
This thread was started and stopped 2 years ago, I am not sure why it was necromancer'ed :-) I am sure OP has moved on since 2024.
Joined May 31, 2024
Last seen May 31, 2024
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox...
Right, when you know you have a degraded cluster - any little blip is potentially a second and fatal failure. You either let the HA system do its job, which sounds like it performed as expected, or take over recovery by disabling HA...
We do this for all upgrades. We probably should have done this on all nodes straight away when it was in this state, but you live and learn right.
Disarming HA should have probably been our first step.
You may want to investigate the "cluster maintenance" option as a tool for the future. If it acts by suspending automatic HA decisions, giving you time to reboot/recover nodes - that may be something to keep in mind.
ha-manager crm-command...
We nailed it down to a failed dbus, causing a cascading effect. Just a perfect storm of things that are making us question HA a bit. i.e. we could have recovered this had HA not fenced and rebooted everything, but hindsight is wonderful right...