VMware vSphere Foundation (VVF) 9 administrators operate a platform where compute, storage, and networking are tightly connected. A datastore can be healthy while virtual machines remain unreachable because the network is wrong; a distributed switch can be healthy while a storage VMkernel path is broken; a cluster can show spare capacity while one storage policy or uplink constraint prevents a workload from moving.
The current VMware VCP-VVF Administrator blueprint expects practical knowledge of vSphere, vSAN, networking, availability, performance, and troubleshooting. Within VMware certifications, the useful operating model is therefore end to end: understand the data path from virtual machine to datastore and the packet path from virtual NIC to physical network, then verify each layer when symptoms cross boundaries.
Know what VVF 9 includes before troubleshooting it
VVF 9 is built around vCenter and ESX with vSAN and VCF Operations capabilities in the product family. It can support traditional virtual-machine workloads as well as Supervisor-based workloads. That means administrators need the classic vSphere fundamentals while also understanding the newer VVF packaging and operational context.
Current Broadcom documentation treats VVF as a subset of the broader VCF platform stack, but its lifecycle and entitlement model is distinct from full VCF. This matters because support procedures, downloads, and some lifecycle workflows are organized under VVF rather than the older standalone vSphere product pages.
When troubleshooting, begin by confirming the environment type and release. A procedure written for vSphere 8, VCF 5.x, or VCF 9 may describe a similar component but a different management workflow. The underlying networking and storage concepts are durable; the operational wrapper can change.
Datastores present storage capacity to vSphere workloads
vSphere can present several storage types to virtual machines. VMFS uses block storage, NFS presents file-based datastores, vSAN aggregates local devices across cluster hosts, and vVol-based designs integrate storage policy more directly with an external array. The existing overview of vSphere storage types is useful background for these distinctions.
The administrator’s task is not to memorize storage names in isolation. Each datastore has a connectivity path, capacity model, failure behavior, multipathing or network dependency, and operational owner. A VMFS datastore over Fibre Channel fails differently from an NFS datastore whose network path is broken. vSAN adds cluster membership, disk groups, policies, resynchronization, and network health to the troubleshooting model.
Capacity should be evaluated as usable capacity, not raw device size. Snapshots, policy overhead, thin provisioning, rebuild requirements, and growth can all consume space that a simple free-capacity percentage hides.
vSAN turns storage health into a cluster-wide concern
vSAN distributes data across hosts according to storage policy. This can simplify operations because policy expresses the desired availability and performance characteristics, but it also means storage health depends on host membership and network communication. A host can be powered on and still be unhealthy from the vSAN perspective if it is partitioned from the cluster.
Broadcom support cases for VCF/VVF 9.x show how VLAN errors, MTU mismatches, or physical switch configuration can partition vSAN traffic. When hosts cannot communicate correctly, storage policy cannot be satisfied and deployment or remediation workflows may fail even though the individual disks look healthy.
Administrators should monitor object compliance, capacity, resynchronization, disk health, and the vSAN network together. Maintenance operations should account for data movement and policy impact before a host is evacuated or rebooted.
Standard and distributed switches solve different operational problems
A vSphere Standard Switch is configured per host. A vSphere Distributed Switch (VDS) centralizes switch configuration across hosts through vCenter. Distributed switching reduces configuration drift and supports richer operational features, which is why it is common in clustered enterprise environments.
The VDS does not eliminate physical networking. Its uplinks still map to real NICs and upstream switches. Port groups, VLAN tags, teaming policy, MTU, and load-balancing behavior must agree with the physical network. A perfectly configured distributed port group cannot carry traffic if the upstream trunk omits its VLAN.
The network trunking fundamentals remain relevant at this boundary. VVF administration adds centralized switch state, host membership, VMkernel services, and lifecycle requirements on top of those Ethernet concepts.
VMkernel adapters carry infrastructure traffic
VMkernel adapters are used for host-level services such as management, vMotion, vSAN, and other infrastructure traffic. Each service has different performance, reachability, and isolation requirements. A VM can have normal guest networking while vMotion or storage traffic is failing because those services use separate VMkernel interfaces.
Troubleshooting should confirm IP address, subnet, VLAN, MTU, service bindings, route behavior, and physical uplinks for the relevant VMkernel adapter. Do not test only the management interface and conclude that host networking is healthy. The packet path for vSAN or vMotion may be different.
Isolation decisions should be intentional. Separate VLANs or uplinks can reduce contention and blast radius, but they consume interfaces and switch capacity. Shared uplinks can be efficient if teaming, quality of service, and failure-state capacity are designed correctly.
Uplink redundancy must work during the failure state
Two physical NICs do not automatically provide useful redundancy. They need independent upstream paths where possible, consistent trunking, and a teaming policy that produces the expected behavior when a link or switch fails. If both uplinks terminate on one physical switch, the design may survive a cable failure but not a switch failure.
Broadcom’s current VCF 9 deployment guidance also reinforces that supported designs can require multiple pNICs on distributed switches. The exact requirement depends on architecture and deployment model, but the operational principle is broader: design the remaining path to carry the traffic when one uplink is unavailable.
Administrators should test failover rather than assuming it. Planned maintenance on one switch or uplink is a useful opportunity to confirm that management, storage, vMotion, and virtual-machine traffic remain available and that no hidden VLAN or MTU mismatch appears only on the standby path.
VLAN and MTU errors often look like higher-level platform failures
Layer 2 configuration mistakes can produce confusing symptoms. A wrong VLAN can make a service completely unreachable. An MTU mismatch can allow small packets while breaking larger encapsulated or storage traffic. Inconsistent native VLAN behavior can create intermittent reachability that appears to be a host or application problem.
The existing explanation of VLANs helps with the fundamentals, but VVF troubleshooting should trace the same VLAN through the distributed port group, host uplink, physical switch trunk, and routed gateway. The configuration is only correct when the entire path agrees.
MTU should be verified end to end as well. Increasing it on a VDS without changing VMkernel interfaces or physical switches creates a partial configuration that may fail under load. Use targeted connectivity tests that exercise the expected packet size and path.
Troubleshoot storage by following the dependency chain
When a datastore is slow or unavailable, start by identifying its storage model. For NFS, inspect network reachability, VLANs, VMkernel binding, server health, and export permissions. For block storage, inspect path state, adapters, fabric or iSCSI connectivity, multipathing, and array health. For vSAN, inspect cluster membership, disk health, object compliance, capacity, and the vSAN network.
Then separate scope. Is one host affected, one datastore, one cluster, or every workload using the storage system? A single-host problem often points to adapter, path, or host configuration. A cluster-wide problem points more strongly to shared storage, network, policy, or management dependencies.
Finally, check recent change history. Storage incidents often follow firmware updates, switch changes, host remediation, certificate changes, or policy edits. Correlating the first symptom with the last infrastructure change can reduce a large troubleshooting tree quickly.
Troubleshoot networking by moving from virtual to physical or physical to virtual
For a virtual-machine connectivity problem, inspect the guest interface, virtual NIC, port group, VDS or standard switch, host uplink, physical switch port, VLAN, gateway, and upstream route or firewall. For a host-service problem, substitute the relevant VMkernel adapter for the guest vNIC and follow the same layered process.
Scope again matters. If every VM on one host loses the same VLAN, inspect the host’s uplink and switch configuration. If one VM is affected, inspect its port group, guest settings, and security policy. If all hosts lose one network simultaneously, investigate shared upstream switching, routing, or VLAN changes.
Use counters and evidence instead of repeatedly changing settings. Link state, dropped packets, teaming state, port status, ARP or neighbor behavior, and switch logs can show where traffic stops. Random changes make the original fault harder to reconstruct.
Operate storage and networking as one availability system
In VVF 9, storage and networking meet in vSAN, NFS, iSCSI, vMotion, backup traffic, Supervisor services, and many management workflows. A network maintenance event can therefore become a storage incident, and a storage recovery operation can become a network-capacity event.
Change planning should consider these interactions. Before modifying uplinks or distributed switches, identify storage and VMkernel traffic that shares the path. Before placing hosts into maintenance, confirm both compute headroom and storage policy impact. Before expanding a cluster, validate that the new host matches the expected switch, NIC, MTU, and storage design.
The best VVF administrators learn to think in paths rather than products. Trace where data lives, how packets reach it, which policies control placement, and which physical components carry the traffic. That model makes both exam objectives and real troubleshooting much easier to reason about.