Trying something new out, join us?
Hi all! Briana from the community team here. adhill and nfritsch came to me over the summer with the idea to host a virtual PUG meetup. So we put our heads together and came up with the idea of hosting a virtual PUG all about the landscape of virtualization options and figuring out how to make a choice or make the most of the choice you've already made. We'll meet on zoom & use breakout rooms to have small group discussions on 7 different virtualization topics. Info & registration link can be found by clicking on this image ⬇️ We're hosting it in 2 week and will be sending you a DoorDash gift card to cover your lunch during it. If you're part of a local chapter an SE in your area will be hosting a happy hour later in the day. (So far, Pittsburgh, Cleveland, and Columbus, OH have committed to this. Oh and you have to be at meetup to learn about the HH location & get swag.) We've brought in the Everpure experts on each of these options, and in some case they'll be interviewing customers who have already made the move. You'll have the chance to ask both of them your questions and get to know other Everpure customers that are making the same decision as you. What I'm asking is two things of you: 1) If you're interested, please register. This will help me know if it was a good idea to try out and will make it so I can get you that GC for lunch. Bonus points for commenting here & letting everyone know which room you're joining or thinking of joining. 2) If you think this is a terrible idea, tell us! Even better if you have an idea of what you'd like to see from the community team.Azure Red Hat OpenShift with Everpure Cloud
Azure Red Hat OpenShift (ARO) can use Everpure Cloud for persistent block storage, for VMs and containers. Both Everpure Cloud options - Everpure Cloud Azure Native and Everpure Cloud Dedicated are certified with ARO, and the cluster-side setup is nearly identical for both. This post covers the architecture, configuration sequence, and the checks that catch most problems early. Two storage options, one ARO procedure Everpure Cloud Dedicated is an array you deploy into your Azure subscription. Everpure Cloud Azure Native is delivered through the Azure portal, where you deploy a Storage Pool into a delegated subnet in your own Azure Virtual Network. With Azure Native you manage the array through the Platform Console, which gives you the Purity GUI, REST API, and CLI. It's disabled by default and you enable it per Storage Pool. With Dedicated you use the Purity interface directly. Architecture ARO provides the compute platform for VMs and containers. The Storage Pool (or Dedicated array) provides persistent block storage, and PX-CSI connects the ARO worker nodes to it to provision and manage volumes. The solution uses two paths. Management path. PX-CSI talks to the Purity management endpoint to create and manage volumes. With Azure Native, the Platform Console is how you get that endpoint. Data path. iSCSI traffic flows between the ARO worker nodes and the storage over the Azure virtual network. Deploy the ARO cluster and the storage in the same Azure region and virtual network. Put ARO in its dedicated subnets and the Azure Native Storage Pool in a separate subnet delegated to the Everpure Cloud service. A jump host VM is optional, and it's handy for reaching both the cluster and the Platform Console. For the data path, keep it short and boring. Everpure's field guidance is no virtual network peering and no user-defined routes or virtual appliances between the workers and the storage. Walkthrough Enable the Platform Console (Azure Native only) In the Azure portal, open the Storage Pool, go to Settings, then Platform console, and set it to Enabled. Pick the access methods you need (GUI and REST API, and optionally SSH) and select Configure. Copy the management IP address and the cloudadmin user name from Connection details, then generate a one-time password. It's shown once, so copy it before you close the dialog. Browse to https://<management-IP-address>, sign in as cloudadmin, and create a local administrator account right away. cloudadmin is only for first access. Make sure your Network Security Group allows TCP 80 and 443 for the GUI and REST API, and TCP 22 if you enabled SSH, and limit those rules to your management addresses. Prepare the OpenShift cluster Log in to the cluster from your Azure VM, create the Portworx namespace, and turn on user workload monitoring so OpenShift can scrape Portworx metrics. RESOURCE_GROUP="<ARO cluster resource group name>" CLUSTER_NAME="<ARO cluster name>" ADMIN_PW=$(az aro list-credentials --name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP --query "kubeadminPassword" -o tsv) API_URL=$(az aro show --name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP --query "apiserverProfile.url" -o tsv) oc login $API_URL -u kubeadmin -p $ADMIN_PW oc create namespace portworx apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: true Apply that with oc apply -f. Then, in the ARO web console, go to Ecosystem -> Software Catalog, search for Portworx Enterprise, and install it into the portworx namespace. Don't create a StorageCluster yet. It comes after the worker nodes and the credentials are ready. Configure worker nodes PX-CSI attaches volumes over iSCSI, so the workers need multipath and udev settings that match Everpure's Linux recommendations. Create a multipath.conf with "user_friendly_names no" and "find_multipaths no" (each controller has a single path), and a udev.rules file with the recommended queue depth and tuning. The same two files go on every worker. Base64-encode both with base64 -w0, and wrap them in a MachineConfig. apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 98-worker-pure-multipath labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/multipath.conf mode: 0644 contents: source: data:text/plain;charset=utf-8;base64,<base64-multipath-conf> - path: /etc/udev/rules.d/99-pure-storage.rules mode: 0644 contents: source: data:text/plain;charset=utf-8;base64,<base64-udev-rules> systemd: units: - name: iscsid.service enabled: true - name: multipathd.service enabled: true oc apply -f 98-worker-pure-multipath.yaml oc get mcp worker -w The Machine Config Operator merges this into the worker pool and rolls it out one node at a time, cordoning, draining, applying, and rebooting each. Wait until the worker pool shows Updated as True. Give PX-CSI access to the array Create a user with the Storage Admin role (or an equivalent tenant-scoped role if you use secure multi-tenancy) and generate an API token for it. On Dedicated, that looks like this: pureadmin create --access-policy storage_admin px-pure-user ssh px-pure-user@<array-management-IP> pureadmin create --api-token On Azure Native, do the same from the Platform Console. Next, describe the array in a pure.json file and load it into a secret in the portworx namespace. { "FlashArrays": [ { "MgmtEndPoint": "<management-endpoint-IP>", "APIToken": "<api-token>" } ] } oc create secret generic px-pure-secret \ --namespace portworx \ --from-file=pure.json=/path/to/pure.json The secret name has to be px-pure-secret, because PX-CSI looks for that name by default. Generate and apply the PX-CSI StorageCluster Open Portworx Central, go to Spec List, Create New Spec, and choose PX-CSI. Pick a supported release (26.1.x in the documented setup), set the namespace to portworx, choose Azure Red Hat OpenShift (or generic OpenShift, since the YAML is valid for both), set the access type to Block Storage and the SAN type to iSCSI, and leave the rest at defaults. Download the manifest and apply it. oc project portworx oc apply -f px-csi-storagecluster.yaml Watch the StorageCluster in the console until it reads Running. During creation PX-CSI reads px-pure-secret, parses pure.json, and uses those endpoints and the token to manage volumes. Verify and use oc get pods -n portworx | grep -E 'px|pure-csi' oc get storagecluster -n portworx All PX-CSI pods should be Running and the StorageCluster should report Online or Running. oc get sc PX-CSI creates several default px-pure-csi-* StorageClasses, pick your PX-CSI StorageClass with backend: pure_block or create your own. Create a PVC or VM against the class, bind it to a pod, and you'll see the volume appear in the Platform Console or Purity UI. When something doesn't work Start at the bottom of the stack and work up. Connectivity. From a worker, run iscsiadm discovery against the array endpoint, and check that initiator names are unique. Node configuration. Confirm multipath.conf and the udev rules landed on every worker, and that iscsid and multipathd are running. PX-CSI. Check that the pods are Running, the StorageCluster is Online, and px-pure-secret exists in the same namespace as the operator. Connect to workers oc get nodes oc debug node/<worker> -T -- chroot /host Check services (ensure iscsid and multipathd services are enabled and running on workers) and check config files are updated. cat /etc/multipath.conf cat /etc/udev/rules.d/99-pure-storage.rules Resources Everpure Cloud Dedicated with Azure Red Hat OpenShift and PX-CSI Deployment GuideEverpure Cloud Azure Native: A closer look at the Platform Console
In this post, I thought to take a closer look at the Platform Console for Everpure Cloud Azure Native. It provides access to a Storage Pool through the familiar Purity GUI, REST API, and CLI, giving storage administrators an additional way to handle advanced configurations. The important distinction here is that the Platform Console complements the Azure-native experience. It does not replace it. Azure remains the primary interface for day-to-day management, while the Platform Console is intended for specific tasks that Azure does not expose. What does it add? Let's start with the practical use cases. Storage configuration outside Azure Resource Manager The Platform Console allows you to create and manage Purity resources such as standalone volumes, hosts, host groups, protection groups, and snapshot policies outside Azure Resource Manager (ARM). This gives administrators more flexibility when a supported storage workflow requires objects or settings that are not available through the Azure-native interface. For teams already familiar with Purity, it also means working with interfaces they already know. Snapshot management For resources managed through the Platform Console, you can create manual snapshots, configure snapshot schedules, and restore snapshots. The benefit here is control over when recovery points are created and how snapshot protection is configured for those resources. However, it is important to keep resource ownership clear when using both Azure and the Platform Console. More on that below. Automation and monitoring Supported storage workflows can be automated through the REST API, SDKs, or CLI. Local users can generate API tokens for REST access and upload SSH public keys for command-line access. Array metrics can also be collected through the OpenMetrics endpoint using a local-user API token. This provides a way to collect storage metrics for monitoring workflows, alongside the ability to script supported administrative tasks rather than perform each operation manually. Getting access One Platform Console is available per Storage Pool. It is disabled by default and must be explicitly enabled from Azure. In the Azure portal, open the Storage Pool and navigate to Settings → Platform console. Web console and REST API access are enabled together, while SSH can be enabled independently. Once the configuration is applied, the portal provides the management IP address and the pre-created cloudadmin user name. Initial access uses a one-time password generated from Azure. The cloudadmin account is temporary: it’s reserved for this first sign-in and removed when the password expires. Generating a new password recreates it. After signing in, create your own local users for ongoing administration. The management interfaces use the same delegated subnet as the storage data path. Because of that, use Network Security Groups to restrict management access to the administrative hosts that need it. Application VMs do not need Platform Console access to consume storage. Two interfaces, but not interchangeable resource management This is probably the most important operational consideration. Resources created through Azure are tracked in Azure. Resources created through the Platform Console exist on the array, but are not visible to the Azure-native interface. There is also no hard isolation between the two. Changing or deleting an Azure-created resource through the Platform Console can leave Azure with stale information, causing subsequent operations to fail or report an incorrect state. A practical rule is therefore: Manage the lifecycle of Azure-created volumes and volume groups through Azure. Use the Platform Console for resources created there, or for specifically documented advanced configuration. Keep a record of resources created outside Azure so they are not overlooked during decommissioning. The summary The Platform Console adds flexibility where the Azure-native interface does not expose a supported storage operation. Familiar Purity tools, snapshot management, automation, and access to array metrics give administrators more options for advanced workflows. The key is to use those options deliberately: keep routine management in Azure, limit console access to the people and systems that need it, and maintain clear ownership of resources across the two interfaces. For the supported workflows, access requirements, and configuration instructions, refer to the Platform Console for Everpure Cloud Azure Native KB.Our First Virtual Pure User Group Meeting
I hope you’re enjoying the fall weather. Baseball fans have already seen two roof balls this postseason, while Bengals fans know the drill. We tried to gather this summer, but the July 4th holiday and vacations made scheduling tough. We’re planning one last community get-together before 2027, and details are coming soon. In the meantime, join us for our first virtual Pure User Group, focused on modern virtualization. Subject matter experts and customers will share their experience and answer questions. We’re bringing together Pure User Group communities from across the Midwest, including Pittsburgh, but don’t let the Steelers fans scare you off even though they got the best of our Bengals a few weeks ago. Event Date/Time: Thursday, October 29, 2026, 1:00–2:20 p.m. Eastern Register: https://experience.everpuredata.com/virtualizationlunchlearn I’ve loved the community we’ve built in 2025 and 2026. We have a great foundation, and I’m looking forward to building on it in 2027.Simplify mounting volumes on Azure VM with EC Mount VM Extension
Managing external storage on Azure VMs no longer has to involve repetitive guest OS configuration or custom scripts. The Everpure Cloud Mount VM Extension is now generally available across Azure regions. It automates iSCSI configuration, enables and optimizes MPIO, establishes target connectivity, and mounts storage volumes according to Everpure best practices. With support for both Linux and Windows VMs, the extension can be deployed during provisioning or added to existing VMs. It also integrates with ARM templates, Azure Bicep, and Terraform, making storage connectivity part of your infrastructure-as-code workflows. For Everpure Cloud Azure Native, a one-click mount workflow from the Azure Portal makes attaching storage even simpler. Everpure Cloud Dedicated customers can automate guest-side setup and reduce manual configuration at scale. Less scripting. Less configuration drift. A faster, more consistent path to usable storage on Azure VMs. Learn more: https://blog.everpuredata.com/news-events/announcing-general-availability-of-everpure-cloud-vm-extension/Everpure Cloud and Azure Red Hat OpenShift: Why it is worth a look
Moving VMs to Azure does not necessarily mean modernizing them. For many organizations, the challenge is to keep existing applications running while finding a practical path toward containers, without creating another separate infrastructure stack. This is where KubeVirt and Azure Red Hat OpenShift (ARO) become interesting. OpenShift Virtualization lets teams run VMs alongside containers on the same platform, so they can adopt Kubernetes-based operations gradually rather than rewriting every application up front. Storage matters in this equation too. Everpure Cloud provides persistent block storage for this environment, with Portworx CSI connecting it to OpenShift workloads. Thin provisioning, data reduction, and snapshots can help teams make better use of storage and protect data, while storage capacity can scale independently of compute. The actual savings will depend on the workload and its data characteristics. When evaluating ARO for VM modernization, these are good places to start: Everpure Cloud Azure Native Documentation Everpure Cloud Dedicated Documentation Why KubeVirt makes "move and improve" possible Everpure Cloud and Azure Red Hat Openshift The main takeaway: moving VMs and improving the platform do not have to be separate projects.09172026 - TechTalk Recap - Building an Efficient Storage Platform in Microsoft Azure ☁️
If you missed our latest TechTalks session, Michelle Berry, Nick Scuola, and I talked about a challenge that is top of mind for a lot of IT teams: moving workloads to Azure without creating a new set of cost, performance, and operational headaches. The practical takeaway? Cloud storage should give you more flexibility—not force you to overprovision capacity, rebuild your operational model, or choose between modernizing today and keeping the lights on. What you missed 👇 💸 Cloud costs are not always predictable. Capacity and performance can be tied together in traditional cloud storage, which can leave teams paying for more capacity than they need just to get the performance an application requires. ⚙️ Decouple capacity from performance. Everpure Cloud Azure Native lets teams independently tune capacity and performance, so they can align what they buy with what workloads actually need. 🧰 Keep operations familiar. The service is integrated with Azure tools, including the Azure portal, Marketplace, Azure Resource Manager templates, SDKs, and Azure CLI—helping teams deploy and manage storage without introducing another operational silo. 🔄 Modernize at your own pace. Whether you are running Azure VMs, Azure VMware Solution, or Azure Red Hat OpenShift, Everpure Cloud provides a common storage foundation for VMs and containers. 🛡️Efficiency should not come at the expense of data services. Data reduction, snapshots, cloning, encryption, and other enterprise storage capabilities are built into the platform. One of the most useful parts of the discussion was the practical deployment walkthrough. The core flow is straightforward: create the service, deploy a storage pool, and connect it to the application resource—all from the Azure environment teams already know. For organizations navigating cloud migrations, changing virtualization strategies, or container adoption, this gives you another option: move workloads without being locked into a one-size-fits-all storage model. Catch up on the session 🎥- HERE 💬 What is the biggest storage challenge your team is working through in Azure: cost control, operational complexity, VM migration, or container modernization? Share your perspective in the comments.Azure VM users — what’s your biggest storage challenge today?
Azure VM users — what’s your biggest storage challenge today? Cody_Hosterman shares some perspectives in the latest Pure Report podcast on Everpure Cloud Azure Native for Azure VMs. 🎙️ https://www.youtube.com/watch?v=TqJwrfWu7Vw What are you seeing in your environment?
Everpure Cloud: Building an Efficient Storage Platform in Microsoft Azure
September 17 | Register Now More organizations are migrating VMs and containerized apps into Azure and hitting a wall: native cloud storage wasn't built to provide the enterprise data services they rely on. Teams are lifting workloads into the cloud only to discover unpredictable costs, the inability to manage their storage from a unified platform, and data protection gaps. Join us to learn how to easily scale demanding, storage-heavy workloads without sacrificing data requirements or budget. With the right storage platform as your foundation, your hybrid cloud environment can deliver flexibility, cost savings, and operational simplicity. Key takeaways: Versatile workload support: Seamlessly run and manage mixed enterprise workloads on Everpure Cloud without compromising performance or flexibility. Streamlined Azure integration: Rapidly provision and scale Everpure Cloud using familiar, standard Azure-native tools and workflows. Unified management and security: Simplify data management across cloud and on-premises environments with consistent controls, governance, and built-in data protection. Optimized storage TCO: Significantly reduce overall enterprise storage costs through efficient resource utilization. Register Now!Ask Us Everything Recap: Bringing Enterprise Storage Simplicity to Azure
What happens when you take the enterprise storage capabilities IT teams rely on and deliver them as a fully managed, Azure-native experience? That question was at the heart of our latest Ask Us Everything, focused on Everpure Cloud Azure Native for Azure VMs. And judging by the questions from attendees, storage admins and cloud practitioners are thinking beyond simply moving workloads to Azure. They’re asking how to get there without trading familiar enterprise capabilities for higher costs, more operational overhead, or another collection of storage tiers to manage. Everpure experts David Stamen, Nick Scuola, and Joe Houghes dug into those questions—and the conversation surfaced several useful takeaways. “Azure already has storage. What makes Everpure different?” Cloud storage can mean navigating different offerings, tiers, feature sets, and regional availability. Joe contrasted that with the enterprise storage model Everpure customers know: capabilities delivered consistently through the Purity OS, rather than requiring administrators to continually determine which storage option provides which feature. Everpure Cloud for Azure Native brings capabilities including thin provisioning, deduplication, compression, performance, and availability into an experience designed to operate natively as an Azure service. Customers can deploy and consume it through Azure Marketplace, and get benefits they’re used to with their on-prem Everpure, all without managing the underlying storage infrastructure themselves. That distinction matters: IT gets enterprise-grade block storage, without turning cloud storage into another infrastructure management project. “How do I balance performance with cost?” Attendees naturally wanted to know about performance tiers—and the answer illustrated the service’s approach to simplicity. Instead of selecting among traditional on-prem array models or architecting around underlying infrastructure, customers simply choose the performance they need. The experts described a slider-based model for adjusting storage-pool performance, with Everpure handling everything behind the service. That abstraction becomes particularly valuable as Azure evolves. The panel discussed how underlying Azure storage improvements have previously delivered both performance gains and lower infrastructure costs. With a managed service, Everpure can incorporate infrastructure changes behind the scenes, rather than requiring customers to redesign their environments every time the cloud platform changes. As Nick summarized, the objective is the outcome: deliver the service level that customers need, while Everpure handles how it gets delivered. “Can cloud storage actually help reduce our Azure spend?” Cost was a recurring theme. We polled attendees, and half responded that they were “very concerned” about their Azure storage spend. One important lever that can help lower costs is data reduction. Thin provisioning, deduplication, and compression can reduce the physical capacity required, although results depend heavily on workload and data type. The experts noted that the majority of traditional application data benefit greatly from data reduction capabilities built into Everpure Cloud, while already-compressed or encrypted data naturally offer less reduction. The consumption model is simplified, too. Everpure Cloud for Azure Native combines the service and underlying infrastructure into a Marketplace purchase rather than separating software licensing from Azure infrastructure costs. Customers simply choose how much capacity and performance they need, and then receive it as one service and one bill. “Does this simplify my storage management job?” Perhaps the most important answer of the session: Yes! The experts described storage deployments that can be stood up in hours rather than turning implementation into a weeks- or months-long project. For example: once a storage pool is created, volumes can be connected to workloads using Azure VM extensions, simplifying the process of getting storage in front of an application. For experienced storage practitioners, that may be the biggest shift. Everpure Cloud for Azure Native isn’t about recreating every storage-management task in Azure. It’s about abstracting more of those tasks away so teams can concentrate on all their other work: applications, data, migrations, automation, and new initiatives. Or, as Nick put it during the session: the goal is to help free up customers to manage their applications and data—not their storage. That’s a cloud operating model storage admins can get behind. Check out this and all our other Ask Us Everything sessions. And, keep the conversation going by jumping into the Everpure Community.
