The city innovation loft runs both KVM and ESXi and wants one network-virtualization platform. Which product supports that mixed-hypervisor use case?
Select an answer to reveal the explanation.
Short Explanation
One overlay for both the KVM lab and the ESXi cluster is an NSX-T job. NSX-V was the vSphere-only older product. A standard vSwitch and Horizon do not become a multi-hypervisor NV platform.
Full Explanation
A city innovation loft that runs both KVM and ESXi needs one network-virtualization platform designed for multiple hypervisors. NSX-T Data Center supports ESXi and KVM transport nodes on a shared fabric, which matches that mixed-hypervisor civic use case. NSX-V was vSphere-centric and is not the multi-hypervisor overlay design candidates should select for new labs. A vSphere Standard Switch provides ESXi-local Layer 2 switching and is not a mixed-hypervisor overlay fabric. Horizon Connection Server brokers desktops; it is not a network-virtualization platform for KVM and ESXi. Exam caveat: when a stem stresses mixed hypervisors, identify NSX-T; selecting NSX-V for nostalgia fails the objective. Operational check: prepare both KVM and ESXi hosts as transport nodes in the same overlay transport zone, attach a test segment, and verify Geneve connectivity between a KVM guest and an ESXi guest before promoting the loft to production agencies. In municipal operations, record the chosen control and the rejected distractors in the change ticket so future on-call staff understand which failure modes would affect city services. Re-validate after the next maintenance window that the same design still holds for the current NSX build and the agency workloads that depend on it.