# Pre-requisites

This document describes the infrastructure pre-requisites to get your <code class="expression">space.vars.product\_name</code> private cloud up and running. If you're looking to deploy Self-Hosted version of <code class="expression">space.vars.product\_name</code>, please follow [Self Hosted Pre Requisites](/private-cloud-director/2025.7/getting-started/self-hosted/self-hosted-pre-requisites.md) first.

## Hypervisor Host Prerequisites

Each physical server or host that you will use as a hypervisor with <code class="expression">space.vars.product\_name</code> must meet the following requirements:

1. x86 server - <code class="expression">space.vars.product\_name</code> only supports x86 server hardware today.
2. Running [Ubuntu 22.04 LTS](https://cloud-images.ubuntu.com/releases/jammy/release/) (Jammy Jellyfish) AMD64 cloud image. Note: A full server distribution is not required, and the minimal distribution is not supported.
3. The server must meet the [CPU Model Pre-requisites for Hypervisor Hosts](/private-cloud-director/2025.7/virtualized-clusters/add-hosts-virtualized-cluster/cpu-model.md#cpu-model-pre-requisites-for-hypervisor-hosts).
4. Each server should have following minimum amount of resources:
   1. 8 vCPUs
   2. 16GB RAM
   3. 250 GB storage (including OS + Platform9 installer packages, logs, etc. + VM storage). Note: When using non-ephemeral (cinder) storage for VMs, storage of 100 GB should be enough.
5. `sudo` access enabled for Administrator to log into the server and install the Platform9 agent
6. Server `hostname` should contain at least one non-numeric character
7. Make sure that the content under `/opt/pf9` is not shared across hosts. Either make this a local directory, or if using shared storage, make sure that this path mounts to a unique shared storage file share or volume that is not shared across any other hosts in your <code class="expression">space.vars.product\_name</code> setup.
8. When using the SaaS-hosted deployment model, outbound connectivity (port 443) must be enabled on each server so that the Platform9 agent can connect to the <code class="expression">space.vars.product\_name</code> SaaS management plane.
9. In the case of a multi-domain environment, host onboarding should be done by the Administrator user in the `default` domain and not the secondary domains.
10. If planning to use [VM Live Migration](/private-cloud-director/2025.7/virtualized-clusters/deploying-workloads/vm-migration.md#live-migration) feature, follow the [Live Migration Prerequisites](/private-cloud-director/2025.7/virtualized-clusters/deploying-workloads/vm-migration.md#live-migration-prerequisites)
11. If planning to use the [Virtual Machine High Availability Vm Ha ](/private-cloud-director/2025.7/virtualized-clusters/virtualized-cluster/virtual-machine-high-availability-vm-ha.md)feature, follow the [VM HA Prerequisites](/private-cloud-director/2025.7/virtualized-clusters/virtualized-cluster/virtual-machine-high-availability-vm-ha.md#pre-requisites).
12. If planning to use the [Dynamic Resource Rebalancing Drr ](/private-cloud-director/2025.7/virtualized-clusters/virtualized-cluster/dynamic-resource-rebalancing-drr.md)feature, follow the [DRR Pre-requisites](/private-cloud-director/2025.7/virtualized-clusters/virtualized-cluster/dynamic-resource-rebalancing-drr.md#drr-pre-requisites).

## Storage Prerequisites

<code class="expression">space.vars.product\_name</code> supports a wide variety of enterprise storage solutions. Verify you have access to the administrative console of your storage solution and can lookup the required configuration information from your admin console.

* Read more in the [Storage Overview](/private-cloud-director/2025.7/storage/storage-overview.md) article about types of storage supported by <code class="expression">space.vars.product\_name</code>.
* For [block storage](/private-cloud-director/2025.7/storage/volume.md), see the list of [supported block storage drivers](/private-cloud-director/2025.7/storage/block-storage-options---configuration/supported-storage-drivers.md)
* <code class="expression">space.vars.product\_name</code> expects every hypervisor that connects to iSCSI storage to present **one unique iSCSI Qualified Name (IQN)**. Duplicate IQN can exist across hypervisor hosts when multiple hosts boot with an identical IQN, often because their OS image was cloned. Please refer to the [knowledge base article](https://platform9.com/docs/private-cloud-director/kb/how-to-rename-iscsi-initiator-names-to-the-existing-hypervisors-) to address duplicate IQNs.
* See also: [latest compatibility matrix of Cinder storage drivers and devices](https://docs.openstack.org/cinder/latest/reference/support-matrix.html#driver-support-matrix) as maintained by the OpenStack project.

#### Using Ephemeral Local Storage

If you plan to use [Ephemeral Local Storage](/private-cloud-director/2025.7/storage/storage-overview1sq.md#ephemeral-local-storage) for VM root disk, sufficient local disk space is required at per hypervisor host level to store virtual machine instance files. The recommended minimum storage per hypervisor host in this case is:

* **250GB** of local disk space
* This space is used for storing VM images, swap, and temporary storage.
* Ensures sufficient capacity for high-density workloads.

#### Using Ephemeral Shared Storage or Volume Based Storage

If you plan to use [Ephemeral Shared Storage](/private-cloud-director/2025.7/storage/storage-overview1sq.md#ephemeral-shared-storage) or [Block Storage Volumes](/private-cloud-director/2025.7/storage/volume.md) for VM root disk, then per hypervisor host local disk requirements are significantly lower:

* **95GB** of local disk space for operating system and services.
* Virtual machine storage is managed externally, reducing local storage needs.

#### Partitioning Recommendations

For Volume based storage, partitioning should optimize performance and ensure efficient storage utilization:

* `/` (root) – Minimum **50GB** for operating system and essential services.
* `/var` – Minimum **30GB**, especially for logs and temporary files.
* `/home` – Optional, size as needed based on user requirements.
* `/opt` – If using additional services, allocate **15GB+**.
* `Swap` – Recommended **1.5x** RAM for best performance.

## Networking Prerequisites

All hypervisor hosts should have a minimum of 1 network interface, and ideally 4 network interfaces to enable redundancy across network interface failure. A typical configuration would look like:

1. bond0 mapped to two adapters: eth0 and eth1
2. bond1 mapped to two adapters: eth2 and eth3

### Key Networking Decisions

Your key decisions before configuring networking in <code class="expression">space.vars.product\_name</code> are:

1. Use of bonded network interfaces (recommended) to ensure availability if a physical network interface fails
2. Desired network topology and separation:
   1. Management network
   2. Workload network (e.g. a VM network)
   3. Storage network
   4. Backup/DR network
3. Use of physical networks vs "virtual" software defined networks:
   1. A common use case is that external north-south connectivity is available via an existing physical network in your infrastructure; but a group of users may want to use a virtual network that doesn't need to consume ports from this external network
   2. You may have limitations on the VLANs that are available to use, and may want to expand the logical network range by using an IP overlay such as VXLAN or GENEVE networking
   3. Groups of users and workloads that have overlapping IP ranges can be isolated easily using virtual networks
4. External firewall (outside cluster) vs in-cluster firewall

Segregation of traffic can be done within the <code class="expression">space.vars.product\_name</code> if you aren't already using VLAN or VXLAN based network segments.

For further reading, see [Overview & Architecture](/private-cloud-director/2025.7/virtualized-networking/networking-overview.md).

### Outbound Connectivity Requirements

You would need to configure outbound access on port 443 from your hosts for the below domain names to ensure they can be onboarded to the <code class="expression">space.vars.product\_name</code> management plane.

1. <code class="expression">space.vars.product\_name</code> management plane url is accessed over port 443.
2. For `pcdctl` CLI download on hosts, <https://pcdctl.s3.us-west-2.amazonaws.com/pcdctl-setup>
3. APT sources list for installing packages on the Ubuntu host using `pcdctl prep-node` :
   1. <http://security.ubuntu.com/ubuntu>
   2. <http://us.archive.ubuntu.com/ubuntu>
   3. <http://ubuntu-cloud.archive.canonical.com/ubuntu>
   4. <http://nova.clouds.archive.ubuntu.com/ubuntu>
   5. <https://wiki.ubuntu.com/OpenStack/CloudArchive>

## Image Library Prerequisites

The Image Library service manages virtual machine images in the <code class="expression">space.vars.product\_name</code> environment. To enable its proper operation, the following prerequisites must be met:

1. Ensure that port `9494` is allowed, used by the Image Library API for image operations.
2. The Image Library service must operate with `admin` permissions to read and write image files to persistent storage.

### External Connectivity

The hypervisor node that you've assigned image library role (the image library node) must have external connectivity to be accessible via a browser. This requirement is necessary for:

* Uploading images through the <code class="expression">space.vars.product\_name</code> UI.
* Verifying and accepting self-signed certificates.

### Self-Signed Certificates

The image library node uses self-signed certificates. To enable image uploads from the UI, users need to:

* Navigate to the image library endpoint in a browser.
  * Click Access & Security Menu -> API Access -> and look for glance-cluster.
* Accept the insecure certificate when prompted.

#### Why Self-Signed Certificate?

The self-signed certificate is needed because the image library node secures communication with SSL/TLS and uses a self-generated certificate instead of one from a public CA.

Since browsers and CLI tools trust only publicly verified certificates, users must manually accept the self-signed certificate when accessing the Image Library Admin endpoint.

Similarly, the `--insecure` flag is required for the OpenStack CLI to bypass certificate verification during image uploads.

## Load Balancer As a Service (LBaaS) Prerequisites

These pre-requisites only apply if you plan to deploy [Load Balancer as a Service (LBaaS)](/private-cloud-director/2025.7/virtualized-networking/load-balancer.md) implementation offered by <code class="expression">space.vars.product\_name</code> to create one or more software-defined load balancers for your application services.

#### CLI Update

You need to install the Octavia extension to the OpenStack CLI in order to use the LBaaS specific OpenStack CLI commands. Run the following command on a machine where you want to run OpenStack CLI to install both packages.

{% tabs %}
{% tab title="Bash" %}

```bash
sudo apt install python3-openstackclient python3-octaviaclient -y
```

{% endtab %}
{% endtabs %}

Alternatively, run the following command on the machine where you already have OpenStack CLI running, to add the LBaaS extension.

{% tabs %}
{% tab title="Bash" %}

```bash
sudo apt install python3-octaviaclient -y
```

{% endtab %}
{% endtabs %}

#### Network Requirements

You will need:

* Internal VXLAN or flat network(s) (a physical or virtual network) that will be used both by your load balancer instance, and your pool of virtual machines that will run the service and receive client requests.
* (Optionally) An external network if you plan to use public (floating) IPs for your load balancer.

#### Pool of Virtual Machines

The pool of virtual machines that will run your application that requires load balancing must meet the following requirements:

* Be running and in an 'active' state
* Have a valid IP address assigned from the same tenant network that you will use to create a new load balancer instance.
* Have your application (e.g., web server) running and accessible

#### Router Configuration

The load balancer requires a virtual router to forward traffic from its virtual IP (VIP) and the backend pool of VMs. The following scenarios require the router to be configured differently:

* If the VIP and backend pool of VMs are on the same physical or virtual network, the router simply needs to have a single interface on that network. This allows it to respond to ARP requests for the VIP.
* If the VIP and backend pool are on different networks, the router needs to have an interface each for both networks.
* If you plan to use a floating IP to front the VIP of the load balancer, you will need a router connecting the tenant network used by the load balancer and the pool of VMs, and your external network serving the floating IPs. Additionally, you will also need available public (floating) IPs in your quota.

## Kubernetes Pre-requisites

Read [Kubernetes Pre-requisites](/private-cloud-director/2025.7/kubernetes-clusters/k8s-pre-requisites.md) for requirements to setup a Kubernetes cluster in <code class="expression">space.vars.product\_name</code>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/2025.7/getting-started/pre-requisites.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.