Salta ai contenuti
OpenShift Virtualization per Admin VMware

Modulo 7 — Conclusione e next steps

⏱ Tempo di lettura: ~10 minuti 🎯 Obiettivo: ricapitolare quello che hai imparato e tracciare un percorso di approfondimento concreto, sia tecnico sia di certificazione.

Quello che dovresti portarti a casa

Se hai seguito i moduli precedenti, ora dovresti avere chiari almeno questi sei punti.

  1. OpenShift Virtualization è virtualizzazione “Kubernetes-native”: non un nuovo hypervisor proprietario, ma KVM/QEMU integrato in un piano di controllo Kubernetes. Le VM sono oggetti API, gestibili come qualunque altro workload.

  2. Lo storage si traduce con StorageClass + PVC, non più con datastore. La logica di policy-based provisioning resta, cambia il punto di applicazione. Storage live migration esiste, Storage DRS no.

  3. La rete è SDN-first: OVN-Kubernetes copre overlay, microsegmentazione, IPAM, load balancing L4. Multus + NetworkAttachmentDefinition ti permettono di mantenere il modello “VLAN + port group” dove serve. NMState configura l’underlay sui nodi in modo declarativo.

  4. Compute si distribuisce fra più componenti: scheduler per il placement, descheduler per il rebalancing, Node Health Check + fencing per l’HA, live migration per i movimenti a caldo. È meno “magico” del DRS, più granulare e trasparente.

  5. Observability è inclusa, non opzionale: Prometheus, Alertmanager, Loki/Vector, Grafana sono già lì. Tutto YAML, tutto versionabile in Git, tutto multi-tenant.

  6. Le operazioni quotidiane cambiano linguaggio, non sostanza: oc e virtctl al posto di PowerCLI, GitOps al posto di vRA/Aria, MTV al posto di vMotion-cross-vCenter per la migrazione.

E un settimo punto, più morbido ma altrettanto importante:

  1. Non è un clone di vSphere. Alcune feature mancano (Storage DRS, HA “auto-on”), altre sono concettualmente diverse (descheduler vs DRS, networkpolicy vs firewall NSX). Non cercare l’equivalente 1:1 ovunque: cerca il modo OpenShift di risolvere lo stesso problema. È un cambio di mentalità più che di strumento.

Il piano di approfondimento consigliato

A questo punto, in ordine logico:

Settimana 1 — Hands-on solitario

Procurati un cluster di test (Single Node OpenShift su una VM/laptop, o accesso a un cluster aziendale). Fai questi cinque esercizi, da solo:

  1. Installa l’operator OpenShift Virtualization e crea l’oggetto HyperConverged.
  2. Crea una VM RHEL e una Windows da template, accedile via console e SSH/RDP.
  3. Esegui una live migration manuale, una snapshot, un restore.
  4. Configura una NetworkAttachmentDefinition VLAN-bridge e attaccala a una VM.
  5. Scrivi una NetworkPolicy che limiti il traffico a una VM solo da pod con una certa label.

Settimana 2 — Lab Red Hat ufficiali

Apri redhat.com/en/interactive-labs, filtra “Virtualization”, e fai almeno:

  • Single Node OpenShift deployment with Assisted installer
  • Deploying OpenShift Virtualization with Assisted Installer
  • Node Maintenance
  • Manage and monitor VMs with ACM
  • Regional Disaster Recovery for VMs using RHACM and ODF

I lab sono in inglese, eseguibili dal browser, e ti danno un cluster temporaneo già configurato. Non serve installare nulla.

Settimana 3 — Migrazione

Se hai un vCenter di test (o anche di produzione, ma con VM non critiche scelte ad arte):

  1. Installa MTV (Migration Toolkit for Virtualization).
  2. Configura il provider verso il tuo vCenter.
  3. Crea NetworkMap e StorageMap.
  4. Migra una VM Linux semplice in modalità cold.
  5. Migra una VM più complessa (Windows, con multi-disk) in modalità warm.

Documenta passo-passo cosa è andato bene, cosa no, dove sei dovuto intervenire a mano. Sarà la base del runbook di migrazione del tuo team.

Settimana 4 — GitOps e automazione

  1. Imposta un repo Git con le definizioni delle tue VM (anche solo una manciata).
  2. Installa OpenShift GitOps (Argo CD).
  3. Configura un’Application che sincronizzi le VM dal repo.
  4. Modifica una VM da Git e osserva il roll-out automatico.
  5. Bonus: scrivi un playbook Ansible che fa la stessa operazione, per confronto.

Certificazioni e formazione formale

Per chi vuole “metterci un timbro” sopra:

CertificazioneCodiceA chi è rivolta
Red Hat Certified System AdministratorEX200Base RHEL, prerequisito raccomandato
Red Hat Certified Specialist in OpenShift AdministrationEX280Admin OpenShift in generale
Red Hat Certified Specialist in OpenShift VirtualizationEX316Specifica per Virtualization
Red Hat Certified Engineer (RHCE)EX294Automation Ansible — utile per scripting/operazioni

Il percorso tipico per un admin VMware che vuole certificarsi: EX200 → EX280 → EX316. C’è anche un corso ufficiale Red Hat (DO316 — Managing Virtual Machines with Red Hat OpenShift Virtualization) che prepara direttamente all’EX316.

Tutti i dettagli su redhat.com/en/services/certification.

Risorse di lungo periodo

Da tenere a portata di mano:

  • Documentazione ufficiale OpenShift Virtualization: docs.redhat.com. Bookmark obbligatorio.
  • KubeVirt upstream: kubevirt.io. Per capire “perché” certe cose funzionano in un certo modo: spesso la documentazione upstream è più dettagliata.
  • Red Hat blog “Virtualization”: redhat.com/en/blog (filtro per topic). Articoli pratici, casi d’uso, deep-dive.
  • Red Hat developer blog: developers.redhat.com/blog. Spesso include articoli tecnici molto dettagliati.
  • YouTube – Red Hat / OpenShift TV: webinar e demo, spesso più recenti della documentazione.
  • Red Hat Customer Portal: access.redhat.com per knowledge base, security advisory, casi di supporto.
  • Communities: r/redhat, r/openshift, r/kubernetes su Reddit; il forum learn.redhat.com.

Strumenti complementari da conoscere

Una volta padroneggiato OpenShift Virtualization base, questi sono i tool “vicini” che spesso entrano in gioco in un’organizzazione reale:

  • Red Hat Advanced Cluster Management (RHACM): gestione multi-cluster, governance, application lifecycle, DR multi-sito. Quasi obbligatorio se gestisci più di 2-3 cluster.
  • Red Hat OpenShift Data Foundation (ODF): storage software-defined Ceph-based. Ottimo punto di partenza se non hai già un partner storage CSI.
  • Red Hat OpenShift GitOps (Argo CD): come visto, la via “industriale” per gestire le VM in modo declarative.
  • Red Hat Ansible Automation Platform: per automazione enterprise di patching, configurazione, runbook.
  • Red Hat Quay: container registry privato, utile per immagini di container e per immagini sysprep di Windows.
  • Red Hat Insights: telemetria proattiva su rischi, raccomandazioni di security e compliance.

Conclusione

Il salto da vSphere a OpenShift Virtualization non è banale, ma non è nemmeno il salto da virtualizzazione a “qualcosa di completamente diverso”: è un cambio di linguaggio per gli stessi problemi, con qualche pezzo che si guadagna (GitOps, hybrid cloud, container+VM nello stesso piano) e qualche pezzo che si perde o cambia forma (DRS automatico, HA out-of-the-box).

Il consiglio finale, valido per qualunque migrazione di piattaforma: non fare big bang. Inizia con un cluster di test, porta 5-10 VM non critiche, costruisci il runbook, forma il team, poi scala. Sei mesi di “doppio binario” non sono uno spreco, sono assicurazione.

E se ti perdi: la community è grande, la documentazione è ricca, e Red Hat ha un team dedicato a clienti che migrano da VMware. Non sei il primo a fare questo viaggio.

In bocca al lupo.

← Modulo 6 — Operazioni quotidiane | Avanti → Modulo 8 — Approfondimenti