UCS Hypervisor Integration. This is the mechanism that lets Cisco UCS talk directly to VMware ESXi or Microsoft Hyper-V so that when you create a virtual server in the hypervisor, the required physical server resources in UCS are automatically prepared and configured. For the 350-601 exam, this topic matters because automation and orchestration serve as core requirements in modern data centres, and Cisco tests whether you understand how UCS removes manual steps between physical and virtual layers.
Jump to a section
A simple way to picture UCS Hypervisor Integration
400 hotel rooms need to be assigned to 400 guests checking in on the same day. Without integration, the front desk clerk has to manually walk each guest to their room, unlock the door with a master key, and replace the lock cylinder after checkout. That is 400 separate, slow, error-prone physical tasks.
Now imagine a system where the guest's credit card swipe at check-in generates a unique electronic key code that works only for their assigned room and only for their booked nights. The same system automatically tells the heating to turn on in that room, charges the minibar to the correct folio, and updates the housekeeping schedule. That is hypervisor integration. The hotel's Property Management System is the hypervisor – the master software that manages all the rooms. The credit card terminal is the UCS Manager – the tool that talks to the hotel system. The guest is the virtual machine (VM) that needs a room (compute resource). Before integration, every room assignment required a human walking and turning a physical key. After integration, the front desk (UCS Manager) and the hotel system (hypervisor) speak a common language so that when a guest is created, a room (VM) is automatically provisioned, configured, and locked down. No one walks a hallway. No one replaces a lock. The process becomes instant and scalable.
A data centre is a building full of physical servers, each running multiple virtual machines (VMs). A hypervisor, like VMware ESXi or Microsoft Hyper-V, is the software layer that sits on a physical server and carves its CPU, RAM, and storage into virtual chunks that VMs use. Think of the hypervisor as the operating system for virtual machines – it manages all the VMs on one piece of hardware.
Before hypervisor integration, deploying a new VM involved many manual steps. You would first log into the UCS Manager web interface, find an available server blade (a modular server that fits into a larger chassis), assign network and storage settings via Service Profiles (a UCS document that defines a server's identity), and then install the hypervisor on that server. Only after that could you create a VM inside the hypervisor. This process took hours or days and was prone to human error – a typo in a network address could bring down an entire application.
UCS Hypervisor Integration automates this handshake. The key components are:
UCS Manager (UCSM): The central management software for all UCS hardware. It holds templates called Service Profiles that define every characteristic of a server – how much memory, which network VLAN (Virtual Local Area Network) it belongs to, which storage WWPN (World Wide Port Name) it uses.
Hypervisor: VMware ESXi or Microsoft Hyper-V installed on the UCS server blades. The hypervisor is itself a lightweight operating system whose only job is to run VMs.
UCS Manager Plugin: A software add-on installed inside the hypervisor's management tool. For VMware, this plugin installs into vCenter Server (the tool that manages all ESXi hosts). For Hyper-V, the plugin integrates with System Center Virtual Machine Manager (SCVMM).
Single Sign-On (SSO): The plugin authenticates to UCSM using credentials stored in the hypervisor tool, so you do not log into two separate consoles.
When you use the integrated workflow, the process looks like this: From within vCenter, you right-click a host or cluster and choose 'Cisco UCS – Provision Server'. The plugin speaks to UCSM and says, "I need a new physical server with these specs." UCSM finds an available server blade, applies the correct Service Profile, assigns the proper network and storage identities, and powers on the server. The hypervisor on that blade then boots, connects to vCenter, and makes itself ready to host VMs. All that happens without you ever opening the UCSM interface.
The integration also enables hardware visibility in the hypervisor console. While normally vCenter sees only generic host hardware details, the plugin enriches this view with UCS-specific data – chassis serial number, fabric interconnect (the UCS network switch) port, firmware version. This makes troubleshooting easier. If a blade fails, you can see which physical component caused the issue directly in vCenter.
The most common configuration requires UCSM to have a user account with specific RBAC (Role-Based Access Control) permissions. The plugin user needs privileges like 'admin' or a custom role that includes the ability to create and apply Service Profiles, power on servers, and query inventory. The hypervisor tool also needs network connectivity to UCSM – typically on a management VLAN that is separate from production data traffic.
Why does this exist? Because data centres scale. When you manage 1,000 servers, performing manual steps for each one becomes impossible. Integration cuts deployment time from 45 minutes per server to under 5 minutes. It also enforces consistency: because Service Profiles are templates, no one forgets to assign a VLAN or storage path. Every server deployed through the integration is identical, reducing configuration drift (when servers in the same role have slightly different settings due to manual changes) and making troubleshooting predictable.
UCS Hypervisor Integration replaces the old break-fix model where server provisioning and VM provisioning were separate silos, each requiring different expertise. It unifies the two workflows under one pane of glass, typically vCenter, which is the tool most server administrators already use every day.
Install the UCS Manager Plugin
In vCenter Server, navigate to the Plug-in Manager and register the Cisco UCS Manager plugin. This is a one-time installation that adds a menu option like 'Cisco UCS' to vCenter. The plugin contains the code that translates vCenter actions into UCSM API calls over HTTPS.
Create a UCSM User Account for the Plugin
In UCSM, create a local user (or use an existing LDAP account) with RBAC privileges: 'server-control', 'service-profile-control', and 'inventory-read'. This user is the identity the plugin uses to authenticate with UCSM. The credential is stored in the plugin configuration in vCenter.
Configure the Plugin with UCSM Details
In vCenter, under the Cisco UCS plugin settings, enter the UCS Manager IP address (or FQDN) and the credentials created in step 2. The plugin tests the HTTPS connection. If successful, it retrieves the list of available Service Profile Templates and server blades from UCSM.
Define a Service Profile Template in UCSM
Before the plugin can provision a server, a Service Profile Template must exist in UCSM. This template includes the boot policy (e.g., boot from SAN), network policy (VLAN membership), and BIOS settings. The template must use WWPN and MAC address pools so the plugin can assign unique values to each new server.
Provision a Host from vCenter
In vCenter, right-click a cluster or datacentre and choose 'Cisco UCS – Add Host' (or similar menu option depending on plugin version). Select the Service Profile Template from a dropdown. The plugin sends a SOAP request to UCSM, which discovers an available blade, applies the template as a concrete Service Profile, assigns unique WWPNs/MACs from pools, and powers on the blade. The blade boots the hypervisor and registers with vCenter automatically.
Verify the Provisioned Host in Both Consoles
In vCenter, the new host appears as a fully managed ESXi server. Under the Hardware Status tab, UCS-specific details (chassis, slot, firmware, power supply status) are visible. In UCSM, the corresponding Service Profile appears with a state of 'Associated' and the blade shows 'Operable Status: Ok'. This verifies that the integration synchronised correctly.
A large financial services company hosts its trading platform on Cisco UCS B-Series blade servers running VMware ESXi. The platform includes 50 virtual servers – 10 for the front-end trading web interface, 20 for the back-end transaction processing engine, and 20 for the database cluster. The infrastructure team manages these VMs through VMware vCenter.
One afternoon, the database team reports that their 20 database VMs are running at 95% memory utilisation across the current hosts. They need to add four new database VMs to handle increased trade volume, but the existing two ESXi hosts are tapped out – they have no spare RAM or CPU. The team needs to bring a new UCS blade online.
The IT professional follows this step-by-step process using UCS Hypervisor Integration:
Step 1: Open VMware vCenter and navigate to the datacentre inventory. Right-click the cluster where the database VMs live and select 'Cisco UCS – Add Host' (a custom menu option provided by the UCS plugin).
Step 2: In the dialog that appears, select a UCS Service Profile Template named 'ESXi_Database_Blueprint'. This template includes BIOS settings tuned for database workloads (higher memory clock speed, NUMA (Non-Uniform Memory Access) alignment disabled), two 40Gb uplinks mapped to the storage VLAN, and a boot-from-SAN (Storage Area Network) policy that directs the server to boot ESXi from a centralised storage array.
Step 3: The plugin calls UCSM, which discovers an available B-Series blade in chassis 3, slot 7. UCSM applies the Service Profile, assigning the blade a unique WWPN, MAC address (Media Access Control address – a unique hardware identifier for network interfaces), and management IP. Power is applied to the blade.
Step 4: Within two minutes, the blade boots ESXi from the SAN. The new host automatically registers with vCenter thanks to a pre-configured DRS (Distributed Resource Scheduler) rule. vCenter sees the new host as 'esxi-db-05.domain.com'.
Step 5: The administrator v-motions (live-migrates) one existing database VM to the new host. The host shows green status in vCenter, with the UCS chassis and slot information visible in the Hardware Status tab thanks to the plugin.
The entire process took less than five minutes. Without integration, the administrator would have needed to log into UCSM separately, manually find an available blade, create a Service Profile from scratch, configure networking and storage adapters, power on the server, wait for ESXi to install, and then manually add the host to vCenter – a 40-minute job. The integration also prevents errors that occur when copying MAC addresses or WWPNs manually – a typo here can take down the entire cluster because duplicate addresses cause network storms.
The IT professional also troubleshot a non-booting blade using the integrated view. In vCenter, the host showed a red 'Disconnected' state. The administrator clicked the UCS tab and saw 'Storage Adapter Fault: No boot LUN (Logical Unit Number) presented.' The storage administrator had forgotten to provision a new LUN for the blade. The administrator opened a ticket with the storage team directly from the vCenter interface, avoiding a separate login to the storage management console.
The 350-601 exam tests UCS Hypervisor Integration heavily in the 'Automation and Orchestration' domain (Objective 2.3). Expect a mix of multiple-choice single-answer, multiple-select, and scenario-based drag-and-drop questions. The exam writers love testing the difference between integration pre-requisites and post-deployment tasks.
Concepts the exam targets most frequently:
The requirement for RBAC (Role-Based Access Control) on UCSM for the integration plugin user. The exact permissions needed: the plugin user must have 'admin' privileges OR a custom role that includes 'server-control' (the ability to power cycle servers), 'service-profile-control' (create and apply profiles), and 'inventory-read' (discover blades). A common trap question gives a user 'read-only' permissions and asks whether integration will work – the answer is no.
Network connectivity between vCenter and UCSM. The exam often asks which protocol the plugin uses for communication: HTTPS (port 443) with SOAP (Simple Object Access Protocol) XML messages. A distractor might list SNMP (Simple Network Management Protocol) or SSH (Secure Shell) – those are wrong. The plugin initiates outbound HTTPS connections from vCenter to UCSM.
The correct plugin installation order. For VMware: install the UCS Manager plugin into vCenter Server, then configure a user account in UCSM for the plugin, then in vCenter's plugin menu enter the UCSM IP and credentials. For Hyper-V: the plugin installs into SCVMM (System Center Virtual Machine Manager). The exam might present a scenario where someone installs the plugin on the ESXi host itself – that is incorrect. It lives at the vCenter level.
Service Profile Templates versus Service Profiles. The integration deploys servers from templates, not from individual profiles designed for one specific server already in use. Questions often ask, "Which UCS object must exist before the plugin can provision a host?" The answer: a Service Profile Template. If they say Service Profile (without Template), that is the trap – you cannot clone a concrete profile for a new host without breaking the original one.
'Policy Resolution' in UCSM. When the plugin provisions a server, UCSM automatically resolves policies (like BIOS, Boot, Network) from the template. The exam may ask what happens if a referenced policy is deleted. Expected answer: the provisioning action fails with a 'Policy Not Found' error. The system does not default to a generic policy.
The difference between the two supported hypervisors. VMware integration is deeper: it supports hardware monitoring (temperature, power supply status) in vCenter. Hyper-V integration via SCVMM provides basic provisioning but not the same depth of health monitoring. The exam may ask which hypervisor offers 'sensor telemetry' visible in the management tool.
Trap patterns:
A question describes a scenario where the integration cannot discover UCS blades. The answer is rarely a hardware fault; it is most commonly that the plugin user account in UCSM has insufficient RBAC permissions.
A scenario where two UCS domains (separate management instances) exist. The plugin binds to exactly one UCS Manager instance. The distractor will suggest configuring the plugin with a cluster IP – but UCS Manager is already an active-standby pair, so the management IP is the cluster address.
Questions that ask what happens when the Service Profile Template uses 'Unique' WWPNs versus 'Pool'-assigned ones. For integration to work, WWPNs must come from a pool, not be manually typed into the template. The plugin cannot assign random static values; it must draw from a defined pool.
Memorise these exact definitions for the exam:
UCS Hypervisor Integration: The automated provisioning of UCS physical servers from within a hypervisor management tool using a plugin.
Service Profile Template: A reusable blueprint that defines server identity, networking, storage, and firmware for a class of servers – used by the integration to provision new blades.
RBAC: Restricts the plugin to only the operations needed to discover and provision servers.
Plugin: A software extension installed in vCenter or SCVMM that communicates with UCSM over HTTPS.
UCS Hypervisor Integration automates physical server provisioning from within vCenter or SCVMM using a UCS Manager plugin, eliminating manual UCSM login steps.
The plugin requires an RBAC user account in UCSM with at least 'server-control', 'service-profile-control', and 'inventory-read' privileges.
The integration uses Service Profile Templates, not concrete Service Profiles, as the blueprint for new server deployments.
Network communication between the plugin and UCSM occurs over HTTPS (port 443) using SOAP XML messages.
For VMware integration, the plugin installs in vCenter Server, not on individual ESXi hosts.
The plugin provides hardware health monitoring for UCS blades directly in the vCenter Hardware Status tab for VMware environments.
A Service Profile Template used by integration must reference WWPN and MAC address pools rather than static values to support automated provisioning.
UCS Hypervisor Integration works for both VMware ESXi (vCenter) and Microsoft Hyper-V (SCVMM), but VMware offers deeper hardware monitoring.
The integration reduces server deployment time from approximately 45 minutes to under 5 minutes and eliminates configuration drift by enforcing template-based consistency.
These come up on the exam all the time. Here's how to tell them apart.
UCS Hypervisor Integration
Automated from within vCenter or SCVMM using a plugin.
Deploys a server in under 5 minutes without leaving the hypervisor console.
Uses Service Profile Templates for consistency; no risk of misconfiguration.
Manual UCS Provisioning
Requires logging into two separate consoles (UCSM and vCenter).
Takes 30–45 minutes for a skilled administrator to complete.
Prone to typos in WWPNs, MAC addresses, and VLAN assignments.
Service Profile Template
A reusable blueprint not tied to a specific blade.
Used by the integration plugin to provision new servers.
Must reference WWPN/MAC pools for automated deployment.
Service Profile (Concrete)
Associated with one specific blade at a time.
Cannot be applied to a second blade without first disassociating it.
Typically created by cloning a template during manual provisioning.
VMware vCenter Integration
Plugin provides hardware monitoring (temperature, voltage) in vCenter.
Supports DRS and vMotion visibility for UCS blades.
Plugin must be registered via vSphere Web Client plug-in manager.
Microsoft SCVMM Integration
Basic provisioning only; no in-depth hardware health telemetry.
Does not integrate with SCVMM's live migration features.
Configured through SCVMM console extensions.
Plugin (vCenter/SCVMM)
Operates at the hypervisor management layer (vCenter).
Provides a limited set of actions: provision, deprovision, view hardware status.
Uses HTTPS SOAP API to communicate with UCSM.
UCS Manager Native Interface
Full UCSM web GUI or CLI with all configuration capabilities.
Any UCSM configuration action is possible, including firmware upgrades, policy creation, and QoS settings.
Native UCSM protocols (XML API, CLI over SSH).
Mistake
UCS Hypervisor Integration means the hypervisor runs inside UCS Manager.
Correct
The hypervisor runs on the UCS server blades, and UCS Manager manages the physical hardware. The integration creates a communication channel between two separate management systems so that provisioning actions in one automatically trigger actions in the other.
The word 'integration' implies merging, so beginners assume one system swallows the other. In reality, they remain distinct but synchronised.
Mistake
Once the integration is configured, any user in vCenter can automatically provision UCS servers without limits.
Correct
The integration uses a specific UCSM user account with RBAC permissions. Only users who have both vCenter access and knowledge of the UCSM credentials used by the plugin (stored in the plugin settings) can trigger provisioning. vCenter users without those credentials cannot launch the integration workflow.
People assume integration removes all security controls, when in reality it adds a cross-system authentication step that inherits RBAC from both systems.
Mistake
The integration replaces the need for Service Profiles entirely.
Correct
The integration uses Service Profile Templates to provision servers. A concrete Service Profile is still applied to each blade – the integration automates the application of a template to create that profile. Without templates, the integration has no instructions for how to configure the server.
Because the process is automated, beginners think the concept of a Service Profile disappears. It does not; it just becomes invisible to the user triggering the action from vCenter.
Mistake
UCS Hypervisor Integration only works with VMware ESXi, not Hyper-V.
Correct
Cisco UCS Manager supports integration with both VMware ESXi (via vCenter plugin) and Microsoft Hyper-V (via SCVMM plugin). Both are valid and tested on the 350-601 exam.
VMware dominates the data centre market, and many training materials focus exclusively on it. Hyper-V integration is equally supported but less frequently discussed in study guides.
Mistake
The integration plugin must be installed on every individual ESXi host.
Correct
The plugin installs at the vCenter Server level (or SCVMM level), not on each hypervisor host. The plugin communicates with UCSM on behalf of all hosts under that vCenter. Installing on each host would defeat the centralised management purpose.
Beginners confuse 'hypervisor integration' with 'agent on each host'. They assume a component must be running locally, like antivirus software, when really it is a central management plugin.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. UCS Hypervisor Integration uses the existing UCSM license. The plugin is a free add-on from Cisco. However, the hypervisor (ESXi or Hyper-V) requires its own license, which is independent of UCS.
Yes, but the plugin binds to one UCSM instance per vCenter. To manage two UCS domains (e.g., two separate fabrics), you install the plugin configuration pointing to one UCSM and then provision servers from that domain. For the second domain, you need a separate plugin configuration (or a third-party orchestration tool).
The integration stops working. vCenter cannot authenticate to UCSM, and provisioning actions fail with an authentication error. The password must be updated in the plugin settings in vCenter as well as in UCSM.
Not directly from the integration workflow. The plugin focuses on provisioning and de-provisioning (power on/off) of blades. Power management features like Dynamic Power Savings must be configured directly in UCSM policies, not through vCenter.
No. For integration provisioning to work, the Service Profile Template must use WWPN and MAC address pools. Static values would cause the plugin to assign the same identity to multiple servers, creating network conflicts.
No. The Hyper-V integration requires System Center Virtual Machine Manager (SCVMM) to be installed. The free standalone Hyper-V Server does not include SCVMM, which is a separate product with a license cost.
You've finished UCS Hypervisor Integration. Continue through the 350-601 study guide to build a complete picture of the exam.
Done with this chapter?