StarLvm does not allow linked clones of linked clones?

[rhp]

Hi,

We have a Proxmox cluster (9.2.3) with StarLvm installed and configured.

We have a number of templates that are "stacked" on top of each other (base windows, base windows + sql, base windows + sql + iis, etc.) and we want to use linked clones to make this cheap.

However, we have observed that this is not allowed with the StarLvm implementation. With local-lvm this is working just fine.
The first linked-clone is no problem. However, creating the second linked-clone (so the 3rd in the row) we are getting this error:

Error creating VM: 500 Linked clone feature is not supported for 'starlvm:vm-132-disk-0'

To reproduce this, use the following steps:
1. Create a VM with StarLvm storage.
2. Convert this to a template. Note that the disk is renamed from vm-x-disk-0 to base-x-disk-0.
3. Create a linked clone from this template.
4. Convert the clone to a template. Note that the disk is not renamed this time to base-, but keeps being named vm-. This is inconsistent with e.g. local-lvm.
5. Create another linked clone. This results in the error listed above.

Is this a known limitation of the StarLvm implementation, or should this be considered a bug?

[yaroslav (staff)]

Please let me know which StarLVM version you use.

[rhp]

Hi Yaroslav,

starwind-proxmox-plugin-pve9 is installed (version: 1.1.41)

[yaroslav (staff)]

Please collect the logs /opt/starwind/starwind-proxmox-plugin/collect_pve_logs.sh and share them with me here.

[rhp]

How do I transfer this?
When I try to attach the file, I get an error it is too big (73MB).

[yaroslav (staff)]

https://www.starwindsoftware.com/support-form
1525955 - is your case reference.

[rhp]

Thanks. File is uploaded now.

[rhp]

@yaroslav can you confirm that you got the requested logging?
Can you reproduce the scenario that I mentioned above, or are we doing something wrong on our side?

[yaroslav (staff)]

Thanks for your update. Yes, the request was logged.
The fix might take some time though. I will try to update this thread once I hear back from my team.
As a side note, the current (i.e., the latest) plugin version that you have is not working with 9.2.3; it was created to address a similar issue in 9.2.4.

[rhp]

Is there a changelog somewhere that we can use to identify which versions of the plugin are or are not compatible with which versions of Proxmox?

[yaroslav (staff)]

Sadly no. I've proposed that recently.

[yaroslav (staff)]

The dev team concluded that there's something with the LUN behind the Prox181LVM storage.
Below, I am quoting their answer.

/etc/pve/storage.cfg defines:

lvm: Prox181LVM
vgname VolumeGRP181
base Prox181DS:0.0.0.scsi-36090a0c8c0d826d39aa1164df206c04c
That scsi-36090a0c... WWN resolves (ls -la /dev/disk/by-id/) to /dev/sdc.

/dev/sdc is the disk behind iSCSI target ...-proxmox181-ds (10.0.0.250, logged in, sdc, confirmed in iscsi-sessions.txt/dmesg.txt).

But disks/disk-sdc.txt shows /dev/sdc has a GPT table with EFI System / MSR / Basic Data / Windows-RE partitions — i.e. it's a Windows VM's disk, not an LVM2 physical volume . Compare with sdd (backs Prox184LVM/VolumeGRP184) and sde (backs the StarLVM shared storage), which both show clean LVM PV/VG structures.

So every Volume group "VolumeGRP181" not found error seen across qmcreate/qmmove tasks for VMs 104, 105, 114, 119, 123, etc. (from 2026-07-02 through 2026-07-16, i.e. both before and after the plugin bump) is expected: Prox181LVM is pointed at a LUN that was never pvcreate/vgcreate'd as VolumeGRP181 — it's presenting an already-provisioned Windows disk instead. This is a SAN-side/target-mapping issue (wrong volume exposed under the proxmox181-ds target, or the intended VolumeGRP181 volume was never initialized), not something the plugin upgrade would fix.

Separately, there's an unrelated real I/O error during two qmclone operations against VolumeGRP184 (qemu-img: error while writing... Input/output error on /dev/VolumeGRP184/vm-114-disk-1) — worth flagging to the user but it's a different LUN/target (proxmox184-ds) than the one causing the recurring VG error.