Everpure supports Proxmox VE; the plugin is still being written

The press release Proxmox published on 5 November 2026 to announce Everpure as a partner is written in two different tenses, and that is the whole story. Support is present tense: Proxmox VE "is supported across the full Everpure FlashArray™ family". Integration is future tense: "FlashArray will integrate directly with Proxmox VE". Between one sentence and the other sit the months your project does not have. And the words that decide a design — snapshot, clone, provisioning, plugin — appear nowhere in the release: they live on Everpure's blog, in the present continuous and with no date.

The three sentences of the release, in order

The first one establishes the support: "Proxmox Virtual Environment is supported across the full Everpure FlashArray™ family of high-performance and efficient all-flash storage arrays". The second one spells out the how: "Everpure FlashArray delivers centralized shared storage for Proxmox VE clusters over iSCSI, Fibre Channel, NVMe/TCP, or NFS", for virtual machines and containers. The third is the one not to skip: "FlashArray will integrate directly with Proxmox VE, so the platform's built-in high availability and live migration work seamlessly, with virtual machines moving between nodes without copying their disks". Two present tenses and one future, in three consecutive sentences.

The rest of the release is ecosystem: Everpure joins as an official Solution Provider, Thomas Lamprecht, CTO of Proxmox, says they welcome "one of the best-known names in all-flash storage" as a solution partner, and Craig Robertson, AVP of Partners for EMEA and LatAm at Everpure, says their partners will be able to design Proxmox VE solutions on FlashArray "with confidence". There are also three context figures that explain why array vendors are knocking on this door: Proxmox VE claims more than 2.3 million hosts, a community of over 225,000 members and more than 60,000 companies with an active support subscription.

The plugin they are building, in their own words

The part missing from the press release sits on Everpure's technical blog, and it is stated with a candour we appreciate: "One of the capabilities we're already working on is building a native storage plugin for Proxmox VE". They describe that plugin as a backend orchestrator, comparable to Cinder in OpenStack or a Kubernetes CSI driver, to "provision, attach, snapshot, and clone VM disks on FlashArray". The stated goal includes array-offloaded snapshots and clones, which is exactly what a vSphere administrator takes for granted and starts missing ten minutes into Proxmox.

We think the design is the right one: a plugin that talks to the array is the only way a snapshot you take from Proxmox means anything on the array, and the other way round. But "we are already working on it" has an operational translation that leaves no room for nuance: it does not exist today, there is no published date, and the lab they describe is six Proxmox VE 9.1 nodes split across two sites. In the meantime, a snapshot taken on the array does not show up in the Proxmox console: they are two inventories of restore points that never talk to each other, and the one your on-call team looks at is Proxmox's.

What you actually find today when you present the LUN

While the plugin is being written, FlashArray enters Proxmox the same way any block array does: you present a LUN over iSCSI, Fibre Channel or NVMe/TCP, and you put LVM on top. The Proxmox documentation says it plainly: the backend implements proper cluster-wide locking if the storage is marked as shared in the configuration, and that is how it is used on iSCSI LUNs or equivalent systems. It works, it is stable and it is what we have been operating for years. What it does not give you out of the box are the two things everybody asks about first.

The NFS route — FlashArray offers it through its file services — swaps one set of rules for another: there the disks are qcow2 files and Proxmox manages the snapshot, with its own footnote. We pulled apart the eight ways of setting up shared storage in Proxmox, and the small print of each one, a few days ago in this walk through the backend table; and why there is still no array-verified VMFS equivalent is covered in this other post. If what worries you is what happens to the snapshots already sitting on your array on moving day, that has its own article: the snapshot does not travel.

Four storage announcements in 2026, and one title that changes

It is in the titles, which anyone can see on the Proxmox press release index. 4 March: "native NAKIVO integration". 27 April: "native StorPool integration". 29 October: "native storage integration" with Lightbits. 5 November, the Everpure one: "expands enterprise storage options". The phrase missing from the fourth is native integration, and it is precisely the one that separates a backend Proxmox understands from an array Proxmox sees as a LUN.

That said, "native integration" is not a blank cheque either, and this is a warning we have already given ourselves. The Lightbits plugin is the vendor's own code, published openly and maintained together with the community, and its documentation states that it is not part of the commercial LightOS product and not covered by its support agreements or SLAs. An adjective in a headline does not tell you who answers the phone.

Why you search for "Pure Storage" and cannot find the announcement

A practical detail that saves half an hour of confusion: Everpure is Pure Storage. The name change was announced on Monday 23 February 2026; the company started operating under the Everpure name that same Thursday, the 26th, and began trading under the brand on 5 March, keeping the PSTG ticker. Its technical blog, the one that talks about the plugin, now lives at blog.everpuredata.com. If your internal documentation, your support contracts or your searches still say "Pure Storage", you are looking for the old name of the same array. Worth noting in the inventory before someone on the team concludes that the vendor "does not support Proxmox" because the press release does not carry the name they remember.

What does change on 5 November, and it is not trivial

It would be easy to settle for the cynical "it is only a press release", and it would be unfair. In the meetings where a migration gets decided, the objection we have most often seen stop a project is not technical: it is "my array vendor does not support that". For anyone with a FlashArray, nobody can say that sentence anymore. And for a shop with a Fibre Channel fabric already built and paid off, vendor-declared support weighs more in practice than a pretty plugin: it means that if multipath starts behaving oddly with Proxmox, there is somebody at the other end of the phone who will not tell you your platform is not on their list.

The three questions we ask before signing off a design

We ask them because we do not sell anybody's licences: we are not Proxmox resellers, nor VMware resellers, nor any array vendor's. That is our entire advantage when answering this kind of question, and it is also why the answer is sometimes "stay where you are for another year". If you want that reading applied to your own inventory and your own contract, that is exactly what we do in IT consultancy.

When to wait for the plugin and when not to

The usual case that reaches us looks like this: a three-year-old array, paid off, still under support; vSphere renewing at a price that no longer defends itself; and the question of whether to pause the project until the plugin ships. Our answer in that scenario is no. You design with what exists — a shared LUN, LVM, and a written inventory of which operation is done by hand — you document it and you move. Postponing a VMware to Proxmox migration while waiting for a release nobody has dated ends up being a licence renewal signed by omission.

Do wait for it — or look for another route — if your operation depends on production snapshots taken and rolled back from the virtualization console, several times a day, as part of a written procedure. In that case the plugin is not an improvement, it is a requirement, and a requirement with no date is treated as a risk: either you stay on the current platform until it lands, or you build the storage layer where the capabilities already exist today without an asterisk, which is what leads us to propose Ceph in quite a few infrastructure designs when the array is not untouchable.

Four storage announcements in nine months, two of them in the last three weeks: the Proxmox ecosystem is filling up with big names and that is good news for anybody planning to leave VMware. The calendar of a press release and the calendar of a migration do run at different speeds, though. The question that will hurt is not answered by the logo in the announcement, but by the inventory of which operation is still done by hand and who has it written down.

Sources (verified on 8 November 2026): press release "Proxmox expands enterprise storage options with Everpure FlashArray", 5 Nov 2026, and the press release index with the dates and titles for NAKIVO (4 Mar), StorPool (27 Apr) and Lightbits (29 Oct) — proxmox.com. Native plugin under construction, Cinder/CSI comparison and testing on Proxmox VE 9.1 — blog.everpuredata.com. LVM behaviour, snapshot-as-volume-chain as a technology preview, effect only on newly created volumes and the I/O degradation of classic snapshots — Proxmox VE storage documentation and Storage: LVM wiki. Pure Storage renaming to Everpure (announced 23 Feb 2026, operating as Everpure since 26 Feb 2026 and trading under the name since 5 Mar 2026, domains moved to everpuredata.com, PSTG ticker unchanged) — SiliconANGLE and Computer Weekly. The Lightbits plugin support statement ("community-driven", maintained "on a best-effort basis" and outside the commercial product) was verified by us on 2 November 2026 and is recorded in our walk through the eight storage types. Photo: fibre optic patch panel, free licence (details and attribution recorded with the image in the site repository).