Day 2 Storage Operations After the VMware Exit: Snapshot, DR, and Observability on Disaggregated NVMe/TCP

The post from June 26 on overlay storage covered the economics of the migration storage decision: why replacing vSAN with another hyper-converged overlay layer on Kubernetes recreates the same coupling problems teams tried to leave behind. Teams that chose disaggregated NVMe/TCP storage now face the follow-on question: how do you operate that storage layer day to day?

This question is more concrete than it appears. vCenter handled three categories of storage operations automatically: point-in-time recovery via VMware® snapshots, replication and disaster recovery through vSphere Replication and Site Recovery Manager, and storage health observability through the vCenter performance dashboard. None of these transfer to Kubernetes automatically. The Kubernetes API does not snapshot volumes, does not replicate them between sites, and does not expose per-volume IOPS metrics natively. Platform teams that complete the migration and decommission vCenter will need to rebuild that operational layer, unless the storage layer they chose provides it natively.

This guide covers all three Day 2 operation areas: snapshots and point-in-time recovery, cross-zone replication and disaster recovery, and storage observability. For each, it explains what vCenter provided, where the gap opens in a Kubernetes environment without a deliberate storage strategy, and how disaggregated NVMe/TCP via simplyblock closes it.

What Day 2 Storage Operations VMware Teams Lose When They Leave vCenter

The vCenter operational model is comprehensive by design. Storage administrators work with a single control plane that covers virtual machine snapshots through the VMware snapshot mechanism, policy-based replication to a secondary site using vSphere Replication, failover orchestration via Site Recovery Manager, and real-time IOPS, throughput, and latency charts per virtual disk visible in the vCenter performance dashboard. These capabilities are bundled with the vSphere license and require no separate tooling to configure.

When a team migrates workloads to Kubernetes and decommissions vCenter, all three layers become the team’s problem to solve. Kubernetes core manages compute scheduling, not storage protection. The CSI specification provides a driver interface for volume lifecycle operations but does not mandate snapshot scheduling, replication topology, or metrics export. What a team gets from Kubernetes out of the box is volume provisioning, mount, resize, and basic VolumeSnapshot API support, with the storage driver responsible for the actual implementation.

Platform teams that deploy overlay storage to fill the gap inherit a second management layer without necessarily gaining all three Day 2 capabilities. Longhorn provides its own snapshot mechanism and recurring snapshot schedule, but cross-site replication requires a separate tool. Ceph-Rook supports asynchronous mirroring between clusters, but setup requires RBD mirroring peer configuration, and monitoring integration is a manual step. Overlay storage solves the persistent volume provisioning problem but does not solve the full Day 2 operations problem.

Disaggregated NVMe/TCP via simplyblock is designed to close all three gaps at the storage layer level: snapshots, replication, and metrics, without requiring a second overlay or a separate management plane.

CSI Snapshots on simplyblock: Point-in-Time Recovery After the VMware Exit

The CSI VolumeSnapshot API provides a standard interface for creating persistent volume point-in-time copies in Kubernetes. A VolumeSnapshotClass defines which driver handles the snapshot operation. A VolumeSnapshot object references the source PVC and triggers the snapshot. The result is a VolumeSnapshotContent object that can be used as the data source for a new PVC.

simplyblock’s CSI driver implements the VolumeSnapshot API natively. Snapshots are space-efficient: the driver uses copy-on-write semantics at the NVMe layer, so a snapshot does not immediately duplicate the volume’s full capacity. On a disaggregated NVMe/TCP storage cluster, the snapshot operation happens entirely at the storage layer without data movement to compute nodes.

Crash-consistency is guaranteed by default. This is the same consistency model vSAN provides without VMware Tools installed: I/O is quiesced at the block device level, producing a recoverable but not application-consistent state. For databases and stateful applications, application-consistent snapshots require pre/post hooks that flush in-flight writes before the snapshot triggers. The simplyblock CSI driver supports pre-snapshot and post-snapshot annotations on the PVC, allowing a backup coordinator to run an application quiesce command before the block-level snapshot fires. A MySQL pod using Percona XtraBackup, a Redis pod issuing BGSAVE, or a PostgreSQL pod running pg_start_backup() can all be wired into this flow.

For multi-volume workloads that require point-in-time consistency across more than one disk, such as a database data directory and its WAL volume, Kubernetes group snapshots provide a mechanism to snapshot multiple PVCs as a single atomic operation. simplyblock’s CSI driver supports the group snapshot extension.

The recovery path is straightforward: create a new PVC with the VolumeSnapshotContent as the data source. The new PVC provisions as a clone of the snapshot state, mounts to a replacement pod, and resumes from the point-in-time state. No vCenter console required; the entire flow is YAML-driven and compatible with GitOps tooling.

Replacing vSAN’s snapshot and DR model in Kubernetes requires a storage layer that provides these capabilities natively. Talk to a storage architect to map your current vSAN snapshot and replication policies to simplyblock’s Day 2 operations model. Talk to a storage architect

Cross-Zone Replication and Disaster Recovery for Kubernetes Persistent Volumes

vSphere Replication copies virtual machine disks to a secondary site asynchronously, with configurable RPO intervals. Site Recovery Manager adds orchestrated failover: it brings up a protected set of VMs in sequence at the recovery site, respecting boot order dependencies. These are the two capabilities most storage administrators miss first after a VMware exit.

simplyblock provides cross-zone replication as a native capability of the storage cluster. A volume can be configured with a replication target: a second availability zone or a second simplyblock cluster in a different physical location. The replication operates asynchronously at the block layer, tracking changed regions since the last sync cycle. RPO is configurable, and RTO depends on volume size and the bandwidth available between zones.

The Kubernetes integration uses the VolumeReplication custom resource from the CSI add-ons framework. A VolumeReplication object binds a PVC to a replication policy and exposes the current replication state, Primary, Secondary, or Resync, as a Kubernetes status field. A secondary copy in the recovery zone can be promoted to Primary when a failover event is declared, making it mountable by a pod in the recovery cluster.

For teams migrating KubeVirt workloads, the replication model maps directly to what vSphere Replication provided for VMs: the storage layer protects the disk, and Kubernetes reconciliation handles bring-up order. The KubeVirt backup and restore guide covers tooling that operates on the same volume objects.

Cross-zone replication testing is non-disruptive: the secondary copy can be mounted read-only to verify data integrity without interrupting the primary write path. This is equivalent to vSphere Replication’s test recovery mode and closes a gap that most overlay storage tools leave to external backup tooling. For organizations with formal Kubernetes disaster recovery requirements, the combination of VolumeReplication status monitoring and periodic test failovers provides an auditable DR posture that does not depend on vCenter at all.

Storage Observability Without vCenter: Metrics in Kubernetes

The vCenter performance dashboard provides per-disk IOPS, throughput, and latency charts for every virtual machine in the cluster. Storage administrators use these charts to detect bottlenecks, right-size volumes, and correlate application-level latency with storage-level behavior. Losing vCenter removes this visibility at the exact moment, during and after migration, when storage behavior is most likely to change.

Kubernetes does not include storage observability in the base distribution. The metrics API exposes node-level CPU and memory; volume I/O metrics require instrumentation at the storage driver level. Overlay storage systems approach this differently: Longhorn exposes Prometheus metrics for volume IOPS and throughput from its manager pods, and Ceph-Rook integrates with the Ceph Manager Prometheus module. Both solutions add per-volume metrics visibility, but instrumenting them requires configuring a Prometheus scrape target and mapping volume metrics to the pods that use them.

simplyblock exports Prometheus metrics natively from the storage cluster, without requiring a sidecar on the compute side. Metrics include IOPS (read and write separated), volume throughput in MBps, NVMe/TCP connection latency per initiator, queue depth and I/O wait, replication lag when cross-zone replication is configured, and snapshot space consumption.

These metrics flow into a standard Prometheus scrape endpoint. A Grafana dashboard tuned to these metrics can replicate the per-volume visibility that vCenter’s performance charts provided, with the added benefit of Kubernetes-native alert routing: AlertManager rules can page on-call teams when a specific PVC’s IOPS drop below a threshold, correlating the storage metric with the Kubernetes object name and the pod using the volume.

For teams running both Kubernetes and legacy VMs during a phased migration, the simplyblock storage cluster serves both simultaneously. Storage metrics for volumes mounted by Kubernetes pods and volumes attached to KubeVirt VMs appear in the same Prometheus export, providing a unified observability layer that does not require the vCenter dashboard to remain live.

Day 2 Operations Compared: vSAN Plus vCenter vs. Disaggregated NVMe/TCP

The table below maps the three Day 2 operational areas against what vSAN with vCenter provides, what overlay storage on Kubernetes adds, and what simplyblock delivers as native storage-layer capabilities.

Table 1: Day 2 storage operation coverage across vSAN, overlay storage, and simplyblock disaggregated NVMe/TCP.

The post covering vSAN cost economics examined the licensing model. This operational comparison addresses the other side of the evaluation: whether a replacement storage layer can maintain the Day 2 operational posture that vCenter built for VMware shops over the last decade. The coverage above shows that disaggregated NVMe/TCP provides all three capabilities natively, without requiring a second overlay or a third-party management plane.

Questions and Answers

What Day 2 storage operations does vCenter handle that teams lose after a VMware migration?

vCenter manages three categories of storage operations that Kubernetes does not provide by default: point-in-time volume snapshots through the VADP snapshot mechanism, cross-site replication and failover orchestration via vSphere Replication and Site Recovery Manager, and per-disk observability through the vCenter performance dashboard. When a team migrates to Kubernetes and decommissions vCenter, platform engineers become responsible for each of these. A storage layer that does not provide them natively requires additional tooling assembled from multiple projects.

How do CSI snapshots work in simplyblock, and can they be application-consistent?

simplyblock’s CSI driver implements the Kubernetes VolumeSnapshot API. A VolumeSnapshotClass defines the driver and its parameters; a VolumeSnapshot object referencing a PVC triggers the operation at the storage layer using copy-on-write semantics. The default is crash-consistent. Application-consistent snapshots require pre/post hook annotations on the PVC, which trigger application-level quiesce commands such as MySQL’s flush-and-lock, Redis’s BGSAVE, or PostgreSQL’s pg_start_backup() before the block-level snapshot fires. The resulting VolumeSnapshotContent can provision a new PVC as a point-in-time clone.

How does simplyblock handle disaster recovery and cross-zone replication for Kubernetes persistent volumes?

simplyblock replicates volumes asynchronously to a configured secondary zone or cluster at the block layer. The Kubernetes integration uses the VolumeReplication custom resource from the CSI add-ons framework: a VolumeReplication object binds a PVC to a replication policy and exposes replication state, Primary, Secondary, or Resync, as a Kubernetes status field. A secondary copy can be promoted to Primary during a failover event, making it mountable in the recovery cluster. DR testing is non-disruptive: the secondary volume can be mounted read-only for integrity checks without interrupting the primary write path.

How can platform teams observe storage IOPS and latency in Kubernetes without vCenter?

simplyblock exports per-volume Prometheus metrics natively from the storage cluster: IOPS (read and write separated), throughput in MBps, NVMe/TCP connection latency, queue depth, and replication lag. These metrics feed into a standard Prometheus scrape endpoint and can be visualized in Grafana or routed through AlertManager. The metrics are keyed by Kubernetes PVC name and namespace, allowing teams to correlate storage-level behavior with specific applications without a separate monitoring agent on compute nodes.

Does simplyblock require vCenter for any Day 2 operations?

No. simplyblock operates independently of vCenter and vSphere. The storage cluster is managed through its own API and CLI, with Kubernetes integration handled through the CSI driver and, for replication, the VolumeReplication CRD. Teams that decommission vCenter as part of a VMware exit retain full snapshot, replication, and observability capabilities through Kubernetes-native tooling. The storage layer does not depend on any VMware component to remain operational.