SRM, vSphere Replication, and VLR: Untangling the 9.0.4 Upgrade Path

Some upgrades are difficult because the technology is complicated.

Others are difficult because the path is not as obvious as it should be.

My recent VMware Live Recovery 9.0.4 convergence landed in that second category. Once the process clicked, the upgrade path made sense: stage Site Recovery Manager and vSphere Replication to the required 9.0.2.2 baseline, deploy the new VMware Live Recovery appliance, and converge the legacy appliances into the new model.

The confusing part was getting there.

The product names changed. The version strings did not tell the whole story. The build numbers mattered more than the UI labels. The documentation referenced appliance deployment media, but the download showed up as an ISO. And after convergence, the real validation was not just whether the appliance deployed. It was whether the vCenter plugin, replication path, pairing, certificates, and recovery objects all behaved from both sides.

This is not meant to be a click-by-click runbook. It is a field note from the upgrade path: what confused me, what broke, and what I would check first next time.

The naming is half the battle

The first source of confusion was the naming.

In the environment, the legacy components were still familiar:

Name used here	Meaning
SRM	Site Recovery Manager, the legacy recovery orchestration appliance
VR	vSphere Replication, the legacy replication appliance
VLR	VMware Live Recovery, the newer combined appliance model

Broadcom documentation may refer to Site Recovery Manager as VMware Live Site Recovery, while VMware Live Recovery is the newer appliance model used for the combined recovery appliance path. That is not just a branding issue. It affects how you read the documentation, identify downloads, validate versions, and explain the work to another team.

Before starting, I would make the terminology explicit:

Terminology Used in This Article

SRM
Legacy Site Recovery Manager appliance

VR
Legacy vSphere Replication appliance

VLR
New VMware Live Recovery appliance

Simple, but it helps.

Build numbers matter more than version strings

The next issue was version clarity.

The UI may still show 9.0.2, but that does not necessarily tell the whole story. For this upgrade path, the build number is what I would validate.

Component	Required pre-convergence build	Operational meaning
vSphere Replication	24628359	vSphere Replication 9.0.2.2
Site Recovery Manager / Live Site Recovery	24639343	SRM / VLSR 9.0.2.2
VMware Live Recovery appliance	24963726	VMware Live Recovery 9.0.4

This became important because not every 9.0.2 appliance was equal. One vSphere Replication appliance may be at the correct 9.0.2.2 build, while another appliance still reports 9.0.2 but sits at an older build and still needs to be patched.

The lesson: do not stop at the version string. Inventory every SRM and vSphere Replication appliance and validate the build numbers before moving forward.

9.0.4 is not a normal in-place update

The biggest conceptual shift was realizing that this was not a traditional “mount ISO, click update, reboot” upgrade of the existing SRM and vSphere Replication appliances.

For this path, the move to VMware Live Recovery 9.0.4 is a convergence:

The legacy SRM and VR appliances must first be updated to the required 9.0.2.2 baseline. After that, a new VMware Live Recovery appliance is deployed and the legacy appliances are converged into it.

That distinction matters. If you approach VLR 9.0.4 like a normal in-place update of the older SRM/VR appliances, you are starting down the wrong path.

The ISO/OVF surprise

This was one of the more annoying field discoveries.

The documentation referenced deploying the new appliance using OVA/OVF-style deployment media. In the download portal, the obvious item presented as an ISO.

The key detail was that the deployable appliance files were inside the ISO.

That may be obvious after the fact, but it was not obvious during prep. If a KB says to deploy an appliance using OVA/OVF media and the portal only appears to show an ISO, it is easy to assume you are missing an entitlement or looking in the wrong product area.

The practical field note is this:

Do not mount the VLR 9.0.4 ISO to the old SRM or vSphere Replication appliances as an in-place update. Use the ISO to access the deployable appliance files, deploy a new VLR appliance, then run the convergence workflow.

That one sentence would have saved time.

One VLR appliance per site/vCenter

Another point worth making clear: treat the VLR appliance placement like the old SRM model.

For a typical two-site design, each site gets its own VLR appliance, and each VLR appliance is registered or associated with the local vCenter for that site.

Two-Site VLR Model

One VLR appliance per site / vCenter

Site A

vCenter

Local site registration

↓

VLR Appliance

One appliance for Site A

⇄

Site Pairing

Site B

vCenter

Local site registration

↓

VLR Appliance

One appliance for Site B

Key point: deploy and register one VLR appliance per site/vCenter, then establish Site Pairing between the two sites.

Do not assume one VLR appliance covers both sides of the recovery pair. The appliance belongs to the site/vCenter it is deployed for, and the recovery relationship is established through the supported workflow.

Time, DNS, and certificates all have to agree

This was one of the biggest troubleshooting lessons.

During the process, I hit a SAML-style authentication failure that looked roughly like this:

Field Note

Identity and trust matter

Time / NTP

SAML authentication is time-sensitive.

DNS / FQDN

Names need to resolve consistently.

Certificate CN/SAN

Use the appliance FQDN, not short name or IP.

Lesson: Do not validate only that :5480 works. Also validate that vCenter can trust and load the plugin using the appliance FQDN.

The root cause of the authentication failure was time-related. The appliance time was off. Once time/NTP was corrected, the admin UI and authentication path started behaving again.

That made sense. SAML is time-sensitive. If vCenter, SSO, SRM, VR, or VLR appliances disagree on time, authentication can fail in ways that look much more complicated than they really are.

But time was not the only identity issue.

I also had to correct the appliance certificate identity so the certificate subject used the FQDN instead of a short name. After that, additional plugin-access issues improved.

That is the bigger lesson:

The plugin path is sensitive to identity. Time, DNS, FQDN, and certificate subject information all need to line up.

If the VLR appliance is reachable at :5480, that only proves the appliance management interface is reachable. It does not prove the vCenter plugin path is healthy. The vCenter plugin still depends on registration, extension metadata, certificate trust, browser/session behavior, and service health.

Before blaming the plugin, I would check:

Is appliance time synchronized with vCenter/SSO?
Does the VLR FQDN resolve correctly?
Does the certificate use the FQDN rather than a short name or IP?
Is vCenter being accessed by FQDN?
Do the vCenter extension registrations point to the expected VLR appliance?
Has the vSphere Client service or browser session been refreshed after registration/certificate changes?

This was one of those issues where everything looked “mostly right” until vCenter tried to load the plugin. That is where the short-name certificate started to matter.

Post-convergence validation is not optional

After convergence, I would not call the change complete just because the appliance deployed and the workflow finished.

The validation needs to happen from the vCenter plugin path, not only the appliance admin page.

At minimum, I would validate:

VLR appliance admin UI loads at https://<vlr-fqdn>:5480
VLR is registered to the correct local vCenter
vCenter Site Recovery / VLR plugin loads
vSphere Replication shows healthy
VMware Live Site Recovery / recovery services show healthy
Site pairing is connected
Replications are visible
Protection groups are visible
Recovery plans are visible
A non-disruptive test or replication validation succeeds

I saw cases where the local site looked healthy while the remote site still showed inaccessible. That is exactly why both sides need to be validated before declaring victory.

When the plugin does not load

One of the more frustrating failure modes was this:

Troubleshooting Pattern

Admin UI works, but the vCenter plugin does not

Confirmed

VLR appliance admin UI loads

https://<vlr-fqdn>:5480

Issue observed

vCenter Site Recovery / VLR plugin

Does not load correctly

Check first

DNS / FQDN: confirm vCenter and the VLR appliance resolve by FQDN, not just IP.
Certificate trust: confirm the VLR certificate CN/SAN matches the FQDN used by vCenter.
Extension keys: confirm vCenter extension registrations point to the correct VLR appliance.
VLR services: confirm the VLR backend services are running and healthy.
vSphere UI cache: restart vsphere-ui or use a clean browser session if plugin registration changed.

That can send you down the wrong path if you assume the appliance is completely fine because the admin UI works.

The places I would check first:

Time/NTP — especially if SAML or authentication errors appear.
DNS/FQDN — avoid short names and IP-based access paths.
Certificate identity — make sure the appliance certificate aligns with the FQDN.
vCenter extension registration — confirm extension entries point to the new VLR appliance, not an old SRM/VR appliance.
vSphere UI refresh — restart or refresh the vSphere Client service if the plugin appears stale.
Replication NIC configuration — for certain post-convergence VR plugin issues, validate the hbrsrv-nic.xml path called out in Broadcom guidance.

Be careful with extension cleanup. Do not randomly remove vCenter extensions just because an extension key looks suspicious. Validate what the extension points to first. Removing the wrong active extension can make the situation worse.

What I would do before the next window

If I had to run this again, I would prep the window with a short checklist:

Inventory every SRM and vSphere Replication appliance.
Validate build numbers, not just versions.
Confirm the required 9.0.2.2 baseline before convergence.
Stage the VLR 9.0.4 deployment media ahead of time.
Confirm whether the deployable appliance files are inside the ISO.
Take snapshots before each major phase.
Confirm NTP/time on every appliance.
Confirm DNS and certificate identity use FQDNs.
Deploy one VLR appliance per participating site/vCenter.
Validate the plugin from both sides before closing the change.

None of that is complicated, but missing any one of those checks can cost real time during a maintenance window.

Final thoughts

The VMware Live Recovery 9.0.4 convergence path worked. The challenge was not the convergence itself as much as the surrounding details: naming, builds, media packaging, identity, certificates, and plugin behavior.

Once those pieces were clear, the process became much more manageable.

The main takeaway is simple:

This is not just an upgrade. It is a convergence into a new appliance model.

And with that mindset, the rest of the process makes a lot more sense.