From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 41DAB1FF141 for ; Tue, 30 Jun 2026 21:55:00 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id F00502147A; Tue, 30 Jun 2026 21:54:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=szn1; t=1782849241; bh=x6sWOrXRAnasD8w7xxeb7yyKP/PfdkUhDg9BaD12/KA=; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject: Date:Message-Id:Cc:To; b=zS2wfZUdNpfYaJBcrPfu8EqqkAwYM6FgFS1d+bV49FE3ST/rYCvGl8TFt9dbYtK0v p/uX3EJnnc9naqAPvBFA2BP386WuC91T5f+3nXTzF3+dCuocmr75rGt89E7Pr/yIW2 FQgRs1bZMCDhJd9/wrLmTGW0HSIRVlLyv9Qtx+73jQfIp+XWVerviKmWkd7fWAalQ0 qeQj+ui1kOPdC2zZ5SRggA3H3KGEx2toM6vT5hUgUx+g7xE7M/1LRx9tXk4+H4+SB9 oiMetAXXW1qVdstlwQ+Mk3Q/cGtOs/DDhDqBixzXjNayJVREHkfZiT4hvZSJS/gpit BIMZYQBVGLYmQ== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?Karel_Bene=C5=A1?= Mime-Version: 1.0 (1.0) Subject: Re: FC Storage integration Date: Tue, 30 Jun 2026 21:53:46 +0200 Message-Id: References: In-Reply-To: To: Cyrus X-Mailer: iPhone Mail (23F77) X-SPAM-LEVEL: Spam detection results: 0 DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy FREEMAIL_FROM 0.001 Sender email is commonly abused enduser mail provider JMQ_SPF_NEUTRAL 0.5 SPF set to ?all RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: LW5WXA5QMSZ3NINMWB3VM2XCHWSZJH4T X-Message-ID-Hash: LW5WXA5QMSZ3NINMWB3VM2XCHWSZJH4T X-MailFrom: chucky@seznam.cz X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-user@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE user list List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, if you can, and it looks like you do, then please do. You=E2=80=99ll make a w= hole bunch of people happy, including those who don=E2=80=99t answer in mail= ing lists and forums. I have personally never worked with a Hitachi storage (= only HP, 3PAR, NetApp and Dell), but the functionality you describe is exact= ly where I=E2=80=99d shout =E2=80=9Cyes, I want it too=E2=80=9D. Regards, Karel > On 2026. Jun 30., at 4:24, Cyrus wrote: >=20 > =EF=BB=BFHello, >=20 > It's currently working!: >=20 > - 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) >=20 > 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. >=20 > 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. >=20 > Regards. >=20 >> El lun, 29 jun 2026 a las 18:09, Karel Bene=C5=A1 () es= cribi=C3=B3: >>=20 >> Hi, >> If you=E2=80=99re seeking for reassurance, then lately I was thinking abo= ut this too. Why VM-level snapshots on FC storage, when nowadays these stora= ge 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 AP= I of the storage to snapshot the LUN. Removal of a snapshot would be fully t= ransparent. Where it gets more complicated is an app-aware snapshot. And rev= ert to a snapshot, that would have to be done very carefully, nodes should n= ot start panicking that they lost storage. Is this what you meant? >>=20 >> Regards, >> Karel >>=20 >>=20 >>>> On 2026. Jun 29., at 14:20, Andrei Boros wrote: >>>=20 >>> =EF=BB=BFHi, >>>=20 >>> We are interested in using FC based storage in PVE, including HA with >>> multipath. >>>=20 >>> I am not sure what you mean by "the specialized box". The plugin, the >>> backend, other? >>>=20 >>>> On 2026-06-26 1:06 AM, Cyrus wrote: >>>> Hello!, >>>>=20 >>>> 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. >>>>=20 >>>> Is there any interest in having a storage plugin to integrate to FC >>>> Storage systems in a 1 vdisk =3D 1 LUN fashion?. That should allow you >>>> to offload some operations like cloning/snapshots operations to the >>>> specialized box. >>>>=20 >>>> 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) >>>>=20 >>>> Regards. >>>>=20 >>>=20 >>> -- >>>=20 >>> *ing. Andrei Boros* >>>=20 >>> Serviciul IT&C >>> *Radio Romania* >>> |Tel: +40-21-303-1870 >>> +40-745-115721 >>> Email: andrei@srr.ro | >>>=20 >>=20