From: Ciro Iriarte <cyruspy@gmail.com>
To: "Karel Beneš" <chucky@seznam.cz>
Cc: pve-user@lists.proxmox.com
Subject: Re: FC Storage integration
Date: Tue, 30 Jun 2026 18:12:35 -0300 [thread overview]
Message-ID: <CAEaLa5FJdQeQv4_hNbeC=nyUJHPOWoKHBw43xK5mE48sCJ12EA@mail.gmail.com> (raw)
In-Reply-To: <CA4E743D-6BF6-4FFC-A8BD-2173606AAB3D@seznam.cz>
Thanks for the shout out. If you have test environments, I'm happy to
add other platforms that expose APIs to automate.
Regards,
El mar, 30 jun 2026 a las 16:54, Karel Beneš (<chucky@seznam.cz>) escribió:
>
> Hi,
> if you can, and it looks like you do, then please do. You’ll make a whole bunch of people happy, including those who don’t answer in mailing lists and forums. I have personally never worked with a Hitachi storage (only HP, 3PAR, NetApp and Dell), but the functionality you describe is exactly where I’d shout “yes, I want it too”.
> Regards,
> Karel
>
>
> > On 2026. Jun 30., at 4:24, Cyrus <cyruspy@gmail.com> wrote:
> >
> > Hello,
> >
> > It's currently working!:
> >
> > - LUN create/elimination
> > - Mapping/Masking
> > - Masking/Unmasking on migration
> > - Snapshots
> > - Clone was implemented, but PVE cannot drive it (at least I could
> > find how to avoid cloning via dd on host side and offload to the
> > storage layer)
> >
> > Everything is driven from PVE 9.2, the only annoyance is that the
> > storage REST interface is taking 6 seconds to respond to simple
> > queries (upgrade pending). Today is SCSI-3 Persistent Reservation day.
> > I will enable some use cases like Windows Server Failover Clusters.
> >
> > The module is centered in Hitachi VSP, I'm mostly interested in
> > understanding if there are more users to justify a full refactor to
> > accommodate multi-vendor support.
> >
> > Regards.
> >
> >> El lun, 29 jun 2026 a las 18:09, Karel Beneš (<chucky@seznam.cz>) escribió:
> >>
> >> Hi,
> >> If you’re seeking for reassurance, then lately I was thinking about this too. Why VM-level snapshots on FC storage, when nowadays these storage boxes are smart enough to do LUN-level snapshots. All it would require is proper layout on the storage side. If a LUN (or more LUNs) is dedicated to a VM, then you need to freeze the writes in a VM for a little and call the API of the storage to snapshot the LUN. Removal of a snapshot would be fully transparent. Where it gets more complicated is an app-aware snapshot. And revert to a snapshot, that would have to be done very carefully, nodes should not start panicking that they lost storage. Is this what you meant?
> >>
> >> Regards,
> >> Karel
> >>
> >>
> >>>> On 2026. Jun 29., at 14:20, Andrei Boros <andrei@srr.ro> wrote:
> >>>
> >>> Hi,
> >>>
> >>> We are interested in using FC based storage in PVE, including HA with
> >>> multipath.
> >>>
> >>> I am not sure what you mean by "the specialized box". The plugin, the
> >>> backend, other?
> >>>
> >>>> On 2026-06-26 1:06 AM, Cyrus wrote:
> >>>> Hello!,
> >>>>
> >>>> It seems the pve-devel mail list is not very welcoming or I am doing
> >>>> something wrong. I would try another angle: asking the users.
> >>>>
> >>>> Is there any interest in having a storage plugin to integrate to FC
> >>>> Storage systems in a 1 vdisk = 1 LUN fashion?. That should allow you
> >>>> to offload some operations like cloning/snapshots operations to the
> >>>> specialized box.
> >>>>
> >>>> I'm currently testing an integration with Hitachi VSP, but it could be
> >>>> generalized to accommodate specific brand/model drivers (would assume
> >>>> Dell, HPE, Huawei, Purestorage are still selling similar systems)
> >>>>
> >>>> Regards.
> >>>>
> >>>
> >>> --
> >>>
> >>> *ing. Andrei Boros*
> >>>
> >>> Serviciul IT&C
> >>> *Radio Romania*
> >>> |Tel: +40-21-303-1870
> >>> +40-745-115721
> >>> Email: andrei@srr.ro <mailto:andrei@srr.ro>|
> >>>
> >>
>
next prev parent reply other threads:[~2026-07-02 8:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 22:06 FC Storage integration Cyrus
2026-06-29 12:03 ` Andrei Boros
2026-06-29 21:09 ` Karel Beneš
2026-06-30 2:24 ` Cyrus
2026-06-30 19:53 ` Karel Beneš
2026-06-30 21:12 ` Ciro Iriarte [this message]
2026-06-29 12:26 ` SPAM: " Chunhui Ouyang
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='CAEaLa5FJdQeQv4_hNbeC=nyUJHPOWoKHBw43xK5mE48sCJ12EA@mail.gmail.com' \
--to=cyruspy@gmail.com \
--cc=chucky@seznam.cz \
--cc=pve-user@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox