Commvault Integration with PCD
Configure Commvault to back up and restore VMs running on Private Cloud Director (PCD).
Commvault protects virtual machines running in Private Cloud Director (PCD). This guide walks through the Commvault setup for PCD. VM protection is agentless. It does not require agents inside the guest. Commvault integrates with PCD through OpenStack APIs.
What you deploy
Commvault components you deploy (see OpenStack system requirements):
CommServe: Central management and metadata server.
MediaAgent / Access Node: VM(s) per PCD region for data movement and restores.
Disk library: Backup storage. This is typically local disks on MediaAgent VMs.
Terminology used in this guide
Access Node: A MediaAgent VM used as the Virtual Server Agent (VSA) proxy for backup/restore.
Restore proxy: The Access Node selected for restore operations.
Key constraints
Only VMs that boot from persistent (bootable) volumes are supported. VMs that boot from ephemeral disks (created directly from images) are not protected.
Snapshot quota and snapshot concurrency must match your backup schedule.
Restores require an OS-matching Access Node (Windows ↔ Windows, Linux ↔ Linux).
Restoring to a network with port security disabled is not supported.
Layer 2 Networks (introduced in Private Cloud Director 2026.1) are not supported.
Architecture overview
Core components
CommServe
Central management and metadata server.
No backup data stored here.
Media Agents (MA) / Access Nodes (VMs)
Deployed as VMs per PCD region.
Responsible for:
Data movement (backup and restore)
Hosting local disk backup storage
Acting as restore proxies
OS separation (important for restores)
Backup: Either Windows or Linux MediaAgent can move data.
Restore: The VSA proxy mounts VM disks to browse or restore files. This requires an OS-matching MediaAgent.
Windows VM restore → Windows MediaAgent
Linux VM restore → Linux MediaAgent
Prerequisites
Commvault
A supported OS for CommServe (Windows or Linux).
Commvault packages for OpenStack / Virtual Server Agent (VSA) on the Access Nodes.
Commvault system requirements: https://documentation.commvault.com/v11/software/system_and_hardware_requirements_for_commvault.html
Private Cloud Director / OpenStack
Keystone endpoint reachable over HTTPS/443 from CommServe and Access Nodes.
Credentials with enough scope to discover and snapshot the VMs you plan to protect.
Use system-scoped admin if you need cross-project discovery.
Use project-scoped permissions if you only protect one project.
Network and storage
Access Nodes must be able to reach:
Private Cloud Director endpoints (Keystone/Nova/Cinder/Glance) over HTTPS/443. You may need provider networks to host Access Nodes.
The disk library (local disk or object storage, if used)
CommServe installation
Requirements
Supported OS (Windows or Linux)
As per Commvault system requirements
Install
Download & Run Installer
Download the Commvault Media Kit.
Run the installer.

Choose:
Install required packages locally
Configure CommCell
Post-install
Confirm Commvault services are running.
Access UI
https://<commserve-fqdn>/commandcenter

Backup storage configuration
Primary storage (recommended)

Local disk storage on Media Agent VMs
Disk Library configuration:
Use high IOPS storage.
Size it based on retention and workload.
Benefits:
Faster restores (low RTO)
No WAN dependency during recovery
Secondary storage (optional)


Can be cloud storage (S3 / Azure / etc.)
Used for:
Secondary copy
Long-term retention
DR use cases
MediaAgent (MA) / Access Node deployment
VMs can be configured to do various jobs depending on the packages installed on them:


General Rules
Deploy as VMs in Private Cloud Director.
Use one Windows MediaAgent and one Linux MediaAgent per region.
Attach local disks for backup storage.
Create a Custom Installation Package
Create a Custom Installation Package
Linux MediaAgent (Access Node)
OS-level requirements
Install the following packages (required for restore & file browse):
QEMU disk image utility (qemu-img)
libguestfs
libguestfs-tools
Logical Volume Management (lvm)
Required Commvault packages
Installed from Commvault UI:
Linux File System
Virtual Server Agent
MediaAgent
Install
Windows MediaAgent (Access Node)
OS-level requirements
Install .NET Framework 4.8
Required before Commvault package installation
Windows clients cannot be installed from a Linux CommServe UI in some versions.
Install
Copy TAR to Access Node
Copy the generated TAR file to the Access Node server.
Silent Installation
Execute the silent installation script (silent_install).

Verify
Appears as Media Agent in UI
Assigned as Windows restore proxy

Add Private Cloud Director to Commvault
Go to Commvault UI.
Enter PCD Details
PCD Keystone endpoint (HTTPS/443), for example:
https://<pcd-region-fqdn>:443/keystone/v3Note: Commvault defaults to port 5000 if not otherwise specified. Be sure to use port 443 in the Keystone address.
OpenStack Domain User (mandatory): the domain associated with the user. Specify Default if not using a custom domain.
Credentials
Project / Region details

Backup and restore
Add VMs for backup
VM Groups
Create VM Groups using:
Content (explicit VMs)
Rules (tags / naming patterns)

Database protection (optional)
Database protection is agent-based.
Add the DB serverAdd the DB server:Manage → Servers → Add ServerInstall agents on the DB serverInstall directly on the same database server:File System AgentApplication-specific agent (MySQL, MSSQL, etc.)Configure policies and verifyConfigure DB backup policies.Verify visibility under the Database tab.Since the agent is installed on the database server itself, backups are application-aware. This ensures consistent backups and supported restores.
Backup and restore workflow in Private Cloud Director
This section explains the sequence of operations and the resources created in PCD when a backup or restore job is triggered from Commvault.
Backup Workflow (High-Level Flow)
Commvault interacts with PCD using the OpenStack APIs. Backups are agentless at the VM level (for VMs), with data movement handled by the Media Agent (Access Node).
Backup Job Triggered
A backup job is initiated from Commvault (scheduled or manual).
The job is associated with a VM Group and a Storage Policy.
PCD / OpenStack Authentication
Commvault authenticates to PCD via Keystone using the configured credentials.
Project and region context is established.
VM Metadata Collection
Commvault queries PCD for:
VM details
Attached volumes
Disk layout
Snapshot capabilities
Snapshot Creation (PCD Side)
PCD creates:
AVM snapshot or
Volume snapshots (depending on configuration)
Only VMs that boot from persistent (bootable) volumes are supported. Ephemeral-root VMs are not protected.
The VM remains powered on unless otherwise configured.
Temporary Snapshot Resources Created
On the PCD side, the following resources are created temporarily:
Snapshot objects (VM or volume)
Temporary snapshot volumes
Snapshot metadata entries
Data Read by Media Agent
The MediaAgent (Access Node VM) accesses the snapshot data.
A temporary volume created from the snapshot is attached or mapped to the MediaAgent. This allows reads without impacting the source VM.
Backup data is streamed:
From snapshot → MediaAgent
From MediaAgent → local disk library
Snapshot Cleanup
Once data transfer completes successfully:
Snapshot resources are deleted
Temporary volumes are removed
PCD returns the VM to its original state.
Job Completion
Backup metadata is updated in Commvault.
Backup data is retained according to the Storage Policy.
PCD Impact Summary (Backup)
No permanent resources left behind
Short-lived snapshots only
No agent installed inside the VM
Minimal VM performance impact
Restore Workflow
Restores are proxy-based and require an OS-matching MediaAgent. Commvault uses PCD APIs to recreate or overwrite VM resources.
1. Restore Job Triggered
Restore initiated from Commvault:
Full VM restore
File-level restore
2. Restore Proxy Selection
Commvault selects an OS-specific Media Agent:
Windows VM restore → Windows Media Agent
Linux VM restore → Linux Media Agent
3. PCD Authentication
Commvault authenticates to PCD using Keystone.
Target project, network, cluster, and region are selected.
4. Target Resource Preparation (PCD Side)
Depending on restore type, PCD creates:
New volumes from backup data
Temporary volumes (during restore)
Network attachments
5. Data Transfer
Backup data is read from:
Local disk library on Media Agent
Data is written to:
Newly created or existing PCD volumes
6. VM Reconstruction
For full VM restore:
VM definition is recreated
Volumes attached
Networks connected
The network selected for restore should have port security enabled.
VM powered on (optional)
7. Cleanup of Temporary Resources
Temporary restore volumes or staging resources are removed.
Final VM and disks remain active.
8. Restore Job Completion
Restore status updated in Commvault.
VM becomes available in PCD.
PCD Impact Summary (Restore)
New resources may be permanently created:
VMs
Volumes
Network attachments
Temporary resources are cleaned automatically
Restore speed depends on:
Media Agent proximity
Local disk performance
Volume size
Troubleshooting quick checks
Discovery fails
Confirm Keystone URL ends in
/keystone/v3.Confirm HTTPS/443 reachability from CommServe and Access Nodes.
Confirm credentials and scope (system vs project).
Backup fails at snapshot
Check tenant snapshot quota and concurrent jobs.
Check Cinder snapshot support for the backend.
Restore fails
Confirm the restore proxy OS matches the guest OS.
Confirm Access Node can attach and read volumes in the target project.
Summary
Deploy CommServe and Access Nodes per PCD region for performance and isolation.
Backups are snapshot-based and agentless for VMs.
Database backups remain agent-based (inside the DB server).
Media Agents handle all data movement.
Local disk storage ensures:
Faster restores
Reduced dependency on network or cloud storage
OS-specific Media Agents are mandatory for restores, not backups.
Last updated
Was this helpful?






















