What you’ll find here

Practical answers about the new Extensions (XaaS) Framework, CKS/Kubernetes & CSI, GPU, Netris SDN, and more.

 

CloudStack XaaS Extension Framework

Q: What is the CloudStack XaaS Extension Framework and why was it introduced?

A: The CloudStack XaaS Extension Framework allows operators and developers to integrate CloudStack with external systems such as orchestrators and deployment tools. It was introduced to make CloudStack more flexible and extensible without modifying its core codebase. Starting with the 4.21 release, the framework supports Orchestrator-type extensions. In the future, it can be extended to additional types such as Networker, Authenticator, or Storage integrations.

Q: What types of extensions can be created with CloudStack XaaS?

A: As of the 4.21 release, CloudStack supports Orchestrator extensions, which handle provisioning and lifecycle management of VM Instances on external platforms. The framework is designed to be extended to additional types in the future, such as Networker (network provisioning, firewall, SDN), Authenticator (external authentication/identity providers), and Storage (external storage provisioning and lifecycle).

Q: In which programming languages can I write an extension?

A: Any language or script that can read and write JSON and run as an executable—e.g., Bash, Python, Go, Java. CloudStack invokes your executable with an action and a JSON payload path; your program returns a JSON result on stdout and uses the exit code to signal success or failure.

Q: How does CloudStack interact with an extension during VM deployment or lifecycle operations?

A: On each lifecycle (or custom) action, CloudStack runs the registered extension executable as <path> <action> <payload_path> <timeout>. The payload is a JSON file with resource context and parameters. The extension performs the operation on the external platform and writes a JSON result to stdout; CloudStack reads that result to update state/events, and treats timeouts, non-zero exits, or invalid JSON as failures.

Q: What is the expected input and output format for extensions?

A: Input is a JSON payload file describing the action, resource context, and parameters (CloudStack passes the file path to your executable). Output is a JSON object written to stdout with status (success/error), result/IDs, and optional metadata/messages; a non-zero exit code or invalid JSON is treated as failure.

Q: Where should the extension executable be placed, and what permissions are required?

A: Install the executable on every Management Server at the same absolute path, owned by cloud:cloud and executable (e.g., chmod 750). Ensure the parent directory is readable/executable by the cloud user.

Q: Are there any inbuilt extensions shipped with CloudStack?

A: Yes—CloudStack ships two sample Extensions: Proxmox (Bash) and Hyper-V (Python), which serve as reference implementations for custom development.

Q: How are extension actions triggered, and what command-line arguments are passed by CloudStack?

A: CloudStack invokes the registered executable as

<extension_path> <action> <payload_path> <timeout>

For example:

/usr/share/cloudstack-management/extensions/demo/demo.sh deploy /var/lib/cloudstack/management/extensions/demo/payload-1234.json 1800

Where action is the lifecycle/custom action name, payload_path is a JSON file with context/parameters, and timeout is in seconds.

Q: What happens if an extension fails to respond or returns an error?

A: CloudStack marks the action failed if the extension times out, exits non-zero, or returns invalid JSON. The error is logged and surfaced in the UI/events. Implement clear exit codes and a JSON error object to aid diagnostics.

Q: Can I run multiple extensions in the same CloudStack environment, and how are they managed/configured?

A: Yes—multiple extensions can coexist. You assign one extension per type to a given scope/resource (e.g., an Orchestrator per Cluster). Registration and assignment are done via the CloudStack UI/APIs, so you can choose which extension handles each workload.

Q: What are “Custom Actions” and how do I define them?

A: For the Orchestrator resource type, Custom Actions are admin-defined operations your extension exposes beyond standard VM lifecycle (e.g., backupNow, restore). Define them in the UI or via the addCustomAction API, specifying Allowed roles (Admin, Resource Admin, Domain Admin, User), name, parameters, timeout, and success/error messages. Your executable must implement a handler for that action and read the JSON payload passed by CloudStack.

Q: How do I run a Custom Action and what does the extension receive?

A: Invoke it from the Run Action UI or via the runCustomAction API for the matching resource type (e.g., Orchestrator). CloudStack executes your extension as <path> <action> <payload> <timeout>, where payload is a JSON file containing resource context and user-supplied parameters. Your executable must return a JSON result on stdout; CloudStack then displays your configured success/error message.

Q: How does usage and quota accounting work with extensions?

A: With Orchestrator extensions, CloudStack still generates usage events (e.g., VM run-hours) and enforces account/domain limits based on the selected service offerings (instances/vCPU/RAM). Storage is not accounted for these workloads in 4.21—extensions don’t expose per-disk sizes or pool capacity—so storage usage/quota and host/cluster/pool capacity visibility remain external.

Q: Are usage events still generated when using extensions?

A: Yes—CloudStack continues to emit the standard VM lifecycle usage events (e.g., VM.CREATE/START/STOP/DESTROY) even when operations are handled by an Orchestrator extension, so billing/reporting integrations remain consistent. Custom Actions return results and can be audited via logs/events as configured.

Q: How can I debug or troubleshoot an extension?

A: Enable DEBUG on the Management Server to capture extension calls; have your executable log to stderr/a file and use clear exit codes/JSON; reproduce locally by running /<path> <action> <payload> <timeout>, validate outputs with jq, and check CloudStack events/logs for failures/timeouts (raise the timeout if needed).

Q: What is the performance impact of using extensions?

A: There’s a small overhead to spawn the executable and exchange JSON, but end-to-end latency is primarily determined by the external platform your extension talks to. Keep payloads lean, reuse connections (avoid heavy startup), and offload slow tasks via async/queues or caching; set sensible timeout values, use retries/backoff, and make actions idempotent to scale reliably.

Q: What skills should we look for when hiring a developer to build an orchestrator extension?

A: Python or Go (Bash acceptable), strong REST/JSON and Linux CLI, familiarity with CloudStack concepts/APIs/events, target-platform APIs (e.g., Proxmox/PBS or PowerShell/WinRM for Hyper-V), secure secrets handling, idempotent/retry-safe workflow design, state reconciliation (ID mapping), structured logging/observability, and the ops know-how to package/deploy the executable on all Management Servers with correct permissions.

Q: For Proxmox, is this using an API or does it require an agent?

A: Typically API/CLI only. An agent is optional if your design prefers it; CloudStack doesn’t require one.

Q: Can I use the new XaaS framework to orchestrate lightweight hypervisors like Firecracker?

A: Yes—implement a custom Orchestrator extension that maps CloudStack actions to Firecracker lifecycle.

Q: Is it possible to deploy SystemVMs (e.g., Virtual Router) on an external hypervisor via XaaS?

A: Not in 4.21. SystemVMs run on CloudStack-managed native hypervisor hosts; XaaS focuses on external Instance lifecycle and custom actions.

Q: Can you support Proxmox API & Proxmox Backup Server (PBS) API as you support vCenter (controller-level)? If planned, when?

A: In 4.21 the Extensions are Orchestrator-type only—there’s no separate Backup extension. You can manage PBS by adding Custom Actions in your Proxmox Orchestrator extension that call PBS APIs (backup/restore/retention) while PBS remains configured on Proxmox. A dedicated backup-type extension/provider is under consideration with no public ETA.

 

GPU Integration with KVM

Q: Which hypervisors are supported for GPU in 4.21?

A: KVM only in 4.21. Xen/others aren’t covered by this release.

Q: Does 4.21 support both passthrough and vGPU?

A: Yes. 4.21 supports passthrough and vGPU assignment models on supported KVM Hosts.

Q: Are GPU utilization metrics shown in the CloudStack UI?

A: Allocation/scheduling are tracked; deep real-time utilization is limited in the UI. Use vendor/observability tooling for detailed telemetry.

 

Netris SDN Integration

Q: Which hypervisors does the Netris integration target in 4.21?

A: Validated for Advanced KVM Zones; broader hypervisor coverage is outside 4.21’s scope.

Q: What network constructs can CloudStack orchestrate when using Netris?

A: VPC tiers, ACLs, SNAT/DNAT, Port Forwarding, Load Balancing, and VPN via standard CloudStack flows; Netris programs the fabric.

Q: Do I need to configure physical switches manually?

A: No. Netris handles fabric configuration; CloudStack drives intent via the Netris provider.

 

CKS Enhancements

Q: Can I choose different compute offerings per node type (master/worker/etcd)?

A: Yes. 4.21 allows per-node-type offerings at cluster creation.

Q: Can I select a custom CNI plugin (e.g., Calico/Cilium)?

A: Yes. You can choose the CNI and pass plugin-specific settings via structured userdata.

 

Create Instance from Backup

Q: Can I restore if the original Instance was deleted?

A: Yes. 4.21 lets you create a new Instance directly from a backup, with adjustable compute/network parameters.

 

Instance Lease

Q: What does Instance Lease do in 4.21?

A: It enforces a time-bound lifecycle: on expiry, CloudStack stops or deletes the Instance per policy, with grace/polling controls.

 

Deploy Instance Form Improvements

Q: What changed in the Deploy Instance form?

A: Architecture-aware image mapping, OS-category grouping (icons/labels), improved filtering, and consistency with Reinstall flow.

 

For end-to-end guidance on the CloudStack 4.21 new Features see the official Apache CloudStack Documentation: Usage Guide — Apache CloudStack 4.21.0.0 documentation