Should I Run Redis on VMware, and What Anti-Affinity Rules Do I Need?

Redis runs fine on VMware virtualization — it's a common, well-supported deployment pattern. But "runs fine" and "correctly configured for production resilience" are different claims, and the gap between them is usually invisible until a host failure takes down more Redis nodes than it should have. This post covers what a real production VMware/Redis infrastructure review found, and the specific configuration gaps that mattered.

Missing anti-affinity rules. This is the single most consequential gap, and it's exactly what a real production infrastructure review identified: a Redis cluster's VMs, hosted on a specific hardware chassis with a shared network backbone, had no anti-affinity rules configured — meaning nothing was actively preventing multiple Redis cluster nodes from landing on the same physical host.

Without anti-affinity rules, your VM scheduler is free to place multiple nodes of the same Redis cluster (or Sentinel group) on the same physical host purely based on resource availability, with no awareness that doing so defeats the entire purpose of running a distributed, fault-tolerant cluster. If that host fails, you don't lose one node — you lose however many landed there, potentially taking your cluster below quorum in a single event.

The fix: configure explicit VM-to-VM anti-affinity rules in vSphere (DRS anti-affinity rules) ensuring that no two nodes belonging to the same Redis cluster or Sentinel group can ever be scheduled onto the same physical host.

Yes, and it was flagged as a distinct risk in the same review: shared storage risk, alongside the missing anti-affinity rules, was specifically identified as a concern for the Redis VM infrastructure being assessed.

If your Redis VMs' underlying storage is provisioned from a shared storage pool without deliberate segregation, a storage-layer failure or performance degradation event can affect multiple Redis nodes simultaneously — the same fundamental problem as compute anti-affinity, but at the storage layer instead. The recommendation from that review specifically included storage segregation as part of the broader VM sizing and resilience guidance.

Two Linux kernel settings were specifically called out as needing review in a real Redis-on-VMware assessment: memory overcommit behavior and transparent huge pages (THP).

Memory overcommit. Redis's own documentation recommends specific vm.overcommit_memory kernel settings to avoid failed background save operations under memory pressure — this is a standard Redis operational best practice, but it's easy to miss in a VM context where the guest OS's kernel parameters aren't always part of a platform team's VM provisioning checklist the way VM-level CPU/memory allocation is.

Transparent huge pages. THP is a Linux kernel memory management feature that can cause Redis latency issues under certain conditions — it's a widely-documented Redis operational gotcha, and it was specifically checked as part of a real production Redis-on-VMware review, alongside memory overcommit settings, as part of validating whether the guest OS was correctly tuned for Redis's specific memory access patterns.

cat /sys/kernel/mm/transparent_hugepage/enabled

Practical check: run the command above on each Redis VM. If it shows [always] rather than [madvise] or [never], that's worth addressing per Redis's documented recommendations, since THP's memory allocation behavior can introduce latency spikes that are difficult to diagnose if you don't already know to look at this setting specifically.

Yes, and this is worth explicit kernel and hypervisor-level tuning rather than relying on defaults. Recommendations from a real Redis-on-VMware review specifically included kernel parameter tuning for memory management and snapshot behavior on hosts running Redis — reflecting that VM-level snapshot operations (routine for backup and DR purposes across most VMware environments) interact with Redis's memory model in ways that generic VM workloads don't need to account for.

Redis holds large amounts of data in memory and uses copy-on-write forking for background persistence operations (BGSAVE); a VM-level snapshot operation happening concurrently with Redis's own internal fork-based persistence can compound memory pressure in ways that aren't obvious from either system's documentation in isolation. If your Redis VMs are included in the same snapshot schedule as your general VM fleet without consideration for Redis's specific memory behavior, that's worth reviewing.

VM sizing recommendations from a real infrastructure review covered several dimensions beyond simple CPU/memory allocation:

• VM sizing relative to actual Redis working-set size and expected peak load, not generic sizing templates used for other application workloads
• Resource pinning where appropriate, to reduce the kind of CPU contention that can introduce latency variability in a workload as latency-sensitive as Redis
• Storage segregation, as covered above, to avoid shared-storage failure domains spanning multiple cluster nodes

The overarching theme from that review: Redis's operational characteristics (memory-resident data, latency sensitivity, background persistence forking) mean it benefits from deliberate, Redis-aware VM sizing rather than being treated identically to a stateless application VM.

Limitations in current monitoring practices were noted directly as part of a real infrastructure assessment, alongside the anti-affinity and kernel-tuning findings — meaning even when the infrastructure configuration itself was reasonable, visibility into how it was actually performing under real load was incomplete.

At minimum, monitor:

• Redis-level metrics (memory usage, ops/sec, latency, replication lag) via INFO or an exporter
• VM-level resource contention (CPU ready time, memory ballooning, storage latency) — since these can degrade Redis performance without Redis's own metrics clearly indicating a hypervisor-layer cause
• Anti-affinity rule compliance over time — DRS rules can be overridden or fail silently under certain cluster conditions, so periodically confirming actual VM placement matches your intended anti-affinity configuration is worth building into routine operational checks, not just configuring once and assuming it holds indefinitely

Redis-on-VMware is a legitimate, supportable long-term architecture, particularly for organizations with an established VMware operational practice and where migrating to a different platform isn't otherwise justified. The findings in this post are configuration gaps to close, not evidence that VMware is the wrong platform for Redis.

That said, if your organization is already planning a broader infrastructure migration — to a new data center, to Kubernetes, or to a cloud-managed Redis offering — that's a reasonable time to reassess the anti-affinity, storage, and kernel-tuning decisions covered here rather than simply cloning the existing (potentially misconfigured) setup into the new environment. A real infrastructure review of this kind was specifically conducted ahead of an upcoming data center migration, precisely to avoid carrying forward the same configuration gaps into new infrastructure. If VMware licensing changes are also part of what's driving that migration planning, that's worth reviewing separately — see our guidance on VMware licensing.

1. Confirm anti-affinity rules exist and are actually enforced for every Redis cluster/Sentinel group — don't assume DRS is handling this by default.
2. Check for shared storage risk — are your Redis VMs' disks provisioned from a pool shared with unrelated, potentially noisy workloads?
3. Verify kernel-level memory overcommit and THP settings on each Redis VM's guest OS.
4. Review your VM snapshot schedule for interaction with Redis's own background persistence behavior.
5. Audit your current monitoring for gaps between VM-layer and Redis-layer visibility — can you actually tell whether a Redis latency spike originated in Redis itself or in hypervisor-level resource contention?

Running Redis on VMware and want a configuration review before your next infrastructure change or migration? AceMQ works across both the Redis and VMware layers — from anti-affinity and kernel tuning to broader VMware licensing planning. We provide enterprise Redis support. Talk to an AceMQ engineer.