Alternative Virtualization Meet-Up at //Accelerate
Our company like many others have parted ways with VMWare. We decided not to renew this last April and are currently running unsupported/perpetual as we look for a replacement hypervisor. Costs on a 7000+ core renewal came in at about 5x what we paid in previous years. Just a little backstory, but this post is not to discuss that. For hardware we currently run Cisco ACI, Cisco UCS and Pure Storage in a converged architecture. What Cisco/Pure call Flashstack. 4 Sites, 200+ blades, Mix of 14 //x and //c Arrays. We are heavy Vvol users today. We have narrowed our search down to Proxmox, XCP-NG, and OpenShift Virtualization. Successes with Proxmox have been great, deployment (iSCSI Boot), automation, migration, etc. Winning so far. XCP-NG, similar to Proxmox. Some issues with Migrations. But overall working. OpenShift, just started vetting. Have a workshop scheduled with RedHat to really test out and see if the product is a good fit. Would require Portworx. Now to what I am wondering, would any of you that will be attending Pure //Accelerate be interested in a meet-up to network and discuss the trials and tribulations with these or other alternative hypervisors on Pure Storage? I am happy to present my decision process, success criteria, testing results and implementation configuration for each. If we get enough people I can ask my AE/SE to see if Pure would allow us use of a breakout meeting room. If interested let me know, I would prefer to keep this vendor neutral other than Pure, as we would not be going to a Pure conference if not interested or already running Pure Storage.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 GuideOur 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.09222026 - Demo Recap - From CSI to Snapshots—Seamless VM Management on Red Hat OpenShift
If you missed our latest Expert Led Demo, Matt Webb and I walked through how teams can manage virtual machines on Red Hat OpenShift while using Everpure FlashArray through CSI. The goal was not to turn every VMware administrator into a Kubernetes expert overnight. It was to connect the dots: many familiar VM operations still exist, but the platform uses different objects, policies, and automation to get the job done. What you missed 👇 🗺️ A familiar operating model with new terminology. Worker nodes, StorageClasses, PersistentVolumeClaims, live migration, and VirtualMachine objects map closely to concepts many VMware administrators already know. ⚙️ CSI automates the storage plumbing. A StorageClass defines the storage policy, while the CSI driver provisions volumes, maps them to the right node, and handles the day-to-day attachment work. 🔀 Choose the right storage-consumption model. Teams can use Portworx Enterprise volumes for flexible, software-defined storage services across mixed infrastructure, or FlashArray Direct Access when they want array-level data services and visibility in Purity. 🚀 Keep VM operations simple. In the demo, we showed a live compute migration, created a VM from a template, and used the OpenShift console to work through familiar virtualization tasks. 📸 Use array-based snapshots for fast recovery. With CSI configured, snapshots are FlashArray-based. The demo showed taking a snapshot, deleting data, restoring the VM, and bringing the data back quickly. 🧳 Plan migrations around your environment. Migration Toolkit for Virtualization can support cold migrations, while storage-offload migration can use SCSI XCOPY when source VMware storage and OpenShift storage share the same FlashArray. The practical takeaway: storage policies and automation remove much of the manual LUN, mapping, rescan, and multipathing work. That gives virtualization and platform teams more time to focus on the workload—not the plumbing behind it. 🎥Catch up on the demo HERE 🎥 💬 What is the biggest question your team has about running VMs on OpenShift: migration, storage policy, snapshots, or day-two operations? Share it in the comments.
