[PR #489] [MERGED] fix: Preserve volume path for LVM-based disks #504

New issue

Closed

opened 2026-02-28 00:42:26 +03:00 by kerem · 0 comments

kerem commented

2026-02-28 00:42:26 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Telmate/proxmox-api-go/pull/489
Author: @pavel-z1
Created: 10/20/2025
Status: ✅ Merged
Merged: 10/23/2025
Merged by: @Tinyblargon

Base: master ← Head: fix/lvm-disk-update

📝 Commits (1)

633876e fix: Preserve volume path for LVM-based disks

📊 Changes

6 files changed (+27 additions, -5 deletions)

View changed files

📝 proxmox/config__qemu__disk.go (+10 -4)
📝 proxmox/config__qemu__disk__ide.go (+3 -0)
📝 proxmox/config__qemu__disk__sata.go (+3 -0)
📝 proxmox/config__qemu__disk__scsi.go (+3 -0)
📝 proxmox/config__qemu__disk__virtio.go (+3 -0)
📝 proxmox/config__qemu__disk_test.go (+5 -1)

📄 Description

fix: Preserve full volume path for LVM-based disks

Issue

When updating a QEMU virtual machine that uses disks on LVM-based storage, the Proxmox API returns a 500 can't activate LV error.

This occurs because the API client incorrectly parses the disk identifier (e.g., storage:vm-123-disk-0). It retains the storage pool and the disk's numeric ID but discards the full volume path (e.g., vm-123-disk-0). During a subsequent update operation (like changing disk bandwidth or backup settings), the client sends an incomplete identifier back to the API, which causes the operation to fail as the logical volume cannot be found.

Error Example

An attempt to update a VM resource results in the following error:
Error: error updating VM: 500 can't activate LV '/dev/lun-st1-db/vm-153-disk-0': Failed to find logical volume "lun-st1-db/vm-153-disk-0" (params: map[... scsi0:lun-st1-db:vm-153-disk-0,aio=native,discard=on ...])

The Fix

This pull request corrects the disk parsing and handling logic to ensure the full volume path is preserved throughout the lifecycle of the object and used during subsequent API operations.

The qemuDisk struct is updated with a VolumePath field to store the complete volume identifier.
The parseDisk function is modified to correctly extract and store this VolumePath.
Bus-specific disk structs (SCSI, IDE, SATA, VirtIO) are updated to properly handle and propagate the VolumePath during internal data conversions.
The mapToApiValues function now uses the preserved VolumePath when constructing API requests for disk updates, ensuring the correct, full identifier is always sent to Proxmox.

This change resolves the update failure for LVM-backed disks without affecting other storage types.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/Telmate/proxmox-api-go/pull/489 **Author:** [@pavel-z1](https://github.com/pavel-z1) **Created:** 10/20/2025 **Status:** ✅ Merged **Merged:** 10/23/2025 **Merged by:** [@Tinyblargon](https://github.com/Tinyblargon) **Base:** `master` ← **Head:** `fix/lvm-disk-update` --- ### 📝 Commits (1) - [`633876e`](https://github.com/Telmate/proxmox-api-go/commit/633876eb9fd1b6068fd5d89a64b53ce1b7990396) fix: Preserve volume path for LVM-based disks ### 📊 Changes **6 files changed** (+27 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `proxmox/config__qemu__disk.go` (+10 -4) 📝 `proxmox/config__qemu__disk__ide.go` (+3 -0) 📝 `proxmox/config__qemu__disk__sata.go` (+3 -0) 📝 `proxmox/config__qemu__disk__scsi.go` (+3 -0) 📝 `proxmox/config__qemu__disk__virtio.go` (+3 -0) 📝 `proxmox/config__qemu__disk_test.go` (+5 -1) </details> ### 📄 Description # fix: Preserve full volume path for LVM-based disks ### Issue When updating a QEMU virtual machine that uses disks on LVM-based storage, the Proxmox API returns a `500 can't activate LV` error. This occurs because the API client incorrectly parses the disk identifier (e.g., `storage:vm-123-disk-0`). It retains the storage pool and the disk's numeric ID but discards the full volume path (e.g., `vm-123-disk-0`). During a subsequent update operation (like changing disk bandwidth or backup settings), the client sends an incomplete identifier back to the API, which causes the operation to fail as the logical volume cannot be found. #### Error Example An attempt to update a VM resource results in the following error: `Error: error updating VM: 500 can't activate LV '/dev/lun-st1-db/vm-153-disk-0': Failed to find logical volume "lun-st1-db/vm-153-disk-0" (params: map[... scsi0:lun-st1-db:vm-153-disk-0,aio=native,discard=on ...])` ### The Fix This pull request corrects the disk parsing and handling logic to ensure the full volume path is preserved throughout the lifecycle of the object and used during subsequent API operations. - The `qemuDisk` struct is updated with a `VolumePath` field to store the complete volume identifier. - The `parseDisk` function is modified to correctly extract and store this `VolumePath`. - Bus-specific disk structs (SCSI, IDE, SATA, VirtIO) are updated to properly handle and propagate the `VolumePath` during internal data conversions. - The `mapToApiValues` function now uses the preserved `VolumePath` when constructing API requests for disk updates, ensuring the correct, full identifier is always sent to Proxmox. This change resolves the update failure for LVM-backed disks without affecting other storage types. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>