vSphere Foundation 9.0 Administrator (2V0-16.25)

VVF Architecture Overview#

VVF Definition:

vSphere Foundation combines vSphere 9.0, vSAN 9.0, and vSphere Kubernetes Engine (formerly Tanzu Kubernetes Grid) without NSX for networking and without VCF Automation/Operations stack. VVF targets medium-sized deployments requiring converged infrastructure but not the full enterprise VCF breadth.

VVF vs VCF:

VCF includes NSX (enterprise networking/security), VCF Automation (vRealize Orchestrator), and VCF Operations (vRealize Operations advanced). VVF omits these, reducing license footprint and operational complexity while maintaining vSphere, vSAN, and Kubernetes.

VVF Component Stack

• vSphere 9.0 (vCenter + ESXi):
• Management plane (vCenter Server Appliance 9.0) and compute hosts (ESXi 9.0 minimum)
• vSAN 9.0:

Converged storage with automatic deduplication & compression (ESA standard), native replication, witness nodes for 2-node clusters

vSphere Kubernetes Engine:

Kubernetes on ESXi clusters via vSphere Supervisor control plane

vSphere Lifecycle Manager (vLCM):

Image-based ESXi management, firmware/driver updates, desired state tracking

No NSX:

Traditional vSphere networking (vDS/vSS) only; no Geneve, no micro-segmentation, no advanced routing

Licensing Tiers

• vSphere Foundation Standard:
• vSphere Standard, vSAN Standard, vSphere Kubernetes Engine
• vSphere Foundation Advanced:
• vSphere Advanced, vSAN Advanced, plus AppDefense & vSphere DRS
• vSphere Foundation Enterprise:
• Enterprise editions of all components, plus Skyline Advisor, Workload Optimization

Typical Deployment Architecture

┌─────────────────────────────────────────────────────────┐
│                   vCenter Server (VCSA 9.0)             │
│  (Tiny: 2vCPU/8GB | Small: 4vCPU/16GB | Med: 8/32GB)   │
└──────────────────┬──────────────────────────────────────┘
                   │
        ┌──────────┼──────────┐
        │          │          │
    ┌───▼──┐   ┌──▼───┐   ┌──▼───┐
    │ESXi-1│   │ESXi-2│   │ESXi-3│  (min. 3 nodes for vSAN quorum)
    └───┬──┘   └──┬───┘   └──┬───┘
        │         │          │
    ┌───▼─────────▼──────────▼───┐
    │   vSAN Cluster             │
    │  (RAID-1 or Erasure Code)  │
    └────────────────────────────┘

Key Takeaways

• For exam: Know the six vSAN node roles (Coordinator, Witness, Leader, Aggressor) and how quorum is maintained in 2-node + witness topology.

vSphere Core Administration#

vCenter Server Appliance (VCSA) Sizing & Deployment

• Size
• vCPU
• RAM
• Storage
• Max VMs
• Tiny
• 2
• 8 GB
• 160 GB
• 10
• Small
• 4
• 16 GB
• 290 GB
• 100
• Medium
• 8
• 32 GB
• 580 GB
• 400
• Large
• 16
• 64 GB
• 2.1 TB
• 1000
• X-Large
• 24
• 128 GB
• 3.2 TB
• 4000

VCSA HA:

VVF does not include vCenter High Availability (vCenter HA requires 3 VCSA instances in Enhanced Linked Mode). Single VCSA deployments are standard; backup/restore strategy essential.

ESXi Installation & Configuration

ESXi 9.0 boot parameters

allowNonSSLConnections=true (deprecated, avoid)
sslThumbprints=vCenter_cert_hash (optional auto-registration)

Boot from USB/ISCSI/FC only; no network boot

BIOS: HT (Hyper-Threading), AES-NI (vSAN encryption), VT-d (SR-IOV)

Licensing:

Serial numbers bound to hardware; upgrade from Standard→Advanced→Enterprise triggers automatic license pool reallocation via vCenter.

Networking: vDS vs vSS

Storage: VMFS, NFS, vVols

VMFS 5 and VMFS 6 (there is no VMFS 7 or 8):
Used for BLOCK datastores (FC, iSCSI, local SCSI/NVMe) - vSAN does NOT use VMFS at all; it presents its own object-based vsanDatastore. vSphere treats VMFS, NFS, vSAN and vVols as four distinct datastore types. VAAI support (primitives: xcopy, atomic test-set, zero), automatic space reclamation

NFS 4.1:

Stateless, multipath failover via DNS; VAAI support (server-side copy for Linked Clones)

vVols (Virtual Volumes):

Per-VM VASA storage policies, automated tiering, granular snapshots/replication (requires VASA provider)

vSAN datastore:

Transparent to VM admin; vSAN Cluster Network Service (VCNS) advertises vSAN capacity as datastore

VM Management & Templates

Content Libraries:

Published (read-only, synced from upstream) or Subscribed (pull content from publisher). VVF supports OVF/OVA templates, ISO images, scripts.
vSphere Deployed Clusters (new in 9.0):

Git-like resource versioning for infrastructure-as-code (IaC)

VM Templates:

Cloning requires network booting or cloud-init; sysprep for Windows

Host Profiles (vSphere Profile-Driven Storage)

Host Profile: Captures ESXi configuration state as template

Use case: Apply consistent settings (NTP, DNS, syslog) across cluster

vCenter UI → Configure → Host Profiles
→ Create profile from reference host
→ Attach profile to cluster
→ Remediate (apply) on non-compliant hosts

Distributed Virtual Switch (vDS) — Production Recommended

Centralized management:

Policies apply uniformly across all hosts in vDS version (6.x/7.x/8.x)

Port groups:

VLAN-based (802.1Q) or vSAN traffic type (management, vMotion, vSAN, FT)

NIC Teaming:

Route Based on IP Hash (LACP-recommended):

LACP protocol negotiated with physical switch, deterministic load balancing, requires all uplinks active

Route Based on Originating Port:

Simpler, works with dumb switches, potential unbalanced load

Beacon Probing:

Teaming failover via ARP, deprecated in vDS 7+

LACP Configuration:

vDS MAC address (Link Aggregation Control Protocol) must match LAG on switch; 60sec bond timer default

vSAN Network Isolation:

Separate vDS or VLAN (e.g., VLAN 100) for vSAN traffic; enable Jumbo Frames (MTU 9000)

vMotion Optimization:

Separate port group, TCP/IP Stack, TCP MSS clamping (1500 MTU default, 1450 for overlay)

🔬 Lab: Deploy vDS & Configure NIC Teaming

Create new vDS (6.7+ recommended): vCenter UI → Networking → New Distributed Switch

Add all ESXi hosts to vDS (1-pass migration: create VM port group, migrate management vmk, then data vmks)
Create port groups: Management, vMotion (TCP/IP Stack), vSAN (VLAN 100, MTU 9000)

Configure NIC Teaming to "IP Hash" with LACP

Verify on switch: LACP interface shows active state, etherchannel summary shows all links up
Test: vmkping -I vmk_vsan_ip vsan_gateway_ip (should succeed with <2ms RTT)

Standard vSwitch (vSS) — Legacy/Edge Only

Host-local only; no policy replication

• NIC Teaming limited: Active-Standby, Route by Physical NIC ID, IP Hash without LACP
• No LACP support; no central management
• Used for single-host labs or edge deployments

Key Takeaways

• For exam: VCSA sizing depends on workload count (Tiny=10 VMs, Small=100 VMs). Know the sizing table by heart for capacity planning questions.
• For exam: vDS is enterprise standard; standard vSwitch for legacy/edge only. Know NIC teaming modes and LACP configuration for advanced networking questions.
• For exam: vSphere supports VMFS5 and VMFS6 only - there is no VMFS 7 or 8, and vSAN does not use VMFS (it is an object store, vsanDatastore). VMFS is for block LUNs; NFS for file-based datastores. Understand VAAI primitives (xcopy, atomic test-set) and when to use each.

vSAN in VVF Context#

vSAN 9.0 Architecture: Standalone (No VCF Orchestration)

vSAN in VVF is deployed and managed directly via vCenter (no SDDC Manager). Quorum and resilience handled automatically via intelligent placement.

Cluster Topologies

3-Node Cluster:

Native quorum (2-of-3 majority). No witness required. Tolerates 1 host failure.

2-Node Cluster + Witness VM:

Witness appliance (1-vCPU, 16GB disk) on third host or external array. Requires split-brain handling.

Stretched Cluster (Multi-Site):

Hosts in Site-A and Site-B with witness in Site-C. RPO 0 with synchronous replication, RTO <1min failover.

Single-Node (Proof-of-Concept):

vSAN enabled on lone ESXi; no replication, no tolerance.

vSAN Disk Groups & Capacity

Disk group: 1 cache tier (SSD) + N capacity tier (HDD or SSD)

vSAN 9.0: EXPRESS Storage Architecture (ESA) standard [ESA = Express, not Elastic]

- Compression is INLINE and always on. Deduplication is cluster-wide and post-process,

but arrived only in VCF 9.0 P01 (limited) and went GA in VCF 9.1 - vSAN 8 ESA has compression only.

- ESA is NVMe-flash ONLY: at least one NVMe TLC device per storage pool.

SAS/SATA devices and RAID/tri-mode controllers are NOT supported. There is NO HDD support.

Only OSA (Original Storage Architecture, disk groups) can use magnetic media, in hybrid mode.

OSA disk group (hybrid): cache SAS/SATA SSD or PCIe flash + capacity 7.2K SAS/NL-SAS HDD [hybrid OSA deprecated as of the vSAN 9.0 announcement]
ESA storage pool: NVMe TLC only (min 1.6 TB production drives, 4+ devices/host recommended, host RAM >=128 GB)

vSAN File Services (vSAN FSA)

Distributed NFS server built into vSAN 9.0:

Use case:

Multi-tenant workloads requiring POSIX-compliant file access (Kubernetes persistent volumes, shared home dirs)

Deployment:

vSAN FSA namespace created on vSAN cluster; mounts to containers/VMs via NFSv3/v4

Replication:

File shares replicated via vSAN write-back, same FTT rules as VMs

vSAN Encryption

Data-at-Rest (TKMS):

Transparent Key Management Server integration (Thales, Gemalto HSMs). Per-VM encryption policy via vSAN policy engine.

Data-in-Transit (vSAN Network Encryption):

TLS 1.2+ between vSAN nodes. Enable: vSAN cluster UI → Encryption → Enable Network Encryption

Performance impact:

5-10% CPU overhead for at-rest (depends on HSM latency), <2% for in-transit (AES-NI hardware acceleration)

Deduplication & Compression (ESA)

vSAN Express Storage Architecture (ESA) deduplication is cluster-wide and

post-process and asynchronous

(note: ESA dedup is NOT in vSAN 8 - limited availability in VCF 9.0 P01, GA in VCF 9.1. OSA dedup is the opposite: inline at destage, scoped to a single disk group):

Threshold:

Triggered when used capacity > 80% of available space or idle cycles detected

Block size:

4KB fingerprint, 64KB max dedup unit

Savings:

50-75% common (identical VMs, linked clones, test/dev environments)

Trade-off:

Dedup read-hit requires SHA-512 lookup; slower on HDDs. Verify workload performance in lab.

vSAN Performance Service

vSAN Performance Service: Real-time telemetry collection

Enabled by default; aggregated to vCenter UI (Performance tab)

Metrics collected: Latency (read/write), Throughput, IOPS, Congestion

Granularity: 5min intervals, 24-hour retention

Dashboard: vSAN cluster → Performance graphs

vSAN Resilience & FTT (Fault Tolerance Threshold)

FTT=0:
No replication (not recommended production)
FTT=1 (RAID-1):
2-way mirror, tolerate 1 host/disk failure. Space overhead = 2x
FTT=2 (RAID-6):

Erasure code (4+2 stripe, NOT 6+2), tolerate 2 failures. Space overhead = 1.5x, minimum 6 hosts (7 recommended)

FTT=3:

Rarely used; RAID-1 mirroring only, space overhead 4x, minimum 7 hosts
RAID overhead reference (verified): RAID-1 FTT=1 = 2.0x (3 hosts); RAID-1 FTT=2 = 3.0x (5 hosts); OSA RAID-5 3+1 FTT=1 = 1.33x (4 hosts); ESA RAID-5 is ADAPTIVE - 2+1 = 1.5x below 6 hosts (3 host min), 4+1 = 1.25x at 6+ hosts (5 host min), re-evaluated 24h after a host-count change; RAID-6 4+2 FTT=2 = 1.5x (6 hosts min, 7 recommended). VCF 9.1 Auto-RAID retires the 4+1 scheme: RAID-5 is always 2+1 at 3-5 hosts, RAID-6 4+2 at 6+.

Key Takeaways

• Exam question tip: FTT=1 with 3-node cluster = 1 host failure tolerated. FTT=2 with 4-node cluster = 2 host failures tolerated.

vSphere Lifecycle Manager (vLCM)#

vLCM Overview: Image-Based vs Baseline (Legacy)

vLCM (v9.0 recommended):
Single ESXi image (includes OS, drivers, firmware) applied to cluster. Replaces vSphere Update Manager (VUM) baseline approach.

Baseline (deprecated in 9.0):

Old method — patches applied incrementally

Image-based:

Atomic replace of entire ESXi installation (clean, reproducible, rollback easier)

Cluster Image Composition

Cluster image = ESXi base + OEM customization image (HW drivers/firmware)

Workflow: Download from VMware, apply OEM drivers, validate, deploy to cluster

1. vCenter → Clusters → Update Manager (or Lifecycle)

2. Create cluster image: Select ESXi 9.0 ISO + OEM image (Dell, HP, Lenovo)
3. Attach image to cluster (desired state)
4. Preview mode (dry-run) recommended before remediate
5. Remediate cluster: Hosts updated in rolling fashion (HA maintains uptime)

Hardware Compatibility & VCG (VMware Compatibility Guide)

Before image deployment, verify:

Hardware certified in VMware Compatibility Guide (VCG) for ESXi 9.0

OEM image includes certified driver versions

Firmware versions match OEM recommendations (e.g., Dell iDRAC, Broadcom HBA)

vLCM with NSX (N/A in VVF)

Note: NSX Edge node images also managed via vLCM in VCF. VVF does not include NSX.

Firmware Updates via vLCM

Firmware updates (e.g., BIOS, iLO, SSD) managed through OEM image

vLCM integrates with hardware vendor Lifecycle Management platforms

OEM Examples:

• Dell: iDRAC (iLO for HP, RedFish API for modern servers)
• Firmware bundle downloaded via OEM portal, included in OEM customization image
• vLCM applies automatically on cluster remediation

Key Takeaways

• For exam: vLCM replaces VUM baseline approach with atomic image-based updates. Know the cluster image composition (ESXi base + OEM image) and remediation workflow.
• For exam: Preview mode is essential before cluster remediation to validate compatibility. Always check VCG for hardware certification before deploying OEM images.
• For exam: Firmware updates managed through OEM customization image (Dell iDRAC, HP iLO). vLCM integrates with OEM platforms for automated firmware delivery.

Monitoring & Operations#

vSphere Alarms & Events

Events:

Historical log of configuration/runtime changes (powered on VM, host connection lost, etc.)

Alarms:

Triggered on event conditions; actions configurable (email, SNMP, scripts)

Custom alarms:

vCenter UI → Alarms → Define custom triggers (e.g., CPU >80%, memory <10%)

Performance Charts

vCenter UI → VM/Cluster → Performance tab provides real-time and historical graphs:

CPU:

Used%, Ready%, Co-stop%, Overlap%, Guest % (useful for identifying scheduling contention)

Memory:

Used, Shared, Ballooned, Swapped (swapped = bad; indicates overallocation)

Disk (IOPS/Latency):

Read/Write latency <5ms ideal, >20ms = storage contention

Network:

Throughput Mbps, Packets dropped (indicates physical NIC saturation or vNIC issues)

vSAN Health Check

Automated diagnostic suite; run manually or on schedule:

vSAN Health Check categories:

- Cluster: Quorum, unicast agent reachability

- Storage: Disk claims, controller mode, encryption certs

- Network: Latency <5ms, packet loss <1%, jumbo frames MTU 9000

- Limits: Max objects, max hosts (9.0 = 64 hosts max per cluster)

- vSAN FSA (if enabled): Namespace health, share accessibility

Access: vCenter UI → Cluster → vSAN → Health

Skyline Health (Proactive Support)

Cloud-connected diagnostic tool; requires VMware account:

Capability:

Analyzes logs, compares against millions of deployments, flags configuration drift/risks

Alerts:

Config/capacity/performance warnings (e.g., "Host memory 95% used" before full)

Lifecycle:

HW end-of-life warnings, security patch recommendations

Setup:

vCenter UI → Administration → Skyline → Register cluster, enable data collection

Proactive HA (HA Redundancy)

vSphere HA monitors host health via isolation detection; isolates non-responsive hosts to prevent split-brain:

Heartbeat dampers:

Isolation addresses (configurable) tested via ICMP; if all fail, host assumed isolated

VM restart policies:

High (restart immediately), Medium (wait 30s for cluster response), Low (wait 300s)

Configuration:

vCenter UI → Cluster → HA → Click Edit → Set restart priority, isolation response

vSphere Health Checks (vSUM-equivalent)

ESXi version check: All hosts running same ESXi version

VM snapshots: Age >14 days flags performance risk

Disk I/O queue depth: >4 indicates potential contention

vMotion network: Dedicated NIC recommended

Troubleshooting Integration

📄 Skyline Advisor Documentation
📄 vSAN Health Check Reference

Key Takeaways

• For exam: Understand Performance Chart metrics—CPU Ready%, Memory Swapped, Disk latency >20ms = problem. These indicators critical for troubleshooting workload performance.
• For exam: vSAN Health Check run before major operations. Categories: Cluster (quorum), Storage (disk claims), Network (latency <5ms, jumbo frames), Limits (64 hosts max).
• For exam: Skyline proactive support flags drift/risks. HA isolation addresses test via ICMP; restart policies (High/Medium/Low) control VM restart timing on host failure.

VVF vs VCF — Precise Positioning (Admin Track)#

vSphere Foundation (VVF) bundles core virtualization technologies without orchestration/automation layers. Understanding what VVF includes and excludes is critical for product positioning and customer advisory.

VVF Component Bundle

VVF (vSphere Foundation) Includes:

---

1. vSphere 8.x (Hypervisor + vCenter)

• ESXi 8.x kernel and runtime
• vCenter Server (UI, API, management)
• vSphere DRS, HA, vMotion, Storage vMotion
• vSAN 8.x (HCI storage)

2. vSAN Essentials (Simplified storage management)

• Cluster creation UI
• Health monitoring
• Component placement (automatic)
• No advanced features (capacity forecasting, cost modeling)

3. Tanzu Kubernetes (Container orchestration)

• Supervisor Service (Kubernetes control plane on vSphere)
• Tanzu Kubernetes Grid (TKG) for managed clusters
• kubectl, container runtime (containerd)
• No NSX (uses basic L3 forwarding, external LB)

4. Aria Operations for Logs (Basic telemetry)

• Log aggregation from ESXi, vCenter, vSAN
• Simple dashboards
• No advanced analytics or forecasting

5. vSphere+ Entitlements (Cloud-connected features)

• Cluster health insights (VMware cloud-side analysis)
• vSphere+ security hardening
• Update recommendations

VVF Does NOT Include:

---

1. VCF Operations (Advanced analytics)

• No capacity forecasting engine
• No cost chargeback
• No compliance engine
• No custom dashboards/views

2. VCF Automation (Cloud assembly, orchestration)

• No service broker
• No cloud templates
• No ABX actions
• No approval workflows

3. NSX (Networking & security)

• No overlay networking
• No micro-segmentation
• No distributed firewall
• No advanced load balancing

4. Aria Suite (Advanced IT operations)

• No Aria Automation (formerly vRealize Automation)
• No Aria Operations (formerly vRealize Operations)
• No Aria Automation Config (formerly Puppet)

5. vSAN Max (Disaggregated storage)

• Only HCI mode (colocated compute+storage)

VVF Architecture Overview

VVF Stack (Layer Model):

┌──────────────────────────────────────────┐
│  Applications & Workloads                │
│  (VMs, Kubernetes Pods, Containers)      │
└──────────────────────────────────────────┘
         ↑
┌──────────────────────────────────────────┐
│  Tanzu Kubernetes                        │
│  (Supervisor Service, TKG clusters)      │
└──────────────────────────────────────────┘
         ↑
┌──────────────────────────────────────────┐
│  vSphere 8.x                             │
│  (Compute, vMotion, HA, DRS)             │
└──────────────────────────────────────────┘
         ↑
┌──────────────────────────────────────────┐
│  vSAN 8.x (HCI)                          │
│  (Storage, RAID, Dedup, Compression)     │
└──────────────────────────────────────────┘
         ↑
┌──────────────────────────────────────────┐
│  Hardware                                │
│  (Servers, Disks, Network)               │
└──────────────────────────────────────────┘

Notable Absence: NSX layer

(VVF uses native vSwitch/DVS, external LB for Kubernetes)

VVF vs VCF Detailed Comparison

• Feature
• VVF
• VCF
• Hypervisor (ESXi)
• Yes (8.x)
• Yes (8.x-9.x)
• vSAN Storage
• Yes (HCI mode only)
• Yes (HCI + Max disaggregated)
• NSX Networking
• No
• Yes (NSX 4.x, overlay + micro-segmentation)
• Tanzu Kubernetes
• Yes (basic, Supervisor only)
• Yes (full Supervisor + TKG + Tanzu Services)
• Advanced Analytics (VCF Operations)
• No (Aria Ops Logs only, basic)
• Yes (capacity, forecasting, compliance, cost)
• Automation (VCF Automation)
• No
• Yes (cloud templates, service broker, ABX)
• Multi-Cluster Management (Fleet Manager)
• No
• Yes (10+ clusters under 1 pane)
• Licensing Model
• Subscription per cluster
• Subscription with module options (optional Ops, Automation)

Upgrade Path VVF → VCF

Upgrade Scenario:

Customer has VVF 8.0, wants to add VCF Operations for analytics

Procedure (In-place):

1. Cluster remains on vSphere 8.x + vSAN (no change)
2. Deploy VCF Operations as separate cluster

(or standalone, if less than 10k objects)

3. Configure adapters to collect from vSphere + vSAN
4. Cost: VCF Operations subscription added (VVF + Operations = VCF)

Upgrade VVF + VCF Ops → Full VCF:

1. Add NSX 4.x to existing vSphere clusters
2. Deploy VCF Automation (cloud templates, service broker)
3. Consolidate: VCF Operations + VCF Automation under VCF licensing

Timeline: Phased (NSX first, then Automation, or parallel)

Cost: Subscription tier upgrades at each step

Use-Case Decision Framework

Use VVF when:

• Single cluster deployment (3-64 hosts)
• Basic Kubernetes (no advanced networking)
• Simple Kubernetes storage (vSAN volumes)
• No multi-cluster federation
• No network security (internal-only workloads)
• Budget: ~$30k-50k per cluster/year

Example Customer: Mid-market, 6-host cluster, SMB on Kubernetes

Use VCF (full) when:

• Multi-cluster (3+ clusters, Fleet Manager)
• Advanced Kubernetes (multi-tenancy, network policies)
• Com

Key Takeaways

• For exam: VVF = vSphere + vSAN + basic Tanzu (no NSX, no Aria Ops/Automation). VCF = full stack with NSX, advanced analytics, automation, and multi-cluster.
• For exam: Know the VVF vs VCF comparison table—what's included/excluded per product. Critical for product positioning and customer advisory scenarios.
• For exam: Upgrade path VVF → VCF is phased (NSX first, then Automation). Understand cost model difference (per-cluster subscription vs. tiered modules).

Virtualization Fundamentals (Objective 2.1)#

Blueprint Objective 2.1 — Virtualization Fundamentals

Principles of Virtualization

Virtualization abstracts physical hardware into logical resources, enabling multiple operating systems to run concurrently on a single physical server. The hypervisor (ESXi in VMware's case) sits between hardware and guest OS, managing CPU scheduling, memory allocation, I/O, and device access.

Type 1 (Bare-Metal) Hypervisor:

ESXi runs directly on hardware — no host OS. Minimal attack surface (~150MB footprint). Direct hardware access via VMkernel for maximum performance.

Type 2 (Hosted) Hypervisor:

Runs atop a host OS (e.g., VMware Workstation). Higher overhead, used for development/testing only.

Key Abstraction Layers:

├── CPU: Virtual CPUs (vCPUs) scheduled on physical cores via VMkernel scheduler
│   └── Overcommit: More vCPUs than physical cores; scheduler uses time-slicing
├── Memory: Virtual memory mapped to physical via TPS (Transparent Page Sharing), ballooning, compression, swap
│   └── Overcommit: Total VM memory > physical RAM; managed via ballooning driver (vmmemctl)
├── Storage: Virtual disks (VMDKs) on datastores (VMFS, NFS, vSAN, vVols)
│   └── Thin provisioning: Allocate on write, report full size to guest
├── Network: Virtual NICs (vNICs) connected to virtual switches (vSS/vDS)
│   └── SR-IOV: Direct hardware NIC access bypassing hypervisor for latency-sensitive workloads
└── GPU: vGPU passthrough or shared GPU (NVIDIA GRID) for VDI/AI workloads

Use Cases for Virtualization

Server Consolidation:

Reduce physical servers 10:1 or higher. Typical enterprise runs 15-25 VMs per host. Saves power, cooling, rack space, hardware maintenance.

Business Continuity & DR:

vMotion (live migration), HA (automatic restart), SRM (Site Recovery Manager) — workloads survive hardware failures and site disasters without application changes.

Development & Testing:

Rapid provisioning via templates/clones. Snapshots for point-in-time rollback. Linked clones share base disk, reducing storage 70%+.

Cloud-Native Applications:

vSphere Supervisor enables Kubernetes on ESXi. Containers and VMs coexist on same infrastructure. VKS (VMware Kubernetes Services) provides managed K8s clusters.

Desktop Virtualization (VDI):

Horizon View on vSphere. Persistent/non-persistent desktops. Instant clones for rapid provisioning (<2 seconds).

Edge Computing:

Single-host ESXi deployments at retail/branch locations. Managed centrally via vCenter.

Value Proposition for Virtualization

Hardware Efficiency:

Without virtualization: typical server runs at 5-15% CPU utilization. With: 60-80% utilization. ROI in hardware alone is 3-5x.

Operational Agility:

Provision new server in minutes (not weeks). Scale up/down with DRS automation. No procurement cycle for dev/test.

Standardization:

Host Profiles enforce consistent ESXi configuration. VM templates enforce OS/app standards. Reduces configuration drift.

Security:

VM isolation (each VM has own address space). Micro-segmentation (with NSX, not in VVF). vTPM and VM encryption. Secure Boot chain from hardware to guest.

Cost Reduction:

Fewer physical servers = less power, cooling, rack space, cabling. Centralized management reduces admin overhead. License consolidation.

Holodeck Lab Note: In Holodeck environment, virtualization is nested — ESXi hosts are themselves VMs running on physical ESXi. This demonstrates Type 1 hypervisor running inside Type 1, useful for understanding CPU/memory overhead and performance characteristics of nested environments.

Key Takeaways

• Exam: Know Type 1 (bare-metal, ESXi) vs Type 2 (hosted, Workstation) hypervisor distinction. ESXi is always Type 1.
• Exam: Understand overcommit — CPU uses time-slicing, memory uses ballooning/compression/swap hierarchy. TPS shares identical pages.
• Exam: Value proposition = hardware efficiency (5-15% → 60-80% utilization), operational agility (minutes not weeks), security (isolation, encryption).

VVF Networking Fundamentals (Objective 2.4)#

Blueprint Objective 2.4 — VMware Network Fundamentals

Differentiate Between VVF Networking Components

VVF uses traditional vSphere networking only — no NSX overlay. Understanding the components and when to use each is critical.

vSphere Standard Switch (vSS):

├── Scope: Host-local only — each ESXi host has its own vSS
├── Configuration: Manual per-host (no central management)
├── Port groups: Named network connections (e.g., "VM Network", "Management")
├── NIC teaming: Active-Standby, Route by Physical NIC Load, IP Hash
├── Limitations: No LACP, no NetFlow, no port mirroring, no central policy
├── Use case: Small deployments, edge locations, labs
└── Max ports: 4096 per vSS

vSphere Distributed Switch (vDS):

├── Scope: Cluster-wide — single configuration applied to all member hosts
├── Configuration: Centralized via vCenter (survives host rebuilds)
├── Port groups: Distributed port groups with uniform VLAN, security, traffic shaping
├── NIC teaming: All vSS modes PLUS LACP (Link Aggregation Control Protocol)
├── Advanced features:
│   ├── NetFlow: Export flow data to collector for traffic analysis
│   ├── Port mirroring: SPAN/RSPAN equivalent for packet capture
│   ├── Network I/O Control (NIOC): QoS — reserve bandwidth per traffic type
│   │   └── Shares: Management(100), vMotion(50), vSAN(100), VM(50-100)
│   ├── Traffic filtering: Allow/deny rules on port groups
│   └── Health check: Verify VLAN trunking, MTU, NIC teaming consistency
├── Use case: Production clusters, any deployment >3 hosts
└── Max ports: 60,000 per vDS

VMkernel Adapters (vmk):

├── vmk0: Management traffic (vCenter-to-ESXi communication)
├── vmk1: vMotion (live VM migration — dedicated recommended)
├── vmk2: vSAN (storage replication — MUST be isolated VLAN, MTU 9000)
├── vmk3: FT logging (Fault Tolerance — high bandwidth required)
├── vmk4: NFS/iSCSI storage (if external storage used)
└── Each vmk has: IP, subnet, VLAN, TCP/IP stack, MTU setting

Traffic Types and Isolation:

In VVF, physical separation or VLAN isolation is the primary security mechanism (no NSX DFW):

Jumbo Frames (MTU 9000):

Required for vSAN and recommended for vMotion. Must be enabled end-to-end: ESXi vmk → vDS/vSS → physical switch → destination.

Verify: vmkping -d -s 8972 <target_ip> (8972 + 28 header = 9000 MTU)

NIOC v3 (Network I/O Control):

Quality of Service for virtual networking. Assigns bandwidth shares and reservations per traffic type. Critical when vSAN, vMotion, and VM traffic share physical NICs.

Holodeck Lab Note: Holodeck nested environment uses vDS for all traffic. Jumbo frames may not work in nested environments due to outer ESXi MTU limitations. Test with standard MTU 1500 first, then verify jumbo frame path if outer host supports it.

Key Takeaways

• Exam: vSS = host-local, manual config, no LACP. vDS = cluster-wide, centralized, LACP + NetFlow + NIOC + port mirroring.
• Exam: Know VMkernel adapter assignments — vmk0 (mgmt), vmk1 (vMotion), vmk2 (vSAN). vSAN MUST be isolated VLAN with MTU 9000.
• Exam: NIOC v3 provides QoS via bandwidth shares/reservations. Know default share values per traffic type.

VVF Deployment & Supervisor Configuration (Objective 4.1)#

Blueprint Objective 4.1 — VVF: Deploy and Configure

Components of a VVF Deployment

VVF deployment consists of:

├── ESXi 9.0 hosts (minimum 3 for vSAN quorum, minimum 1 for non-vSAN)
├── vCenter Server Appliance (VCSA 9.0) — single appliance or HA pair
├── vSAN cluster (if HCI storage desired)
├── vSphere Distributed Switch (recommended) or Standard Switch
├── VCF Operations (integrated monitoring)
├── VCF Operations for Logs (centralized logging)
└── vSphere Supervisor (optional — for Kubernetes workloads)

NOT included in VVF deployment:

├── NSX Manager (no overlay networking)
├── VCF Automation (no cloud templates/service broker)
├── SDDC Manager / VCF Operations Manager (that's VCF, not VVF)
└── Fleet Manager (VCF-only)

VVF Deployment Process

Step 1: Hardware Preparation

├── Verify servers in VMware Compatibility Guide (VCG)
├── Configure BIOS: VT-x/AMD-V enabled, AES-NI (vSAN encryption), UEFI Secure Boot
├── Network: Management VLAN configured on ToR switches, trunk ports for vDS
└── Storage: Local disks for vSAN or SAN/NAS for external storage

Step 2: ESXi Installation

├── Boot from ISO (USB, PXE, or iLO/iDRAC virtual media)
├── Accept EULA, select boot disk (USB or local SSD)
├── Set root password, configure management network (vmk0)
├── Post-install: Enable SSH, set NTP (esxcli system ntp set --server=<ntp-ip>)
└── Repeat for all hosts

Step 3: vCenter Deployment

├── Deploy VCSA 9.0 OVA to first ESXi host
│   ├── Stage 1: Deploy appliance (15-20 min)
│   └── Stage 2: Configure SSO domain (vsphere.local), NTP, DNS
├── Sizing: Small (4 vCPU/16GB) for <100 VMs, Medium (8/32GB) for <400 VMs
└── Post-deploy: Create datacenter object, add ESXi hosts, create cluster

Step 4: Cluster Configuration

├── Create vSphere cluster with DRS and HA enabled
├── Configure vDS: Create distributed switch, add hosts, migrate vmk adapters
├── Enable vSAN: Select disks (cache + capacity), choose ESA or OSA
├── Configure storage policies (FTT, RAID level)
└── Verify: vSAN Health Check all green

Step 5: Configure Supervisor (vSphere Kubernetes)

Supervisor enables Kubernetes workloads on vSphere clusters:

Prerequisites:

├── vSphere cluster with DRS enabled (fully automated recommended)
├── HA enabled on cluster
├── vSAN or shared storage (for persistent volumes)
├── Networking: vDS with dedicated port group for Supervisor (or NSX — but VVF uses vDS)
└── Load balancer: HAProxy or external LB (required for Kubernetes API endpoint)

Supervisor Deployment (vDS networking mode — VVF):

├── vCenter → Workload Management → Enable Supervisor
├── Select cluster, choose "vSphere Distributed Switch" networking
├── Configure:
│   ├── Management network: IP range for Supervisor control plane VMs (3 IPs minimum)
│   ├── Workload network: IP range for Kubernetes nodes
│   ├── Storage policy: Select vSAN policy for persistent volumes
│   ├── Content library: For VM images (Ubuntu, Photon OS)
│   └── Load balancer: HAProxy endpoint (IP, credentials, virtual IP range)
├── Deployment creates 3 Supervisor control plane VMs automatically
└── Validation: kubectl get nodes shows Supervisor nodes Ready

Supervisor Namespaces:

├── Logical isolation boundary for Kubernetes workloads
├── Each namespace gets: resource quota (CPU, memory, storage), network policy, storage policy
├── Admin creates namespace → assigns to developer → developer deploys workloads
└── Access: kubectl vsphere login --server=<supervisor-ip> --vsphere-username=user@domain

Holodeck Lab Note: Supervisor deployment in Holodeck requires careful resource planning — 3 control plane VMs consume ~12 vCPU and 48GB RAM. Ensure Holodeck hosts have sufficient resources. HAProxy must be pre-deployed as load balancer since NSX is not available in VVF.

Key Takeaways

• Exam: VVF deployment components = ESXi + VCSA + vSAN + vDS + VCF Operations + VCF Ops for Logs. No NSX, no SDDC Manager, no Fleet Manager.
• Exam: Supervisor in VVF uses vDS networking (not NSX). Requires: DRS enabled, HA enabled, shared storage, external load balancer (HAProxy).
• Exam: Supervisor creates 3 control plane VMs. Namespaces provide logical isolation with resource quotas, network policies, storage policies.

VCF Operations & Operations for Logs in VVF (Objective 4.3)#

Blueprint Objective 4.3 — VVF: Operate

This is the largest section of the exam (19 sub-objectives). VCF Operations and VCF Operations for Logs are included in VVF licensing and are the primary monitoring/observability tools.

VCF Operations — Architecture & Deployment (Obj 4.3)

VCF Operations (formerly vRealize Operations / Aria Operations) is a monitoring, capacity planning, and compliance platform.

Cluster Components:

├── Analytics Node: Processes metrics, runs algorithms (capacity, anomalies)
├── Collector Node: Gathers data from vCenter, ESXi, vSAN via adapters
├── Remote Collector: For distributed/remote data centers
└── Data Node: Stores time-series metrics (internal TSDB)

Deployment Options:

├── Small (up to 4,000 objects): 1 analytics node (4 vCPU, 16GB, 512GB)
├── Medium (up to 20,000 objects): 2-node cluster + 1 remote collector
├── Large (up to 100,000 objects): Multi-node cluster + multiple remote collectors
└── Extra Large: Scaled with additional data nodes

Initial Setup:

├── Deploy OVA → configure admin password → access UI (https://<ops-ip>)
├── Add vCenter adapter: Provide vCenter IP, credentials, test connection
├── Adapter collects: VMs, hosts, clusters, datastores, networks, vSAN objects
├── Data collection starts immediately; analytics available after ~24 hours (baseline)
└── Content packs: Install for vSAN, Kubernetes, storage, network visibility

VCF Operations for Logs — Architecture & Deployment (Obj 4.3)

Centralized log management (formerly vRealize Log Insight / Aria Operations for Logs).

Cluster Components:

├── Primary Node: Ingests, indexes, and stores log data
├── Worker Nodes: Horizontal scale for ingestion throughput
└── Integrated Load Balancer: Distributes log traffic across nodes

Deployment Options:

├── Standalone: 1 node (up to 5,000 events/second)
├── Cluster: 3+ nodes with integrated LB (10,000+ events/second)
└── HA: Primary + 2 workers minimum for redundancy

Log Sources:

├── ESXi: Syslog forwarded to Ops for Logs (esxcli system syslog config set --loghost=<ip>)
├── vCenter: VCSA syslog configuration → Ops for Logs endpoint
├── vSAN: vSAN observer data forwarded automatically
├── VMs: Agent-based (Fluentd) or agentless (syslog)
└── Custom: Any syslog-capable source (network switches, firewalls, apps)

Metrics, Properties, and Logs — Differentiation (Obj 4.3)

Metrics:

├── Numeric time-series data collected at regular intervals
├── Examples: CPU usage %, memory consumed MB, disk latency ms, IOPS
├── Source: vCenter performance counters, vSAN performance service
├── Retention: 5-minute intervals for 1 day, 1-hour for 1 month, 1-day for 1 year (default)
└── Use: Trending, capacity planning, anomaly detection

Properties:

├── Configuration attributes — static or slowly changing
├── Examples: VM name, host model, ESXi version, vSAN disk type, cluster DRS level
├── Source: vCenter inventory, hardware probes
├── Retention: Current value + history of changes
└── Use: Filtering, grouping, compliance checks

Logs:

├── Unstructured or semi-structured text events
├── Examples: "Host esxi-01 lost network connectivity at 14:32:05", vpxd.log entries
├── Source: Syslog, VCSA logs, ESXi logs, application logs
├── Retention: Configurable (default 30 days, archive to NFS/S3)
└── Use: Root cause analysis, security forensics, audit trail

Custom Views & Reports (Obj 4.3)

Views:

├── Tabular display of objects with selected metrics/properties
├── Create: Operations UI → Dashboards → Views → Create View
├── Types: List (table), Summary (aggregated), Distribution (histogram), Trend (time-series)
├── Filters: By object type, property value, metric threshold
└── Share: Export as CSV/PDF, schedule email delivery

Reports:

├── Multi-page documents combining views, charts, and text
├── Templates: Pre-built (Capacity, Performance, Compliance) or custom
├── Schedule: Daily/weekly/monthly auto-generation
├── Format: PDF or CSV
└── Use case: Weekly capacity report for management, monthly compliance audit

Dashboards (Obj 4.3)

Creating Dashboards:

├── Operations UI → Dashboards → Create Dashboard
├── Widgets: Scorecards, heatmaps, top-N, trend charts, object lists, alerts
├── Interactions: Widget-to-widget linking (click host → filter VMs)
├── Layout: Grid-based, drag-and-drop
└── Share: Assign to user/group, set as default, export/import

Sharing Dashboards:

├── Per-user or per-group visibility
├── Read-only or edit permissions
├── Export as JSON for backup/migration
└── Import from content packs (vSAN dashboard pack, K8s dashboard pack)

Alerting (Obj 4.3)

Alert Definitions:

├── Symptom: Single condition (CPU > 90% for 5 min)
├── Alert: One or more symptoms combined with logic (AND/OR)
├── Recommendation: Suggested action attached to alert
├── Notification: Email, webhook, SNMP trap, REST API callback

Built-in Alert Examples:

├── "Host CPU Contention" — CPU ready > 5% for 10 minutes
├── "Datastore Running Out of Space" — free space < 15%
├── "vSAN Disk Latency High" — write latency > 30ms for 5 minutes
├── "VM Memory Pressure" — balloon + swap > 20% of configured memory
└── Custom: Create symptom → create alert definition → attach notification

Log Events Monitoring (Obj 4.3)

Operations for Logs — Explore Logs:

├── Full-text search across all ingested logs
├── Structured fields: timestamp, source, text, facility, severity
├── Filters: Time range, source (host/VM/app), severity (emergency→debug)
├── Group by: Source, field extraction (regex), time bucket
├── Save as: Named query, alert trigger
└── Example: Search "SCSI sense code" + source=esxi* → find storage errors across fleet

Dashboards in Operations for Logs (Obj 4.3):

├── Pre-built: ESXi overview, vCenter events, vSAN errors
├── Custom: Create from saved queries, pin charts to dashboard
├── Widgets: Event trend (line chart), top sources (bar), event distribution (pie)
└── Share: Same model as Operations dashboards (user/group visibility)

Costing & Pricing (Obj 4.3)

VCF Operations Costing:

├── Define cost drivers: Server hardware ($/month), storage ($/GB), network ($/port)
├── Assign costs to clusters, datastores, host groups
├── Chargeback: Allocate costs to business units based on VM resource consumption
├── Showback: Display costs without billing (awareness mode)
├── Reports: Cost per VM, cost per business unit, cost trend, what-if scenarios
└── Setup: Operations UI → Administration → Cost Settings → Define rate cards

VCF Operations Integration (Obj 4.3):

├── vCenter adapter: Primary data source (inventory + metrics)
├── vSAN adapter: Deep storage metrics (disk health, rebuild status)
├── Kubernetes adapter: Supervisor and TKG cluster monitoring
├── SNMP adapter: Network device monitoring
├── REST API: Custom integrations (ServiceNow, Slack, PagerDuty)
└── Operations for Logs integration: Correlate metrics with log events

vSAN Storage Operations (Obj 4.3):

├── Deep vSAN monitoring within VCF Operations
├── Metrics: Disk health, rebuild progress, dedup ratio, capacity forecast
├── Alerts: Disk failure prediction, capacity threshold, congestion
├── Views: Per-disk group, per-host, per-cluster vSAN performance
└── Capacity planning: Predict when vSAN will need additional disks/hosts

VCF Operations Policies (Obj 4.3):

├── Define thresholds for alerts and capacity
├── Types: Capacity remaining (days), workload utilization, compliance
├── Apply to: Object groups (clusters, datacenters, custom groups)
├── Override: Per-object or per-group policy customization
└── Compliance: Map to regulatory frameworks (CIS, DISA STIG, PCI-DSS)

Application Monitoring (Obj 4.3):

├── Service Discovery: Auto-detect applications running in VMs
│   └── Discovers: Web servers (Apache, IIS), databases (MySQL, PostgreSQL), app servers
├── Application-aware metrics: Response time, throughput, error rate
├── Dependency mapping: VM → application → service → infrastructure
└── Setup: Install Telegraf agent in guest OS, or use agentless discovery

Security Hardening & Compliance (Obj 4.3):

├── Security benchmarks: CIS ESXi, DISA STIG, PCI-DSS
├── Compliance dashboard: Green/yellow/red per host, per cluster
├── Drift detection: Configuration changes from hardened baseline
├── Remediation: Recommendations with PowerCLI/esxcli commands
└── Reports: Compliance status over time, audit-ready export

VCF Operations for Logs — Cluster & Deployment (Obj 4.3):

├── Already covered above in Architecture section
├── Integration with VVF components:
│   ├── ESXi syslog → Ops for Logs (configure via Host Profile or esxcli)
│   ├── vCenter events → Ops for Logs (VCSA syslog configuration)
│   ├── vSAN observer → Ops for Logs (automatic if vSAN adapter configured)
│   └── VCF Operations → Ops for Logs (bidirectional launch-in-context)
└── Configure integration: Ops for Logs UI → Administration → Integration → Add VCF Operations

Holodeck Lab Note: VCF Operations and VCF Operations for Logs can be deployed in Holodeck as nested VMs. Minimum sizing for lab: VCF Ops = 4 vCPU/16GB RAM, Ops for Logs = 4 vCPU/8GB RAM. Configure ESXi syslog forwarding from all Holodeck ESXi hosts to Ops for Logs for hands-on log analysis practice.

Key Takeaways

• Exam: VCF Operations = metrics + analytics + capacity + compliance. VCF Operations for Logs = centralized log management. Both included in VVF.
• Exam: Know the difference — Metrics (numeric, time-series, trending), Properties (config attributes, static), Logs (text events, forensics).
• Exam: Dashboards use widgets (scorecards, heatmaps, top-N). Alerts = symptoms + logic + notifications. Policies define thresholds per object group.
• Exam: Costing = rate cards + chargeback/showback. Service Discovery = auto-detect apps in VMs. Compliance = CIS/DISA STIG benchmarks.
• Exam: Operations for Logs — Explore Logs for full-text search, structured field filtering, regex extraction. Integrates bidirectionally with VCF Operations.

VVF Consume & Automate — Supervisor Services, VKS, Orchestrator (Objective 4.4)#

Blueprint Objective 4.4 — VVF: Consume and Automate

Supervisor-Based Services in VVF (Obj 4.4)

The vSphere Supervisor is a Kubernetes control plane embedded in vSphere. In VVF, Supervisor uses vDS networking (not NSX).

Supervisor Services:

├── Built-in services that extend Supervisor functionality
├── Catalog: vCenter → Workload Management → Services → Service Catalog
├── Examples:
│   ├── Contour (Ingress Controller): HTTP/HTTPS routing to K8s services
│   ├── Harbor (Container Registry): Private image registry on-premises
│   ├── Velero (Backup): Kubernetes resource and persistent volume backup
│   ├── MinIO (Object Storage): S3-compatible storage for cloud-native apps
│   ├── cert-manager: Automated TLS certificate management
│   └── External DNS: Automatic DNS record management for K8s services
├── Installation: Download from VMware Marketplace → Install via vCenter UI
├── Lifecycle: Versioned, upgradeable through vCenter Workload Management
└── Networking: Services use Supervisor load balancer (HAProxy in VVF)

Deploy Virtual Machines Using VM Service (Obj 4.4)

VM Service enables self-service VM provisioning through Kubernetes API:

Concept:

├── Define VM class (size: CPU, memory)
├── Define content library (VM images: Ubuntu, Windows, Photon OS)
├── Developer creates VirtualMachine YAML manifest
├── kubectl apply -f vm.yaml → VM created on vSphere cluster
└── VM managed through both kubectl and vCenter UI

VM Classes (predefined resource profiles):

├── best-effort-xsmall: 2 vCPU, 2GB RAM (no reservation)
├── best-effort-small: 2 vCPU, 4GB RAM
├── best-effort-medium: 4 vCPU, 8GB RAM
├── guaranteed-small: 2 vCPU, 4GB RAM (100% reservation)
├── guaranteed-medium: 4 vCPU, 8GB RAM (100% reservation)
└── Custom: Admin defines via vCenter → Workload Management → VM Classes

Example VM Service YAML:

apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachine
metadata:
  name: my-ubuntu-vm
  namespace: dev-team
spec:
  className: best-effort-medium
  imageName: ubuntu-2204-server
  storageClass: vsan-default-storage-policy
  networkInterfaces:
  - networkType: vsphere-distributed
  powerState: poweredOn

Deploy Kubernetes Workloads Using VMware Kubernetes Services (VKS) (Obj 4.4)

VKS (formerly Tanzu Kubernetes Grid) provides managed Kubernetes clusters:

Architecture:

├── Supervisor Cluster: Control plane (3 VMs on ESXi)
├── TKG Cluster: Worker cluster created by Supervisor (Cluster API)
│   ├── Control plane nodes: 1 or 3 (HA)
│   ├── Worker nodes: 1-N (auto-scaled via MachineDeployment)
│   └── Container runtime: containerd
├── Storage: Persistent volumes backed by vSAN (CSI driver)
└── Networking: Antrea CNI (default in VVF, replaces NSX NCP)

Create TKG Cluster:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: prod-cluster
  namespace: dev-team
spec:
  topology:
    class: tanzukubernetescluster
    version: v1.27.5+vmware.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
      - class: node-pool
        name: worker-pool-1
        replicas: 5

Lifecycle:

├── Upgrade: Change spec.topology.version → Supervisor rolls nodes
├── Scale: Change worker replicas → auto-provisioned
├── Delete: kubectl delete cluster prod-cluster → all resources cleaned up
└── Monitor: vCenter → Workload Management → Clusters shows status

Deploy vSphere Pods and Other Services (Obj 4.4)

vSphere Pods:

├── Lightweight containers running directly on ESXi (no worker VM needed)
├── Each pod gets its own micro-VM (CRX — Container Runtime for ESXi)
├── Benefits: VM-level isolation + container-level density
├── Limitations: Only Linux containers, limited to Supervisor namespace
└── Use case: High-security workloads requiring VM isolation per container

Other Services:

├── Persistent Volume Claims: vSAN CSI driver auto-provisions VMDKs
├── Load Balancer Services: HAProxy in VVF (automatic VIP allocation)
├── Ingress: Contour or third-party (Nginx, Traefik)
└── Service Mesh: Istio (manual install, not built-in for VVF)

VCF Operations Orchestrator (Obj 4.4)

VCF Operations Orchestrator (formerly vRealize Orchestrator / Aria Automation Orchestrator):

Purpose:

├── Workflow automation engine for vSphere operations
├── Pre-built workflows: VM lifecycle, snapshot management, reporting
├── Custom workflows: JavaScript/Python actions + drag-and-drop designer
├── Integration: vCenter API, REST endpoints, PowerShell, SSH
└── Scheduling: Run workflows on schedule or trigger on events

Use Cases in VVF:

├── Automated VM provisioning with approval workflow
├── Scheduled snapshot cleanup (delete snapshots >7 days)
├── Automated compliance remediation (apply host profiles on drift)
├── Custom reporting (query vCenter API, format, email)
├── Integration with ITSM (ServiceNow ticket creation on alert)
└── Day-2 operations: disk expansion, CPU/memory hot-add workflows

Deployment:

├── Standalone appliance (2 vCPU, 6GB RAM, 100GB disk)
├── Embedded mode: Included with VCF Operations (if deployed)
├── Access: https://<orchestrator-ip>/orchestration-ui/
└── API: RESTful API for external integration

Holodeck Lab Note: VKS cluster deployment in Holodeck requires: (1) Supervisor enabled on Holodeck cluster, (2) HAProxy deployed as load balancer, (3) Content library with TKG node images. Minimum resources for 1 TKG cluster: 3 control plane VMs (6 vCPU, 24GB) + 3 workers (6 vCPU, 24GB) = 12 vCPU, 48GB total. Plan Holodeck host resources accordingly.

Key Takeaways

• Exam: VM Service = deploy VMs via kubectl YAML. VM Classes define resource profiles (best-effort vs guaranteed). Content Library provides images.
• Exam: VKS = managed Kubernetes clusters on vSphere. Uses Cluster API, Antrea CNI (not NSX), vSAN CSI for persistent volumes.
• Exam: vSphere Pods = containers with VM-level isolation (CRX micro-VMs). Only Linux, only in Supervisor namespace.
• Exam: VCF Operations Orchestrator = workflow automation engine. Pre-built + custom workflows. Use cases: VM lifecycle, snapshot cleanup, compliance remediation.

VCF Operations Policies, Explore Logs & Certificate/Identity Management (Objectives 4.2–4.3)#

VCF Operations Policies (Obj 4.3)

VCF Operations uses policies to automate operational decisions. Policy types:

Alert Policies:

├── Symptom-based: Trigger when a metric crosses threshold (e.g., CPU usage >90% for 5 min)
├── Condition-based: Multiple symptoms combined with AND/OR logic
├── Notification: Email, Webhook, SNMP trap, Slack integration
├── Suppression: Silence known-maintenance alerts via maintenance schedules
└── Smart alerting: VCF Operations groups related alerts into a single root-cause alert

Capacity Policies:

├── Time Remaining: Alert when projected resource exhaustion is within X days
├── Risk-based: High/medium/low risk scores based on utilization trends
├── Committed capacity: Track reserved vs actual usage across clusters
└── Reclaimable resources: Identify idle VMs, oversized VMs, orphaned VMDKs for reclamation

Automation Policies:

├── Workload placement: DRS-like recommendations based on cost/performance optimization
├── Right-sizing: Recommend CPU/memory resize based on utilization history (30/60/90 day)
├── Reclamation: Auto-tag VMs with no activity for >30 days for review
└── Custom actions: Script execution via VCF Operations Orchestrator on policy trigger

Compliance Policies:

├── vSphere Configuration Guide (SCG) benchmarks
├── DISA STIG profiles for DoD environments
├── CIS Benchmark alignment
├── Custom compliance templates: Define organization-specific hardening standards
├── Drift detection: Alert when host/VM configuration deviates from baseline
└── Remediation: One-click fix for non-compliant settings (e.g., enable SSH timeout, disable TLS 1.0)

Explore Logs Feature (Obj 4.3j)

VCF Operations for Logs provides an interactive log exploration interface:

Explore Logs UI:

├── Search bar: Full-text search across all ingested logs (syslog, vCenter events, NSX logs)
├── Filters: By source (ESXi, vCenter, NSX, vSAN), severity (emergency→debug), time range
├── Field extraction: Auto-parse structured log fields (hostname, process, PID, message)
├── Saved queries: Save frequent searches for reuse (e.g., "all PSOD events last 7 days")
├── Query language: Supports regex, wildcard, AND/OR/NOT operators
└── Export: Download filtered log results as CSV for offline analysis

Log Dashboard Integration:

├── Pin log query results to custom dashboards
├── Create log-based widgets: top error sources, log volume trends, severity distribution
├── Cross-reference: Link log events to VCF Operations metric anomalies
└── Alerts: Create alert definitions from log patterns (e.g., "if >10 auth failures in 5 min")

vSphere Pods (Obj 4.4d)

vSphere Pods run containers natively on ESXi without a guest OS VM:

Architecture:

├── CRX (Container Runtime for ESXi): Lightweight VM that acts as pod sandbox
├── Each pod gets its own CRX instance with dedicated kernel
├── Spherelet: Kubernetes kubelet equivalent running on ESXi
├── Integration: Pods appear in vCenter inventory alongside VMs
└── Networking: NSX Container Plugin (NCP) provides pod networking via NSX segments

Use Cases:

├── Privileged workloads requiring direct hardware access
├── Low-latency applications (no guest OS overhead)
├── CI/CD ephemeral build agents (fast startup, disposable)
└── Sidecar/init containers running alongside VMs in the same namespace

Deployment:

├── Enable Workload Management on cluster → Supervisor created
├── Create vSphere Namespace → assign resource quotas
├── Apply VM Class and Storage Class to namespace
├── kubectl apply -f pod.yaml (standard K8s manifest)
└── Pod scheduled by Supervisor's scheduler → CRX created on ESXi host

Limitations:

├── No DRS-aware live migration (pod must be recreated on another host)
├── Requires NSX networking (not available with VDS-only networking)
├── Not supported on stretched clusters
└── Pod storage is ephemeral by default; use PVCs for persistent data

Certificate Management in VVF (Obj 4.2c)

VMCA (VMware Certificate Authority):

├── Embedded CA in vCenter: Issues certificates to ESXi hosts, vCenter services, Solution Users
├── Certificate hierarchy: VMCA Root CA → Machine SSL → Solution User certs
├── Default mode: VMCA acts as intermediate CA (recommended for most deployments)
├── Custom CA mode: Replace VMCA root with enterprise CA-signed certificate
├── Certificate lifecycle: Auto-renewal before expiration (default 2 years for machine SSL)
└── Certificate refresh: vCenter UI → Administration → Certificate Management → Refresh

Certificate Replacement Scenarios:

├── Replace Machine SSL cert: When hostname changes or cert expires
├── Replace VMCA Root: When transitioning to enterprise CA
├── Replace Solution User certs: Rarely needed; auto-generated by VMCA
├── ESXi host certificates: Auto-provisioned by VMCA when host joins vCenter
└── Thumbprint verification: For trust establishment between components

Certificate Store:

├── VECS (VMware Endpoint Certificate Store): Central cert repository on vCenter
├── Stores: MACHINE_SSL_CERT, TRUSTED_ROOTS, SMS, vpxd, vsphere-webclient
├── CLI: /usr/lib/vmware-vmafd/bin/vecs-cli store list
├── Backup: Include VECS in vCenter backup strategy
└── Troubleshooting: Certificate mismatch → services fail to start → check vecs-cli entry list

Identity Management & RBAC in VVF (Obj 4.2a)

Identity Sources:

├── Embedded SSO (vsphere.local): Default identity domain, always available
├── Active Directory (Integrated Windows Auth): Join vCenter to AD domain
├── Active Directory over LDAP: Configure LDAP endpoint for AD queries
├── OpenLDAP: Third-party LDAP directory support
└── ADFS/Okta (Identity Federation): SAML 2.0 or OIDC identity providers

Role-Based Access Control (RBAC):

├── Privileges: Granular permissions (e.g., VirtualMachine.Interact.PowerOn)
├── Roles: Named collections of privileges (Administrator, ReadOnly, VM Power User, custom)
├── Principals: Users or groups from identity sources
├── Objects: vCenter inventory objects (datacenter, cluster, folder, VM, datastore)
├── Permissions: Principal + Role + Object + Propagation (inherit to children)
└── Global Permissions: Apply at root vCenter level, propagate everywhere

Built-in Roles:

├── Administrator: Full control (assign sparingly — principle of least privilege)
├── Read-Only: View inventory, no changes
├── No Access: Explicitly deny access to object subtree
├── VM Power User (custom example): PowerOn/Off, Console, Snapshot — no reconfigure
└── Network Administrator (custom): Port group management, no VM operations

Best Practices:

├── Use AD groups, not individual users, for permission assignments
├── Apply permissions at folder level, not individual VM level (scalability)
├── Audit permissions quarterly: vCenter → Administration → Access Control → Roles
├── Enable vCenter event logging for permission change tracking
└── Use Global Permissions only for cross-datacenter admin roles

Key Takeaways

• VCF Operations policies include Alert, Capacity, Automation, and Compliance types — each automates operational decisions at scale.
• Explore Logs provides interactive log search with regex/wildcard queries, field extraction, saved queries, and dashboard integration.
• vSphere Pods run on CRX (Container Runtime for ESXi) — native containers without guest OS overhead, managed via kubectl.
• VMCA is the embedded certificate authority in vCenter — manages machine SSL, solution user, and ESXi host certificates automatically.
• RBAC uses Privileges → Roles → Permissions model. Always assign permissions to AD groups at folder level, not individual VMs.

VCF 9.x Operational Changes: Green Score, Storage DRS and vCLS#

GREEN SCORE (VCF Operations 9.0 / 9.1)

Green Score is a documented VCF Operations KPI — renamed from "Sustainability" in 9.0 — that measures energy efficiency in digital operations achieved through data-centre virtualization. It is comprised of multiple parameters and is configured at the ORGANIZATION level and for physical data centres.

Dashboards cover: Energy Efficiency with Virtualization (estimated carbon-footprint reduction versus physical), Energy Efficient Clusters / Infrastructure (compare clusters or data centres by estimated CO2 or power), Environmental Impact of Idle VMs (idle-VM identification), and aging compute/storage.

Important caveat Broadcom states explicitly: the calculators are INFORMATIONAL and are not intended for regulatory or compliance disclosure.

STORAGE DRS — WHAT CHANGED IN vSPHERE 9 / VCF 9.x
Storage DRS remains SUPPORTED, but only for a subset of what it used to do:

├── STILL SUPPORTED: initial placement, space-utilization load balancing, anti-affinity rules, SDRS maintenance mode, automation levels, off-hours scheduling, SPBM limits
└── REMOVED in vCenter 9.0: the SDRS I/O Load Balancer, the SDRS I/O reservations-based load balancer, and Storage I/O Control (SIOC) entirely — including enabling SIOC on a datastore and setting Reservations/Shares through SPBM storage policies

The deprecation was pre-announced in vSphere 8.0 U3; 7.x and 8.x retain all three balancing modes for their lifecycle.
EXAM TRAP: "Storage DRS balances space AND I/O" is correct for 8.x and materially WRONG for 9.x. The 9.0 datastore-cluster documentation lists only space-utilization load balancing and anti-affinity rules, and the aggressiveness page sets thresholds for space used only.

vCLS IN vSPHERE 9 — DEPRECATED, NOT REPLACED

vSphere 9.0 DEPRECATES vCLS; it does not remove the agent VMs. Embedded vCLS VMs (vSphere-Pod-based, introduced in 8.0 U3, desired redundancy reduced from 3 to 2) still deploy by default and still appear in the vCLS folder.

What actually changed: vCLS is no longer REQUIRED. Verbatim from the docs — "Starting vSphere 9.0, vCLS can be disabled on a vSphere cluster without any impact to vSphere DRS or vSphere HA functionality" — and Broadcom recommends putting clusters into Retreat Mode to avoid the redundant resource usage. Full removal is deferred to a future vCenter release.

The enabling mechanism is DKVS, an etcd-based distributed key-value store run by clusterAgent on the ESX hosts, present in ESXi 8.x and 9.x and also used during vCenter restore-from-backup to provide more up-to-date recovery. Note the vCLS documentation pages do not themselves name DKVS — that link is inferential, so do not assert it as a documented vCLS replacement.

Key Takeaways

• Green Score is real and documented (VCF Operations 9.0/9.1, renamed from Sustainability): energy efficiency of digital operations through virtualization, configured at organization and physical-data-centre level. Broadcom labels the figures informational, not for regulatory disclosure.
• Storage DRS in vSphere 9/VCF 9.x: initial placement and SPACE balancing only. The I/O load balancer, the I/O reservations balancer and Storage I/O Control (SIOC) were all REMOVED in vCenter 9.0 — deprecation pre-announced in 8.0 U3.
• vCLS in vSphere 9 is DEPRECATED, not replaced: embedded agent VMs still deploy, but DRS and HA no longer depend on them, so a cluster can run in Retreat Mode with no functional impact. Removal is deferred to a future release.
• Exam trap: 'Storage DRS balances space and I/O' is right for 8.x, wrong for 9.x — the kind of version split exam questions exploit.