Introduction

VMware Cloud Foundation (VCF) 9 represents one of the most significant architectural shifts in the history of VMware’s private cloud platform. While previous releases focused heavily on consolidating infrastructure management, VCF 9 introduces a new approach where networking, lifecycle management, operations, and cloud-scale automation become deeply integrated components of the platform.

During a recent VMUG session, industry experts Alan Harrington and Van Rodriguez shared practical guidance, lessons learned, and architectural considerations for organizations planning a VCF 9 deployment or upgrade.

The key takeaway was simple:

Success in VCF 9 is determined long before the first upgrade begins.

Organizations that invest time in preparation, validation, networking design, and operational readiness are the ones that experience smooth deployments.

The Most Common Deployment Issues

Many VCF deployment failures occur because of seemingly small environmental issues.

NTP Synchronization

Time synchronization remains one of the most critical requirements.

The VMUG session highlighted cases where environments experienced deployment issues due to clock drift exceeding acceptable thresholds.

Recommendations include:

• Deploy a Photon-based utility server.
• Configure dedicated NTP sources.
• Validate synchronization before deployment.
• Ensure time drift remains within acceptable limits.

Even a small timing discrepancy can cause authentication failures, certificate validation problems, and deployment instability.

DNS Hygiene

Poor DNS configuration continues to be one of the biggest causes of failed VCF deployments.

Before starting:

• Clean up stale records.
• Validate forward and reverse lookups.
• Standardize naming conventions.
• Lock down management naming standards.

As Alan Harrington noted, DNS cleanup should happen before any VCF bring-up activities.

Certificate Validation

SSL certificate issues remain a frequent deployment blocker.

Best practices include:

• Ensure certificate names are consistent.
• Verify all certificate references use lowercase naming.
• Validate certificate chains before deployment.
• Confirm all required services trust the issuing authority.

Licensing Readiness

Many organizations underestimate licensing preparation.

Before deployment:

• Verify the License Server is reachable.
• Confirm licenses are imported.
• Validate license assignments.
• Test connectivity from management components.

Licensing should be treated as a deployment prerequisite rather than a post-deployment activity.

The VCF 9 Readiness Gate

One of the most valuable concepts discussed during the session was the idea of an integration pre-flight checklist.

Think of this as the readiness gate before any upgrade or deployment begins.

Readiness Checklist

License Server reachable and populated

Upgrade sequence validated against current versions

Identity and vIDB migration path confirmed

Networking architecture selected

Fabric configuration validated

Backup and recovery procedures tested

Disaster recovery processes documented

Upgrade dependencies understood

Organizations that complete these checks dramatically reduce deployment risk.

Understanding the New Networking Architecture

Perhaps the biggest change in VCF 9 is networking.

According to Van Rodriguez, networking has evolved into a dedicated architectural domain, with documentation approaching 950 pages.

Networking is no longer simply an infrastructure component.

It is now a strategic design decision.

Three Networking Models

VCF 9 supports three primary networking approaches.

1. VLAN-Based Networking

Ideal for:

• Traditional Layer 2 environments
• Smaller deployments
• Simpler operational models

Benefits:

• Familiar architecture
• Lower complexity
• Faster adoption

2. NSX Overlay Networking

Ideal for:

• Existing NSX customers
• Advanced segmentation requirements
• Micro-segmentation strategies

Benefits:

• Flexible networking
• Enhanced security
• Advanced workload mobility

3. NSX VPC Model

The most modern architecture.

Benefits:

• Self-service networking
• Multi-tenancy
• Transit Gateway integration
• Cloud-like operational experience

A critical point raised during the session was that the networking model selected today may influence future upgrade and expansion paths.

Networking Decisions That Must Be Made Early

Organizations should determine the following before deployment:

Distributed Model

VLAN-only architecture operating primarily within Layer 2 environments.

Centralised Model

Layer 3 routing using:

• NSX Edge Nodes
• BGP
• ECMP

Unified Fabric Model

VCF integrated directly with the physical network fabric using:

• MP-BGP EVPN
• EVPN-VXLAN

This model represents the future direction of private cloud networking.

Additional considerations include:

• Transit Gateway design
• VPC strategy
• Multi-tenancy architecture
• Edge throughput requirements
• Growth projections

The Biggest Innovation: Unified Fabric with Arista

One of the most exciting announcements discussed was the deep integration between VCF 9.1 and Arista networking.

Historically, virtual networking and physical networking existed as separate operational domains.

This created:

• Manual route management
• North-south bottlenecks
• Additional edge infrastructure
• Increased operational complexity

VCF 9.1 changes this model.

One Fabric, One Routing Domain

Using MP-BGP EVPN and EVPN-VXLAN standards, VCF becomes part of the network fabric itself.

Instead of:

“VCF talks to the network”

The new model becomes:

“VCF is the network.”

This removes many of the traditional boundaries between virtualization and networking teams.

How Unified Fabric Works

Control Plane

The VCF Route Controller establishes MP-BGP EVPN peering with the Arista EVPN Gateway.

Both systems dynamically advertise and learn workload routes.

This creates a shared routing domain.

Multi-Tenancy

Each VCF Transit Gateway maps directly to a dedicated Layer 3 VNI within the EVPN fabric.

Benefits include:

• Tenant isolation
• Consistent routing
• Simplified management

Route Exchange

Route distribution occurs automatically using EVPN Type-5 routes.

VCF advertises:

• Workload-specific /32 prefixes
• TEP addresses

The fabric advertises:

• Subnet routes
• Default routes
• VRF information

No manual route configuration is required.

Data Path

Traffic flows using VXLAN end-to-end:

VCF TEP → EVPN Gateway → Leaf Switch → Destination

The result is line-rate forwarding and significantly simplified operations.

Business Outcomes

Benefits for Network Teams

• Unified routing visibility
• Consistent multi-tenant policies
• Better segmentation
• Standards-based architecture
• No proprietary lock-in

Arista CloudVision complements VCF Operations to provide enhanced visibility and automation.

Benefits for Virtualization Teams

• Simplified workload connectivity
• Easier workload-domain expansion
• Reduced operational complexity
• Faster deployment times
• Lower total cost of ownership

One major advantage is the reduced dependency on dedicated edge-node infrastructure.

Real-World Deployment Strategy

The VMUG team shared their implementation approach.

Phase 1 – Design

Define:

• Sovereignty regions
• Naming standards
• IP addressing strategy
• VLAN architecture

Phase 2 – Management Domain

Deploy a greenfield management domain.

Phase 3 – Fleet Expansion

Deploy:

• One fleet per sovereignty region
• Dual cloud proxies per location
• Persistent data services

Phase 4 – Scale

Add workload domains incrementally.

Phase 5 – Operational Transition

Move monitoring and operations to VCF Operations.

Phase 6 – Day-2 Expansion

Bring additional workload domains online as required.

This phased approach significantly reduces risk.

Monitoring Gets a Major Upgrade

VCF Operations is now a core platform service rather than an optional add-on.

New capabilities include:

• Green Score
• Advanced Dashboards
• Super Metrics
• Service Discovery
• OpenTelemetry Integration
• Telegraf Integration

Organizations reported:

• Faster scaling
• Improved observability
• Quicker issue detection
• Reduced operational costs

What Experienced Architects Would Do Differently

The most valuable part of the session was hearing what practitioners would change if starting again.

Key Lessons Learned

1. Fix DNS before deployment.
2. Design the IP scheme early.
3. Consider dedicated VMware management VLANs.
4. Build a sandbox environment first.
5. Spend time in a lab before touching production.
6. Test recovery procedures before upgrading.
7. Never underestimate pre-deployment validation.

As Alan Harrington summarized:

“Pre-checks beat heroics.”

Final VCF 9 Readiness Checklist

Before beginning your VCF 9 journey:

Determine whether you’re performing a greenfield deployment, import, or fleet upgrade.

Validate your supported upgrade path using the Upgrade Planner.

Account for VCFMS, License Server, vIDB, Fleet Management, and Lifecycle dependencies.

Validate the complete upgrade sequence.

Finalize networking architecture.

Decide on your fabric strategy.

Test backups and recovery procedures.

Plan for vSphere 8.x End of Support in October 2027.

Build and test in a sandbox before production.

Conclusion

VCF 9 is much more than another infrastructure upgrade.

It introduces a new operational model where lifecycle management, observability, networking, and cloud-scale operations become part of a unified platform.

The organizations that will gain the most value from VCF 9 are not necessarily the ones with the newest hardware or largest budgets.

They are the ones that invest in planning, architecture, validation, and operational readiness before deployment begins.

The message from VMUG was clear:

Success with VCF 9 starts long before the upgrade wizard is launched.

For many VMware administrators, networking is the point where VMware Cloud Foundation starts to feel different.

Most of us entered the VMware world through vSphere. We became comfortable with ESX, vCenter, clusters, DRS, HA, vMotion, datastores and virtual machines. That was the world we knew. We could build clusters, troubleshoot hosts, move workloads, manage capacity and keep platforms running.

Then VMware Cloud Foundation brings NSX into the centre of the conversation.

Suddenly the language changes.

People start talking about Tier-0 Gateways, Tier-1 Gateways, Segments, Distributed Firewall, Edge Nodes, Transport Zones, VPCs, Transit Gateways, North-South traffic and East-West traffic.

At first, it can feel like a different discipline altogether.

But it is not.

NSX is not there to make networking complicated.

NSX exists because traditional data centre networking was not designed for the speed, automation and security model required by modern private cloud.

To understand NSX properly, we need to step back and look at the problem VMware was trying to solve.

Why Traditional Networking Became a Bottleneck

In a traditional VMware environment, the virtualisation team could build servers quickly.

A project team asks for five virtual machines. The VMware administrator creates the VMs, attaches them to port groups, allocates CPU and memory, connects storage, installs the operating system, and the compute side is largely complete.

But the application is not ready yet.

The team still needs VLANs.

They need firewall rules.

They need routing.

They may need load balancing.

They may need isolated networks for testing.

They may need connectivity between environments.

They may need security policies between application tiers.

This is where delivery slows down.

The VMware administrator can create the VM in minutes, but the network change may take days or weeks because the configuration often sits outside the virtualisation platform. It requires coordination with network teams, firewall teams, security teams and sometimes external providers.

This is not because those teams are slow.

It is because physical networking was built for stability and control, not rapid application delivery.

Cloud changed the expectation.

In AWS, Azure or Google Cloud, teams expect to create networks, subnets, routing, firewalls and isolated environments through software. Nobody raises a ticket to configure a physical switch every time a new application environment is required.

VMware needed to bring that same operating model into the private data centre.

That is the background to NSX.

What NSX Really Means

The simplest way to understand NSX is this:

NSX virtualises the network in the same way ESX virtualised compute.

Before ESX, an application usually depended on a physical server. If you needed another application environment, you often needed another server. ESX changed that model by abstracting compute from hardware. Virtual machines could run on shared physical infrastructure while still behaving like independent servers.

NSX applies the same idea to networking.

Before NSX, network services were strongly tied to physical infrastructure. VLANs lived on switches. Routing lived on routers. Firewalls lived on firewall appliances. Load balancing lived on load balancer appliances.

NSX abstracts those services into software.

That means networking becomes programmable.

Security becomes programmable.

Routing becomes programmable.

Firewalling becomes programmable.

This is the foundation of software-defined networking.

The physical network still matters. NSX does not remove the need for physical switches, uplinks, routing or resilient underlay design. What NSX does is reduce the dependency on physical change every time the application environment needs to evolve.

In a VMware Cloud Foundation environment, this becomes critical because VCF is designed to operate as a private cloud platform, not just a virtualisation estate.

Why NSX Is So Important in VMware Cloud Foundation

In older VMware environments, NSX was often seen as an optional product.

Some customers used it for micro-segmentation.

Some used it for overlay networking.

Some used it for security.

Some did not use it at all.

In VMware Cloud Foundation, that mindset changes.

NSX becomes part of the platform architecture.

VCF is trying to deliver a cloud operating model. A cloud operating model needs automated networking, consistent security, workload mobility, tenant isolation and predictable lifecycle management.

Without software-defined networking, VCF would still depend heavily on manual physical network change. That would break the promise of cloud-like operations.

This is why NSX is so central to VCF.

vCenter gives you the compute control plane.

vSAN gives you software-defined storage.

SDDC Manager gives you lifecycle and domain management.

NSX gives you the network and security fabric.

Once you understand that, NSX stops looking like a separate product and starts looking like a core layer of the private cloud.

The Three Planes of NSX

One of the most important concepts to understand in NSX is the idea of planes.

This is common in networking architecture, but it can feel abstract at first.

NSX is easier to understand when you separate it into three areas: the management plane, the control plane and the data plane.

Each plane has a different job.

If you understand which plane is responsible for which job, troubleshooting becomes much easier.

The Management Plane

The management plane is where configuration is created and stored.

When an administrator logs into NSX Manager and creates a Segment, configures a Gateway, defines a firewall policy, creates a VPC or changes routing configuration, they are working with the management plane.

The management plane is about intent.

It records what you want the network to look like.

For example, you might say:

I want a Segment called App-Web.

I want it connected to a Tier-1 Gateway.

I want that Tier-1 Gateway connected to a Tier-0 Gateway.

I want a firewall rule that allows web traffic from the internet to the web tier.

I want database traffic only from the application tier.

The management plane stores those decisions.

In traditional networking, these decisions might be spread across multiple switches, routers and firewalls. In NSX, the configuration is centralised and policy-driven.

NSX Manager is the most visible part of the management plane. It provides the interface and API through which administrators and automation tools define the desired state of the network.

In VCF environments, some NSX capabilities are also surfaced through vCenter and VMware Cloud Foundation workflows. This is part of VMware’s broader direction, making private cloud operations more integrated and less fragmented.

For the VCF exam, it is important to remember that the management plane is not where packets are forwarded. It is where configuration is defined.

That distinction matters.

If an administrator creates the wrong policy, that is a management plane problem.

If the policy is correct but not distributed properly, that may involve the control plane.

If everything is configured correctly but traffic still does not flow, the issue may be in the data plane, routing, firewall enforcement or the underlying physical network.

The Control Plane

The control plane is responsible for distributing network state and making forwarding information available across the NSX environment.

If the management plane says what the network should look like, the control plane helps the environment understand how to make that happen.

It deals with questions such as:

Where does this workload live?

Which ESX host is running this virtual machine?

Which routes should be known?

Which tunnel endpoints are involved?

Which Gateway should handle this traffic?

Which distributed components need updated forwarding information?

The control plane is not the user interface.

It is also not the place where the actual application traffic is forwarded.

Its job is to distribute intelligence.

A good analogy is air traffic control.

The management plane decides that a new airport route exists.

The control plane ensures that the relevant towers and systems know how flights should be directed.

The data plane is the actual aircraft moving passengers.

In NSX, the control plane is what allows a distributed software network to behave consistently across many ESX hosts and Edge Nodes.

This is extremely important because modern VCF environments are distributed by design. Workloads may live across multiple hosts, clusters or workload domains. The network must understand where those workloads are and how traffic should reach them.

For the exam, remember that the control plane is about network state, route distribution and communication between NSX components. It is the layer that helps translate desired configuration into usable network behaviour.

The Data Plane

The data plane is where traffic actually moves.

When a virtual machine sends traffic to another virtual machine, that is data plane traffic.

When a workload reaches an external network, that is data plane traffic.

When a packet is routed, switched, filtered or forwarded, the data plane is involved.

In NSX, the data plane exists across ESX hosts and NSX Edge Nodes.

This is one of the most powerful parts of the architecture.

Instead of forcing all traffic through a central physical appliance, NSX can perform many services in a distributed way. Routing and firewalling can happen close to the workload, directly in the hypervisor.

This is why NSX scales well.

Traffic does not always need to hairpin through a central device. East-West traffic between workloads can often be handled locally and efficiently.

For troubleshooting, the data plane is where you ask practical questions.

Can the VM reach its default gateway?

Is the Segment connected correctly?

Is the distributed firewall allowing the traffic?

Is routing working between Tier-1 and Tier-0?

Is the Edge Node forwarding North-South traffic?

Is the physical network receiving the advertised routes?

This is where architecture becomes real.

Segments, The New Starting Point for Workload Networking

When you connect a virtual machine to a network in NSX, you usually connect it to a Segment.

A Segment is a logical Layer 2 network.

For VMware administrators, the easiest comparison is a port group or VLAN-backed network, but that comparison only goes so far.

A traditional VLAN depends on the physical network.

The VLAN must exist on the physical switch.

The trunk must carry the VLAN.

The upstream network must understand the VLAN.

A Segment, by contrast, is created in software.

The physical network still provides transport, but the logical network exists inside NSX. This allows administrators to create application networks quickly without waiting for physical switch configuration every time.

For example, you might create a Segment for web servers, another for application servers and another for database servers. Each Segment provides network separation. Each Segment can have its own security rules and connectivity model.

This is the beginning of cloud-like networking.

Instead of asking the network team to build every network manually, platform teams can define logical networks as part of the environment.

Tier-1 Gateways, The Local Gateway for Applications

Once workloads are connected to Segments, they usually need routing.

This is where Gateways come in.

A Tier-1 Gateway is typically the first routing point for application networks.

Think of Tier-1 as the local router for a group of application Segments.

For example, an application may have a web Segment, an app Segment and a database Segment. Those Segments may all connect to the same Tier-1 Gateway. The Tier-1 Gateway provides routing between those networks and connects them upward toward the rest of the environment.

This gives administrators a clean way to organise applications.

A development environment can have its own Tier-1 Gateway.

A production application can have its own Tier-1 Gateway.

A DMZ environment can have its own Tier-1 Gateway.

This design creates separation and control.

The Tier-1 Gateway can also be associated with services such as NAT, load balancing and firewalling depending on design and licensing. From an exam point of view, the most important idea is that Tier-1 usually sits close to the workload and connects application networks upward toward Tier-0.

Tier-0 Gateways, The Bridge to the Outside World

The Tier-0 Gateway sits above the Tier-1 Gateway.

If Tier-1 is close to the application, Tier-0 is close to the physical network.

Tier-0 provides North-South connectivity. That means traffic entering or leaving the NSX environment usually passes through Tier-0.

A Tier-0 Gateway commonly connects to the physical network using dynamic routing such as BGP. It can advertise routes from NSX to the physical network and learn routes from the physical network into NSX.

This is one of the most important NSX concepts for VCF administrators.

Traffic from a VM to the internet may follow this path:

The VM sends traffic to its Segment.

The Segment connects to a Tier-1 Gateway.

The Tier-1 Gateway forwards upward to Tier-0.

Tier-0 forwards toward the physical network through Edge Nodes.

The physical network then routes the traffic to the next destination.

This hierarchy is central to NSX.

If you understand Segment to Tier-1 to Tier-0 to physical network, you understand the foundation of NSX routing.

NSX Edge Nodes, Where Centralised Services Live

When people first learn NSX, they often ask where Tier-0 and Tier-1 Gateways actually run.

The answer depends on the type of service.

Some routing is distributed and happens on the ESX hosts.

Some services require Edge Nodes.

An NSX Edge Node is an appliance that provides centralised networking services. Edge Nodes are commonly used for North-South routing, NAT, VPN, load balancing and connectivity to the physical network.

In a production design, Edge Nodes are usually deployed in clusters for resilience.

This matters because not every NSX function is distributed across all ESX hosts. Some services need a centralised service router component, and that is where Edge Nodes become important.

For the exam and for real environments, always ask:

Is this traffic handled in a distributed way on the ESX host, or does it need to go through an Edge Node?

That question often leads you to the correct troubleshooting path.

Distributed Routing, Why NSX Does Not Behave Like Traditional Networks

Distributed routing is one of the most powerful ideas in NSX.

In traditional networking, routing usually happens on a physical router or Layer 3 switch. Traffic must travel to that device before it can be routed.

NSX changes this model.

With distributed routing, routing can happen directly in the hypervisor, close to the virtual machine.

This is especially useful for East-West traffic, which is traffic moving between workloads inside the data centre.

Imagine a web server and an application server running on the same ESX host but on different logical networks. In a traditional model, traffic might leave the host, reach a router, then come back. That is inefficient.

With distributed routing, NSX can route that traffic locally.

This reduces latency.

It reduces unnecessary network hops.

It improves scale.

It also means the network becomes much more closely tied to the hypervisor.

For vSphere administrators, this is the mental shift.

The ESX host is no longer just running virtual machines.

It is participating in the network fabric.

Distributed Firewall, Security at the Workload Level

Traditional firewalls protect the edge of the network.

They are very good at inspecting traffic entering or leaving an environment.

But modern threats do not always stay at the edge.

Once an attacker compromises one system, they often try to move laterally. They move from server to server, from application tier to database tier, from user subnet to management subnet.

This lateral movement is difficult to control with only perimeter firewalls.

NSX Distributed Firewall solves this by placing firewall enforcement close to the workload, inside the hypervisor.

Instead of sending traffic to a central firewall, policy can be enforced at the virtual NIC level.

This is a major architectural shift.

Every workload can have its own security boundary.

A web server can be allowed to talk to an application server on a specific port.

The application server can be allowed to talk to a database server.

Everything else can be denied.

This is the foundation of micro-segmentation.

Micro-Segmentation, Security Designed for Modern Threats

Micro-segmentation is often explained badly.

It is not simply “more firewall rules.”

It is the practice of reducing unnecessary communication between workloads.

The old data centre model often trusted everything inside the network. Once traffic was internal, it was often allowed more freely.

That model no longer works.

Modern security assumes that compromise is possible. The goal is to reduce the blast radius.

If one server is compromised, it should not automatically be able to talk to every other server.

Micro-segmentation allows organisations to define security based on application behaviour rather than network location alone.

This is why NSX became so important to VMware’s security story.

Security is no longer only at the perimeter.

Security follows the workload.

For VCF administrators, this matters because networking and security are now joined together. You cannot fully understand NSX networking without understanding distributed security.

North-South and East-West Traffic

Two terms appear constantly in NSX conversations: North-South and East-West.

North-South traffic is traffic entering or leaving the environment.

A user accessing an application from outside the data centre is North-South traffic.

A VM reaching the internet is North-South traffic.

An application calling an external API is North-South traffic.

This traffic usually involves Tier-0, Edge Nodes and the physical network.

East-West traffic is traffic that stays inside the data centre.

A web server talking to an application server is East-West traffic.

An application server talking to a database server is East-West traffic.

A Kubernetes node talking to another Kubernetes node is East-West traffic.

This traffic often benefits from distributed routing and distributed firewalling.

Understanding the difference between North-South and East-West traffic helps you troubleshoot faster.

If the issue is external access, think Tier-0, Edge Nodes, BGP, NAT, upstream routing and physical connectivity.

If the issue is workload-to-workload traffic, think Segments, Tier-1, distributed routing, distributed firewall and local workload connectivity.

VPCs in VMware Cloud Foundation 9.1

VCF 9.1 continues VMware’s move toward a more cloud-like operating model, and one of the most important concepts in that direction is the Virtual Private Cloud, or VPC.

Many people already know the term from AWS.

A VPC is an isolated logical network environment. It gives a team, tenant or application group its own private networking space inside a larger shared platform.

In a traditional enterprise environment, creating this level of isolation could involve multiple VLANs, firewall contexts, routing changes and manual coordination.

With VPCs, the goal is to make that experience simpler and more self-service.

A platform team can provide isolated network environments to application teams without giving each team direct control over the underlying infrastructure.

This is important for large enterprises, service providers and internal platform teams.

It allows VCF to behave more like a private cloud platform rather than a traditional virtualisation environment.

In simple terms, VPCs help VMware Cloud Foundation move from “the infrastructure team builds everything manually” toward “the platform provides controlled self-service.”

Transit Gateways, Connecting VPCs Without Creating Chaos

As soon as you create multiple VPCs, another question appears.

How do they communicate?

If every VPC connects directly to every other VPC, the design quickly becomes messy.

This is where Transit Gateway concepts become useful.

A Transit Gateway acts as a central routing point between multiple isolated environments.

Instead of building many individual connections, traffic can pass through a central routing hub.

This simplifies connectivity.

It improves control.

It makes routing easier to manage at scale.

For VCF 9.1, this matters because VMware is strengthening the private cloud networking model. VPCs provide isolated environments. Transit Gateway capabilities help connect those environments in a controlled way.

For administrators, the key is not to memorise terminology.

The key is to understand the design pattern.

Isolation is useful.

Connectivity is also required.

Transit Gateway helps balance both.

How to Troubleshoot NSX Like an Architect

Many administrators troubleshoot NSX by jumping straight into the interface and clicking around.

That usually wastes time.

A better method is to follow the traffic.

Start with the workload.

Can the VM reach its own default gateway?

If not, check the VM network adapter, Segment connection, IP configuration and local firewall.

If the VM can reach the gateway, check whether it can reach another workload on the same Segment.

If same-Segment traffic works but routed traffic fails, look at Tier-1 connectivity and distributed routing.

If internal routing works but external access fails, move upward to Tier-0, Edge Nodes, NAT, BGP and the physical network.

If routing looks correct but traffic still fails, check the Distributed Firewall and Gateway Firewall policies.

If everything looks correct inside NSX, do not forget DNS, upstream routing, physical switch configuration and external firewalls.

The best NSX administrators do not guess.

They follow the packet.

That mindset is also extremely useful for the VCF exam.

What the VCF Exam Is Really Looking For

The VCF Admin exam is not trying to turn every VMware administrator into a network architect.

But it does expect you to understand how networking works inside a modern private cloud platform.

You should understand what NSX does.

You should understand why Segments exist.

You should understand why Tier-1 and Tier-0 Gateways are separate.

You should understand when Edge Nodes are involved.

You should understand the difference between distributed and centralised services.

You should understand why distributed firewalling matters.

You should understand how VPCs support cloud-like networking in VCF 9.1.

Most importantly, you should understand traffic flow.

Because once you understand traffic flow, the terminology becomes easier.

NSX is not just another networking product.

It is the layer that allows VMware Cloud Foundation to behave like a true private cloud platform.

In Part 4, we will move into storage and vSAN, looking at how VMware Cloud Foundation delivers software-defined storage, why storage policies matter, how stretched clusters fit into the design, and what administrators should understand before sitting the VCF 9 exam.

Understanding vCenter, ESX Communication and the Hidden Services That Run VMware Cloud Foundation

Most VMware administrators spend years working inside vCenter.

They create virtual machines.

Build clusters.

Configure DRS.

Manage HA.

Perform vMotion migrations.

Monitor workloads.

Yet surprisingly few administrators fully understand what happens behind the scenes.

When you click “Power On Virtual Machine” inside vCenter, what actually happens?

When you add an ESX host to vCenter, how does communication work?

When authentication fails, where do you begin troubleshooting?

Understanding these concepts will not only help you pass the VCF certification exam, but will also make you significantly more effective when troubleshooting production environments.

Understanding vCenter’s Real Purpose

Many administrators think of vCenter as a graphical interface.

In reality, vCenter is the orchestration engine of the compute platform.

Without vCenter, ESX hosts still run.

Virtual machines continue running.

Applications continue serving users.

But many advanced capabilities disappear.

There is no central inventory.

No Distributed Resource Scheduler.

No vMotion orchestration.

No centralised permissions.

No cluster-level management.

No lifecycle operations.

vCenter acts as the management plane responsible for coordinating all of these services.

In VCF environments, this role becomes even more important because vCenter is one of the foundational services that SDDC Manager relies upon.

A useful way to think about it is this:

ESX runs workloads.

vCenter coordinates workloads.

SDDC Manager coordinates the platform.

Each layer has a different responsibility.

Understanding that hierarchy is essential.

The Hidden Services Behind Every Click

One of the most common certification questions involves understanding the communication path between vCenter and ESX.

This is not something most administrators think about every day.

Yet when something breaks, understanding these services becomes incredibly valuable.

Three services matter more than any others:

hostd

vpxa

vpxd

If you understand these three services, you understand most of VMware’s management architecture.

hostd – The Brain of the ESX Host

Every ESX host runs a service called hostd.

Think of hostd as the local management service for the host.

It knows:

Which virtual machines exist.

Which datastores are mounted.

Which networks are available.

Which services are running.

Which hardware resources are available.

Even if vCenter completely disappears, hostd continues operating.

This is why you can connect directly to an ESX host using the VMware Host Client.

The Host Client communicates directly with hostd.

This is an important exam concept.

Many candidates incorrectly assume vCenter is required for host administration.

It is not.

vCenter simplifies administration.

hostd performs administration.

vpxa – The Translator

When an ESX host is added to vCenter, another service enters the picture.

This service is called vpxa.

Think of vpxa as a translator.

vCenter does not communicate directly with hostd.

Instead:

vCenter communicates with vpxa.

vpxa communicates with hostd.

vpxa acts as the intermediary.

This architecture allows VMware to maintain consistent communication between the management platform and individual hosts.

When vCenter needs to power on a virtual machine, migrate a workload, or change a configuration, the request flows through vpxa before reaching hostd.

Many troubleshooting scenarios ultimately come down to failures in this communication chain.

vpxd – The vCenter Engine

Running inside vCenter itself is a service called vpxd.

This is effectively the heart of vCenter.

vpxd processes administrative requests.

It coordinates inventory updates.

It manages cluster operations.

It orchestrates automation workflows.

It communicates with ESX hosts through vpxa.

When vCenter becomes slow, unstable, or unresponsive, vpxd is often one of the first services administrators investigate.

From an exam perspective, remember:

hostd lives on ESX.

vpxa lives on ESX.

vpxd lives on vCenter.

If you can remember that relationship, you will solve many architecture questions correctly.

Why Certificates Matter More Than Most Administrators Realise

Certificates appear repeatedly throughout the VCF blueprint.

That is not accidental.

Certificates underpin trust across the entire platform.

Every component communicates securely.

vCenter trusts ESX.

ESX trusts vCenter.

SDDC Manager trusts vCenter.

NSX trusts SDDC Manager.

Identity services trust certificates.

Automation services trust certificates.

Without certificates, secure communication breaks.

This becomes especially important during VCF upgrades and lifecycle operations.

Many upgrade failures can ultimately be traced back to certificate problems.

Expired certificates.

Incorrect common names.

Certificate authority issues.

Trust chain failures.

One of the best habits a VCF administrator can develop is proactively monitoring certificate health before issues occur.

Single Sign-On: The Foundation of Identity

Most administrators log into vCenter every day without thinking about what happens behind the scenes.

They enter a username.

They enter a password.

Access is granted.

Simple.

Behind the scenes, however, VMware’s identity architecture is doing considerable work.

Single Sign-On exists to centralise authentication across the platform.

Instead of maintaining separate credentials for every component, administrators authenticate once and gain access based on assigned permissions.

This becomes especially important in larger environments.

Imagine managing:

Multiple vCenters.

Multiple workload domains.

Multiple NSX instances.

Multiple operational teams.

Without centralised identity management, administration quickly becomes chaotic.

Enhanced Linked Mode

Historically, organisations deployed multiple vCenter instances.

This created management challenges.

Enhanced Linked Mode helps solve this problem.

Multiple vCenter instances can appear through a unified interface.

Administrators gain visibility across environments without constantly changing connections.

For enterprises running large VMware estates, this capability significantly simplifies operations.

From a certification perspective, understand why Enhanced Linked Mode exists.

The exam often rewards architectural understanding over memorisation.

Identity Broker and the Future of Authentication

Identity Broker represents VMware’s move toward modern identity integration.

Traditional Active Directory authentication remains important.

But enterprises increasingly require:

Federated authentication.

Multi-factor authentication.

External identity providers.

Cloud-based identity services.

Identity Broker provides the abstraction layer that allows VMware Cloud Foundation to integrate with modern identity platforms.

As organisations adopt zero-trust security models, this component becomes increasingly important.

Expect Identity Broker to become more prominent in future VCF releases.

What Changed in VCF 9 and 9.1 for Identity and Management?

One of VMware’s major goals with VCF 9 is simplifying operations.

Historically, administrators spent considerable time maintaining infrastructure components individually.

VCF 9 moves toward platform-centric operations.

Identity services become more integrated.

Certificate management becomes more automated.

Lifecycle management becomes more consistent.

Authentication becomes more unified.

VCF 9.1 continues this trend by reducing operational complexity and increasing automation throughout the management stack.

The direction is clear.

Less manual administration.

More platform automation.

More consistency.

More resilience.

What VMware Is Really Testing

Most candidates study vCenter features.

The exam often tests architecture.

There is a difference.

Memorisation asks:

“What does this feature do?”

Understanding asks:

“Why does this feature exist?”

VMware increasingly rewards administrators who understand the platform.

Why does hostd exist?

Why does vpxa exist?

Why does vCenter exist?

Why does SSO exist?

Why does Identity Broker exist?

Why are certificates critical?

When you understand those answers, the architecture becomes logical.

And once the architecture becomes logical, passing the exam becomes much easier.

In Part 3, we move into one of the most important domains in modern VMware Cloud Foundation:

Networking.

We will explore vSphere Standard Switches, Distributed Switches, NSX Segments, Tier-0 Gateways, Tier-1 Gateways, VPCs, Transit Gateways, Micro-Segmentation, and the networking architecture that powers modern private cloud platforms.

Most VMware administrators start their VCF journey by asking the wrong question.

“What do I need to memorise to pass the exam?”

The better question is:

“What problem was VMware Cloud Foundation created to solve?”

Once you understand the answer, the certification becomes dramatically easier.

More importantly, you become a better administrator.

Because VMware Cloud Foundation is not simply another VMware product.

It is VMware’s attempt to solve one of the biggest problems facing modern infrastructure teams:

Complexity.

The Problem VMware Is Trying to Solve

Think back to a traditional VMware environment.

You might have:

A vCenter Server.

Several ESX clusters.

A SAN managed by the storage team.

Physical networking managed by the network team.

Firewalls managed by the security team.

Monitoring tools managed by operations.

Automation tools deployed separately.

Backups configured independently.

Every component works.

But every component also has its own lifecycle.

Its own upgrade path.

Its own support matrix.

Its own dependencies.

Its own operational procedures.

Over time these environments become increasingly difficult to maintain.

Upgrading vSphere becomes a project.

Upgrading networking becomes another project.

Upgrading storage becomes another project.

Soon the infrastructure team spends more time maintaining infrastructure than delivering value.

VMware looked at this challenge and asked:

“What if the entire private cloud operated as a single platform?”

That idea became VMware Cloud Foundation.

Understanding VMware Cloud Foundation

Many people describe VMware Cloud Foundation as:

vSphere + vSAN + NSX + SDDC Manager

Technically that is correct.

But it misses the real value.

VMware Cloud Foundation is an operating platform for private cloud.

Just as Azure operates public cloud infrastructure.

Just as AWS operates public cloud infrastructure.

VCF provides a consistent operating model for on-premises infrastructure.

The platform combines compute, networking, storage, security, automation, operations, lifecycle management, identity management, and Kubernetes into a single architecture.

This is the first mindset shift required for the certification exam.

Do not think in products.

Think in platforms.

The exam increasingly tests how components interact rather than how individual features operate.

Why vCenter Still Matters

One misconception I frequently hear is:

“VCF replaces vCenter.”

It does not.

In fact, vCenter remains one of the most important components in the entire platform.

VMware vCenter continues to act as the control plane for compute operations.

Every ESX host ultimately reports into vCenter.

Every virtual machine is managed through vCenter.

Every cluster, datastore, resource pool, DRS recommendation, HA action and vMotion operation flows through vCenter.

Even in VCF 9, vCenter remains the heart of compute management.

The difference is that vCenter is no longer expected to manage the entire private cloud lifecycle.

That responsibility now belongs elsewhere.

Enter SDDC Manager

This is where many certification candidates get confused.

They know vCenter.

They understand ESX.

But they struggle to understand why VMware introduced SDDC Manager.

The answer is simple.

vCenter manages infrastructure resources.

SDDC Manager manages the platform.

That distinction is incredibly important.

When VMware Cloud Foundation performs:

Certificate management

Password management

Domain deployment

Lifecycle management

Fleet management

Platform upgrades

Workload domain operations

These activities are orchestrated through SDDC Manager.

Think of SDDC Manager as the cloud operating system.

Think of vCenter as the compute management plane.

Understanding this relationship immediately makes a large portion of the VCF architecture easier to understand.

What Changed in VCF 9?

VCF 9 represented one of the biggest architectural shifts VMware has made in years.

Historically, VMware environments often felt like collections of products.

VCF 9 moved aggressively toward platform integration.

The focus shifted toward:

Unified operations

Fleet-level lifecycle management

Kubernetes integration

AI-ready infrastructure

Security by default

Private cloud as a service

Infrastructure teams increasingly want public-cloud-like operations without losing control of data.

VCF 9 was VMware’s answer to that challenge.

The result is a platform that treats virtual machines, Kubernetes workloads, AI workloads, networking, storage, and security as first-class citizens inside a unified private cloud architecture.

Why NSX Became So Important

Many VMware administrators have spent years focusing primarily on vSphere.

For the VCF exam, that approach can become a problem.

Because modern VMware Cloud Foundation is built around NSX.

In traditional environments, networking often relied heavily on physical infrastructure.

VLANs.

Firewalls.

Routing.

Load balancing.

Security policies.

Much of this was configured outside the VMware stack.

VCF changes that approach.

NSX brings networking into software.

The network becomes programmable.

Security becomes programmable.

Routing becomes programmable.

Load balancing becomes programmable.

This shift is one of the most important concepts in the entire VCF architecture.

Understanding NSX is no longer optional.

It is foundational.

When you deploy a workload domain today, networking is no longer simply “connected.”

It becomes an integrated part of the cloud platform itself.

This is why so many exam objectives focus on troubleshooting NSX gateways, routing, DHCP, VPN services, VPCs, and network operations.

VMware expects administrators to understand how the software-defined network behaves.

Not just how virtual machines connect to it.

What Is New in VCF 9.1?

VCF 9.1 is not a complete redesign.

It is an optimisation release.

VCF 9 introduced the architecture.

VCF 9.1 improves how that architecture operates at scale.

One major improvement is around operational efficiency.

VMware enhanced NVMe Memory Tiering, allowing hot data to remain in DRAM while colder pages move intelligently to NVMe storage. This improves memory efficiency and reduces infrastructure costs without changing how applications behave.

For administrators studying the exam, this matters because VMware continues pushing toward software-defined infrastructure where hardware resources are utilised more efficiently.

VCF 9.1 also introduces significant improvements around Kubernetes scalability.

Supervisors can support dramatically larger Kubernetes deployments, allowing platform teams to manage both containerised and traditional workloads using the same operational model.

Another area receiving major investment is networking.

VCF 9.1 expands VPC capabilities, transit gateway functionality, IP address management, and multi-site connectivity options directly through vCenter and NSX.

This is important because VMware is positioning VCF not simply as a virtualisation platform, but as a complete private cloud platform.

The networking layer is becoming increasingly intelligent and increasingly automated.

vCenter in VCF 9.1

Even vCenter receives important improvements.

One particularly useful enhancement is the ability to resize vCenter resources through a simple API-driven process rather than requiring more complex operational procedures.

This may sound like a small feature.

But it reflects VMware’s broader strategy.

Reduce operational friction.

Reduce manual administration.

Increase automation.

The same philosophy appears throughout VCF 9.1.

The Most Important Lesson for Exam Candidates

If there is one lesson I would give every VCF certification candidate, it is this:

Stop studying individual products.

Start studying the platform.

Understand how:

ESX supports vCenter.

vCenter supports workload operations.

NSX provides networking.

vSAN provides storage.

SDDC Manager provides lifecycle management.

VCF Operations provides observability.

Identity Broker provides authentication.

VCF Automation provides self-service consumption.

When you understand those relationships, the blueprint begins to make sense.

And when the blueprint makes sense, the exam becomes far less intimidating.

Because VMware is not testing whether you can memorise menu options.

They are testing whether you understand how a modern private cloud platform operates.

That understanding is what ultimately separates a VMware administrator from a VMware Cloud Foundation administrator.

Technology never stands still.

As infrastructure professionals, we are constantly learning, adapting, and evolving alongside the platforms we support.

I’m pleased to share that I have successfully achieved the VMware Certified Professional (VCP) – VMware Cloud Foundation Administrator certification. This certification validates my knowledge and practical understanding of VMware Cloud Foundation, the platform that is rapidly becoming the foundation of modern private cloud infrastructure.

Why VMware Cloud Foundation Matters

Over the past few years, organisations have faced increasing pressure to modernise their infrastructure while maintaining security, resilience, operational efficiency, and control over their data.

VMware Cloud Foundation brings together the core building blocks required to deliver a modern private cloud platform:

• vSphere for compute virtualisation

• vSAN for software-defined storage

• NSX for networking and security

• SDDC Manager for lifecycle management and automation

Rather than managing these components independently, VMware Cloud Foundation provides an integrated platform that simplifies deployment, operations, upgrades, and lifecycle management.

For many organisations, VMware Cloud Foundation is becoming the strategic platform for private cloud transformation.

Why I Pursued This Certification

My career has been built around enterprise infrastructure, virtualisation, cloud technologies, and platform operations.

Having worked across large-scale VMware environments, including multi-site estates, private cloud platforms, and infrastructure modernisation programmes, I wanted to deepen my expertise in the latest VMware Cloud Foundation architecture and operational model.

This certification provided an excellent opportunity to strengthen my understanding of:

• VMware Cloud Foundation architecture

• Management and workload domains

• SDDC Manager operations

• Lifecycle management

• Storage and networking integration

• Security and operational best practices

• Private cloud design principles

As organisations continue their journey toward private cloud and hybrid cloud strategies, these skills are becoming increasingly valuable.

What I Learned

One of the most valuable aspects of studying for the VMware Cloud Foundation Administrator certification was understanding how all the platform components work together as a single integrated solution.

The certification goes beyond individual products and focuses on operating VMware Cloud Foundation as a complete private cloud platform.

Key learning areas included:

• Platform architecture and design

• Deployment methodologies

• Lifecycle management processes

• Monitoring and troubleshooting

• Security and governance

• Operational readiness

• Day-to-day administration

These are all critical areas for organisations running production VMware Cloud Foundation environments.

Looking Ahead

This certification is not the destination, it is another step in the journey.

My focus now is continuing to expand my expertise in:

• VMware Cloud Foundation 9

• Private cloud transformation

• Infrastructure modernisation

• Automation and operational excellence

• AI-ready infrastructure

• Cloud operating models

I am particularly interested in helping organisations plan and execute their transition to modern private cloud platforms while ensuring operational simplicity and long-term business value.

Thank You

A huge thank you to the VMware community, fellow vExperts, customers, colleagues, and technical professionals who continue to share knowledge and support one another.

The VMware community has always been one of the strongest technology communities in the industry, and I am grateful to be part of it.

Learning never stops.

Onwards to the next challenge.

#VMware #VMwareCloudFoundation #VCF #VCP #PrivateCloud #CloudInfrastructure #vExpert #Virtualization #Infrastructure #CloudComputing #DigitalTransformation

When I first started working with VMware technologies, I never imagined that sharing my experiences with the community would become such an important part of my professional journey.

What began as a passion for virtualization and infrastructure gradually evolved into writing blogs, helping others solve technical challenges, creating VMware-focused content on my YouTube channel (https://m.youtube.com/@agileops), which I started in 2019, and sharing knowledge with the wider community—an effort that ultimately helped me achieve vExpert recognition—participating in community discussions, speaking with peers, and continuously learning from some of the brightest minds in the industry.

Along the way, I was fortunate enough to be recognised as a VMware vExpert.

For those unfamiliar with the program, vExpert is not a certification. It is a global recognition awarded to individuals who actively contribute to the VMware community through knowledge sharing, content creation, mentoring, speaking engagements, and community leadership.

The award represents something I deeply value: giving back.

Why Community Matters

Technology moves fast.

New platforms emerge, architectures evolve, and best practices change constantly. No single person has all the answers.

Throughout my career, I have benefited enormously from community-driven knowledge. Blog posts written by strangers helped me solve production issues. Community forums provided answers when documentation fell short. Experts shared their experiences, allowing others to avoid costly mistakes.

The vExpert community embodies this spirit.

It is a network of professionals who believe that sharing knowledge strengthens the entire ecosystem.

Being part of that community has been one of the most rewarding aspects of my career.

A New Milestone: vExpert VCF

This year, I am honoured to have been accepted into the VMware by Broadcom vExpert VCF sub-program.

VMware Cloud Foundation (VCF) represents the future of modern private cloud infrastructure, bringing together compute, storage, networking, security, automation, and lifecycle management into a unified platform.

As organisations continue their journey towards private cloud and hybrid cloud operating models, VCF is becoming increasingly important in delivering consistency, scalability, security, and operational efficiency.

The vExpert VCF sub-program recognises community members who actively engage with and contribute knowledge around VMware Cloud Foundation technologies.

For me, this recognition is particularly meaningful because much of my recent work has focused on cloud transformation, VMware Cloud Foundation architecture, NSX modernisation, lifecycle management, infrastructure automation, and helping organisations navigate complex platform upgrades and modernisation initiatives.

Eight Years of Learning

Looking back, one of the most valuable lessons I have learned is that expertise is not about knowing everything.

It is about remaining curious.

The technology industry rewards those who continue learning, sharing, and adapting.

Whether I am working with VMware Cloud Foundation, vSphere, NSX, vSAN, automation platforms, or helping organisations modernise their infrastructure, I still approach every project with the mindset of a student.

There is always something new to discover.

The vExpert and vExpert VCF communities are filled with individuals who share that same mindset.

Looking Ahead

Being recognised as a vExpert VCF is not an endpoint.

It is a responsibility.

A responsibility to continue learning.

A responsibility to continue sharing.

A responsibility to help others navigate the increasingly complex world of cloud infrastructure and digital transformation.

I am grateful to the VMware by Broadcom Communities Team, the wider vExpert community, colleagues, customers, and everyone who has supported me throughout this journey.

I look forward to contributing more content, sharing more experiences, and continuing to support the community that has given so much to me over the years.

The best part of this journey has never been the award itself.

It has always been the people.

And that journey continues.

Thank you to everyone who has been part of it.

Modern datacentres run on layers of virtualisation, applications, networks, and security policies that all need to be monitored together, not in isolation. As environments scale, the real challenge is not deploying the technology—it’s keeping it healthy, stable, and predictable over time.

This is where VMware Aria comes in.

VMware Aria is VMware’s cloud management platform designed to give organisations complete visibility across their virtual and cloud environments. It brings together metrics, logs, network flows, capacity insights, and application dependencies into one integrated ecosystem. Instead of monitoring the environment through multiple tools, teams can use Aria to see the full picture: performance, behaviour, security, and dependencies.

Aria is made up of several components, but the three that directly support infrastructure monitoring are:

• VMware Aria Operations
• VMware Aria Operations for Logs
• VMware Aria Operations for Networks

In this blog, we’ll break down what each platform does, how it supports day-to-day operations, and how they work together to give you full-stack visibility.

This section outlines how monitoring will be implemented using the three VMware Aria Operations components:

1. VMware Aria Operations – Monitoring Design

VMware Aria Operations will act as the core monitoring platform for the virtual infrastructure. It collects performance metrics from vCenter, ESXi hosts, and virtual machines, and uses these metrics to evaluate health, performance, and capacity at every layer. Once deployed, the system continuously analyses CPU, memory, disk, and network usage trends to identify performance issues early. Aria Operations does not just present raw metrics; it builds baselines of typical behaviour and highlights deviations that may indicate future issues.

Aria Operations will be configured to pull detailed metrics from each vCenter Server. This includes host hardware status, VM performance counters, datastore capacity information, and cluster-level resource usage. These metrics enable capacity forecasting so teams can see when resources are likely to run out and plan expansions ahead of time. The forecasting engine also identifies oversized or undersized virtual machines, helping the operations team optimise resource consumption.

Dashboards in Aria Operations provide a structured way of monitoring the environment. For example, the Host Performance dashboard allows engineers to quickly identify issues such as high CPU Ready times or memory contention. The VM Troubleshooting dashboard brings together CPU, memory, I/O, and network graphs into one place, making it easier to trace the source of performance complaints. If required, custom dashboards can be created for critical applications or specific business units so their behaviour can be monitored more closely.

Alerts in Aria Operations will be based primarily on VMware’s recommended thresholds, but custom alerting rules will also be applied. For example, alerts may be configured at specific CPU Ready levels, datastore latency thresholds, or memory ballooning levels to match the organisation’s performance expectations. All alerts are designed to provide context and recommended actions, giving the operations team clear guidance on what needs attention. Alerts can also be escalated to service desk tools or email groups.

In addition to real-time monitoring, Aria Operations will support scheduled reporting. These reports include cluster capacity summaries, host performance over time, datastore growth trends, and VM rightsizing recommendations. The operations team can use these reports in monthly service reviews or capacity planning meetings.

Monitoring Scope

VMware Aria Operations is the main platform for performance, health, and capacity monitoring of the virtual infrastructure. It collects metrics from:

vCenter Servers

ESXi hosts

Virtual machines

Datastores

NSX-T Manager and related objects (if integrated)

Aria Operations stores time-series metrics and uses analytics to learn “normal” behaviour and highlight anomalies, issues, and risks.

Data Collection and Adapters

vCenter Adapter

Primary data source for ESXi, VMs, clusters, and datastores.

Collection interval: typically 5 minutes (can be tuned if needed).

NSX-T Adapter (if deployed)

Collects metrics for logical switches, routers, edges, and firewalls.

Other Management Packs (optional)

Additional packs can be added later (e.g. for physical hardware, backup, storage) to extend monitoring.

All collectors use authenticated service accounts with read-only or least-privilege roles defined in vCenter and NSX.

Dashboards and Views

Out-of-the-box dashboards in Aria Operations will be used as the baseline, for example:

vSphere Overview – overall health of clusters, hosts, and VMs

Capacity and Utilisation – CPU, memory, and storage trends

Troubleshooting Dashboards – detailed views for specific objects when investigating issues

Where needed, simple custom dashboards will be created to:

Group objects by site, cluster, or application

Show key KPIs for management (e.g. top 10 busy clusters, host contention, datastore usage)

KPIs and Thresholds

Key metrics monitored include:

Cluster / Host

CPU usage (%)

Memory usage (%)

Disk latency (ms)

Network throughput and packet drops

VM

vCPU ready time and CPU contention

Memory usage and ballooning / swapping

Disk latency and IOPS

Datastores (non-vSAN)

Capacity used / free

Disk latency and outstanding IO

Default Aria Operations alert definitions and dynamic thresholds are used, with adjustments where the environment has known baselines (for example, high but normal CPU usage in test clusters).

Alerts and Notification Flow

Alert Types

Health / performance alerts (e.g. high CPU, datastore latency)

Risk alerts (e.g. capacity exhaustion in 30 days)

Efficiency alerts (e.g. oversized or idle VMs)

Alert Routing

Alerts are grouped and forwarded to the central ticketing system (e.g. ServiceNow, Jira) using email or webhook integration.

Critical alerts (e.g. host down, cluster redundancy at risk) are tagged with higher severity for on-call escalation.

Noise Reduction

Non-actionable alerts (e.g. short, transient spikes) are tuned or disabled after an agreed review period.

Alert policies are scoped per object group (e.g. production vs. non-production) to avoid unnecessary tickets from lab systems.

Capacity and Planning

Aria Operations is used to support capacity planning:

Tracks consumption trends for CPU, memory, and storage

Identifies when clusters are predicted to run out of capacity based on observed growth

Provides simple “what-if” analysis to estimate impact of adding or removing hosts

Capacity reports are generated monthly and reviewed by the infrastructure team.

Reporting and Responsibilities

Daily

Operations team monitors key dashboards and new critical alerts.

Weekly

Review of recurring alerts and potential tuning / remediation.

Monthly

Capacity and performance summary report for management.

The infrastructure operations team owns Aria Operations dashboards and alert configurations, with change control for any major policy changes.

2. VMware Aria Operations for Logs – Monitoring Design

Aria Operations for Logs provides centralised log management for the environment. Instead of manually reviewing logs on individual ESXi hosts or vCenter Server, all system logs are forwarded into a single platform. This ensures that operational and security events are captured reliably and retained for the required duration.

The platform will receive logs from vCenter Servers, ESXi hosts, and other infrastructure components. Logs can include events such as authentication failures, service restarts, hardware warnings, VM lifecycle events, and any configuration changes. If the customer chooses to forward application logs from VMs, those can also be processed and indexed for troubleshooting purposes.

Once logs are ingested, they become searchable in real time. This enables engineers to quickly investigate incidents by filtering and correlating logs from different sources. For example, if a host becomes unresponsive, the platform can show related warnings from ESXi, vCenter’s task history, and any VM-level events around the same time. This reduces the time required to identify the root cause of issues.

Aria Operations for Logs also supports alerting based on log patterns. Alerts can be created to detect repeated authentication failures, storage-related warnings, host PSOD events, or any specific text patterns the customer wants to monitor closely. These alerts supplement the metric-based alerts from Aria Operations, providing more context around system behaviour.

Dashboards in Aria Operations for Logs present log data in an organised manner. Examples include dashboards for ESXi health events, vCenter errors, and security-related events. These dashboards help teams monitor the environment without having to run manual searches. Logs can be retained for 30, 90, or more days depending on compliance and storage policies. The retention period should match operational and auditing needs, as older logs are often required during incident investigation or compliance reviews.

By centralising all logs, the environment gains consistent visibility and much faster troubleshooting capabilities. Instead of connecting manually to each ESXi host, engineers can access an indexed, searchable history of system activity.

VMware Aria Operations for Logs – Monitoring Design
Monitoring Scope

VMware Aria Operations for Logs is the central log management and analysis platform. It collects logs from:

vCenter Servers

ESXi hosts (via syslog)

NSX-T components (Managers, Edges, T0/T1 gateways)

Aria Operations nodes

Optionally, other infrastructure devices and systems that support syslog (e.g. firewalls, load balancers, Linux VMs)

No vSAN log content is required in this design.

Log Collection and Ingestion

ESXi hosts and other syslog sources forward to Aria Operations for Logs using:

Standard syslog (UDP/TCP 514) or

Encrypted syslog (TCP 6514 / 1514) where required.

vCenter sends events, tasks, and alarms through its native integration.

Aria Operations sends events into Logs to link metrics and logs for end-to-end troubleshooting.

Log volume and EPS (events per second) are estimated to ensure the appliance is correctly sized for the environment.

Content Packs and Dashboards

Built-in content packs are used to provide ready-made dashboards, queries, and alerts for core platforms (e.g. vSphere, NSX, Aria Operations itself).

Custom dashboards will be created where needed to:

Show a “single pane” of critical logs for production

Highlight failed logins, configuration changes, and system errors

Provide quick filters by site, environment, or application tag

Log-Based Alerts

Aria Operations for Logs generates alerts when log patterns match known issues or error conditions, for example:

Repeated authentication failures

ESXi host connection failures

NSX component errors

vCenter or Aria Operations service issues

Alert notifications are integrated with the same central ticketing / notification system used by Aria Operations to keep workflows consistent.

Where possible:

Metric + Log Correlation is used (e.g. a CPU spike in Aria Operations plus related error logs in Operations for Logs) to speed up root-cause analysis.

Retention and Storage

Log retention period is defined based on:

Troubleshooting needs (e.g. 30–90 days online)

Any audit or compliance requirements (e.g. longer retention in cheaper storage or external archive)

The appliance storage is sized to keep the agreed retention without impacting performance. When storage usage nears thresholds, the operations team either expands storage or adjusts retention.

Responsibilities

Platform Owners

Ensure all required devices and systems send logs to Aria Operations for Logs.

Maintain parsing rules and log source configurations if new platforms are added.

Operations Team

Review log-based alerts daily.

Use dashboards for incident investigation.

Tune noisy or duplicate alerts in a controlled manner.

3. VMware Aria Operations for Networks – Monitoring Design

Aria Operations for Networks provides visibility into traffic flows, network dependencies, and communication paths across the virtual and physical network. This platform focuses on understanding how applications communicate, detecting abnormal traffic patterns, and mapping the end-to-end network path for any VM.

The system will connect to vCenter Server to discover virtual machines and their relationships to hosts and networks. It can also integrate with physical switches, routers, and firewalls through SNMP, API connections, or flow exports such as NetFlow or IPFIX. This allows it to build a combined view of both virtual and physical network components.

One of the primary benefits of Aria Operations for Networks is the ability to analyse traffic flows. It shows which VMs communicate with each other, the volume of data exchanged, and whether any unexpected or unauthorised flows occur. This is particularly useful for troubleshooting connectivity issues. For example, if a VM cannot communicate with a database server, the platform can display the full path between them, highlighting any firewall drops, misconfigurations, or latency issues.

The system also provides application-level visibility. Aria Operations for Networks can automatically identify application components based on their communication patterns and present them as a visual map. This helps teams understand dependencies and allows better planning for changes or migrations.

Performance monitoring is another important capability. The platform can highlight areas of the network experiencing packet loss, increased latency, or bandwidth congestion. These insights allow the network team to identify potential bottlenecks or misconfigurations before they affect users. If NSX-T is deployed, the platform can also show security group behaviour and suggest firewall rules based on real traffic patterns. This helps maintain a secure and efficient micro-segmentation policy.

Network alerts are generated when anomalies are detected. Examples include detection of unexpected inbound traffic, high latency between specific workloads, or sudden changes in communication patterns. These alerts allow the network team to act quickly and reduce the impact of issues.

Reports generated by Aria Operations for Networks include application dependency maps, firewall rule usage summaries, traffic volume reports, and network health assessments. These reports support regular operational reviews and help validate that the network is functioning as intended.

VMware Aria Operations for Networks – Monitoring Design

Monitoring Scope

VMware Aria Operations for Networks provides network visibility, flow analysis, and security posture monitoring across virtual and (optionally) physical networks.

In this design it is used to monitor:

NSX-T logical switches, routers, and edges

Traffic flows between VMs, tiers, and applications

Connectivity between on-premises data centres and cloud endpoints (if present)

Firewall and security rules (where integrated)

Data Sources and Collectors

Typical data sources:

vCenter Servers – inventory of VMs, port groups, and distributed switches

NSX-T Manager – logical networking, routing, and security rules

Physical devices (optional) – switches, routers, firewalls via SNMP, API, or flow exports

Collector/Proxy nodes are placed close to key data sources to reduce latency and minimise impact.

Dashboards and Visualisation

Default Aria Operations for Networks dashboards are used to provide:

Application Topology Views

End-to-end paths between application tiers

Identification of dependencies (e.g. web → app → DB)

Flow Analytics

Who is talking to whom, over which ports

East-west vs. north-south traffic patterns

Security Posture

Unused firewall rules

Potential micro-segmentation policies

These dashboards help to:

Validate network changes

Understand impact of outages or degraded links

Prepare for future segmentation or migration projects

Thresholds and Alerts

Aria Operations for Networks is configured to raise alerts for:

Loss of connectivity between key application components

Abnormal changes in traffic volume or patterns

NSX-T or network component health issues

Potential security issues, such as new unexpected flows or changes to policies

Conclusion

Monitoring a VMware environment effectively requires more than just collecting metrics or reviewing logs. You need a unified view that connects performance, events, and network behaviour. VMware Aria delivers exactly that through three tightly integrated components: Aria Operations, Aria Operations for Logs, and Aria Operations for Networks.

• Aria Operations shows how the environment is performing.
• Aria Operations for Logs shows what is happening behind the scenes.
• Aria Operations for Networks shows how everything communicates.

Together, they give operations teams the visibility they need to keep systems running smoothly, troubleshoot issues faster, and plan capacity with confidence. By using the full Aria suite, organisations can move from reactive firefighting to proactive management, reducing downtime and improving the overall stability of their environment.

Introduction

As virtualisation workloads expand, RAM alone can struggle to meet performance requirements. Starting with ESXi 8 Update 3, VMware now allows administrators to use NVMe SSDs as a memory tier, bridging the gap between volatile memory and persistent storage.

This feature can significantly boost performance, but setting it up isn’t always straightforward. Errors like “read-only file system” or “device already has an existing partition” are common when preparing NVMe drives.

In this post, I’ll walk you through a step-by-step configuration guide based on a real-world setup. You’ll see exactly how to clean, configure, and enable an NVMe device for memory tiering in ESXi 8 Update 3—while avoiding the common pitfalls.

Practical Tip: I used a Windows bootable USB stick, started the installer, and when prompted to choose an installation partition, I deleted all existing partitions. This ensured the NVMe drive was completely clean with no VMFS remnants before proceeding.

Step 1: Enable Memory Tiering in the Kernel

Before you can use any NVMe device as a memory tier, you need to enable memory tiering in the ESXi kernel:

esxcli system settings kernel set -s MemoryTiering -v TRUE

This allows ESXi to recognize NVMe storage as a valid memory tier candidate.

Step 2: Verify NVMe and Other Storage Devices

Next, confirm which devices are available on your host:

esxcli storage core path list

Typical output will show your NVMe device and any other storage. For example:

pcie.3a00-pcie.0:0-t10.NVMe____NVME_SSD_1TB____________________________0100000000000000
  Device Display Name: Local NVMe Disk
  Adapter: vmhba1
  Plugin: HPP
  State: active

This shows the NVMe is recognized but not yet configured as a tier device.

Step 3: Clean the NVMe Device

NVMe devices previously used for VMFS or other partitions often have leftover metadata. Attempting to create a tier device before cleaning will fail with errors like:

Selected device already has an existing partition. Aborting partition creation.

Make sure all datastores using the NVMe are unmounted. If the device is still claimed internally, a host reboot may be necessary to release any lingering claims.

Step 4: Create the NVMe Tier Device

Once the NVMe device is free of partitions and claims, create it as a tier device:

esxcli system tierdevice create -d /vmfs/devices/disks/t10.NVMe____NVME_SSD_1TB____________________________0100000000000000

If successful, ESXi now recognizes the NVMe as available for memory tiering.

Step 5: Set the Memory Tiering Percentage

Now configure what percentage of the host memory should be accelerated using the NVMe tier:

esxcli system settings advanced set -o /Mem/TierNvmePct -i 400

Note: The value must be a valid percentage (0–100). Using an invalid value like 600 or 800 will throw errors.

Step 6: Reboot the Host

Finally, reboot the ESXi host to apply all kernel and tiering changes:

reboot

After reboot, your NVMe device is now functioning as a memory tier, accelerating memory operations and improving performance for workloads that benefit from high-speed NVMe storage.

Tips and Gotchas

• Always unmount any datastore on the NVMe device before attempting to create a tier device.
• Tip I used Windows 11 installattion CD to deleted all the partions from the NVME drive
• If dd or partedUtil fail with read-only errors, it usually means ESXi still has an internal claim. A reboot is the cleanest fix.
• Check esxcli storage core path list to confirm the NVMe device is recognized and not in use.
• Only set /Mem/TierNvmePct after the tier device is created; otherwise, ESXi will throw a “bad parameter” error.

[root@localhost:~]   esxcli system settings kernel set -s MemoryTiering -v TRUE**
[root@localhost:~]         esxcli storage core path list
sata.vmhba0-sata.0:2-t10.ATA_____SAMSUNG_SSD_PM871a_2.5_7mm_256GB________S2XNNX0HA05452______
UID: sata.vmhba0-sata.0:2-t10.ATA_____SAMSUNG_SSD_PM871a_2.5_7mm_256GB________S2XNNX0HA05452______
Runtime Name: vmhba0:C0:T2:L0
Device: t10.ATA_____SAMSUNG_SSD_PM871a_2.5_7mm_256GB________S2XNNX0HA05452______
Device Display Name: Local ATA Disk (t10.ATA_____SAMSUNG_SSD_PM871a_2.5_7mm_256GB________S2XNNX0HA05452______)
Adapter: vmhba0
Controller: Not Applicable
Channel: 0
Target: 2
LUN: 0
Plugin: HPP
State: active
Transport: sata
Adapter Identifier: sata.vmhba0
Target Identifier: sata.0:2
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 33554432

pcie.3a00-pcie.0:0-t10.NVMe____NVME_SSD_1TB____________________________0100000000000000
UID: pcie.3a00-pcie.0:0-t10.NVMe____NVME_SSD_1TB____________________________0100000000000000
Runtime Name: vmhba1:C0:T0:L0
Device: t10**.NVMe____NVME_SSD_1TB____________________________0100000000000000**
Device Display Name: Local NVMe Disk (t10.NVMe____NVME_SSD_1TB____________________________0100000000000000)
Adapter: vmhba1
Controller: nqn.2014-08.org.nvmexpress_126f_NVME_SSD_1TB____________________________2020080100009
Channel: 0
Target: 0
LUN: 0
Plugin: HPP
State: active
Transport: pcie
Adapter Identifier: pcie.3a00
Target Identifier: pcie.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 262144
[root@localhost:~]         esxcli system tierdevice create -d /vmfs/devices/disks/t10.NVMe____NVME_SSD_1TB____________________
**0100000000000000

[root@localhost:~] esxcli system settings advanced set -o /Mem/TierNvmePct -i 400
[root@localhost:~]   reboot

so my NVME is here and ignore all the commands which I was trying to test to increse the memory it only take 400

After giving the above command reboot the esx host.

Here is a photo of booting for the first time

After the reboot

See it in action on my YouTube Channal

Login to the ESX and you can see the Memory 315 GB.

Proof that we are able to run vm ( btw I have enabled legacy CPU for this ESX8 server as I am using Intel NUC10 i7, which is not on the ESX8 Compatible list. )

At VMware Explore Las Vegas 2025, cybersecurity took center stage. With ransomware costs soaring and data breaches hitting even the largest global enterprises, Hock Tan and VMware leaders made one thing clear: cyber resilience is now a business survival issue, not just an IT responsibility.

The Rising Cost of Cyber Threats

The keynote highlighted how ransomware attacks and data leaks are redefining risk across every industry. Some sobering examples included:

Marks & Spencer: $440M lost after ransomware downtime crippled operations. Snowflake breach: A credential attack affecting 165 companies worldwide. U.S. Government Database leak: 2.9 billion records exposed, raising questions of national resilience.

These incidents underscore the stakes: one breach doesn’t just impact IT—it can destroy brand trust, erode customer confidence, and disrupt entire supply chains.

Introducing PCS Advanced Cyber Compliance

VMware’s answer is PCS (Private Cloud Services) Advanced Cyber Compliance—a new extension of the VMware Cloud Foundation platform designed to bake in resilience from day one.

Key capabilities include:

Multi-factor authentication & encryption: Protects data both at rest and in motion. Live patching & runtime protection: Vulnerabilities are addressed without downtime. Zero-trust security model: Assumes no implicit trust, enforcing strict access controls across every layer. vDefend & AVI Security: Deliver real-time visibility, intrusion detection, and web application protection. Continuous compliance enforcement: Ensures workloads meet regulatory standards (PCI, HIPAA, GDPR) automatically. Automated ransomware recovery: Detects, isolates, and recovers workloads while preserving compliance states.

This is security not as a bolt-on, but as a core design principle—reducing the need for endless third-party agents and tools.

Security vs. Agility – A False Trade-off

Traditionally, enterprises faced a painful choice: move fast or stay safe. Security was often seen as the blocker to innovation. VMware’s message at Explore 2025: those days are over.

With VCF 9.0 and PCS, organizations can now:

Deliver infrastructure “at the speed of the developer” with guardrails already in place. Scale AI workloads with built-in compliance enforcement. Automate disaster recovery to avoid the “all systems down” scramble.

Customer Perspective: Why This Matters

Enterprises like Barclays and Walmart shared how cyber resilience is not just IT hygiene—it’s essential for running mission-critical workloads.

Barclays: Needs PCI-compliant resilience as they scale AI workloads on-prem. Walmart: Operates thousands of global stores where downtime is simply not an option.

For both, PCS Advanced Cyber Compliance isn’t about passing audits—it’s about ensuring business continuity under pressure.

A New Era of Cyber Trust

Hock Tan closed this section with a reminder:

“Security is no longer a checkbox. It’s your license to operate.”

With PCS Advanced Cyber Compliance, VMware positions VCF 9.0 as the safest private cloud platform for enterprises navigating the age of ransomware. It provides not just protection but confidence—a foundation where IT can innovate without fear of compromise.

Key Takeaway

Cyber resilience is now business critical. With ransomware and breaches hitting harder than ever, VMware Cloud Foundation 9.0 delivers security by design, combining zero-trust principles, automated compliance, and rapid recovery.

For enterprises, this means fewer bolt-ons, faster operations, and a private cloud platform ready to withstand the threats of tomorrow.

Stay tuned for our next post in the series:

IT’s New Era – From Bottleneck to Business Enabler, where we explore how VCF 9.0 transforms IT teams into true partners in innovation.

VMware Kubernetes Service (VKS): Kubernetes Without the Complexity

One of the headline announcements at VMware Explore 2025 was the evolution of Kubernetes within VMware Cloud Foundation through the VMware Kubernetes Service (VKS).

For years, Kubernetes adoption has been hindered by complexity. Enterprises struggled with multi-cluster sprawl, uneven compliance, patching headaches, and the lack of operational expertise. VKS directly tackles these challenges by embedding Kubernetes as a fully managed, enterprise-grade service within vCF 9.0.

Why VKS Matters

Lifecycle Automation: VKS automates the full Kubernetes lifecycle—from cluster provisioning to patching, upgrades, and decommissioning—without requiring manual intervention. Consistency Across Environments: Whether running in a central data center, regional hub, or edge location, VKS provides a consistent operational model. Integrated Security: Security is enforced at the platform level, including RBAC, identity integration via Pinniped, network policies, and continuous compliance checks. Unified Developer Experience: Developers interact with Kubernetes the same way they would in the public cloud, but IT operations are unified and simplified under vCF.

Image suggestion: Screenshot or diagram of the VKS lifecycle workflow (cluster creation → monitoring → scaling → upgrade).

Developer Velocity at Scale

With VKS, developers can:

Spin up CNCF-compliant clusters directly through self-service portals or GitOps workflows. Use familiar toolchains such as VS Code, GitHub, Helm, and CI/CD pipelines without disruption. Seamlessly move between containerized workloads and traditional VMs on the same vCF platform.

Meanwhile, IT teams maintain centralized visibility and governance—ensuring developers move fast without creating compliance or security risks.

VKS in the Real World

Imagine a financial services company running trading apps and AI models side by side. With VKS:

Dev teams deploy microservices in Kubernetes for real-time transaction monitoring. Data teams spin up GPU-enabled clusters for AI-driven risk analysis. IT maintains audit trails, compliance enforcement, and disaster recovery policies automatically.

The result is not just agility, but confidence—something enterprises can’t afford to compromise.

Key Point on VKS: By embedding Kubernetes directly into vCF 9.0, VMware has eliminated the barriers to enterprise-scale adoption—turning what was once a fragmented, complex ecosystem into a streamlined, policy-driven service.

.

This unified approach reduces operational overhead while empowering organizations to focus on innovation, not integration.

Canonical – Ubuntu embedded into VCF

The partnership with Canonical, the company behind Ubuntu, was another major highlight. By directly embedding Ubuntu into vCF, VMware strengthens both performance and security for enterprise cloud-native environments.

Key benefits include:

Chiseled Containers: Minimal, purpose-built containers containing only essential components—reducing attack surface and improving security posture. vGPU-ready Infrastructure: AI/ML workloads can now run with native GPU drivers pre-integrated, making vCF the fastest path to AI-ready infrastructure. Long-Term Supported (LTS) Ubuntu Images: Enterprises get fully maintained, hardened Ubuntu releases supported by Canonical—eliminating patching and upgrade guesswork.

This collaboration ensures developers and IT teams benefit from the best of both worlds: VMware’s enterprise-grade infrastructure with Ubuntu’s cloud-native agility.

Empowering Developer Autonomy with IT Governance

One of the most important themes of the session was balance: developers need freedom to innovate, while IT needs control to maintain compliance and governance. VMware’s vCF delivers exactly that.

Robust multi-tenancy: Business units like legal, finance, engineering, and operations can each consume resources independently under central IT policy. Self-service consumption: Developers gain direct access to Kubernetes, VMs, storage, and networking resources without waiting for IT tickets. Policy-driven governance: IT admins can predefine guardrails while still enabling flexibility for developers.

Examples included services like:

Private AI as a Service – Secure access to AI images and toolchains, ready to deploy in private environments. Database-as-a-Service (DBaaS) – Pre-approved versions of Postgres, MySQL, and SQL Server delivered instantly with compliance controls.

Image suggestion: Demo screenshot showing developers launching Kubernetes + AI services from a self-service catalog.

This dual approach makes it possible for enterprises to move fast without breaking things—a recurring theme throughout the keynote.

Conclusion: A New Era of Cloud-Native Infrastructure

The message from VMware Explore was clear: Kubernetes isn’t just an add-on to vCF—it’s a first-class citizen. With seamless integration, CNCF compliance, Ubuntu collaboration, and AI-ready infrastructure, VMware is positioning vCF as the most secure, most complete, and easiest-to-manage private cloud platform for cloud-native workloads.

As organizations embrace containers, microservices, and AI-driven applications, vCF with Kubernetes and Ubuntu provides a future-proof foundation that scales without sacrificing security or governance.

Image suggestion: Closing keynote slide with “Cloud-Native at Scale” headline.

Key Takeaway: VMware is delivering a streamlined, enterprise-ready Kubernetes platform with vCF 9.0—uniting the developer’s need for speed with IT’s need for control.