Author
Eleonora Manolova
Record
DR-02
Product
vSphere Lifecycle Manager
Span
4 months
Status
Shipped

Cluster Image Lifecycle & Compatibility Management

In clusters that mix hardware generations, one incompatible driver or firmware version can fail an upgrade. I designed workflows that let administrators find the conflict, understand its root cause and fix it before the update runs.

Role
Product designerOne of several; owned the heterogeneous cluster workflows
Span
4 months
Scope
Platform-widevSphere Lifecycle Manager
Research
4 sessions45 min, think-aloud, plus feedback logs
Prototype
Open in Figma (opens in a new tab) ↗
Fig. 0Illustration: one compatibility check across a 96-host cluster, traced to the layer that failed.

§1Context

Organizations use vSphere to run large fleets of virtual machines on physical servers. Instead of managing each server on its own, administrators group hosts into clusters of dozens or hundreds. Those hosts run critical workloads and have to stay stable, secure and compatible.

Every host needs a compatible combination of operating system version, drivers, firmware and hardware. vSphere Lifecycle Manager lets administrators define the desired configuration once, as an image, and apply it across the cluster.

This project was about heterogeneous clusters, where different hardware generations sit side by side. Different groups of hosts may need different images, and compatibility has to be checked across every layer of the stack.

§2Complexity

  • clusters with dozens or hundreds of hosts
  • several hardware generations in the same cluster
  • compatibility rules across drivers, firmware and devices
  • certification constraints defined by the platform
  • lifecycle operations that affect production workloads
One host, five layers
  1. Image OS version
  2. Driver per device
  3. Firmware not certified
  4. Device PCI, disk, NIC
  5. Certification platform rules
One cluster, 32 hosts
CompatibleNeeds review (!)Incompatible (×)
Fig. 1Illustration. An issue in one layer of one host has to be visible at cluster scale, without inspecting hosts one by one. 3 of 32 hosts incompatible, 2 need review.

§3Process

Start from what admins already reported

The project began with feedback VI administrators had logged inside vSphere. I collected and analyzed all of it to find pain points and gaps before any design work, then wrote use cases and user stories from that foundation.

Map constraints before designing

Early conversations with product and engineering set a shared scope, surfaced technical constraints and identified unhappy paths from the start. I mapped every affected view to understand relationships across the platform and reviewed existing vSphere and VMware patterns to stay consistent.

Validate the concept with the people who run clusters

Four 45-minute sessions with senior VI administrators combined exploratory interviews with structured concept validation. Participants worked through task scenarios thinking aloud, which exposed their decision patterns and friction points directly.

Iterate toward feasibility

From wireframes through three rounds of high-fidelity iteration, shaped by design critiques and engineering reviews focused on technical feasibility.

§4Challenges

C1

Make compatibility understandable

Issues come from relationships between devices, drivers, firmware and certification rules. Admins need to know why a host is incompatible and which layer caused it, in words they can act on.

C2

Find affected hosts at scale

With hundreds of hosts, admins must see quickly how widespread a problem is, without opening each host.

C3

Manage several images

Different host groups may need different images. The relationship between images and hosts had to stay clear without adding cognitive load.

C4

Keep upgrades safe

Applying an image is high impact. Mismatches lead to failed upgrades, unsupported configurations or instability, so risk had to surface before any change.

§5Role

The work sat in the vSphere Lifecycle Manager team, as part of a broader push on lifecycle management and hardware compatibility. Several designers shared the initiative. Reviews and engineering alignment were collaborative, while each designer owned specific workflows end to end.

I owned cluster image management in heterogeneous environments:

  • workflows for managing cluster images in heterogeneous clusters
  • interaction patterns for surfacing and resolving compatibility issues
  • hardware compatibility views, including PCI device and disk compatibility
  • alignment with engineering on system constraints and backend capabilities
  • consistency across lifecycle workflows in cross-team discussions

The team was spread across time zones, so much of the collaboration was asynchronous and needed careful coordination around complex technical constraints.

§6Design response

Instead of showing compatibility checks as isolated warnings, I built them into the lifecycle workflow itself. Four patterns work together:

D1

Compatibility visible across hosts

Status indicators inside host management views show which hosts need attention and how far the issue reaches, with a direct path to the details.

Removes
Manual inspection of individual hosts.
D2

Hardware investigation

Dedicated views list the devices on each host with their firmware and driver versions and certification status.

Removes
Reacting to warnings without knowing the cause.
D3

A path from insight to fix

Clear navigation between compatibility details and image management, so admins can review affected hosts and adjust the image or hardware mapping.

Removes
Jumping between unrelated views to resolve one conflict.
D4

Risk before the irreversible step

Compatibility constraints appear early, and potential risks are stated before an image is applied.

Removes
Failed upgrade attempts and unsupported configurations.

§7Outcome

The compatibility workflows shipped as part of the platform's cluster image management. Administrators can now:

  • identify incompatible hosts faster
  • understand the root cause of a compatibility issue
  • inspect the hardware components involved
  • resolve issues before a lifecycle operation runs

Compatibility checks, image management and lifecycle operations now work as one system instead of separate features, which strengthens support for environments where hardware diversity is normal.

§8Reflection

Infrastructure constraints are built into the experience whether you design for them or not. The work was translating relationships between hardware, firmware, drivers and certification rules into steps an administrator can understand and act on.

The later a constraint shows up, the more expensive it is to solve.

Spec mode

Type size / line height, weight, text contrast against WCAG AA, spacing, and keyboard order. Measured live from this page. Esc to close.