Apache CloudStack è una piattaforma open source potente e flessibile per la gestione di infrastrutture cloud IaaS (Infrastructure as a Service).
Grazie alla sua architettura modulare e alla vasta compatibilità con hypervisor come KVM, VMware e XenServer, CloudStack consente di creare e gestire ambienti cloud privati e pubblici in modo centralizzato e scalabile.
In questo articolo vedremo come eseguire l’installazione e la configurazione base di Apache CloudStack su Ubuntu Server 24.04, l’ultima LTS di casa Canonical.
Seguiremo un approccio passo-passo, pensato per sysadmin, DevOps o semplici appassionati che vogliono iniziare a familiarizzare con questa potente piattaforma cloud.
PREREQUISITI
- Ubuntu 24.04 (server)
- Minimo 2 CPU, 4GB RAM (meglio 8GB+)
- Accesso root o sudo
- Rete configurata con IP statico
- Java 11 (OpenJDK)
- MySQL/MariaDB
- NTP attivo
AGGIORNAMENTO DEL SISTEMA
Aggiornare il sistema con il comando:
|
0 |
sudo apt update && sudo apt upgrade -y
|
Quindi installare i seguenti pacchetti con il comando:
|
0 |
sudo apt install -y software-properties-common curl gnupg
|
INSTALLAZIONE DI JAVA 11
Installare Java 11 con il comando:
|
0 |
sudo apt install openjdk-11-jdk -y
|
Quindi verificare la versione di Java installata con il comando:
|
0 |
java -version
|
Dovremmo visualizzare il seguente output:
|
0
1
2
|
openjdk version "11.0.27" 2025-04-15
OpenJDK Runtime Environment (build 11.0.27+6-post-Ubuntu-0ubuntu124.04)
OpenJDK 64-Bit Server VM (build 11.0.27+6-post-Ubuntu-0ubuntu124.04, mixed mode, sharing)
|
INSTALLAZIONE E CONFIGURAZIONE DEL DATABASE
Procedere con l’installazione di MariDB con il comando:
|
0 |
sudo apt install mariadb-server -y
|
Quindi configurare MariaDB con il comando:
|
0 |
sudo mysql_secure_installation
|
Dovremmo visualizzare l’output:
|
0
1
2
3
4
5
6
7
|
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.
Enter current password for root (enter for none):
|
Premere INVIO
Al seguente output:
|
0
1
2
3
4
5
6
7
|
OK, successfully used password, moving on...
Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.
You already have your root account protected, so you can safely answer 'n'.
Switch to unix_socket authentication [Y/n]
|
Premere Y
Al seguente output:
|
0
1
2
3
4
5
6
7
|
Enabled successfully!
Reloading privilege tables..
... Success!
You already have your root account protected, so you can safely answer 'n'.
Change the root password? [Y/n]
|
Premere Y per cambiare la password di root
Inserire due volte la password di root visualizzando l’output seguente:
|
0
1
2
3
4
|
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
|
Al seguente output:
|
0
1
2
3
4
5
6
|
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n]
|
Premere Y
Al seguente output:
|
0
1
2
3
|
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n]
|
Premere Y
Al seguente output:
|
0
1
2
3
4
|
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n]
|
Premere Y
Al seguente output:
|
0
1
2
3
|
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n]
|
Premere Y
Se è andato tutto a buon fine dovremmo visualizzare il seguente output:
|
0
1
2
3
|
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!
|
Accedere a MariaDB e configurare alcuni parametri editando il file 50-server.cnf con il comando:
|
0 |
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
|
Aggiungere o modificare sotto [mysqld]:
|
0
1
2
3
4
5
|
server-id=master-01
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
|
Salvare e chiudere il file di configurazione
Riavviare MariaDB con il comando:
|
0 |
sudo systemctl restart mariadb
|
A questo punto procedere con la creazione del database per CloudStack
Accedere a MariaDB con il comando:
|
0 |
sudo mysql -u root -p |
Eseguire dal prompt di MySQL i seguenti comandi in sequenza:
|
0
1
2
3
|
CREATE DATABASE cloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES ON cloud.* TO 'cloud'@'localhost' IDENTIFIED BY 'PASSWORD';
FLUSH PRIVILEGES;
EXIT;
|
NOTA BENE: al posto di PASSWORD inserire la password dell’utente cloudstack
AGGIUNTA DEL REPOSITORY CLOUDSTACK
Aggiungere il repository CloudStack ad Ubuntu con i seguenti comandi:
|
0
1
2
|
curl -fsSL https://download.cloudstack.org/release.asc | gpg --dearmor | sudo tee /usr/share/keyrings/cloudstack.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudstack.gpg] http://download.cloudstack.org/ubuntu focal 4.18" | sudo tee /etc/apt/sources.list.d/cloudstack.list
|
⚠️ NOTA BENE: La versione stabile più recente è 4.18. Non esiste ancora un repo ufficiale specifico per Ubuntu 24.04, quindi si usa quello di Ubuntu 20.04 (focal), che funziona compatibilmente.
|
0
1
2
3
4
5
6
|
sudo apt install -y gnupg
wget -qO - https://download.cloudstack.org/release.asc | sudo gpg --dearmor -o /usr/share/keyrings/cloudstack-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudstack-archive-keyring.gpg] http://download.cloudstack.org/ubuntu jammy 4.18" | sudo tee /etc/apt/sources.list.d/cloudstack.list
sudo apt update
|
INSTALLAZIONE DI CLOUDSTACK MANAGEMENT SERVER
Procedere all’installazione di Cloudstack con il comando:
|
0 |
sudo apt install cloudstack-management -y
|
Importare lo schema nel database con il comando:
|
0 |
cloudstack-setup-databases cloud:PASSWORD@localhost --deploy-as=root:rootpassword
|
Dovremmo visualizzare il seguente output:
|
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
Mysql user name:cloud [ OK ]
Mysql user password:****** [ OK ]
Mysql server ip:localhost [ OK ]
Mysql server port:3306 [ OK ]
Mysql root user name:root [ OK ]
Mysql root user password:****** [ OK ]
Checking Cloud database files ... [ OK ]
Checking local machine hostname ... [ OK ]
Checking SELinux setup ... [ OK ]
Detected local IP address as 127.0.1.1, will use as cluster management server node IP[ OK ]
Preparing /etc/cloudstack/management/db.properties [ OK ]
Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
Processing encryption ... [ OK ]
Finalizing setup ... [ OK ]
CloudStack has successfully initialized database, you can check your database configuration in /etc/cloudstack/management/db.properties
|
Quindi configurare CloudStack con il comando:
|
0 |
cloudstack-setup-management
|
Se è andato tutto a buon fine dovremmo visualizzare il seguente output:
|
0
1
2
3
|
Starting to configure CloudStack Management Server:
Configure CloudStack Management Server ...[OK]
CloudStack Management Server setup is Done!
Please ensure ports 8080, 8250, 8443, and 9090 are opened and not firewalled for the management server and not in use by other processes on this host.
|
Avviare ed abilitare il servizio di CloudStack con i seguenti comandi:
|
0
1
2
|
sudo systemctl start cloudstack-management
sudo systemctl enable cloudstack-management
|
CONFIGURAZIONE HOST SERVER
Perchè CloudStack possa funzionare eseguire i seguenti steps.
La prima cosa è quella di modificare il file /etc/hosts
|
0 |
sudo nano /etc/hosts
|
Dovremmo visualizzare il seguente output:
|
0
1
2
3
4
5
6
7
8
|
127.0.0.1 localhost
127.0.1.1 vm-test
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
|
Modificare l’IP del server impostando l’IP reale. Dovremmo visualizzare il seguente output:
|
0
1
2
3
4
5
6
7
8
|
127.0.0.1 localhost
192.168.100.174 vm-test
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
|
Salvare e chiudere il file Host
Riavviare quindi il CloudStack Management Server con il comando:
|
0 |
sudo systemctl restart cloudstack-management
|
Verificare il servizio di CloudStack con il comando:
|
0 |
sudo systemctl status cloudstack-management
|
A questo punto forzare l’IP del cluster in config CloudStack (alternativa garantita)
Modificare il file environment.properties con il comando:
|
0 |
sudo nano /etc/cloudstack/management/environment.properties
|
NOTA BENE: Se non esiste il file procedere alla creazione.
Aggiungere all’interno del file la seguente riga:
|
0 |
cloudstack.management.server.ip=192.168.100.174
|
NOTA BENE: al posto di 192.168.100.174 inserire l’IP del server
Salvare ed uscire dal file di configurazione.
Riavviare Cloudstack Management con il comando:
|
0 |
sudo systemctl restart cloudstack-management
|
Verificare che la configurazione sia corretta con il comando:
|
0 |
grep 'Cluster node IP' /var/log/cloudstack/management/management-server.log | tail -1
|
Se è andato tutto a buon fine dovremmo vedere:
|
0 |
Cluster node IP : 192.168.100.174
|
ACCESSO DALL’INTERFACCIA WEB
A questo punto accedere all’interfaccia grafica da un qualsiasi browser con il seguente link:
http://<IP_DEL_SERVER>:8080/client
Inserire le credenziali predefinite:
USERNAME: admin
PASSWORD: password
Quindi cliccare Login
Cliccare su Continue with installation
Cambiare la password dell’utente admin quindi cliccare OK
In questa schermata di configurazione è possibile scegliere una delle due zone che descriverò di seguito
CORE ZONE
📌 Definizione:
Una Core Zone è una zona CloudStack collocata in un data center centrale (tipicamente on-premise o cloud privato) con ampia capacità di calcolo, rete e storage.
✅ Caratteristiche:
- Elevata capacità e disponibilità.
- Bassa latenza interna, alta affidabilità.
- Accesso diretto a infrastrutture centrali (database, API, backup, ecc.).
Ottimizzata per:
- Carichi di lavoro pesanti
- Archiviazione a lungo termine
- Orchestrazione centrale
📍 Tipico utilizzo:
- Core IT services
- Gestione delle risorse cloud
- Piattaforme centralizzate (es. ERP, DB, ecc.)
EDGE ZONE
📌 Definizione:
Una Edge Zone è una zona CloudStack distribuita in località periferiche (es. sedi remote, filiali, piccoli POP, torri 5G) per portare il calcolo vicino all’utente o ai dispositivi IoT.
✅ Caratteristiche:
- Risorse limitate, progettata per operare in modo autonomo o intermittente.
- Più vicina geograficamente agli utenti finali.
- Minore latenza verso i dispositivi locali.
- Può funzionare anche con connettività intermittente verso il core.
Ottimizzata per:
- IoT
- Content delivery
- Applicazioni sensibili alla latenza (es. AR/VR, AI inferencing)
📍 Tipico utilizzo:
- Sedi remote/filiali
- Infrastruttura 5G/MEC
- Ambiti industriali (smart factory, energy)
In CloudStack, definire zone come Core o Edge non cambia il comportamento tecnico del software, ma rappresenta una classificazione logica/architetturale dell’infrastruttura, usata per progettare deployment ibridi, distribuiti e scalabili.
In questo tutorial utilizzerò la Core Zone
Cliccare Next per proseguire
In questa sezione è possibile scegliere la tipologia della Core Zone:
BASIC ZONE
📌 Descrizione:
Una Basic Zone è progettata per ambienti semplici e piatti, dove tutte le macchine virtuali condividono la stessa rete Layer 2. Non ci sono router virtuali, NAT o reti isolate: ogni VM riceve un IP direttamente dalla rete fisica.
✅ Caratteristiche principali:
- Rete flat (livello 2), una sola subnet per tutto.
- Non ci sono reti isolate per ogni utente/tenant.
- Gli IP pubblici sono assegnati direttamente alle VM.
- Nessun router virtuale (VR).
- Funziona bene con infrastrutture piccole o semplici.
🧰 Tipico utilizzo:
- Ambienti di test o sviluppo
- Cloud privati semplificati
- Laboratori o progetti didattici
🔻 Limitazioni:
- Nessun isolamento tra utenti
- Nessun supporto per servizi di rete avanzati (NAT, VPN, LB)
- Sicurezza e scalabilità limitate
ADVANCED ZONE
📌 Descrizione:
Una Advanced Zone supporta una topologia di rete complessa e multi-livello, dove ogni rete guest può essere isolata tramite VLAN o SDN, e le VM comunicano attraverso un router virtuale che fornisce NAT, firewall, DHCP, VPN, ecc.
✅ Caratteristiche principali:
- Supporta reti multiple: management, storage, guest, public.
- Le reti guest sono isolate e personalizzabili.
- Le VM non hanno IP pubblici diretti, ma passano attraverso il router virtuale.
- Ogni rete utente è separata e può essere configurata con NAT, firewall, VPN, ecc.
- Supporta IPv6, SDN, load balancer, elastic IP, ecc.
🧰 Tipico utilizzo:
- Ambienti di produzione
- Cloud pubblici o multi-tenant
- Data center con requisiti di sicurezza/rete complessi
✅ Vantaggi:
- Isolamento tra tenant
- Maggiore controllo e sicurezza
- Estrema flessibilità di rete
Se si sta iniziando o testando, la Basic Zone è più rapida da configurare.
Se si sta costruendo un’infrastruttura seria, scalabile e sicura, adottare la Advanced Zone.
Una Zone rappresenta l’unità geografica e fisica più ampia in Apache CloudStack, di solito mappata su un singolo data center.
Offre isolamento fisico, ridondanza, e può contenere:
uno o più Pod (gruppi di host + storage primario),
uno o più Secondary Storage, condivisi tra i Pod.
Di seguito la descrizione delle impostazioni da configurare:
🔹 Name: Il nome della zona. Deve essere univoco all’interno del sistema.
Esempio: Torino-DC1 o Torino-Edge.
🔹 IPv4 DNS1 / IPv4 DNS2: Indirizzi IPv4 dei server DNS pubblici che verranno assegnati alle VM guest. Questi DNS sono visibili dalle VM.
Esempio:
8.8.8.8 (Google DNS)
1.1.1.1 (Cloudflare)
🔹 IPv6 DNS1 / IPv6 DNS2: Versione IPv6 dei DNS pubblici (opzionale, solo se usi IPv6). Lascia vuoto se non usi IPv6.
🔹 Internal DNS1 / Internal DNS2: Server DNS usati dall’infrastruttura CloudStack, non visibili alle VM. Di solito, puntano a un server DNS interno aziendale o al DNS della rete di gestione. Necessari per la risoluzione dei nomi nei backend.
🔹 Hypervisor: Il tipo di hypervisor usato nella zona. Tutti gli host in una zona devono usare lo stesso hypervisor.
Opzioni comuni:
- KVM
- VMware
- XenServer
- Hyper-V
- LXC
- Ovm3
- Ovm
🔹 Network Domain: Nome del dominio DNS assegnato alle reti guest. Viene usato come suffisso DNS per le VM.
Esempio: se metti cloud.local, le VM avranno nomi tipo vm01.cloud.local.
🔹 Guest CIDR: La subnet IP usata come riferimento per le reti guest. È usata come spazio indirizzi per le reti isolate gestite dal router virtuale.
Esempio: 10.1.1.0/24 definisce una rete privata per le VM guest.
🔹 Dedicated: Se selezionato, la zona è dedicata a uno specifico account o dominio. Le risorse in questa zona non saranno disponibili ad altri utenti. Utile per scenari multi-tenant con isolamento fisico.
🔹 Enable local storage for user VMs: Se attivo, permette alle VM degli utenti di usare il disco locale degli host come storage.
Utile per ambienti con host standalone o risorse limitate.
ATTENZIONE: non adatto per alta disponibilità (HA), perché non è condiviso.
🔹 Enable local storage for system VMs: Come sopra, ma si applica alle System VMs (ad esempio: router virtuale, console proxy, secondary storage VM). Utile per laboratori o ambienti senza SAN/NFS.
✅ Esempio realistico
Name: Torino-DC1
IPv4 DNS1: 8.8.8.8
IPv4 DNS2: 1.1.1.1
IPv6 DNS1: (vuoto)
IPv6 DNS2: (vuoto)
Internal DNS1: 192.168.100.10
Internal DNS2: 192.168.100.11
Hypervisor: VmWare
Network domain: test.local
Guest CIDR: 10.1.1.0/24
Dedicated: No
Enable local storage for user VMs ✅ Sì
Enable local storage for system VMs ✅ Sì
In questa sezione è possibile configurare il Network
Quando si crea una zona, bisogna configurare almeno una rete fisica (Physical Network).
Su ogni rete fisica è possibile assegnare uno o più tipi di traffico, ciascuno con un ruolo specifico nella piattaforma.
🔹 Campi della sezione Network
1. Network name: Nome della rete fisica. È un’etichetta che ti aiuta a identificarla (es. PhysNet-Guest, PhysNet-Public). Non influisce sulla configurazione tecnica ma è utile per la gestione.
2. Isolation method: Definisce come viene isolato il traffico guest (quello delle VM degli utenti) all’interno della rete fisica.
Valori comuni:
- VLAN – isolamento tramite VLAN (richiede switch fisici configurati).
- VXLAN – isolamento tramite overlay di rete (più flessibile, richiede supporto).
- GRE – simile a VXLAN, ma con incapsulamento GRE.
- L3 – reti Layer 3 (usato in SDN avanzate).
- None – nessun isolamento (solo con Basic zone, non consigliato per produzione).
3. Traffic types: CloudStack gestisce diversi tipi di traffico, ognuno dei quali può essere assegnato a una rete fisica. Ogni tipo di traffico può essere configurato solo una volta per zona.
Tipi principali:
Guest: Rete usata dalle VM guest (utente finale). Può essere isolata o condivisa.
Management: Rete usata per comunicazione tra host e management server. Necessaria per KVM/Xen/VMware.
Public: Accesso internet o reti esterne. Usata da router virtuali per fornire IP pubblici alle VM.
Storage (opzionale): Traffico per accedere allo storage primario o secondario.
Control (solo per Xen/VMware): Comunicazione tra hypervisor e management agent.
4. Tags: Etichette libere che puoi associare alla rete fisica. Servono per selezionare una rete specifica durante l’allocazione delle risorse.
Esempio: se assegni tag: gold, puoi forzare che una rete guest usi solo quella rete fisica “gold”.
5. Physical Network 1 (2, 3, ecc.): Puoi definire una o più reti fisiche all’interno della stessa zona. Su ciascuna rete puoi assegnare uno o più tipi di traffico compatibili.
📌 Esempio di configurazione tipica per una zona Advanced (multi-tier):
PhysNet1 VLAN Guest, Public internet
PhysNet2 None Management, Storage mgmt-storage
PhysNet1 gestisce il traffico delle VM guest e l’accesso pubblico.
PhysNet2 è usata internamente per gestire gli host e comunicare con lo storage.
⚠️ Restrizioni importanti:
Ogni tipo di traffico deve essere assegnato una sola volta per zona.
Alcune combinazioni non sono valide (es. Guest + Management sullo stesso NIC non è consigliato).
I tipi di traffico devono essere mappati correttamente alle interfacce di rete degli host.
✅ Conclusione
La sezione Network è fondamentale per definire come il tuo cloud comunica internamente e con l’esterno. Devi mappare con attenzione le interfacce fisiche agli usi corretti, specialmente in ambienti di produzione.
🧩 Concetti chiave
Pod: Gruppo logico di host (server fisici) + storage in una zona (Zone)
Guest Traffic: Traffico tra VM nelle reti virtuali (guest networks)
Reserved IP Range: IP usati solo da CloudStack per la gestione interna (non per le VM)
ATTENZIONE: ogni zona Deve avere almeno 1 Pod, e ogni Pod deve avere un range IP riservato
🧾 Campi da compilare (esempio con spiegazione)
Pod name: Nome descrittivo del pod (es. Data Center 1) (POD-DC1 )
Reserved system gateway: Gateway IP interno usato da CloudStack per il traffico di sistema (192.168.100.1)
Reserved system netmask: Netmask della rete interna (255.255.255.0)
Start reserved system IP: Primo IP del range riservato (escluso gateway!) (192.168.100.84)
End reserved system IP: Ultimo IP del range (192.168.100.89)
Questi IP saranno usati per:
- gestione degli host
- comunicazioni interne
- servizi di sistema (es. router virtuale, DHCP, DNS)
⚠️ Requisiti importanti
- Il range di IP riservati deve essere univoco all’interno della zona.
- Non deve sovrapporsi ad altri range usati per:
- Public traffic
- Storage
- Guest networks
- Assicurati che non vengano usati da altri dispositivi fisici (es. switch, stampanti, ecc.).
✅ Esempio pratico
Immagina una rete interna riservata a CloudStack: 192.168.100.0/24
- Pod name: POD-DC1
- Gateway: 192.168.100.1
- Netmask: 255.255.255.0
- Start IP: 192.168.100.10
- End IP: 192.168.100.50
🧩 Cos’è il Guest Traffic?
È il traffico tra le VM create dagli utenti finali.
Le VM ricevono IP da questo range, e possono comunicare tra loro (in locale) o uscire su Internet tramite NAT, se configurato.
🧾 Campi da compilare
Guest gateway: L’IP del gateway per la rete delle VM (192.168.200.1)
Guest netmask: La subnet mask della rete Guest (255.255.255.0)
Guest start IP: Il primo IP disponibile per le VM (192.168.100.10)
Guest end IP: L’ultimo IP disponibile per le VM (192.168.100.200)
⚠️ Requisiti importanti
Non deve sovrapporsi al range IP usato per:
- IP di sistema riservati (System IP)
- IP pubblici
- Management o storage network
Deve essere sulla stessa subnet definita dalla netmask/gateway
- Non includere il gateway nel range
✅ Esempio completo
Immagina di voler usare la rete 192.168.200.0/24 solo per le VM:
Guest gateway: 192.168.200.1
Guest netmask: 255.255.255.0
Guest start IP: 192.168.200.10
Guest end IP: 192.168.200.200
🧠 Suggerimento
Puoi riservare i primi 10 IP (es. 192.168.200.2–192.168.200.9) per future espansioni (router virtuali, DHCP, ecc.).
🧩 Cos’è un Cluster in CloudStack?
Un cluster è un gruppo di host (server fisici) che:
- Usano lo stesso hypervisor (in questo caso VMware vSphere),
- Hanno hardware simile,
- Sono sulla stessa subnet,
- Accedono alla stessa storage primaria (SAN/NFS/VMFS).
📝 Campi da compilare
Cluster name: Nome identificativo per questo cluster (es. Cluster-ESXi01)
vCenter host: IP o FQDN del server vCenter (es. vcenter.example.com o 192.168.1.10)
vCenter username: Username con privilegi admin su vCenter (es. [email protected])
vCenter password: Password dell’utente vCenter
vCenter datacenter: Nome esatto del Datacenter come configurato in vCenter
🛠️ Opzioni avanzate
Override public-traffic: Imposta un’interfaccia specifica (vSwitch/port group) per il traffico pubblico
Override guest-traffic: Imposta un’interfaccia specifica per il traffico guest
Nexus 1000v IP address: IP del controller Cisco Nexus 1000v (se usato)
Nexus 1000v username: Username per accedere al Nexus 1000v
Nexus 1000v password: Password per il Nexus 1000v
🔹 Questi ultimi tre campi sono da usare solo se stai integrando Cisco Nexus 1000v come vSwitch virtuale avanzato.
✅ Esempio di configurazione (senza Nexus)
Cluster name: Cluster-DC1-A
vCenter host: 192.168.10.100
vCenter username: [email protected]
vCenter password: ********
vCenter datacenter: Datacenter-01 (come in vSphere Web UI)
Override public-traffic: (lascia vuoto se non necessario)
Override guest-traffic: (lascia vuoto se non necessario)
⚠️ Attenzione
- Il nome del datacenter va scritto esattamente come appare in vCenter.
- Il server vCenter deve essere raggiungibile dalla macchina CloudStack (ping e porte aperte).
- Gli host ESXi nel cluster devono:
- Usare la stessa versione di hypervisor,
- Avere accesso al primary storage.
🧾 Campi da compilare
Name: Nome identificativo del volume di storage. Es: Primary-Storage
Scope: Ambito in cui lo storage è visibile. Scegliere:
- Cluster (solo agli host di questo cluster) – consigliato
- Zone (visibile a più cluster – usato meno spesso con VMware)
Protocol:
Tipo di protocollo usato. Per VMware puoi usare:
- VMFS → se il datastore è su SAN (FC/iSCSI)
- NFS → se il datastore è condiviso via rete
- DatastoreCluster → se è già configurato in vCenter
vCenter datacenter:
Nome del datacenter definito in vCenter. Deve corrispondere esattamente a quanto scritto in vSphere
vCenter datastore: Nome del datastore visibile in vCenter, dove verranno creati i dischi delle VM
Provider: In genere DefaultPrimary, oppure un nome specifico se hai integrato un provider terzo
Storage tags: Etichette opzionali (es. fast, ssd, gold, vmware) utili per filtri nei service offering
✅ Esempio pratico
Supponiamo di avere un ambiente vSphere in casa:
Name: Primary-Storage-VM
Scope: Cluster
Protocol: DatastoreCluster
vCenter datacenter: Datacenter Casa (deve combaciare con vSphere!)
vCenter datastore: Datastore-VM_Host01 (così come lo vedi in vCenter)
Provider: DefaultPrimary
Storage tags: ssd,home (opzionale, solo se userai tag nei piani VM)
🧠 Note utili
Se stai usando datastore già esistenti in vCenter, il protocollo DatastoreCluster è quello corretto.
Assicurati che:
- Gli host nel cluster abbiano accesso al datastore.
- Il datastore sia condiviso tra tutti gli host del cluster.
- Il nome scritto sia identico a quello in vCenter.
🧩 Cos’è il Secondary Storage in CloudStack?
Il secondary storage serve per conservare:
- 📦 Template di VM (immagini da cui si creano le VM)
- 💿 File ISO (installazioni OS, tools, recovery)
- 🧷 Snapshot dei dischi delle VM
- 🔧 È condiviso tra tutti gli host della zona e in genere si basa su NFS, ma può anche usare SMB/CIFS in ambienti Windows (meno comune).
📝 Campi da compilare
- Provider Di solito DefaultSecondary (lascia invariato)
- Name Nome descrittivo del tuo storage secondario (es. Secondary-NFS)
- Server IP del server NFS/SMB che ospita lo storage
- Path Percorso esportato dal server (es. /mnt/cloudstack/secondary)
- SMB domain Solo per SMB/CIFS: dominio AD o Workgroup
- SMB username Solo per SMB/CIFS: username con accesso alla share
- SMB password Solo per SMB/CIFS: password dell’utente SMB
✅ Esempio per NFS (il più comune)
Supponiamo di avere un server NFS con IP 192.168.100.200 che esporta il path /export/secondary
Provider: DefaultSecondary
Name: Secondary-SMB
Server: 192.168.100.200
Path: /export/secondary
SMB domain: (lascia vuoto)
SMB username: (lascia vuoto)
SMB password: (lascia vuoto)
A questo punto è possibile lanciare la zona cliccandio su Launch Zone
Attendere qualche istante fino al termine dell’aggiunta della zona
A questo punto è possibile continuare con le configurazioni del caso
0 commenti