v0.11.6

New Features

• Cluster-wide scope-typed locking — Replaced the host-level operation semaphore with a scope-typed locking layer that coordinates every storage operation (per-VM, per-storage, and per-appliance-command) across the whole cluster through the Proxmox cluster filesystem, making concurrent access to a shared Pool from many nodes and clusters safe.
• Automatic target-prefix re-homing — Changing a storage's target_prefix now takes effect on the next activation of an idle volume, which is moved onto a target under the new prefix. Volumes still in use are left in place and re-homed once idle.
• Shared-target protection — A storage now refuses to attach a volume onto, or log out of, an iSCSI target that another storage is using, refuses to tear down a target that has live connections, and rejects a target name owned by a different Pool — each with a clear message and no futile retrying.

Improvements

• Broken-export detection during activation — Activation verifies the exported LUN presents a usable, non-zero-capacity device before reporting success, and rebuilds through a bounded retry cycle when it does not, catching an appliance that attaches a LUN which isn't functional under load.
• Faster lock reclaim near the deadline — Cluster-lock acquisition polls aggressively in the final minute before its deadline (with jitter to keep contending nodes out of lockstep), reclaiming the lock the moment it frees.
• Larger lock headroom for shared storage — Acquire and hold timeouts for per-VM and per-storage locks were raised so a waiter can outlast a long hold under heavy contention.
• Bounded portal logins during activation — Each iSCSI portal login is time-bounded and refreshes the held lock, closing a window where enough slow portals could let two nodes hold the same lock.
• Credentials required at storage creation — Creating a storage now fails immediately if no REST password is stored, instead of accepting a storage whose later operations all fail with a confusing, far-removed error. The REST user name is now required for the NFS storage type as well.
• Quieter logging — Routine target unpublish is no longer logged at error severity, so it no longer drowns real errors for severity-based monitoring.
• Renamed Proxmox VM/CT tag force_rollback to force-rollback — improves readability and avoids tag specific restrictions.

Bug Fixes

• Fixed a spurious fatal lock error during long activation waits under a shared lock; the stuck-holder watchdog is now refreshed at every cooperation point.
• Fixed rename reporting success without renaming anything, which caused Proxmox to write configs pointing at disks that were never created.
• Fixed a snapshot of a resized volume never being able to activate; activation now requires only a non-zero staged capacity, while the resize path keeps its exact check.
• Fixed resize recovery aborting on a transient hiccup of its own size verification.
• Fixed a force-rollback tag misread as absent silently downgrading a forced rollback to a blocked one.
• Fixed clone name collisions stranding a temporary snapshot on the source volume; only intermediate snapshots created by the operation are removed, never real user snapshots.
• Fixed LUN placement matching target names as patterns, so a foreign target with a similar name can no longer receive a volume.
• Fixed the request layer mishandling an appliance "success with empty payload" response — it now retries the next address instead of returning broken data or looping on one address.
• Fixed empty-name disk allocation creating an invisible, unusable volume; an empty name is now treated as a request for automatic naming.
• Fixed silent disk-file leaks on NFS storage — destroying a guest, unlinking, or detaching a disk now actually removes the files from the share.
• Fixed on_add_hook return so Proxmox VE 9.x storage-add result verification passes.
• Fixed list_snapshots GUID processing.

Known Issues

• After a target-prefix re-name, freeing the volume can leave an empty orphan target on the array. This is a cleanup-hygiene gap only, with no data or device impact.
• Clone cleanup after machine restore: after restoring a machine from a clone, the clone is not removed from the iSCSI target. This relates to Proxmox bug https://bugzilla.proxmox.com/show_bug.cgi?id=6879. Should not affect user experience, as clones are removed automatically during shutdown or migration.
• NFS plugin volume snapshots may still require manual deletion when VMs are removed.
• Cancelling a snapshot operation may cause Proxmox VE to terminate plugin cleanup before it completes. This can leave the VM locked and snapshot-related resources present in JovianDSS but not registered in Proxmox VE.
• Disk import, export, and cross-cluster offline migration are currently unavailable. A minor volume-name parsing issue will be addressed in a future release. Additionally, the Proxmox ZFS migration workflow relies on ZFS send/receive, which is not supported by the current JovianDSS plugin implementation. We recommend using Proxmox Storage Migration to move volumes between storage systems.

Notes

When sharing a JovianDSS Pool between clusters, each cluster — and, more generally, each storage — must use a unique target_prefix. This is now enforced: the plugin refuses to share an iSCSI target between storages and reports which storage to reconfigure.
Notes

High Availability (HA)–managed virtual machines and containers are governed by Proxmox HA policies. Operations such as rollback, migration, or other direct state-changing actions are not recommended while a resource is under active HA control, as they may conflict with HA rules and trigger unexpected recovery actions (for example, automatic restarts or failovers). In such cases, a rollback or similar operation may be blocked or fail, even though the underlying storage is functioning correctly.

To safely perform these operations, users must first adjust the HA state of the affected VM or container by temporarily disabling HA management or marking the resource as ignored in HA. This ensures that HA does not interfere with the requested operation. Failures caused by HA restrictions are expected behavior and do not indicate a malfunction of the storage plugin.