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.

[rhp]

Hi Yaroslav,

Thanks for the feedback.
We are in the process of setting up Proxmox, and we are experimenting with different options, which explains (some of) the problems your team found in the logging.

To clean things up, we deployed another stand-alone Proxmox node, with no other LVM storage via iSCSI.
We created a fresh StarLvm volume and we can reproduce the exact same problem there.

Can you also reproduce this on your side? Or is this somehow particular to our StarLvm + iSCSI connection.
On the surface the fact that the VM disk of the first linked clone is not renamed to "base-..." seems to provide a hint at the root cause.

[yaroslav (staff)]

Could you please pull the same set of logs? Use the same case ID as your reference.