VCF 9 vs the vSphere We All Know: What Actually Changes for Operations

Now that VCF 9 has been out for a little while, let’s clear some things up when it comes to the differences between it and the long-time winner of the virtualization world, VMware vSphere.

At first glance, VCF looks like vSphere with the addition of NSX and Automation. In reality, VCF changes the operational aspects of the entire infrastructure… for the better.

The first big change is how you install VCF versus vSphere, but that’s not where the confusion usually comes from—it comes after the initial deployment. Most people have spent years operating and maintaining vSphere environments, so once it comes time to operate a VCF 9 environment, things can get confusing. This is largely because VCF Operations takes over much of what the vCenter Server Appliance used to handle, while also combining multiple other facets into a single, centralized management interface.

The biggest shift is moving from a component management mindset to a platform management mindset. In traditional environments, you manage ESXi, NSX, and vCenter individually. In VCF, you manage domains that encompass all of these pieces through SDDC Manager.

Because of this, there’s less of the “just SSH in and fix it” approach and more reliance on the platform to avoid interfering with lifecycle processes. Where you once felt full ownership over individual components, now you own the platform and manage it at a higher level.

DAY 2 Operations

What feels different… like actually…

Workload Domain Mindset

In VCF 9, everything revolves around domains:

Management Domain – Houses all VMware applications such as Operations, NSX, SDDC Manager, Automation, Logs, etc.
Workload Domain(s) – Houses your organization’s applications. You can have multiple workload domains in a single VCF instance.

When expanding your environment, it’s no longer just about adding hosts—it’s about expanding domains and scaling them while maintaining consistency across all domains.

Host Lifecycle (Host Profiles Previously)

The traditional way of keeping hosts updated and maintaining baselines has changed.

Instead of patching ESXi individually and upgrading vCenter separately, everything is now tied to bundles, prechecks, and SDDC workflows.

What used to be Host Profiles is now Host Configuration Management, which automates the lifecycle of hosts from the moment they are commissioned into the environment.

Networking

In traditional vSphere environments, NSX was optional—and many customers didn’t use it, often due to knowledge gaps or the time required to learn it.

In VCF, NSX is mandatory. Even if you only want the vSphere portion, NSX will still be deployed.

In my opinion, that’s not a bad thing. Software-defined networking (SDN) is only becoming more relevant, and this is VMware by Broadcom’s solution. If you’re already paying for it and it’s required, you might as well learn it.

Operational differences include:

Segments replacing VLANs (similar concept—if you understand VLANs, you’ll understand segments)
Virtual routing with Tier-0 (T0) and Tier-1 (T1) routers
North/south traffic (in/out of the environment)
East/west traffic (internal application communication)

Troubleshooting also shifts toward internal routing paths and the distributed firewall (formerly DFW, now vDefend), if in use.

Identity and Access

In traditional vSphere environments, most organizations relied on Active Directory via LDAP. Some used external identity providers for MFA, but not widely until recent years.

With VCF, there’s a much stronger reliance on SSO configurations and external IDPs for MFA, ensuring a more secure identity solution.

This also ties into Certificate Management. Certificates are now centrally managed for all VMware applications—including hosts—through VCF Operations. This simplifies management significantly, especially with built-in renewal automation. At that point, your role becomes more about monitoring than manually managing certs.

Lifecycle Management

In traditional vSphere environments, patching could be done individually. That’s no longer the case.

Lifecycle management in VCF is driven by bundles and predefined workflows. If even a small issue fails a precheck, the update will not proceed until it’s resolved.

What this enables is consistency across the entire environment. It helps eliminate scenarios where multiple components are running completely different versions.

The bundle-driven approach simplifies what used to be a fragmented process. It removes guesswork like:

“What version should this be on?”
“Is this compatible with that?”

Bundles are validated as a full stack before release, making upgrades more predictable and manageable. This is where VCF’s consistency really shines.

The Unexpected (Good Things)

One unexpected benefit of this lifecycle approach is that it drives better operational discipline and nearly eliminates configuration drift.

It can feel restrictive at first, but over time, as teams spend less effort figuring out compatibility and patching strategies, it becomes clear that managing domains is actually easier.

Prechecks also help catch issues early, such as:

Certificate problems
Password drift
Infrastructure health issues

Instead of reactive troubleshooting, it becomes proactive validation.

Overall, lifecycle management in VCF is about keeping the entire environment in a continuously healthy state.

Value Added – (Tools formerly known as Aria)

The inclusion of the Aria suite in VCF licensing can feel overwhelming at first, especially since many traditional vSphere environments didn’t use it—either due to lack of familiarity or cost justification.

That said, these tools can significantly improve your infrastructure.

VCF Operations (formerly Aria Operations)

This is now a mandatory component and the primary interface for managing your environment.

It provides:

Visibility
Management
Planning

All in one UI.

You can see not only the current health of your environment but also trends in resource usage and contention.

Features like “What-If Scenarios” allow you to simulate adding workloads and determine whether your environment can handle them without causing issues.

VCF Operations for Logs (formerly Log Insight)

This centralizes logs from all VCF components into one place.

Even better, you can view logs directly from the main Operations UI, reducing the need to jump between tools unless deeper analysis is required.

This consolidation alone saves a significant amount of time.

Value That Becomes Apparent Over Time

Some features don’t seem valuable at first, usually due to familiarity gaps:

Alerts – Actionable directly from the alert itself
Logs – Easier navigation than before
Infrastructure visibility – Much broader and centralized

Not every tool needs to be fully utilized. Most teams focus on:

Visibility
Troubleshooting
Capacity Planning

And for most, that’s where the biggest value lies.

Learning Curve with VCF

There is a learning curve, especially when coming from traditional vSphere.

Most of it comes from the mindset shift.

You move away from quick, manual fixes and toward platform-driven workflows. It may feel slower initially, but over time it leads to:

More consistent environments
Fewer issues
Cleaner lifecycle management

Now – The Bigger Picture

Everything in VCF is more connected. This provides better visibility across the entire infrastructure instead of managing isolated systems.

This connectedness also makes troubleshooting easier.

NSX – It’s Not So Scary

NSX can feel intimidating, especially since it introduces deeper networking concepts into VMware environments.

But once you understand:

Segmentation
Routing
Traffic flow

You unlock significantly more flexibility than traditional networking approaches.

SDN isn’t new—and it’s only becoming more important over time.

A Good Plan Leads to Success

With VCF, your environment is only as good as your planning.

If you take the time to design:

Network architecture
Application dependencies
Domain structure

Your environment will run extremely well.

My Personal Lessons Learned with VCF

After working through a few VCF 9 environments, a few things stood out:

The platform is designed to work with you—work with it, not against it
Fix small health issues early to avoid bigger problems
NSX design has a major impact on everything else
Consistency is key to easier operations

In the End!!

VCF isn’t harder than the old way. In fact, after the initial learning curve, most find it easier—but it does require a different approach.

Once you shift from thinking about individual components to thinking about the platform as a whole, everything starts to fall into place.

You end up with:

More consistent environments
Predictable operations
A scalable platform designed to support your organization

Most struggles with VCF come from trying to apply traditional management styles to a platform that was built to operate differently.

Overcoming Challenges of External OIDC IDP Integration with vCenter 8

Overcoming Challenges of External OIDC IDP Integration with vCenter 8
Recently I was brought in as a consultant on a project for a large company. The
engagement was to integrate Okta as the MFA identity provider for their vCenter instances, starting with their lab environment, which sounded like a simple project.

Of course… it didn’t stay simple for long.

The biggest complication right out of the gate was that all traffic had to pass through two different proxies. That’s where things started to get interesting.
The team had already configured the Okta Identity Provider in vCenter, but SCIM provisioning just wasn’t working. Okta wasn’t pushing groups through at all. Once Istarted digging into the environment, it became clear pretty quickly what we weredealing with—the vCenter appliance had no direct internet access.

On top of that, theorganization wasn’t willing to open outbound 443 to Okta.
So now we needed to introduce a proxy into the mix.

The First Hurdle
The primary proxy in their environment came with a major catch—getting changes approved on it was… let’s just say not quick. In some cases, not even realistic.
Because of that, we started looking for another path forward and ended up finding an internal team that managed their Apigee platform.
We pulled them into a working session and walked through what we needed. After reviewing everything, they confirmed we could split the traffic:

 General outbound traffic would continue through the main proxy
 SCIM provisioning traffic would route through Apigee

That gave us a workable path forward without having to fight the main proxy team forevery change.

The First Major Issue
During testing, things took a turn. At one point we removed and attempted to recreate the Okta Identity Provider in vCenter as part of troubleshooting—and that’s when we started hitting certificate errors.
Cue the troubleshooting spiral.
We went through all the usual steps:
 Running curl commands from vCenter to test connectivity

 Importing CA and issuer certs into the trust store
 Validating proxy certificate chains
None of it worked.
At that point, I started digging through documentation and came across a Broadcom article related to Microsoft Entra ID integration. Even though it wasn’t Okta-specific, the symptoms matched exactly what we were seeing.
The fix ended up being something you wouldn’t normally think of right away—we had to manually import the proxy certificate chain into the VIDB trust store used by the identity provider inside vCenter. That meant dropping into the appliance shell and updating the Java keystore directly.
Once we did that and restarted the relevant services, we were finally able to recreate the Okta Identity Provider successfully.
Below shows the Path and command structure needed to accomplish this:
 Path:
/storage/containers/vc-ws1a-broker/<HASH>/rootfs/usr/local/jre-
17.0.10/lib/security/cacerts
 Command:
keytool -noprompt -storepass changeit -import -trustcacerts \
-file <path to certs> \
-alias MSFT \
-keystore/storage/containers/vc/ws1abroker/########/rootfs/usr/local/jre-
17.0.10/lib/security/cacerts

Finally, we had some forward progress.

The Apigee Learning Curve

With the identity provider working again, the next challenge was getting SCIM fully functional through Apigee. None of us on the infrastructure side had much hands-on experience with Apigee, so there was definitely a learning curve. We had a quick walkthrough from one of their engineers, which helped conceptually, but the real work was in getting the details right.
I put together a basic YAML template for the proxy based on what we knew and some additional research. Sent it over to the Apigee team, and they confirmed we were on the right track.
But during deployment, they used placeholder URLs.

So when we tested… nothing routed correctly.
At that point, it was clear we needed another working session. After lining that up, one of their engineers jumped in, spotted the issue almost immediately, and corrected the base path and endpoint mappings.
Once that was fixed and deployed properly, we looped in the Okta engineer to confirm provisioning. Ran another test login—and this time it worked.
Okta MFA authenticated successfully into vCenter, and group provisioning was finally flowing.
Finally a win after a lot of troubleshooting back and forth.

The Next Unexpected Challenge

With the lab working, the assumption was we could just rinse and repeat for the rest of the vCenters.
Not quite.
Apigee requires every base path to be unique. The problem is that the SCIM base path used by vCenter is essentially fixed—you can’t just change it to something else.

So now we had a new problem:
How do you support multiple vCenters behind Apigee when they all expect the same base path?

The Final Architecture
After working through a few different ideas with the Apigee and networking teams, we
ended up finding a much cleaner solution than what we originally thought we’d need. Instead of adding another layer like NGINX to route traffic, we took a closer look at how the Apigee proxy was actually defined—specifically the OAS (OpenAPI) YAML file. Originally, the base path in Apigee mirrored the full SCIM path required by vCenter. That’s what caused the conflict, since Apigee enforces uniqueness on base paths.
The fix was actually pretty simple once we saw it:
 We shortened the base path to something unique per vCenter (like an identifier
or name)
 Then we moved the full SCIM path (/scim/v2/…) down into the individual
GET/POST operations in the YAML

This basically separated what Apigee cares about (unique base paths) from what
vCenter expects (fixed SCIM endpoints).
Once we made that change:
 Each vCenter had its own unique base path in Apigee
 Requests still hit the correct SCIM endpoints on the backend
 And we didn’t need any additional routing layer
After rolling it out, we validated:
 SCIM provisioning worked across all vCenters
 Group sync was consistent
 Authentication flows stayed stable
Much simpler design, and way easier to scale.
Final Thoughts
What started out as a “quick MFA integration” ended up touching a lot of different areas:
 OIDC identity federation
 SCIM provisioning
 Proxy and network design
 Certificate trust handling
 API gateway behavior
The biggest takeaway for me was how tightly identity integrations are tied to everything around them—networking, security, and even internal team processes. In the end, getting this working wasn’t about one fix. It was about working across multiple teams, figuring things out step by step, and being willing to dig into areas that weren’t originally in scope.

Planning a VMware Migration: A Real-World Approach from a Virtualization Consultant

After working on VMware environments for nearly two decades, one thing has become clear: the hardest part of a virtualization migration is rarely the technology.

It’s understanding the environment well enough to move workloads without breaking the applications that depend on them.

In this article I’ll walk through the practical approach I use when planning large VMware migrations, from discovery to wave planning.

Why Migrate?

Often times migrations within the IT Infrastructure are dictated by one of the following reasons:

Current infrastructure is so far out of date that it would take too many upgrades to get the infrastructure to a supported version of the software.
Bringing the Architecture back from the cloud
Complete infrastructure redesign to enable more modern workflows and Data Center Consolidation
NSX-V to NSX-T migration

Step 1 – Discovery and Environment Analysis

Before planning a migration, you need a clear picture of the existing environment.

This includes gathering data such as:

Number of VMs
CPU and memory usage
Storage consumption
Network segments
Cluster and host configuration
Application dependencies

A common tool used for this stage is RVTools, which can export a large amount of information from a vSphere environment.

Typical data points collected include:

VM inventory
Network assignments
Disk usage
Power state
CPU and memory allocation
Resource pool usage

Once collected, this data should be normalized into a format that allows analysis of:

VM density
Resource utilization
Network segmentation
Application grouping

The goal of discovery is to answer one fundamental question:

What actually exists in the environment today?

In many cases, organizations are surprised by what they find during this phase.

Step 2 – Application and Network Mapping

The next step is understanding how workloads communicate with each other.

Virtual machines rarely operate in isolation. Most applications consist of multiple tiers such as:

Web servers
Application servers
Database servers
Backend services

Understanding these relationships is critical to avoid breaking applications during migration.

Tools that can assist with this include:

vRealize Network Insight (Known as VCF Operations for Networks in recent releases)

The output of this phase should include:

Application groupings
Network segments used by each application
Dependency mapping between workloads

This allows workloads to be migrated as logical groups rather than individual VMs.

Step 3 – Designing Migration Waves

Once workloads are grouped logically, migrations should be organized into migration waves.

A migration wave is simply a group of workloads that will be moved together during a specific migration window.

Migration waves are typically designed around:

Application dependencies
Network segments
Resource availability
Business impact

A typical wave strategy might look like:

Wave	Workload Type	VM Count
Wave 1	Low-risk infrastructure systems	50
Wave 2	Internal applications	120
Wave 3	Tier-2 business applications	200
Wave 4	Tier-1 production workloads	150

Starting with low-risk workloads allows the migration team to validate the process before moving critical systems.

Step 4 – Selecting the Migration Method

There are several methods available for migrating virtual machines.

The appropriate method depends on factors such as:

Network availability
Downtime tolerance
Storage architecture
Distance between sites

Common migration approaches include:

vMotion

Used when environments share the same vCenter or when Enhanced Linked Mode is configured.

Advantages:

Zero downtime
Fast migration

Limitations:

Requires network and storage connectivity between environments.

Storage vMotion

Used when the storage platform is changing but the compute environment remains the same.

HCX Replication Assisted vMotion (RAV)

One of the most commonly used tools for large migrations between environments.

Advantages:

Handles long distance migrations
Works across different vCenters
Allows replication before cutover
Reduces migration downtime

Typical workflow:

VM replication begins
Data is synchronized between environments
Final cutover occurs
Source VM is powered off
Target VM becomes active

This approach allows migrations with minimal downtime even across data centers.

Step 5 – Handling Network Transitions

One of the biggest challenges in VMware migrations is network continuity.

Virtual machines often expect to remain on the same IP address and network segment.

There are several approaches to handling this:

Layer 2 Extension

Technologies such as HCX network extension allow networks to span across environments temporarily.

Advantages:

No IP changes required
Simplifies migration waves

Drawbacks:

Should be temporary
Can introduce complexity if left in place too long

Network Re-IP Strategy

In some cases workloads are migrated to new networks entirely.

This requires:

Application coordination
DNS updates
Change management

Gradual Gateway Migration

A common strategy is:

Extend the network between environments
Migrate VMs gradually
Once most workloads are moved, shift the gateway to the new environment
Remove the extension

This minimizes disruption while allowing a phased migration.

Step 6 – Testing and Validation

After each migration wave, validation should be performed.

Typical checks include:

Application availability
Network connectivity
DNS resolution
Storage performance
Monitoring alerts

Migration teams should also validate:

Backup functionality
Logging
Security policies
Load balancers
External integrations

Skipping validation can allow issues to go unnoticed until later waves.

Step 7 – Operational Readiness

After migration is complete, the new environment must be ready for day-2 operations.

This includes:

Monitoring configuration
Backup validation
Lifecycle management setup
Capacity planning
Documentation updates

Operational readiness is often overlooked but is essential for long-term stability.

Key Lessons from Real-World Migrations

Across many environments, several patterns emerge:

Discovery takes longer than expected.

Organizations rarely have accurate documentation of their virtualization environments.

Network dependencies cause the most problems.

Applications often rely on undocumented communication paths.

Migration tooling is rarely the hardest part.

The real challenge is understanding the environment well enough to move it safely.

Conclusion

VMware migrations are complex projects, but with proper planning they can be executed smoothly and with minimal disruption.

The key is approaching migrations as an architecture and planning exercise rather than just a technical task.

By focusing on:

Thorough discovery
Application dependency mapping
Logical migration waves
Proper tooling
Operational readiness

organizations can successfully modernize their virtualization platforms while minimizing risk.

First Post

This blog, about VMware virtualization (and occasionally other adjacent tech topics), will be run and maintained by me — Christopher McNeil.

I’ve worked with VMware technologies for over 20 years and currently serve as a Senior Consultant for a Broadcom partner, delivering professional services to enterprise and government customers. Most of my work centers on VMware Cloud Foundation, vSphere, NSX, Aria/vRealize products, automation, architecture design, migrations, and operational optimization.

My journey with VMware really began around 2007 while I was serving in the United States Marine Corps as a Tactical Data Systems Operator — essentially a sysadmin in austere and sometimes high-pressure environments. Virtualization quickly became more than just another tool; it became the backbone for how we delivered resilient, scalable infrastructure in the field. I continued working heavily with VMware throughout my military career until retiring in 2023.

Since leaving active duty, I’ve supported multiple government and enterprise environments as a virtualization and systems engineer before moving into my current consulting role. That path has exposed me to everything from greenfield deployments and complex NSX migrations to operational firefighting, architecture design reviews, and helping customers translate business requirements into practical technical solutions.

The goal of this blog is simple:

Share real-world VMware knowledge — not just theory or marketing slides
Document lessons learned from the field (including mistakes — because those teach the most)
Provide practical guidance engineers can actually use
Help bridge the gap between architecture, operations, and implementation
Occasionally explore adjacent areas like networking, automation, security, and career growth in enterprise IT

You’ll see a mix of deep technical walkthroughs, architectural perspectives, troubleshooting notes, exam prep insights, and sometimes opinion pieces based on what I’m seeing across the industry.

If you work with VMware regularly, are studying for certifications, designing infrastructure, or just enjoy digging into how these platforms really work under the hood — you’re in the right place.

Thanks for stopping by.

— Christopher