Modulo 0 — Overview

⏱ Tempo di lettura: ~10 minuti 🎯 Obiettivo: capire cos’è OpenShift Virtualization, perché dovrebbe interessare a un admin vSphere, e come si posiziona rispetto al mondo a cui sei abituato.

Il contesto

Negli ultimi anni — soprattutto dopo l’acquisizione di VMware da parte di Broadcom e i conseguenti cambi di licensing — molte aziende stanno valutando alternative al loro stack vSphere. Red Hat OpenShift Virtualization è una delle alternative più discusse, perché permette di far girare VM tradizionali fianco a fianco con container sulla stessa piattaforma, senza dover scegliere fra “ambiente legacy VM” e “ambiente moderno container”.

Per un admin VMware il salto concettuale però è reale: cambia il vocabolario, cambia l’unità di gestione, cambia il modello operativo. Questa guida serve proprio a costruire un ponte fra i due mondi.

Cos’è OpenShift Virtualization

OpenShift Virtualization è una funzionalità integrata di Red Hat OpenShift (non un prodotto separato a parte) che consente di eseguire macchine virtuali come carichi di lavoro nativi sul cluster Kubernetes/OpenShift. Tecnicamente è basata sul progetto upstream KubeVirt, che a sua volta usa KVM/QEMU sotto il cofano: lo stesso hypervisor che da anni è alla base di RHEL e che gira praticamente su ogni cloud pubblico.

Il punto chiave: in OpenShift Virtualization una VM è una risorsa Kubernetes. Si descrive in YAML, si gestisce con oc, si schedula sui nodi con le stesse logiche dei pod, accede allo storage tramite PV/PVC, alla rete tramite il CNI del cluster. Non c’è un “vCenter” separato: il piano di controllo è OpenShift stesso.

Cos’è (e cosa non è)

È…	Non è…
Una piattaforma per VM e container insieme	Un clone 1:1 di vSphere
Una soluzione Kubernetes-native	Un hypervisor “tradizionale” come ESXi
Multi-cluster e multi-cloud (on-prem, AWS, Azure, GCP, bare metal)	Solo on-prem
Open source (KubeVirt) con supporto enterprise Red Hat	Un progetto chiuso
Compatibile con virtio, ma anche con e1000e per legacy guest	Solo per VM Linux

Perché un admin VMware dovrebbe interessarsene

Ci sono almeno cinque motivi pratici:

Licensing. Il modello di sottoscrizione di OpenShift è prevedibile (per core, per socket o per VM a seconda dell’edizione) e non subisce gli stessi shock di pricing che hanno colpito molti clienti vSphere.
Convergenza VM + container. Se la tua organizzazione ha già OpenShift per applicazioni cloud-native, aggiungere la virtualizzazione sullo stesso cluster significa un solo piano di controllo, un solo team, un solo SLA.
Hybrid cloud. OpenShift gira identico on-prem e sui principali hyperscaler: una VM definita on-prem può essere spostata su ROSA o ARO con poche modifiche, cosa che con vSphere richiede VMC/AVS o porting.
GitOps e Infrastructure-as-Code nativi. Le VM diventano oggetti YAML versionabili. Niente più “esporta OVF, importa OVF, riconfigura a mano”: tutto declarative, tutto in Git.
Ecosistema partner. I principali vendor di backup, storage e networking che già conosci dal mondo VMware (Veeam, Trilio, Pure Storage, NetApp, F5, Cisco, NVIDIA…) hanno integrazione certificata con OpenShift Virtualization.

Cosa non ti aspettare

Per essere onesti, è giusto chiarire anche dove il confronto è meno favorevole o richiede un cambio di paradigma:

Non c’è un equivalente diretto di Storage DRS (SDRS). Il rebalancing automatico dello storage fra datastore non esiste con la stessa logica: il modello PV/PVC con CSI è diverso e si appoggia alla logica del backend.
Il “DRS” è diverso. Esiste un descheduler, ma non è acceso di default e non funziona con la stessa granularità del DRS di vSphere. Il rebalancing si gestisce in modo più dichiarativo (affinity/anti-affinity, taints, tolerations).
L’interfaccia non è vCenter. La OpenShift web console è ottima ma ha una filosofia “Kubernetes prima, VM poi”. Per chi vuole una vista 100% VM-centric esiste anche una console amministrativa dedicata in alcune edizioni.
HA delle VM richiede configurazione esplicita. Il rilevamento dei guasti del nodo e il rescheduling delle VM funzionano, ma vanno configurati con i fencing agent e il Node Health Check Operator. Non è “on by default” come l’HA di vSphere.

Le 4 aree che esploreremo

Il learning path Red Hat (e questa guida) si struttura intorno a quattro pilastri tecnici, più alcune sezioni trasversali:

                 ┌────────────────────────────────────┐
                 │   OpenShift Virtualization         │
                 ├────────────────┬───────────────────┤
                 │   STORAGE      │   NETWORKING      │
                 │   PV / PVC     │   OVN-K, Multus   │
                 │   StorageClass │   NMState         │
                 ├────────────────┼───────────────────┤
                 │   COMPUTE      │   OBSERVABILITY   │
                 │   Live Migr.   │   Prometheus      │
                 │   Descheduler  │   Loki / Vector   │
                 │   HA, hot-plug │   Alertmanager    │
                 └────────────────┴───────────────────┘
                          ▲                    ▲
                          │                    │
                  COMPONENTI VM         OPERAZIONI
                  (virtio, QEMU GA)     QUOTIDIANE

Per ognuna di queste aree partiremo dal concetto vSphere che già conosci e arriveremo all’equivalente (o quasi) in OpenShift, segnalando dove c’è corrispondenza diretta e dove invece il modello cambia.

Come è strutturato ogni modulo

Ogni modulo successivo segue lo stesso schema:

Punto di partenza VMware — come fai questa cosa oggi in vSphere
Mapping concettuale — la tabella di equivalenze
Mapping di menu della console — dove cliccare nella OpenShift web console
Esempi pratici — comandi oc / virtctl o frammenti YAML
Differenze importanti — dove il modello non è 1:1 e va capito a parte
Approfondimenti — link alla documentazione ufficiale Red Hat

Cosa ti serve avere a portata di mano

Per seguire la guida da letta non serve nulla. Per provare gli esempi ti serve:

accesso a un cluster OpenShift 4.16+ (in alternativa: OpenShift Local, una VM/laptop con almeno 16 GB RAM);
l’operator OpenShift Virtualization installato dal catalogo OperatorHub;
la CLI oc (corrisponde grosso modo a una kubectl arricchita);
la CLI virtctl per le operazioni VM-specifiche (start, stop, console, migrate).

Tutti i dettagli sull’installazione li trovi nel modulo 6 e nel file comandi base.

Avanti → Modulo 1 — Storage