From: Cyrus <cyruspy@gmail.com>
To: pve-devel@lists.proxmox.com
Subject: Hitachi Block Storage
Date: Sun, 21 Jun 2026 15:43:27 -0300 [thread overview]
Message-ID: <CAEaLa5GFBuZzZF4Zk4Ep29hccE+KGZXKeu1fpqvX299rJt0_Vw@mail.gmail.com> (raw)
Hello!,
Hope you're doing well. I'm scratching a long standing itch in the way
traditional Storage systems are used with PVE, but I would like to
make a stop and check and ask around in the devel makelist.
I'm building a storage plugin to consume storage services from a
Hitachi VSP E-series storage system via fiberchannel. I would like to
achieve vSphere VVol like features and in that order of ideas I was
wondering if a framework should be built instead:
Option 1: any vendor could clone my plugin and adapt it to make it
work with their brand/model of machine (no framework, just forking)
Option 2: Build a vSphere VVol-like framework/plugin, which can accept
different connectors implementing the specific API calls required per
operation.
Option 2 seems the more vendor-friendly way to go, but after reading
https://pve.proxmox.com/wiki/Storage_Plugin_Development it seems it
would be a framework within the framework (odd at least).
I would like to read you feedback, I'm currently halfway to this scope
with Option 1:
* 1 LUN per virtual disk — direct array volumes, no LVM layer.
* Thin provisioning via Hitachi Dynamic Provisioning (DP) pools.
* Snapshots — array-offloaded Thin Image, per LDEV, with metadata
tracked in a cluster-replicated registry.
* Copy-on-write linked clones — space-efficient Thin Image clones from
a base image or a snapshot; full copies are handled by Proxmox via the
device path.
* Online volume resize — array expand + host-side multipath resize.
* QoS — per-LDEV upper/lower IOPS and throughput limits and I/O priority.
* Multipath-aware — FC WWN discovery, ALUA device stanza, automatic
WWID whitelisting (find_multipaths strict), and authoritative WWID
from the array.
* Active-node-only LUN mapping — keeps per-host LUN counts low; live
migration remaps on the fly.
* Management-plane controller redundancy — mgmt_ip accepts multiple
per-controller endpoints with automatic failover and
re-authentication.
* Storage migration — Move Storage to/from file stores (hot/cold),
plus volume_export/volume_import for offline cross-node / pvesm
migration.
* Disk reassignment (rename_volume), base/template images, orphan
detection, and partial-failure rollback during provisioning.
* Replication CLI (hitachiblock-repl) for TrueCopy, Universal
Replicator, and Global-Active Device (GAD).
Also, I don't see any hooks to expose in the web UI the plugin
options, am I missing something?
PS: I'm a happy Ceph user, but I believe this should be written :)
Regards.
reply other threads:[~2026-06-23 10:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEaLa5GFBuZzZF4Zk4Ep29hccE+KGZXKeu1fpqvX299rJt0_Vw@mail.gmail.com \
--to=cyruspy@gmail.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.