Top 100 VMware Questions & Expert Answers for 2026 — Interview, Exam & Production Ready

Keywords:  VMware Interview Questions • VMware vSphere Questions • VMware ESXi FAQ • VMware vCenter Questions • VMware HA DRS Questions • VMware vMotion • VMware NSX Questions • VMware vSAN • VMware Networking Questions • VMware Storage Questions • VMware Tanzu • VMware Horizon • VMware Troubleshooting • VMware Certification Questions • VMware Admin Questions • VCP VCAP Questions • VMware Performance • VMware Cloud • VMware Backup • VMware 2026

Whether you’re preparing for a VMware VCP/VCAP certification, walking into a senior virtualization engineer interview, or troubleshooting a production ESXi cluster at 2am, the questions in this guide cover the breadth of what VMware professionals actually face. One hundred questions across every major VMware domain, with answers that go beyond surface-level definitions — because the real test is always the follow-up question.

 May 2026  |  ⏱ 45 min read  |   vSphere • ESXi • vCenter • NSX • vSAN • vMotion • HA • DRS • Tanzu • Horizon  |  ⚙ VMware Engineers • VCP Candidates • Solutions Architects

10 Categories — 100 Questions Total

①  vSphere & ESXi Fundamentals (Q1–Q10) ②  vCenter Server (Q11–Q20) ③  vMotion, HA & DRS (Q21–Q30) ④  vSphere Networking (Q31–Q40) ⑤  vSphere Storage & vSAN (Q41–Q50)

⑥  NSX & Micro-Segmentation (Q51–Q60) ⑦  Performance & Troubleshooting (Q61–Q70) ⑧  Security, Backup & Licensing (Q71–Q80) ⑨  VMware Cloud, Tanzu & Horizon (Q81–Q90) ⑩  Advanced & Scenario-Based (Q91–Q100)

Questions 1–10 — Foundation vSphere & ESXi Fundamentals



Q1. What is VMware vSphere and how does it differ from ESXi?

VMware vSphere is the product suite name — the complete virtualization platform. It includes ESXi, vCenter Server, and all associated management components. ESXi is the hypervisor itself: the bare-metal software that installs directly on physical server hardware and creates the virtualization layer where VMs run. ESXi replaced the older ESX in vSphere 5.0. Unlike ESX, ESXi has no Service Console (Linux partition) — it runs a microkernel VMkernel directly, reducing attack surface and memory overhead. When someone says “VMware host,” they mean a physical server running ESXi.

Q2. What is the VMkernel and what does it do?

The VMkernel is ESXi’s core operating system — a purpose-built microkernel not based on Linux (though early management agents use BusyBox Linux in a separate partition). The VMkernel manages CPU scheduling, memory management, device I/O, and network traffic for all VMs running on the host. It provides the hardware abstraction layer that makes VMs portable across different physical servers. It also handles VMkernel port traffic: management, vMotion, vSAN, NFS, iSCSI, FT logging, and provisioning traffic each require dedicated VMkernel ports with appropriate tags.

Q3. What is the difference between a VM snapshot and a VM clone?

A snapshot captures the VM’s state (memory, disk, and configuration) at a specific point in time. It does not create an independent copy — the original VM continues to run, and new writes go to a delta disk file (VMDK delta). Reverting a snapshot restores the VM to that exact point. Snapshots are not backups; they grow unboundedly on active VMs and degrade performance when large (delta files can exceed the original VMDK size). A clone creates a complete independent copy of the VM — either a full clone (separate VMDK files) or a linked clone (shares base VMDK with parent, saves space but creates a dependency). Clones are used for deploying identical VM copies; snapshots are for change control and short-term recovery.

Q4. What VMDK file types exist and what is each used for?

The primary VMDK format types: Thick Provision Lazy Zeroed (default) — allocates full disk space at creation but zeros blocks only on first write. Fastest to create. Thick Provision Eager Zeroed — allocates and zeros all space immediately at creation. Required for VMware FT and Clustering. Slower to create but guarantees no zeroing overhead during runtime. Thin Provision — allocates space on demand as data is written. Storage-efficient but can over-commit. Risk of VM pause if datastore runs out of space during thin VMDK growth. Sparse Extent — used for snapshots (delta disks). The descriptor file (.vmdk) and flat file (-flat.vmdk) are always paired; the descriptor contains metadata, the flat file contains raw disk data.

Q5. What is VMware Tools and why is it critical for VMs?

VMware Tools is a package of drivers and utilities installed inside the guest OS. Without it: (1) vMotion becomes uncoordinated (memory state may not be consistent during migration). (2) VM heartbeat monitoring doesn’t work (vSphere HA can’t verify if the guest OS is alive, only if the VM process is running). (3) Quiesced snapshots fail (VSS integration on Windows requires VMware Tools to freeze application state before snapshotting). (4) Time synchronization between VM and host doesn’t work. (5) The guest IP address isn’t visible in vCenter. (6) Graceful shutdown/restart from vCenter doesn’t work — only hard power-off is available. VMware Tools is not optional in production; it’s a mandatory component for correct VM operation.

Q6. What is the difference between vCPU and pCPU, and what is CPU Ready?

vCPU is a virtual CPU assigned to a VM. pCPU is a physical CPU core (or thread with Hyperthreading). The ESXi VMkernel CPU scheduler maps vCPUs to available pCPUs. CPU Ready is the time a vCPU spends in a ready-to-run state but waiting for a pCPU to become available. It’s measured as a percentage of time in a polling interval. CPU Ready above 5% is a performance concern; above 10% indicates significant contention. High CPU Ready is caused by: over-committing vCPUs beyond physical core count, assigning more vCPUs to a VM than it actually uses (a 16-vCPU VM must find 16 simultaneous free pCPUs), or a host that is genuinely CPU-saturated. Reducing vCPU count on under-utilizing VMs typically reduces CPU Ready across the cluster.

Q7. What is Memory Ballooning in VMware and when does it occur?

Memory ballooning is ESXi’s memory reclamation technique used when host physical memory is over-committed. The VMware Tools balloon driver (vmmemctl) inside the guest OS is instructed by the VMkernel to “inflate” — it allocates memory pages inside the guest OS, which forces the guest’s own OS paging mechanism to page those allocations to the VM’s swap disk. This frees the underlying physical memory pages for other VMs. The guest OS takes the performance hit of paging (not the VMkernel). Ballooning is triggered when host memory usage exceeds the “soft threshold” (about 94% in older vSphere versions). ESXi’s memory reclamation order is: transparent page sharing (TPS) → ballooning → swapping → memory compression → host swap (the most performance-damaging).

Q8. What is NUMA and how does ESXi handle NUMA-aware scheduling?

NUMA (Non-Uniform Memory Access) is the architecture of modern multi-socket servers where each CPU socket has local memory accessed at lower latency, and must cross a QPI/NUMA bus to access memory attached to other sockets. ESXi’s NUMA scheduler keeps a VM’s vCPUs and memory within the same NUMA node when possible. When a VM’s vCPU count exceeds one NUMA node’s pCPU count, the scheduler must split the VM across nodes (NUMA migration), which increases remote memory access and degrades performance. Best practice: size VMs so their vCPU count fits within a single NUMA node. For example, a dual-socket 32-core server has two NUMA nodes of 16 cores each — VMs with up to 16 vCPUs fit within one NUMA node.

Q9. What is the difference between VMware Fault Tolerance (FT) and vSphere HA?

vSphere HA provides restart-level availability: if a VM fails (host crash, guest OS failure), HA restarts the VM on another host in the cluster. Recovery time is typically 1–5 minutes. Data in memory at time of failure is lost. VMware FT provides continuous availability: a second VM (shadow VM) runs in lockstep with the primary on a different host, synchronized via the FT Logging Network. If the primary fails, the shadow instantly becomes primary with zero downtime and zero data loss. FT limitations: supports up to 8 vCPUs per VM (as of vSphere 8), requires dedicated 10G FT Logging Network, high CPU overhead (shadow VM consumes full CPU on secondary host), and requires Eager Zeroed Thick VMDKs. FT suits true zero-RPO/zero-RTO critical workloads; HA suits everything else with tolerable restart time.

Q10. What is a Resource Pool and how does it affect VM performance?

A Resource Pool is a logical partition of CPU and memory resources within a host or DRS cluster. It enforces Shares (relative priority during contention), Reservations (guaranteed minimum), and Limits (maximum ceiling). Shares only matter during contention: if the cluster is under-utilized, a VM with low shares gets full resource access. Reservations guarantee a minimum even under contention but reduce the pool of resources available for other VMs. A common mistake: setting a low reservation on VMs in a Resource Pool can leave VMs starved during peak load if the total reservation exceeds available resources. Resource Pools are useful for organizing VMs by business unit or tier with different service levels, but over-engineering them adds management complexity without performance benefit in lightly loaded clusters.

Questions 11–20 — Management Platform vCenter Server



Q11. What is vCenter Server and what happens if it goes offline?

vCenter Server is the centralized management platform for vSphere. It provides inventory management, role-based access control, orchestration of features (HA, DRS, vMotion), performance monitoring, and alarm management across multiple ESXi hosts. If vCenter goes offline: running VMs continue to run uninterrupted (the hypervisor is ESXi, not vCenter). However, HA and DRS stop functioning (their orchestration runs through vCenter). vMotion is unavailable (needs vCenter coordination). New deployments and management tasks fail. For this reason, vCenter itself should run on a HA-protected cluster. vCenter Server Appliance (VCSA) since vSphere 6.0 ships with built-in HA (VCSA HA) that provides an active-passive-witness configuration for vCenter availability.

Q12. What is the difference between VCSA and the Windows-based vCenter?

The Windows-based vCenter (a .exe installer on Windows Server) was deprecated and removed in vSphere 7.0. The VCSA (vCenter Server Appliance) is a Photon OS-based virtual appliance that ships as an OVA and deploys directly on ESXi. VCSA includes a built-in PostgreSQL-based vPostgres database (replacing the dependency on external SQL Server or Oracle) and supports all vSphere features. VCSA supports VCSA HA (active/passive/witness nodes), native file-based backup/restore, and the vSphere Client (HTML5). Since vSphere 7.0, all new vCenter deployments are VCSA exclusively. If someone asks about Windows vCenter in an interview, the correct answer is that it no longer exists in supported releases.

Q13. What is vCenter Linked Mode and when is it used?

Linked Mode joins multiple vCenter Server instances together under a single inventory view using the vSphere Client. Administrators log into one vCenter and can see and manage VMs across all linked vCenters without switching interfaces. Linked Mode uses the vSphere Single Sign-On (SSO) service to share authentication tokens. Enhanced Linked Mode (introduced in vSphere 6.5) allows linking vCenter instances across different SSO domains. Use cases: managing geographically distributed data centers from one interface, enabling cross-vCenter vMotion (vMotion between two vCenter instances requires them to be in Linked Mode on vSphere 6.0+), and centralized role-based access across multiple vCenters.

Q14. What is vSphere Single Sign-On (SSO) and its role in authentication?

vSphere SSO is the identity and authentication service included with vCenter. It provides token-based authentication for vSphere services, removing the requirement for each component to authenticate separately against Active Directory. SSO supports identity sources: Active Directory (via LDAP or Integrated Windows Authentication), OpenLDAP, and the localOS vsphere.local domain (the default internal domain created at installation). Authentication tokens (SAML tokens) have a configurable lifetime. SSO is integrated into VCSA and cannot be deployed externally in vSphere 7.0+. The vsphere.local administrator account is the break-glass account — always maintain a strong password for it and document it securely, as it’s needed if AD integration fails.

Q15. What is the vSphere Permissions Model and how does it work?

vSphere uses role-based access control (RBAC) with a hierarchical permission model. A Permission is a combination of: (1) an inventory object (datacenter, cluster, folder, VM, etc.), (2) a user or group, and (3) a role (set of privileges). Permissions propagate down the hierarchy by default — a permission on a datacenter applies to all objects within it. Checking “Propagate to Child Objects” enables this inheritance. A permission set on a child object overrides inherited permissions for that object. Built-in roles include Administrator, Read-Only, No Access, and No Cryptography Administrator. Custom roles are created per operational need. A common pattern: assign a help desk group Read-Only on the entire datacenter, then add a VM Power User custom role on specific VM folders they manage.

Q16. What are Tags and Attributes in vSphere and when should you use them?

Tags are metadata labels attached to vSphere inventory objects (VMs, datastores, hosts, networks). Tags are organized into Categories (e.g., “Environment” with tags: Production, Development, Test). Tags are searchable and filterable in the vSphere Client. More importantly, tags drive automation: DRS affinity rules, Storage Policy Based Management (SPBM) tag-based placement, and API-driven workflows (Ansible, Terraform) use tags to identify and group objects. Custom Attributes (legacy) attach key-value metadata to objects but don’t support tag categories or API-level filtering. Use Tags for new deployments; Custom Attributes are legacy. Example use: tag all databases VMs with “App-Type: Database” and use a DRS rule to keep them on specific hosts or require anti-affinity across hosts.

Q17. What is Content Library in vSphere and what does it store?

Content Library is a centralized repository for managing and distributing VM templates, OVF/OVA templates, ISO images, and scripts across one or multiple vCenter instances. Two library types: Local Library (stores content; source for replication) and Subscribed Library (subscribes to a Local Library; receives replicated content). Content can be synced on-demand or immediately. Content Library templates are stored in the OVF format and can be deployed directly from the library, making VM deployment consistent and fast. With vSphere 7.0, Content Library supports VM templates natively (previously required conversion). Template versioning allows maintaining multiple versions of a template and rolling back if a new template version has issues.

Q18. What is vSphere Lifecycle Manager (vLCM) and how does it differ from Update Manager (VUM)?

vSphere Update Manager (VUM) was the patch management tool for ESXi hosts — it applied patches and upgrades individually to hosts using a baseline-attach model. vSphere Lifecycle Manager (vLCM), introduced in vSphere 7.0, replaces VUM with a desired state management model. Instead of managing patches individually, vLCM uses an “Image” that defines the complete software specification for a host cluster: ESXi version, vendor add-ons (drivers from Dell, HPE, etc.), and third-party VIBs. All hosts in a cluster are remediated to match this image. The benefit: drift detection is cluster-wide, remediation is consistent, and hardware vendor components are integrated into the lifecycle process through Hardware Support Managers. VUM still exists for standalone hosts not in vLCM clusters.

Q19. What is vSphere HA Admission Control and why does it matter?

Admission Control is vSphere HA’s mechanism for reserving cluster resources to guarantee VM restart capability after host failures. Without Admission Control, HA might accept VM power-on requests that fill the cluster, leaving no headroom to restart VMs if a host fails. Three policies: Cluster resource percentage (reserve N% of CPU and memory), Slot Policy (reserves capacity for the largest VM’s slot size times the failover host count), and Dedicated failover hosts (specific hosts reserved exclusively for failover). The most common enterprise policy is “Cluster resource percentage” set to the failure level (e.g., 25% for N+1 in a 4-host cluster, 50% for N+2). If Admission Control blocks a VM power-on, it means you’ve filled the cluster beyond the reserved HA headroom.

Q20. What is VMCP (VM Component Protection) in vSphere HA?

VMCP addresses a scenario vSphere HA historically missed: a host is alive and connected to vCenter but loses access to the datastore where its VMs’ VMDKs reside (storage APD — All Paths Down, or PDL — Permanent Device Loss). Without VMCP, the host doesn’t fail, but VMs on it are effectively dead (I/O paused waiting for the storage to return). VMCP detects datastore inaccessibility and can restart affected VMs on hosts that still have datastore access. Two storage failure scenarios: APD (temporary loss, unknown duration) and PDL (permanent loss). VMCP response is configurable: issue events only, power off and restart VMs. VMCP requires that vSphere HA is enabled and the datastore failure tolerance is configured appropriately per the storage environment.

Questions 21–30 — Availability & Mobility vMotion, HA & DRS



Q21. How does vMotion work technically?

vMotion migrates a running VM from one ESXi host to another without downtime. The process: (1) The destination host pre-copies the VM’s memory pages over the vMotion network. (2) While pre-copy runs, pages changed by the running VM are tracked in a dirty-page bitmap. (3) After the initial copy, additional rounds of dirty pages are sent. (4) At the switchover point, the VM is briefly stunned (typically <100ms for most VMs), remaining memory differences are sent, and CPU state is transferred. (5) The destination host resumes execution. (6) The source host receives a “migration succeeded” confirmation and releases its copy. Requirements: shared storage (or Storage vMotion), compatible CPU families, matching vMotion network configuration, VMware Tools installed (for quiescing). With EVC (Enhanced vMotion Compatibility) mode, vMotion works across different CPU generations within a cluster.

Q22. What is Storage vMotion and how does it differ from regular vMotion?

Storage vMotion migrates a VM’s disk files (VMDKs) between datastores while the VM remains running. Regular vMotion migrates the VM’s memory and CPU state between hosts while the VMDKs stay on the same datastore. You can also do both simultaneously — migrate a running VM to a new host and a new datastore in one operation. Storage vMotion uses a mirror driver inside the ESXi host that copies the VMDK to the destination datastore while tracking writes. Once the copy is complete, a brief atomic switchover updates the VM configuration to point to the new datastore location. Use cases: evacuating a datastore before maintenance, migrating from SAS to NVMe storage without downtime, and rebalancing storage utilization.

Q23. What are the vMotion network requirements?

vMotion requires: (1) A VMkernel port tagged for vMotion on both source and destination hosts. (2) Routable Layer 3 connectivity between VMkernel IPs on both hosts (vMotion doesn’t require same subnet but RTT must be <150ms). (3) 1G minimum; 10G recommended for large-memory VMs (a 256GB VM takes significantly longer over 1G, extending stun time). (4) For simultaneous vMotion streams, 10G allows multiple concurrent migrations. (5) CPUs must be compatible (same vendor; EVC mode covers CPU-version differences). (6) The VM cannot have devices that can’t be disconnected (physical RDM mapped in physical mode, some USB controllers). A common interview question: can vMotion work without shared storage? Answer: yes, with vSphere 5.1+ which added Long Distance vMotion (migrations over WAN) and allows vMotion with Storage vMotion simultaneously.

Q24. What is DRS and what are its automation levels?

Distributed Resource Scheduler (DRS) automatically balances CPU and memory resources across hosts in a cluster by migrating VMs via vMotion. DRS evaluates cluster balance using a “cluster imbalance” score (1=balanced, 5=severely imbalanced). Automation levels: Manual — DRS generates migration recommendations that administrators must manually approve. Partially Automated — DRS automatically places VMs at initial power-on but only recommends (not applies) runtime migrations. Fully Automated — DRS applies all migration recommendations automatically. The “Migration Threshold” setting (1–5) controls how aggressively DRS migrates: 1 (Conservative, only applies priority-1 recommendations) to 5 (Aggressive, applies all recommendations). Most production clusters use Fully Automated with threshold 3 (balanced).

Q25. What are DRS Affinity and Anti-Affinity rules?

DRS rules control VM placement relative to other VMs or hosts. VM-VM Affinity: “Keep these VMs together” — keeps specified VMs on the same host (e.g., app server and its paired monitoring agent). VM-VM Anti-Affinity: “Separate these VMs” — ensures specified VMs run on different hosts (e.g., two domain controllers, two web-tier VMs for HA). VM-Host Affinity: restricts a VM or group to run on specific hosts or host groups. Rules are “Required” (hard: DRS violates are blocked) or “Preferred” (soft: DRS tries but can violate if needed). Important: conflicting required rules (anti-affinity that contradicts HA restart behavior) can cause VMs not to power on. Always test DRS rules before production deployment.

Q26. What is vSphere HA isolation response and when is it triggered?

Host isolation occurs when an ESXi host loses communication with all other hosts in the cluster but is still running. The host can’t determine if the cluster has failed or if it is isolated. HA’s isolation response determines what the isolated host does with its VMs. Options: Disabled (do nothing, VMs keep running), Power Off (power off VMs and let HA restart them elsewhere), Shut Down (graceful shutdown using VMware Tools, then HA restarts). The host determines it’s isolated by: failing all heartbeat checks (default: 12 seconds), then pinging the isolation address (default: gateway IP). If pings fail, isolation is confirmed. The isolation response should be configured based on your storage type: if shared storage is VMFS, “Power Off” is safe (HA will restart VMs on surviving hosts). If storage is local, “Disabled” may be preferable.

Q27. What is Proactive HA and how does it differ from reactive vSphere HA?

Reactive vSphere HA acts after failure: host goes down, HA detects failure and restarts VMs on surviving hosts. Recovery time is measured in minutes. Proactive HA (introduced in vSphere 6.5) works with hardware providers (Dell, HPE, Cisco UCS, others) that integrate hardware health telemetry into vSphere. When a hardware provider reports that a component (fan, PSU, CPU temperature) is degrading but hasn’t yet failed, Proactive HA can migrate VMs off that host before the failure occurs. The host is placed in Quarantine Mode (degraded, fewer VMs) or Maintenance Mode (fully evacuated) depending on severity. The net effect: zero-downtime hardware events instead of VM restarts. Proactive HA requires both the hardware integration plugin and DRS Fully Automated.

Q28. What is EVC (Enhanced vMotion Compatibility) and when is it needed?

EVC masks CPU features exposed to VMs so that all VMs see a consistent CPU feature set across all hosts in a cluster. Without EVC, a VM started on an Intel Xeon 4th Gen host exposes Sapphire Rapids-specific CPU instructions to the guest. Migrating that VM via vMotion to an older Ice Lake host fails because the Ice Lake host can’t present those CPU features. EVC sets the CPU baseline to the lowest common denominator in the cluster (or a manually chosen baseline). All VMs started in an EVC cluster see only the baseline CPU features. This allows vMotion between hosts of different CPU generations within the same vendor. You cannot change the EVC mode on a cluster with powered-on VMs; you must power off all VMs, change EVC mode, then power them back on. EVC does not apply cross-vendor (Intel ↔ AMD).

Q29. What is vSphere HA Datastore Heartbeating?

Datastore heartbeating is a secondary communication channel HA uses to resolve split-brain scenarios. When a host stops receiving HA network heartbeats from other cluster members, HA checks whether the host can write to a heartbeat datastore. If the host can write to the datastore but can’t reach the management network, HA classifies the host as “isolated” (host is alive but network-isolated) rather than “failed” (host is dead). This distinction determines whether HA restarts the VMs elsewhere or waits. vCenter automatically selects two datastores per cluster for heartbeating; you can manually specify additional datastores. Datastores used for heartbeating must be accessible by all cluster hosts. NFS and VMFS datastores both work; vSAN uses an internal heartbeat mechanism.

Q30. What is Predictive DRS and how does it use vRealize Operations (Aria Operations)?

Standard DRS is reactive: it detects imbalance after it occurs and then migrates VMs to correct it. Predictive DRS integrates with VMware Aria Operations (formerly vRealize Operations) to use workload trend predictions. Aria Operations analyzes historical performance patterns for each VM and predicts future resource demand (e.g., a VM that spikes CPU every weekday at 9am). Predictive DRS migrates VMs based on predicted future imbalance — before the load spike occurs — so hosts don’t become overloaded. This requires Aria Operations deployed and integrated with vCenter via a vSphere Integration.

Questions 31–40 — Virtual Networking vSphere Networking



Q31. What is the difference between a vSphere Standard Switch (vSS) and Distributed Switch (vDS)?

A vSphere Standard Switch (vSS) is configured per-host. Each ESXi host has its own vSS, and configurations (port groups, uplink policies, NIC teaming) must be maintained independently on each host. No central management. A vSphere Distributed Switch (vDS) is a centralized virtual switch managed through vCenter. The vDS spans multiple hosts; port group configurations are applied once at the vCenter level and pushed to all hosts. Benefits of vDS: consistent port group configuration, LACP support (vSS only supports static 802.3ad), Network I/O Control (NIOC), network health check, distributed port mirroring (SPAN), NetFlow export, private VLANs (PVLAN), and VMware NSX integration. vDS requires vSphere Enterprise Plus license.

Q32. What is Network I/O Control (NIOC) and why is it important?

Network I/O Control allocates bandwidth shares, limits, and reservations to different traffic types sharing the same physical uplinks on a vDS. Without NIOC, a VM running a large file transfer can saturate all uplink bandwidth and starve vMotion traffic, causing slow migrations or timeouts. NIOC defines traffic categories: Management, vMotion, vSAN, NFS, iSCSI, vSphere Replication, Fault Tolerance, and virtual machine traffic. Each category gets a share value, optional reservation (Mbps), and optional limit. During contention, shares determine bandwidth allocation. NIOC v3 (vSphere 6.0+) allows per-vNIC reservations for individual VMs. Production best practice: set a vMotion reservation high enough to guarantee migrations complete within SLA even when uplinks are busy with production traffic.

Q33. What is a Private VLAN (PVLAN) in vSphere and when would you configure it?

PVLANs extend VLAN segmentation by creating sub-VLANs within a primary VLAN, controlling which ports within the VLAN can communicate. Three port types: Promiscuous (can communicate with all ports; typically the gateway/firewall), Isolated (can only communicate with Promiscuous ports; isolated from all other hosts including other Isolated ports), and Community (can communicate with other Community ports in the same community PVLAN and with Promiscuous ports; isolated from other communities and Isolated ports). Use case: multi-tenant hosting where VMs in the same IP subnet should not communicate with each other (each tenant gets Isolated ports; the gateway gets a Promiscuous port). PVLANs require PVLAN configuration on the physical upstream switch to match the vDS PVLAN configuration.

Q34. What NIC teaming policies are available on a vSphere vSS/vDS?

Load balancing policies: Route based on originating virtual port (default): assigns each VM to an uplink based on VM’s port ID. Simple, no switch configuration needed, but doesn’t load-balance well. Route based on IP hash: hashes source+destination IP to select an uplink. Distributes traffic across uplinks based on conversation pairs. Requires EtherChannel/802.3ad on the physical switch. Route based on source MAC hash: uses VM MAC as hash key. Use explicit failover order: active and standby uplinks; no load balancing. Route based on physical NIC load (vDS only, Beacon probing required): ESXi monitors NIC utilization and moves VMs to under-utilized NICs. Requires vDS. Most production environments use “Route based on originating virtual port” for simplicity or IP hash with physical LAG/LACP for maximum throughput.

Q35. What is a VMkernel Port and what traffic types use it?

VMkernel ports are ESXi-level network interfaces (not VM-level) used for host-originated traffic. Unlike VM port groups (which carry guest VM traffic), VMkernel ports handle hypervisor traffic. Traffic types with dedicated VMkernel tags: Management (vCenter-to-ESXi communication, ESXi Shell, SSH), vMotion, vSAN, NFS storage, iSCSI storage, Fault Tolerance logging, vSphere Replication (outgoing traffic for replication), vSphere Replication NFC (incoming replication data). Multiple VMkernel ports with different IP addresses can be created on the same host, typically on different VLANs. Best practice: separate management, vMotion, and storage traffic on dedicated VMkernel ports with dedicated VLANs and separate physical uplinks where possible.

Q36. What is port mirroring (SPAN) in vSphere vDS?

Port mirroring on vDS copies traffic from specified source ports to a destination port (a VM running a network analyzer like Wireshark, or a physical probe). Four vDS mirroring session types: Distributed Port Mirroring (mirrors source vDS ports to destination vDS port, all within the same host or across hosts), Remote Mirroring Source (sends mirrored traffic encapsulated in a VLAN to a remote physical analyzer), Remote Mirroring Destination (receives remotely mirrored traffic from a physical switch), and Encapsulated Remote Mirroring (L3) Source (wraps mirrored traffic in GRE/ERSPAN for delivery over Layer 3 to a remote analyzer). Port mirroring is commonly used for IDS/IPS inspection and network forensics in environments where physical SPAN ports aren’t practical.

Q37. What is Jumbo Frames and when should you enable them in vSphere?

Jumbo Frames sets Ethernet MTU to 9000 bytes (standard is 1500 bytes). Larger frames reduce CPU overhead per byte transferred (fewer frames to process for the same data volume) and increase throughput for sustained large transfers. In vSphere, Jumbo Frames are relevant for: vMotion networks (larger MTU = faster memory copy = shorter stun time), NFS storage networks, iSCSI storage, and vSAN. Critical requirement: Jumbo Frames must be consistently configured end-to-end — ESXi VMkernel port, vSS/vDS port group, physical switch ports, and storage target network interfaces must all be set to 9000 MTU. A single misconfigured hop drops to 1500 and causes significant performance degradation (or connection failures for PMTUD-disabled traffic). Verify with vmkping -d -s 8972 <target-IP> from ESXi shell.

Q38. What is DirectPath I/O (VMDirectPath) in vSphere?

DirectPath I/O (PCI Passthrough) gives a VM direct access to a physical PCIe device on the host, bypassing the ESXi hypervisor layer. The VM communicates with the device at near-native performance because there’s no hypervisor abstraction overhead. Use cases: high-performance NICs for SR-IOV networking (though SR-IOV is preferred over pure passthrough for scalability), GPU passthrough for CUDA/OpenCL workloads in VMs, and high-speed NVMe drives. Tradeoffs: VMs with DirectPath devices cannot use vMotion (can’t detach a physical PCIe device and migrate it), Fault Tolerance is unsupported, snapshots may not capture the passthrough device state, and HA restart may fail if the physical device is unavailable on the restarting host. Requires Intel VT-d or AMD-Vi in the server BIOS.

Q39. What is SR-IOV and how does it differ from DirectPath I/O?

SR-IOV (Single Root I/O Virtualization) is a PCIe standard that allows a single physical NIC to present multiple independent “virtual functions” (VFs) to the hypervisor. Each VF can be assigned directly to a VM, providing near-native NIC performance for that VM. Unlike DirectPath I/O (which dedicates the entire physical device to one VM), SR-IOV shares one physical NIC across multiple VMs via its VFs. With a 4-port 25G SR-IOV NIC that supports 64 VFs per port, you can assign 64 VMs direct NIC access per port. SR-IOV VMs still can’t use live vMotion (same hardware dependency issue as DirectPath). SR-IOV is commonly used for NFV (Network Functions Virtualization) workloads, packet-intensive applications, and high-throughput trading platforms.

Q40. What is vSphere Network Health Check on a vDS?

Network Health Check periodically tests whether the physical switch configuration matches the vDS configuration for uplink ports. It checks three things: (1) VLAN configuration — whether VLANs configured in port groups are allowed on the connected physical switch trunk ports. (2) MTU — whether the physical switch port MTU matches the vDS MTU. (3) Team policy — whether LACP/EtherChannel settings on the physical switch match the NIC teaming policy. Health check results appear in the vSphere Client as warnings on affected uplinks. This feature saves significant troubleshooting time — instead of manually checking every physical switch port for VLAN mismatches, the vDS probes and reports discrepancies automatically.

Questions 41–50 — Storage Platform vSphere Storage & vSAN



Q41. What is VMFS and how does it differ from NFS in vSphere?

VMFS (Virtual Machine File System) is VMware’s proprietary cluster filesystem optimized for storing VMDKs on block storage (iSCSI, FC, FCoE). It supports concurrent access from multiple ESXi hosts simultaneously via its distributed locking mechanism. Current version is VMFS-6 (vSphere 6.5+) which supports 64TB maximum VMDK size and 512e and 4Kn advanced format drives. NFS is a standard network file protocol that ESXi mounts directly as a datastore (NFS v3 and v4.1 supported). NFS datastores are managed by the NAS/NFS server; multiple ESXi hosts can mount the same NFS share. Key differences: VMFS supports RDM (Raw Device Mapping); NFS does not. NFS datastores support hardware acceleration (VAAI-NAS) but with fewer offload primitives than VAAI-SCSI for VMFS. NFS is typically simpler to manage; VMFS is needed for features like FT, VMs requiring physical RDMs.

Q42. What is an RDM (Raw Device Mapping) and when is it required?

An RDM is a pointer file on a VMFS datastore that gives a VM direct access to a LUN on a SAN. The VM sees the LUN as if it were a local disk. Two modes: Virtual Compatibility Mode (vRDM): the LUN is managed by the ESXi SCSI stack; supports snapshots, vMotion, and cloning. Appears as a virtual disk to the VM. Physical Compatibility Mode (pRDM): passes SCSI commands directly to the LUN, bypassing ESXi’s SCSI stack. The VM can issue arbitrary SCSI commands. Used for: Windows Server Clustering (WSFC) that requires SCSI reservations on shared disks, SAN management software inside a VM that needs raw device access, and Oracle RAC configurations. pRDM disables vMotion and snapshots. Use RDMs only when required by an application that specifically needs raw SAN access; standard VMDKs are preferable for all other workloads.

Q43. What is Storage Policy Based Management (SPBM)?

SPBM abstracts storage capabilities from the underlying storage technology and allows administrators to define storage policies (e.g., “Gold: RAID-5, 3 IOPS/GB, encrypted”) that are applied to VMs and VMDKs. The policy engine matches the policy requirements to available storage providers. Storage arrays expose their capabilities (performance tiers, RAID types, dedup, encryption, replication) via VASA (vSphere APIs for Storage Awareness) providers. When a VM is provisioned with a policy, vSphere automatically places it on compatible storage. vSAN uses SPBM natively — all vSAN features (FTT, RAID type, IOPS limit, encryption, stretched cluster rules) are defined via SPBM policies. SPBM monitors compliance: if a storage change causes a VM to no longer comply with its policy, vCenter flags the VM as non-compliant.

Q44. What is VMware vSAN and how does it create a shared datastore?

vSAN is VMware’s hyperconverged storage solution integrated directly into ESXi. It pools local SSDs and HDDs from multiple ESXi hosts into a shared distributed datastore accessible by all hosts in the vSAN cluster. Each vSAN host contributes disk groups (at least one SSD/NVMe for caching + HDDs or SSDs for capacity). The vSAN Distributed Data Store (DD) spreads VM objects across hosts according to SPBM storage policies. RAID-1 (mirroring) and RAID-5/6 (erasure coding) provide data protection. Minimum cluster sizes: 3 nodes for FTT=1 RAID-1, 4 nodes for RAID-5 (FTT=1), 6 nodes for RAID-6 (FTT=2). vSAN requires all hosts to have solid-state caching devices and the vSAN VMkernel port configured. No separate storage hardware is needed.

Q45. What is FTT (Failures to Tolerate) in vSAN and how does it affect storage overhead?

FTT defines how many simultaneous hardware failures a VM’s storage objects can survive. SPBM policy VSAN.hostFailuresToTolerate=1 (FTT=1) means the object survives 1 host, disk, or network failure. Storage overhead by RAID type: RAID-1 (FTT=1): 2 data copies = 2x storage overhead. Needs 3 hosts minimum. RAID-1 (FTT=2): 3 data copies = 3x overhead. Needs 5 hosts. RAID-5 (FTT=1): erasure coding, ~1.33x overhead. Needs 4 hosts. RAID-6 (FTT=2): ~1.5x overhead. Needs 6 hosts. Production recommendation: FTT=1 RAID-1 for latency-sensitive workloads; RAID-5 FTT=1 for capacity efficiency; always use FTT=2 or higher for mission-critical VMs.

Q46. What is vSAN Stretched Cluster and what are its RTT requirements?

A vSAN Stretched Cluster spans two geographically separate sites with a witness node at a third site. Nodes are evenly split between the two sites (minimum 2+2 nodes). Every write is confirmed by both sites before acknowledging to the VM (synchronous replication), providing zero RPO. The witness resolves split-brain scenarios when site-to-site connectivity is lost. RTT requirements: site-to-site (primary sites) must be ≤5ms RTT for optimal performance (≤10ms supported maximum). Site-to-witness can be ≤200ms RTT. Stretched clusters have higher write latency than single-site (every write crosses the inter-site link) but provide site-level fault tolerance. Use for metro-distance DR where zero data loss is required without separate replication software.

Q47. What is VAAI (vSphere APIs for Array Integration) and what does it offload?

VAAI allows ESXi to offload specific storage operations to the storage array’s hardware, reducing CPU load on the ESXi host and improving performance. Three VAAI-SCSI primitives: Hardware-Accelerated Locking (ATS): Atomic Test & Set — replaces SCSI reservations for VMFS metadata operations, dramatically improving VMFS scalability in large clusters. Full Copy (XCOPY): offloads VMDK cloning and Storage vMotion to the array (array copies internally without reading/writing over the network). Block Zeroing (WRITE SAME): zeroing Eager Zeroed Thick VMDKs at array speed without transferring zeros over the network. VAAI-NAS adds similar capabilities for NFS: Fast File Clone, Reserve Space, Full File Clone, and Extended Statistics. VAAI support varies by storage vendor and platform — verify with the VMware Hardware Compatibility Guide.

Q48. What is datastore cluster and Storage DRS (SDRS)?

A Datastore Cluster groups multiple datastores into a single management unit. Storage DRS (SDRS) automatically balances space utilization and I/O workload across datastores in the cluster by migrating VMDKs (via Storage vMotion). SDRS monitors: space utilization (threshold configurable; default 80% triggers SDRS to recommend migrations) and I/O latency (threshold configurable; default 15ms average latency triggers I/O balance recommendations). Like compute DRS, SDRS can be Manual (recommendations only) or Fully Automated. SDRS also provides initial placement recommendations when deploying new VMs — instead of manually choosing which datastore, SDRS selects the optimal one. Anti-affinity rules in SDRS keep specific VMDKs on different datastores (e.g., OS disk and data disk on different arrays for I/O isolation).

Q49. What is vSphere Replication and how does it differ from SAN-based replication?

vSphere Replication is VMware’s host-based asynchronous replication solution. The vSphere Replication appliance runs on both source and destination sites. Changed blocks of each replicated VMDK are tracked and sent to the destination site at configurable intervals (RPO of 5 minutes to 24 hours). Unlike SAN replication (which replicates at the storage array level for all data on a LUN), vSphere Replication is per-VM, allows heterogeneous storage (replicate from SAN to NFS), and doesn’t require matching storage hardware at both sites. Limitations: asynchronous only (RPO ≥ 5 min); no zero-RPO option. SAN replication advantages: handles all LUN data regardless of what’s on it; synchronous replication achievable (zero RPO). vSphere Replication integrates with VMware Site Recovery Manager (SRM) for automated failover orchestration.

Q50. What is VM encryption in vSphere and how does it work?

VM Encryption (vSphere 6.5+) encrypts VM data at rest using AES-256 encryption applied at the hypervisor layer before writing to datastore, independent of the guest OS or storage hardware. Encryption is configured via SPBM storage policy (assign the Encryption policy to a VM). A KMS (Key Management Server) provides the key management; vCenter requests keys from the KMS, decrypts a local DEK (Data Encryption Key) and stores it in memory. The VMkernel encrypts/decrypts data in-flight between VM and storage. Benefits: protects data at rest from physical disk theft, portable encryption keys (works across storage types), and transparent to guest OS. Limitations: encrypted VMs cannot be cold-migrated if the destination lacks KMS access; key management requires a reliable KMS infrastructure. vSphere 7.0 also introduced vTPM (Virtual Trusted Platform Module) which provides a TPM 2.0 device to the guest for Secure Boot and credential storage.

Questions 51–60 — Network Virtualization VMware NSX & Micro-Segmentation



Q51. What is VMware NSX-T (NSX) and what problem does it solve?

NSX (formerly NSX-T Data Center, now simply VMware NSX) is VMware’s network virtualization and security platform. It creates a software-defined networking layer on top of physical infrastructure, providing virtual switches, routers, firewalls, and load balancers entirely in software. The core problem it solves: traditional physical networking applies security at the perimeter (North-South), allowing threats that enter the network to move freely between workloads (East-West). NSX embeds a distributed firewall directly in the ESXi hypervisor at the vNIC level — every packet entering or leaving a VM is inspected by policy, regardless of whether it crosses a physical switch. This micro-segmentation approach prevents lateral movement. NSX also enables consistent networking across vSphere, Kubernetes, bare metal, and public cloud through a single policy management plane (NSX Manager).

Q52. What is the NSX Distributed Firewall (DFW) and how does it differ from a physical NGFW?

The NSX DFW runs as kernel modules in ESXi, inspecting all VM traffic at the vNIC level before it leaves the host. Every VM has its own firewall enforcement point. Rules are based on objects (VM, tag, security group) rather than IP addresses, which means policy follows workloads as they migrate. A physical NGFW is a centralized appliance that traffic must be redirected to — East-West traffic between VMs on the same host never hits a physical firewall. The DFW inspects that traffic inline. Physical NGFWs apply deep inspection (Layer 7, SSL decryption, IDS/IPS) that the basic DFW doesn’t; NSX addresses this through service chaining with partner firewalls (Palo Alto, Check Point) via NSX Introspection, allowing third-party security tools to inspect traffic without requiring VMs to be in the physical traffic path.

Q53. What is the NSX Overlay Network and how does it use Geneve encapsulation?

NSX creates overlay networks using Geneve (Generic Network Virtualization Encapsulation, RFC 8926) tunneling protocol. Each NSX logical switch (Segment) is identified by a unique VNI. When a VM on Host-A sends traffic to a VM on Host-B in the same logical segment, the NSX TEP (Tunnel Endpoint, a VMkernel port on each host) encapsulates the frame in Geneve with the destination VNI and destination TEP IP. The physical network carries the Geneve-encapsulated UDP packet between TEPs without needing to know about the overlay VLANs. This decouples the virtual network topology from the physical network — you can have thousands of logical segments on a physical network that only has a few VLANs. Geneve’s variable-length options header supports richer metadata than VXLAN, which NSX uses for security group tagging and network policy information.

Q54. What is the NSX Tier-0 and Tier-1 gateway and what routes do they handle?

Tier-0 Gateway connects the NSX overlay network to external physical networks. It runs BGP with physical routers (upstream switches, WAN routers) and redistributes routes between the NSX overlay and the physical underlay. Tier-0 is typically deployed in Active-Active or Active-Standby mode across two NSX Edge nodes for redundancy. Tier-1 Gateway is the virtual router that connects NSX Segments (logical switches) to the Tier-0. Workloads attach to Segments; Segments connect to Tier-1; Tier-1 connects to Tier-0. Tier-1 handles North-South routing for its attached segments by advertising their prefixes to Tier-0. Multiple Tier-1 gateways provide tenant isolation: Tenant-A’s Tier-1 and Tenant-B’s Tier-1 each maintain separate routing tables. This maps to ACI’s Tenant/VRF model.

Q55. What is NSX Intelligence and what analytics does it provide?

NSX Intelligence is an analytics and visualization component that processes flow data from the NSX DFW to provide: (1) Application topology visualization — automatically discovers and maps communication flows between VMs and containers, creating a visual network dependency map. (2) Security policy recommendations — suggests DFW rules based on observed traffic patterns. Instead of manually analyzing flows to write micro-segmentation rules, NSX Intelligence proposes them based on what traffic is actually occurring. (3) Anomaly detection — identifies unusual traffic patterns that deviate from the learned baseline. (4) Rule hit count and unused rule identification — shows which DFW rules are actually matching traffic, helping clean up stale policies.

Q56. What is NSX Federation and when is it required?

NSX Federation (formerly Policy Manager) allows managing multiple NSX deployments (locations) from a single Global Manager. A Global Manager is deployed outside any local site and provides a unified policy management interface. NSX Managers at each site synchronize policy from the Global Manager and enforce it locally. Stretched Segments extend a logical network across sites through the Federation. Use cases: consistent DFW security policy across multiple data centers from one place, stretched networking between sites for workload mobility, and single-pane management for DR scenarios. Federation differs from standalone NSX in that security groups and DFW policies created in the Global Manager apply across all connected sites, not just locally.

Q57. How does NSX handle East-West load balancing?

NSX provides a software load balancer that can run in two modes: Inline mode (load balancer is in the traffic path; can perform SSL termination, content-switching, persistence) and Transparent mode (load balancer is not in the path; uses NAT to distribute traffic). The NSX load balancer runs as a service on NSX Edge nodes. For East-West load balancing between microservices within the same data center, NSX LB eliminates the need to hairpin traffic to a physical load balancer. NSX also integrates with Kubernetes via NSX Container Plug-in (NCP) for automatic provisioning of load balancer VIPs for Kubernetes Services. NSX LB supports algorithms: Round Robin, IP Hash, Least Connection, and Weighted algorithms.

Q58. What is NSX-T vs NSX-V and why did VMware migrate customers?

NSX-V (NSX for vSphere) was tightly coupled to vSphere only and used VXLAN for overlay networking. It required a vCenter for every NSX-V deployment and couldn’t extend to non-vSphere environments. NSX-T (NSX Transformers, now simply “NSX”) was rebuilt from the ground up with a transport-layer agnostic architecture supporting vSphere, KVM, bare metal, public cloud (AWS, Azure), and Kubernetes. It uses Geneve instead of VXLAN, supports NSX-T Manager as a standalone management plane independent of vCenter, and can manage networking across heterogeneous environments. VMware end-of-life’d NSX-V after vSphere 6.x — VMware forced migration as NSX-V wasn’t compatible with vSphere 7.0. All new deployments use NSX (formerly NSX-T).

Q59. What is NSX Advanced Threat Prevention (ATP)?

NSX Advanced Threat Prevention integrates IDS/IPS (Intrusion Detection and Prevention), Network Traffic Analysis (NTA), malware detection (Malware Prevention via sandbox analysis), and Network Detection and Response (NDR) capabilities directly into the NSX security platform. Unlike traditional perimeter security, NSX ATP applies these capabilities to East-West traffic inside the data center. IDS/IPS signatures are applied at the ESXi kernel level via the NSX DFW. Suspicious files observed in VM traffic are sent to a cloud-based sandbox for analysis. NDR correlates network events to identify kill chains and attack campaigns across the environment. This replaces the need for separate IDS/IPS appliances for internal traffic inspection.

Q60. What is NSX Context-Aware Firewall / App-ID firewall?

NSX Context-Aware Firewall (Layer 7 firewall in NSX DFW) allows firewall rules based on application identity rather than just ports and protocols. Instead of allowing “TCP port 80,” you allow “HTTP to web servers” while blocking non-HTTP traffic on port 80. NSX uses DPI (Deep Packet Inspection) to identify applications by their traffic signature. Context-aware rules can reference: App-ID (application signature), User-ID (Active Directory user groups via Identity Firewall), and VM-level context (VM name, tag, OS type). This enables writing security rules in business terms (“Allow DB-Admin group access to Oracle Database VMs”) rather than IP/port rules. Context-aware firewall requires NSX Enterprise Plus licensing.

Questions 61–70 — Operations Performance & Troubleshooting



Q61. What ESXi command-line tools are most useful for troubleshooting?

esxtop: Real-time performance monitoring (CPU, memory, disk, network). Press ‘h’ for help, ‘n’ for network view, ‘d’ for disk. Export with esxtop -b -n 10 > output.csv for batch analysis. esxcli: The primary CLI for ESXi management tasks — list VMs, check network config, manage storage, query hardware. vmkping: Ping from VMkernel context (tests VMkernel network connectivity). vim-cmd: Manage VMs from CLI (power operations, list VMs, check snapshots). vsish: vSphere internals shell for deep-level system statistics. cat /var/log/vmkernel.log: Primary ESXi kernel log. cat /var/log/hostd.log: Host management daemon log (vSphere Client connection issues).

Q62. A VM is showing high CPU usage but the application team says it’s slow. What do you check first?

Check CPU Ready before anything else. High CPU utilization inside the VM (“CPU usage 95%”) doesn’t tell you whether the host is contributing to the problem. If CPU Ready is high (>5%), the VM is waiting for pCPUs — the host is over-committed. If CPU Ready is low but CPU usage is high, the VM genuinely needs more compute (add vCPUs or migrate to a more powerful host). Also check: CPU Co-stop (for multi-vCPU VMs: all vCPUs must be scheduled simultaneously; co-stop is time waiting for co-scheduling) — high co-stop suggests the VM has more vCPUs than it actually uses, and they create co-scheduling overhead. NUMA Remote memory access: if the VM spans NUMA nodes, memory latency increases. Use esxtop CPU fields: %USED, %RDY (CPU Ready), %CSTP (Co-Stop), %MLMTD (limited by CPU limit if set).

Q63. A vMotion fails. Walk through the troubleshooting steps.

1. Check the exact error message in vCenter (Tasks & Events). “Failed to migrate VM” with a specific reason code narrows the cause significantly. 2. Verify VMkernel ports: both hosts must have VMkernel ports tagged for vMotion and able to communicate. Test with vmkping -I vmk1 <destination-vmk-ip> from each host. 3. Check CPU compatibility: are the CPUs from the same vendor? Is EVC mode configured? If the source VM was started with CPU features that the destination can’t expose, vMotion will fail. 4. Check for unsupported devices: physical RDM in physical compatibility mode, USB passthrough, and some DirectPath I/O devices prevent vMotion. 5. Check storage: can both hosts access the VM’s datastores? Mount issues will fail the migration. 6. Check vMotion network bandwidth: a slow 1G vMotion network for a VM with 256GB RAM will time out. 7. Review vpxd.log on vCenter and vmkernel.log on the ESXi host for detailed error context.

Q64. What is the PSOD (Purple Screen of Death) and how do you analyze it?

A PSOD is ESXi’s kernel panic. When VMkernel detects a fatal error (hardware failure, driver bug, memory corruption), it dumps state to screen and potentially to a coredump file, then halts. The purple screen contains: the triggering error message, a backtrace showing which kernel functions were executing, and register dump. Analysis: (1) Capture the full PSOD text (screenshot or log). (2) Check the first few lines for the error type. Common PSOD causes: NMI PSOD (hardware error, check iDRAC/iLO logs for memory, CPU, or DIMM errors), PSOD in driver (update or rollback the NIC/HBA/storage driver — check VMware HCL for supported driver version), watchdog PSOD (watchdog timer expired, often hardware or storage I/O hang). Upload the core dump to VMware Support or use VMware’s online PSOD analysis tool at kb.vmware.com/KB1003564.

Q65. How do you identify storage latency issues on an ESXi host?

In esxtop, press ‘d’ for disk view. Key metrics: DAVG/cmd (device average latency — time in the storage array): above 5ms for SAN/NAS is a concern; above 20ms is a problem. KAVG/cmd (kernel average latency — time in ESXi’s storage stack): should be very low (<1ms). High KAVG indicates an ESXi storage driver or queue depth issue. GAVG/cmd (guest average latency = DAVG + KAVG): what the VM actually experiences. QUED (queue depth saturation): if non-zero frequently, the device queue is full and ESXi is holding I/Os. Also check: esxcli storage core device stats get for per-device statistics, and vCenter’s datastore performance charts for historical latency trends.

Q66. What is Transparent Page Sharing (TPS) and is it still enabled by default?

TPS scans VM memory pages and identifies duplicate pages across VMs running on the same host. When duplicate pages are found, ESXi keeps only one copy in physical memory and maps all VMs to that shared page (marked copy-on-write). This was significant memory savings in the era of many identical Windows Server VMs running the same OS. Post-Heartbleed/DROWN era: VMware disabled inter-VM TPS by default in vSphere 5.5 Update 3+ because page sharing between different VMs is a potential side-channel attack vector (attacker VM can infer other VMs’ memory content by measuring TPS sharing patterns). Currently, TPS is enabled only within the same VM (intra-VM TPS), which has no cross-VM security implications. Re-enabling inter-VM TPS requires setting Mem.ShareForceSalting=0 or configuring salting level on shared pages — this is a documented but not recommended change for multi-tenant environments.

Q67. What is vCenter Server Appliance (VCSA) HA and how does it work?

VCSA HA deploys three VCSA instances: Active (handles all management operations), Passive (receives database replication from Active; ready to take over), and Witness (provides quorum and tiebreaking but doesn’t run the vCenter service). If the Active VCSA fails, the Passive becomes Active within 3–5 minutes. The database state is continuously replicated so the failover is nearly seamless. All three nodes must be on the same L2 network segment (direct link is optional, but low-latency connectivity between Active and Passive is critical for replication). VCSA HA is distinct from vSphere HA — VCSA HA is specifically for vCenter’s own high availability. vCenter itself should still run on a vSphere HA-enabled cluster so that if the underlying ESXi host fails, the VCSA VM restarts (the VCSA HA layer then handles the role transition if needed).

Q68. What are the common causes of high memory balloon in vSphere?

Ballooning occurs when the ESXi host’s physical memory is over-committed. Common causes: (1) Too many VMs with too much memory assigned on the host. (2) VMs with memory reservations that weren’t set (by default VMs have no reservation, so the full memory is available for over-commitment). (3) VMs not using their full allocated memory, but that memory can’t be reclaimed without a reservation. (4) Growth in VM workload without corresponding physical memory upgrades. Solutions: add physical RAM to the host, reduce VM memory allocations to what’s actually used (right-size VMs using performance data), set memory reservations for latency-sensitive VMs (prevents ballooning on those VMs but reduces total over-commit capacity), or use DRS to rebalance VMs to hosts with more free memory. Monitor with vCenter performance charts: “Memory Balloon” counter on the host.

Q69. How do you put an ESXi host into Maintenance Mode safely?

Maintenance Mode evacuates all running VMs from a host before any maintenance operation. When entering Maintenance Mode in a DRS cluster: DRS automatically migrates VMs via vMotion to other hosts in the cluster. If DRS is Manual, you’ll need to manually vMotion VMs off. For vSAN clusters: Maintenance Mode offers three options: Full Data Migration (moves all VM data off the host — slowest but safest; required for disk replacement), Ensure Accessibility (ensures all VMs remain accessible but doesn’t fully evacuate data; faster), No Data Migration (don’t move data; risks data accessibility if data is present only on this host). Prerequisites: verify the cluster has enough capacity to absorb the evacuated VMs, check HA admission control won’t block power-ons on other hosts, and confirm no DRS required rules will be violated.

Q70. What is the VM Stun Time and what causes it to increase during vMotion?

VM stun time is the brief period during the final vMotion switchover where the VM is paused. During this pause, remaining memory differences and final CPU state are transferred to the destination host. Normal stun time is under 100ms for most VMs (imperceptible to users). Stun time increases when: (1) The VM has a very large memory footprint and is writing dirty pages faster than the vMotion network can copy them (“dirty page problem” — memory write rate exceeds vMotion transfer rate). (2) The vMotion network is congested or slow. (3) The VM has very high memory activity (databases doing large transactions). Solutions: use 10G or 25G vMotion networks, use NIOC to guarantee vMotion bandwidth during contention, and limit concurrent vMotion streams per host (each consumes vMotion network bandwidth).

Questions 71–80 — Security & Operations Security, Backup & Licensing



Q71. What is vSphere Security Hardening Guide and what are the key recommendations?

VMware publishes a Security Hardening Guide categorizing controls by risk level. Key recommendations: Disable ESXi Shell and SSH when not in use (enable only during maintenance, disable afterward). Configure lockdown mode (restricts direct access to ESXi, forcing all management through vCenter). Use the minimum number of accounts with the least-privilege principle. Enable audit logging (all authentication and configuration events). Configure NTP (certificate validation requires accurate time). Remove unused virtual hardware from VMs (floppy drives, serial/parallel ports). Isolate management network on dedicated VLAN. Configure Account Lockout Policy. Enable FIPS 140-2 mode for cryptographic operations. Disable TLS 1.0/1.1 (enforce TLS 1.2+). The Hardening Guide specifies “Severity-1” (must fix) vs “Severity-2” (should fix) controls with verification CLI commands for each.

Q72. What is VAPI (vSphere Automation API) and how is it used?

VAPI is the current vSphere REST API framework introduced in vSphere 6.5, replacing portions of the older SOAP-based vSphere Web Services SDK. VAPI provides RESTful HTTP/JSON APIs for vCenter management operations: creating/managing VMs, datastores, networks, content library operations, tagging, and more. Available at https://<vcenter>/api (vSphere 8.0) or the API Explorer at /api/content. SDKs available for Python (pyVmomi), Go (govmomi), Java, and .NET. Automation tools (Ansible, Terraform VMware provider, HashiCorp Vault VMware) use VAPI. PowerCLI (VMware’s PowerShell module) uses both VAPI and the older Web Services SDK underneath. For new automation, VAPI/REST is the recommended approach; the SOAP-based vSphere SDK is legacy.

Q73. What is VADP (vStorage APIs for Data Protection) and how do backup solutions use it?

VADP is VMware’s API framework that allows backup vendors (Veeam, Commvault, NetBackup, Rubrik) to create VM backups without deploying agents inside every VM. The backup proxy connects to vCenter, requests a snapshot of the VM (VADP triggers a quiesced snapshot using VMware Tools VSS integration), then reads the VMDK data through changed block tracking (CBT). Changed Block Tracking (CBT) is critical for incremental backups: it tracks which disk blocks changed since the last backup, allowing the backup to read only changed data instead of the full VMDK each backup cycle. VADP supports SAN transport (backup proxy reads directly from the SAN LUN), HotAdd transport (backup VM is on the same host; VMDKs are hot-added directly), and NBD/NBDSSL (network transport). The snapshot is removed after the backup data transfer completes.

Q74. What happened to VMware licensing after Broadcom’s acquisition?

Broadcom completed its acquisition of VMware in November 2023 and restructured the entire product and licensing model. Key changes: Per-CPU perpetual licenses replaced by subscription-only per-core bundles. VMware vSphere Foundation (VVF) and VMware Cloud Foundation (VCF) became the two main bundles. VCF is the primary enterprise offering (includes vSphere, vSAN, NSX, Aria Suite). Perpetual licenses with SnS (support and subscription) renewals were discontinued — all licenses became subscriptions. Thin-provisioned partner programs were revamped under Broadcom’s Advantage Partner Program. Many smaller VMware license resellers lost their partner status. The pricing model shift caused significant customer and partner disruption, accelerating evaluation of alternatives including Nutanix, Microsoft Hyper-V, and open-source KVM-based solutions.

Q75. What is VMware Carbon Black and how does it integrate with vSphere?

VMware Carbon Black (now Broadcom Carbon Black) is a cloud-native endpoint security and EDR (Endpoint Detection and Response) platform acquired by VMware in 2019. Integration with vSphere: the Carbon Black sensor installed in VMs (or Carbon Black App Control agentless via NSX) provides: behavioral endpoint protection (detecting malicious process chains), live query for threat hunting across all VMs, and integration with NSX DFW for automated response (quarantining a compromised VM by changing its NSX security group to an isolated policy). The agentless integration via NSX eliminates the need to install agents in every VM guest, reducing overhead. Carbon Black App Control via NSX uses the Guest Introspection framework (VMware Tools-based) to inspect file operations without an agent in the guest OS.

Q76. What is vSphere Trust Authority (vTA)?

vSphere Trust Authority (introduced in vSphere 7.0) addresses a specific attack surface: the vCenter/ESXi administrator has the power to decrypt VM encryption keys. In sensitive environments, this creates a problem — you can’t trust the same people who manage the infrastructure to also have access to encryption keys. vTA creates a separate “trusted cluster” that acts as the KMS and attestation service for other clusters. ESXi hosts attest their hardware security state (TPM 2.0) to the Trust Authority Cluster. Only attested hosts receive encryption keys. Even a compromised vCenter administrator cannot get encryption keys without also compromising the Trust Authority Cluster, which is a separate administrative boundary. This enables compliance scenarios where the infrastructure team and the security/data-owner team are separate.

Q77. What is VMware Site Recovery Manager (SRM) and how does it automate DR?

SRM is VMware’s DR orchestration solution. It automates the entire failover process from production site to DR site using Recovery Plans — ordered, scripted workflows defining: VM power-on sequence (web tier before app tier before database), IP address remapping (source IP to DR IP), custom scripts (update DNS, disable monitoring alerts), and dependency checks. SRM integrates with: vSphere Replication (VMware’s own replication), SAN-based replication (via SRA — Storage Replication Adapter plugins from storage vendors), and vSAN stretched cluster. DR testing is non-disruptive in SRM: the “Test” operation starts DR VMs on isolated networks and takes a snapshot, verifying the plan works without affecting production. When ready, “Run Recovery” executes the actual failover. SRM tracks RPO compliance and reports on which VMs meet their recovery objectives.

Q78. What is PowerCLI and give a practical example of its use?

PowerCLI is VMware’s PowerShell module for vSphere automation. Install from PowerShell Gallery: Install-Module VMware.PowerCLI. Connect to vCenter: Connect-VIServer vcenter.company.com. Common tasks: Get-VM | Where-Object {$_.PowerState -eq "PoweredOn"} | Select-Object Name, NumCpu, MemoryGB lists all powered-on VMs with their specs. Get-VMHost | Get-VMHostService | Where-Object {$_.Running -and $_.Key -eq "SSH"} | Stop-VMHostService disables SSH on all hosts. Practical scenario: identify all VMs with snapshots older than 7 days: Get-VM | Get-Snapshot | Where-Object {$_.Created -lt (Get-Date).AddDays(-7)}. PowerCLI is the fastest way to make bulk changes across hundreds of VMs.

Q79. What is VMware Aria (formerly vRealize) Suite and its key components?

VMware rebranded the vRealize Suite to VMware Aria. Key products: Aria Operations (formerly vRealize Operations): AI-powered performance monitoring, capacity planning, cost management, and compliance checking for vSphere, NSX, vSAN, and cloud environments. Provides predictive analytics and workload optimization. Aria Automation (formerly vRealize Automation): self-service cloud management platform. Provides a service catalog, infrastructure-as-code (Aria Automation Templates), day-2 operations, and multi-cloud provisioning. Aria Log Insight (formerly vRealize Log Insight): machine learning-based log analytics with structured query and content packs for VMware products. Aria Operations for Networks (formerly vRealize Network Insight): network topology discovery, micro-segmentation planning, NSX rule recommendation, and network flow analytics.

Q80. What is VMware Cloud Foundation (VCF) and what does it bundle?

VCF is Broadcom’s primary enterprise VMware bundle (post-2023 acquisition). It includes: vSphere 8 (ESXi + vCenter), vSAN 8 (hyperconverged storage), NSX (network virtualization and security), Aria Suite Lifecycle (lifecycle management for Aria products), and optionally Aria Operations. VCF can be deployed on-premises or consumed as a managed service. SDDC Manager is the central automation tool for VCF that handles deployment, configuration, lifecycle management, and patching of all VCF components as an integrated stack. VCF Workload Domains allow separating infrastructure into isolated management, VI (Virtual Infrastructure), and specialized workload domains. VCF with Tanzu adds Kubernetes management. The VCF bundle replaces the previous piecemeal vSphere/vSAN/NSX licensing model under Broadcom’s simplified portfolio.

Questions 81–90 — Modern Platforms Cloud, Tanzu & Horizon

☁️

Q81. What is VMware Cloud on AWS (VMC on AWS) and how does it differ from native AWS?

VMware Cloud on AWS runs a VMware SDDC (vSphere + vSAN + NSX) on dedicated AWS bare-metal EC2 instances, managed by VMware as a service. The result is a VMware environment that physically runs inside AWS data centers. VMs run identically to on-premises vSphere — same tools, same management (vCenter), same operational practices. Unlike native AWS (EC2, EKS, RDS), VMC on AWS doesn’t require rearchitecting applications. Migration from on-premises to VMC on AWS uses HCX (Hybrid Cloud Extension) for live vMotion migration without downtime. VMC connects to native AWS services (S3, RDS, Lambda) over AWS’s internal network via ENI (Elastic Network Interface). Use cases: data center extension, migration without re-platforming, disaster recovery, and burst capacity for on-premises workloads.

Q82. What is VMware HCX and what migration types does it support?

HCX (Hybrid Cloud Extension) is VMware’s workload mobility platform for migrations between on-premises vSphere and any vSphere-based cloud (VMC on AWS, Azure VMware Solution, Google Cloud VMware Engine, or another on-premises site). HCX deploys virtual appliances at source and destination that create an encrypted, optimized multi-site fabric. Migration types: Cold Migration: offline VM migration. Live Migration (vMotion): zero-downtime migration of running VMs, even over WAN (Long Distance vMotion). Bulk Migration: replication-based migration with a brief scheduled switchover window (low downtime). Replication Assisted vMotion (RAV): combines replication pre-seeding with a final vMotion, handling large-memory VMs that would otherwise have too-long vMotion stun times. HCX also provides Layer 2 network extension, enabling migrated VMs to keep their IP addresses.

Q83. What is VMware Tanzu and what problem does it solve for Kubernetes?

VMware Tanzu is a portfolio of products for managing Kubernetes clusters on vSphere and across clouds. The core problem: managing many Kubernetes clusters at scale (provisioning, upgrading, security policy, observability, developer self-service) is operationally complex without a consistent management layer. Tanzu addresses this through: Tanzu Kubernetes Grid (TKG): provision and lifecycle-manage Kubernetes clusters on vSphere, AWS, and Azure using the Cluster API. Tanzu Application Platform (TAP): developer experience platform providing a supply chain for container image building, security scanning, and GitOps deployment. Tanzu Mission Control (TMC): centralized management of multiple Kubernetes clusters across environments (on-premises TKG, EKS, AKS, GKE) with unified policy enforcement. vSphere with Tanzu (Workload Management): runs Kubernetes control planes directly on the ESXi hypervisor using Spherelet, enabling VMs and Kubernetes pods on the same vSphere infrastructure.

Q84. What is vSphere with Tanzu Workload Management and the Supervisor Cluster?

When Workload Management is enabled on a vSphere cluster, that cluster becomes a Supervisor Cluster. The Supervisor runs Kubernetes control plane processes directly on the ESXi hosts (using Spherelet, a Kubelet-like agent embedded in vSphere). Kubernetes namespaces map to vSphere Namespaces with resource quotas, RBAC, and storage policies. On the Supervisor, you can run: vSphere Pods (pods that run directly as VMs with each pod in its own VM for stronger isolation — not shared kernel like traditional Kubernetes pods), and Tanzu Kubernetes Clusters (TKC) (guest Kubernetes clusters that provision as VMs within the Supervisor, managed through the Cluster API). NSX or vSphere Distributed Switch with NSX handles pod networking. This architecture allows the same vSphere team to manage both VMs and Kubernetes clusters from familiar vCenter workflows.

Q85. What is VMware Horizon and how does it deliver virtual desktops?

VMware Horizon is the VDI (Virtual Desktop Infrastructure) and application publishing platform. It delivers Windows and Linux desktops and applications from data center or cloud servers to end users on any device. Architecture: Connection Servers handle user authentication (via AD, RADIUS, Smart Card) and broker connections to desktop/app sessions. Unified Access Gateway (UAG) provides secure remote access without VPN for external users. Desktop types: Full Clone (dedicated VM per user, full copy of base image), Instant Clone (forks a running parent VM in milliseconds, creating a fresh desktop from parent’s running memory state — much faster provisioning than linked clones), and RDSH Hosted Apps/Desktops (multiple users share one Windows Server via RDS sessions — applications only, no full desktop). PCoIP and Blast Extreme protocols deliver the remote display.

Q86. What is Instant Clone technology in Horizon VDI?

Instant Clone (Project Fargo technology) creates a new VM by forking from a running parent VM. Instead of copying the entire VMDK (as with traditional clones), Instant Clone creates a child VM that shares the parent’s memory pages (copy-on-write) and a thin disk delta. The parent VM runs continuously in a “frozen” state with the desired desktop configuration. Creating a new Instant Clone desktop takes ~2 seconds vs. minutes for full or linked clones. Each user gets their own Instant Clone at login; when they log out, the clone is destroyed and a new one is created at next login (always-fresh desktop, no persistent user modifications unless using writable volumes or AppVolumes). The parent VM must be powered on at all times. Benefits: extremely fast provisioning, consistent desktop state, no image drift, minimal storage overhead.

Q87. What is VMware AppVolumes and what problem does it address in VDI?

In VDI environments using Instant Clones or non-persistent desktops, users lose any applications they install after login because the VM is reset at logout. AppVolumes solves this by delivering applications as container volumes (AppStacks) that are attached to the user’s VM at login and detached at logout. The application stack is a VMDK containing the application’s installed files, registry entries, and services. When attached to a VM, the AppVolumes Agent uses a filter driver to merge the application files with the OS layers seamlessly. Users see their applications as normally installed. IT manages applications centrally by updating the AppStack VMDK — all users get the update at their next login. This separates application lifecycle from OS image lifecycle, dramatically reducing image management complexity in large VDI deployments.

Q88. What is the difference between PCoIP and Blast Extreme protocols in Horizon?

PCoIP (PC over IP): Teradici’s protocol, licensed by VMware. Uses UDP. Excellent for LAN delivery. Compression is adaptive but can be bandwidth-heavy over WAN. PCoIP offloading hardware (Teradici cards in thin clients) provides hardware-accelerated decoding. Still widely deployed but increasingly superseded by Blast. Blast Extreme: VMware’s H.264/H.265/HEVC-based protocol. Uses either TCP or UDP (adaptive). Far more WAN-friendly — bandwidth consumption is typically 40–60% lower than PCoIP for equivalent quality. Supports HTML5 browser-based access (PCoIP requires a native client). Better performance on high-latency WAN links. Supports USB redirection, multimedia redirection, and real-time audio/video (Teams, Zoom). VMware recommends Blast Extreme for new deployments; PCoIP remains for organizations with existing Teradici endpoint investments.

Q89. What is Horizon Universal License and what changed in the Broadcom era?

VMware Horizon Universal License (pre-Broadcom) was a subscription per named user or concurrent user that covered Horizon on-premises and in cloud deployments (Horizon Cloud on Azure, VMC on AWS). Post-Broadcom, the product has been consolidated under VMware Horizon 8 for on-premises and Horizon Cloud Service for cloud-delivered desktops. Broadcom moved Horizon licensing to its VCF (VMware Cloud Foundation) bundle or as a separate add-on subscription. The per-named-user subscription model remains; perpetual Horizon licenses were discontinued alongside all other perpetual VMware licenses in the post-acquisition restructuring. Customers with existing perpetual Horizon licenses were required to migrate to subscription at renewal, creating a significant total-cost recalculation for large VDI deployments.

Q90. What is Azure VMware Solution (AVS) and Google Cloud VMware Engine (GCVE)?

Both are hyperscaler-hosted VMware services where Microsoft (AVS) and Google (GCVE) purchase, operate, and maintain bare-metal VMware infrastructure in their data centers and sell access as a managed service. Customers receive full VMware SDDC environments (vSphere, vSAN, NSX) validated and supported jointly by Microsoft/Google and Broadcom. The technical architecture is similar to VMC on AWS: dedicated bare-metal servers running ESXi, connected to native cloud services over private connectivity. Key differentiator: AVS and GCVE are first-party services from the cloud provider (Microsoft/Google are responsible for infrastructure operations); VMC on AWS is a VMware-operated service on AWS infrastructure. Migration tools are compatible with HCX. Use cases align with VMC on AWS: data center migration, DC extension, disaster recovery, and regulatory workloads requiring on-premises-equivalent control in public cloud.

Questions 91–100 — Expert Level Advanced & Scenario-Based Questions



Q91. A cluster of 8 hosts experiences intermittent HA failovers that DRS doesn’t prevent. What is the likely cause?

DRS doesn’t prevent HA failovers — HA handles failures; DRS handles balance. The intermittent HA failovers indicate hosts are being declared failed or isolated. Check: (1) Network: is the management network experiencing intermittent packet loss? Even brief management network interruptions can cause HA agents to lose heartbeat contact. Check for NIC driver issues, physical switch errors, or VLAN misconfigurations. (2) Storage: is the shared datastore occasionally losing connectivity (APD)? Even a brief storage timeout on the ESXi management datastore can trigger HA heartbeat loss. (3) Are the hosts showing any hardware alerts (temperature, NIC firmware errors, memory errors) in iDRAC/iLO logs? (4) Check /var/log/fdm.log (VMware HA agent log) on the affected hosts for precise timestamps of heartbeat loss events. (5) Check if the HA isolation detection triggers match network events — correlation confirms the root cause.

Q92. What is vSphere Distributed Power Management (DPM) and what is the risk of enabling it?

DPM monitors cluster resource utilization and powers off ESXi hosts when the cluster is lightly loaded, using WoL (Wake-on-LAN) or IPMI/iLO to wake them back up when load increases. This reduces power consumption during off-peak hours. Risk: DPM powers off hosts, reducing HA failover capacity. If all excess hosts are powered off and a failure occurs, HA may not have enough capacity to restart all VMs. DPM accounts for this by checking HA admission control before powering off a host — it won’t power off a host if doing so would violate HA admission control. Additional risk: the WoL/IPMI reliability is critical. If a host fails to wake when load increases, the cluster may be under-resourced. Test wake behavior thoroughly in your environment before enabling in production. Most production environments don’t enable DPM unless power costs are significant drivers.

Q93. What is vSphere 8.0’s new distributed service (DPU/SmartNIC) support?

vSphere 8.0 introduced Project Monterey’s production feature: DPU (Data Processing Unit) support for SmartNICs (NVIDIA BlueField DPUs, Intel IPUs). A SmartNIC contains its own ARM-based processor, memory, and NIC hardware. vSphere 8 can offload NSX networking and security services (DFW, overlay networking, load balancing) from the ESXi host CPU to the DPU. This provides: (1) CPU offload — networking and security processing moves off the x86 host CPU, freeing it entirely for VM workloads. (2) Infrastructure isolation — networking infrastructure runs on a separate processor, preventing a compromised host CPU from affecting the network processing plane. (3) Better security posture — NSX DFW running on the DPU operates independently of the ESXi software stack. This is particularly valuable for AI/ML workloads where every CPU cycle matters.

Q94. What is the difference between Guest Introspection and Agentless Security in vSphere?

vSphere allows third-party security products (antivirus, EDR) to inspect VM workloads in two ways: Guest Introspection (GI): VMware’s thin-agent API. A lightweight VMware Tools component (thin agent) inside the guest OS intercepts file system and process events and passes them to a Security Virtual Machine (SVM) on the same host via a secure channel. The SVM (from the AV vendor) performs the actual scanning without running the full AV engine inside every VM. Reduces per-VM memory overhead dramatically. Requires VMware Tools and the GI framework. Agentless Security via Network Introspection (NSX): uses NSX network traffic to inspect VM communications without any VM-side agent. Captures traffic via the NSX DFW and redirects copies to a security SVM. Completely agent-free but only inspects network traffic, not file or process events. Full endpoint protection typically requires GI; network threat detection can be fully agentless via NSX.

Q95. A VM that was running fine is now orphaned in vCenter. What does this mean and how do you fix it?

An orphaned VM appears in vCenter inventory with a grey icon, but the VM’s files on the datastore have been moved, deleted, or are no longer where vCenter expects them. Common causes: someone deleted or moved VMDK or VMX files directly on the datastore without using vCenter, the host that was managing the VM was removed from vCenter inventory, or a datastore was re-mounted with different path. Fix: (1) If the files still exist on a datastore, use “Reload from datastore” or browse the datastore, locate the VMX file, and right-click → “Register VM.” (2) If files are missing, check if the datastore has been moved or remounted; browse the new location. (3) If the VM was accidentally deleted from the datastore: check backup system for the most recent backup. (4) Remove the orphaned inventory entry from vCenter to clean up the inventory record once you’ve confirmed the VM files are truly gone or have been re-registered.

Q96. What is vSphere Cluster Quick Start and what does it automate?

Cluster Quick Start (introduced in vSphere 6.7) is a guided workflow in the vSphere Client that walks administrators through configuring a new cluster from scratch. It automates: adding ESXi hosts to the cluster, configuring a distributed switch (vDS) with consistent port groups and uplink policies across all hosts, configuring VMkernel ports for management/vMotion/vSAN, enabling vSphere HA and DRS with recommended settings, and enabling vSAN if applicable. Quick Start generates configuration templates from the first host and applies them to all added hosts consistently. It eliminates the manual, error-prone process of individually configuring each host. For production clusters, Quick Start is the recommended starting point — configurations applied via Quick Start are also validated against common misconfigurations before being applied.

Q97. What is the VMware Compatibility Guide and why is it critical before hardware purchases?

The VMware Compatibility Guide (VCG, at compatibilityguide.vmware.com) lists all hardware — servers, storage, networking, I/O devices — that has been validated and certified to run specific VMware products. Purchasing hardware not on the VCG is a risk: ESXi may lack drivers for the NIC or HBA, storage controllers may not work correctly, and VMware Support may not provide assistance for problems on uncertified hardware. The VCG also shows: supported ESXi versions per hardware, maximum tested memory, supported driver versions (critical — even a certified NIC can cause PSODs if running an unsupported driver version), and known issues. Before any hardware procurement: filter the VCG by the target ESXi version, server model, and all I/O devices (NICs, HBAs, RAID controllers). This single step prevents the most common root cause of unexplained host instability: hardware/driver incompatibility.

Q98. What is vSphere Configuration Maximum and how does it affect cluster design?

VMware publishes Configuration Maximums for each vSphere version (configmax.apps.broadcom.com). These define the tested and supported limits for every scalable parameter. Key maximums for vSphere 8.0: 96 hosts per vSphere HA cluster (increased from 64 in vSphere 7), 8,000 VMs per cluster, 2,048 VMs per host, 768 vCPUs per host, 24 TB RAM per host, 256 virtual disks per VM, 10 simultaneous snapshots per VM (maximum; 2–3 is recommended maximum for production). Exceeding configuration maximums is a support boundary — VMware won’t reproduce or fix issues in configurations beyond these limits. Design clusters that leave comfortable headroom below maximums — a cluster at 95% of the maximum VM count has no room for growth and degrades performance as the vCenter database and HA/DRS computation overhead increases.

Q99. What is VMware vSphere Supervisor Namespace and how does it isolate Kubernetes tenants?

In vSphere with Tanzu, a Supervisor Namespace is a Kubernetes namespace that maps to vSphere resource management policies. Each namespace has: a CPU and memory quota (maximum resources pods/VMs can consume), storage policy (which SPBM policies apply to persistent volumes created in this namespace), network isolation (NSX segment or network policy), and RBAC controls (which Active Directory users/groups can access and what operations they can perform). This maps Kubernetes namespaces to vSphere infrastructure boundaries — a tenant with their own Supervisor Namespace gets isolated compute (quotas), isolated storage (dedicated policy), and isolated networking (NSX microsegmentation). The Supervisor layer enforces these policies at the vSphere infrastructure level, not just at the Kubernetes API level, meaning a compromised Kubernetes control plane within one namespace cannot exceed its vSphere resource quota or access another namespace’s network.

Q100. What is the future of VMware/vSphere post-Broadcom acquisition, and what alternatives are enterprises evaluating?

Post-Broadcom acquisition: Broadcom is focusing development on VCF (VMware Cloud Foundation) as the primary enterprise platform, significantly reducing stand-alone product sales. R&D investment is concentrated on the upper-tier VCF bundle; smaller standalone products receive less development attention. The licensing restructuring increased costs for many customers. Enterprise alternatives being evaluated: Nutanix AHV: hyperconverged infrastructure with its own built-in hypervisor (AHV is included free with Nutanix licenses); strong HCI feature parity with vSphere+vSAN. Microsoft Hyper-V with Azure Arc: for Microsoft-heavy environments; Azure Stack HCI extends Hyper-V with cloud integration. Red Hat OpenShift / KVM: for organizations prioritizing Kubernetes and open-source; KVM is the underlying hypervisor for RHEV (Red Hat Virtualization), though RHEV itself was EOL’d in favor of OpenShift Virtualization. OpenStack: for organizations with significant engineering resources to operate it. Despite the market disruption, vSphere remains the dominant enterprise hypervisor in 2026 by installed base — the switching costs for large vSphere environments are substantial and migration timelines are measured in years.

VMware Quick Reference: Key Numbers & Defaults

Parameter	Value / Default
Max hosts per vSphere HA cluster (v8.0)	96 hosts
Max VMs per cluster (v8.0)	8,000 VMs
Max vCPUs per VM (v8.0)	768 vCPUs
Max memory per VM	24 TB RAM
vSphere HA host isolation detection time	~15 seconds (12s heartbeat + ping confirmation)
CPU Ready alert threshold	5% concern; 10% significant contention
Storage latency alert threshold (DAVG)	5ms concern; 20ms critical
vSAN minimum nodes (FTT=1, RAID-1)	3 hosts
vSAN stretched cluster max RTT (inter-site)	≤5ms (optimal); ≤10ms (maximum supported)
VMFS-6 maximum VMDK size	62 TB per VMDK
FT (Fault Tolerance) max vCPUs per VM	8 vCPUs (vSphere 8)
Kerberos authentication clock skew tolerance	5 minutes maximum
vCenter VCSA HA failover time	3–5 minutes
vSphere Replication minimum RPO	5 minutes

Tags: VMware Interview Questions vSphere FAQ VMware ESXi Questions VMware vCenter VMware NSX VMware vSAN VMware Tanzu VCP Exam Questions