Overview
Xloud Compute follows a distributed, service-oriented architecture. API requests enter through a central API tier, are routed through the Scheduler and Placement services to select the optimal host, and are executed by Compute Agents running on every hypervisor node. Each agent communicates directly with the local hypervisor to manage instance lifecycle operations — creation, power state, migration, and console access.Service Topology
The diagram below illustrates how requests flow from the end user through the Xloud Compute control plane to the hypervisor layer.Service Components
| Component | Port | Runs On | Description |
|---|---|---|---|
| Compute API | 8774 | Controller nodes | REST API endpoint for all instance lifecycle operations |
| Placement API | 8778 | Controller nodes | Tracks resource inventory and allocation across all compute hosts |
| Scheduler | Internal | Controller nodes | Selects the optimal compute node for each new instance request |
| Conductor | Internal | Controller nodes | Orchestrates multi-step operations; acts as a database proxy for compute agents |
| Compute Agent | Internal | Every hypervisor node | Manages instance lifecycle on the local hypervisor |
| Console Proxy | 6080 | Controller nodes | VNC console proxy for browser-based instance access |
The Conductor service decouples compute agents from direct database access. All database
writes from hypervisor nodes flow through the Conductor, which enforces access control
and serializes state transitions.
Service Lifecycle
The following table describes the expected runtime state of each service on a healthy cluster.| Service | Expected State | Managed By |
|---|---|---|
nova-api | Running, listening on :8774 | XDeploy / XAVS |
placement-api | Running, listening on :8778 | XDeploy / XAVS |
nova-scheduler | Running | XDeploy / XAVS |
nova-conductor | Running | XDeploy / XAVS |
nova-compute | Running on every hypervisor node | XDeploy / XAVS |
nova-novncproxy | Running, listening on :6080 | XDeploy / XAVS |
- CLI
- XDeploy
Verify that all Compute services are in an Expected output shows all services with
up state:List all compute services
State: up and Status: enabled.Filter for degraded services
All services report
State: up. Any service showing down requires investigation on the host where it runs.Request Flow: Instance Creation
Understanding the creation flow helps diagnose failures at each stage.API receives the request
The Compute API validates the request, checks quota, and creates an instance record
in the database with status
BUILD.Placement selects resources
The Placement API queries resource inventories to find hosts with sufficient vCPU,
RAM, and disk. It returns a list of allocation candidates.
Scheduler filters and ranks
The Scheduler applies the configured filter chain to eliminate ineligible hosts,
then ranks remaining candidates using weighers. The top-ranked host is selected.
Conductor orchestrates the build
The Conductor sends a
build_instance RPC call to the Compute Agent on the selected
host. It monitors progress and updates the database with state transitions.Next Steps
Compute Hosts
Manage hypervisor nodes — list, inspect, enable, and disable hosts.
Scheduling
Configure filters, weighers, host aggregates, and availability zones.
Admin Guide
Return to the Compute Administration Guide index.