Modulo 6 — Operazioni quotidiane

⏱ Tempo di lettura: ~30 minuti 🎯 Obiettivo: tradurre le attività ricorrenti dell’admin VMware (creare VM, spostarle, fare backup, applicare patch, automatizzare) nel modo OpenShift Virtualization. Questo è il modulo più operativo del corso.

Indice

Day 0 — Installare e configurare l’ambiente
Day 1 — Creare e gestire VM
Day 2 — Manutenzione, upgrade, patching
Backup e Disaster Recovery
Sicurezza e compliance
Automazione: il “PowerCLI moderno”
Migrare le VM da vSphere: MTV
Lab interattivi consigliati

1. Day 0 — Installare e configurare l’ambiente

Installare OpenShift

Le strade principali, in ordine di complessità crescente:

Modalità	Quando ha senso
OpenShift Local (ex CRC)	Lab sul laptop, demo, sviluppo. Single-node, 16+ GB RAM consigliati
Single Node OpenShift (SNO) via Assisted Installer	PoC, edge, ambiente piccolo (1 nodo)
Cluster compatto 3-node	Lab più seri, edge “vero” con HA minima
Cluster standard 3 control-plane + N worker	Produzione
OpenShift su cloud (ROSA, ARO, OSD, GCP-OSD)	Quando vuoi consumare OpenShift “as a service”

L’Assisted Installer (console.redhat.com/openshift/assisted-installer) è oggi il modo più rapido on-prem: scarichi una ISO, la booti sui nodi, l’installer fa il resto guidandoti via UI web. È l’equivalente più simile al wizard di installazione vCenter.

Installare OpenShift Virtualization

Una volta che il cluster OpenShift è su, l’aggiunta della virtualizzazione è un’operazione di pochi minuti:

Vai sulla console OpenShift come admin.
Apri Operators → OperatorHub.
Cerca “OpenShift Virtualization”.
Clicca Install, accetta i default (namespace openshift-cnv, channel stable).
Una volta installato, crea l’istanza dell’oggetto HyperConverged (proposto in automatico dall’operator). Questo configura tutti i sottocomponenti (CDI, CNV, networking, descheduler integration…).

In CLI lo stesso si fa con due manifest:

# Subscription dell'operator
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  channel: stable
  name: kubevirt-hyperconverged
  source: redhat-operators
  sourceNamespace: openshift-marketplace
---
# Istanza HyperConverged
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec: {}

Verifica con:

oc get csv -n openshift-cnv
oc get hyperconverged -n openshift-cnv -o yaml

Configurazioni Day-0 consigliate

Prima di mettere VM in produzione:

Definisci una StorageClass di default con volumeBindingMode: WaitForFirstConsumer e supporto RWX (necessario per la live migration). Verifica anche lo StorageProfile associato.
Configura le NMState policy per i bridge di rete sui worker (vedi modulo Networking).
Definisci una migration network dedicata se hai rete sufficiente: si configura in HyperConverged come liveMigrationConfig.network.
Abilita il Node Health Check Operator e configura il fencing per l’HA delle VM (vedi modulo Compute).
Pianifica Monitoring storage: di default Prometheus tiene 15 giorni in PV; per retention più lunga abilita Thanos / external storage.

2. Day 1 — Creare e gestire VM

Creare una VM dalla console

Il flusso “easy mode”:

Sulla console OpenShift, switch alla Virtualization perspective.
Catalog → Templates — scegli un template (es. RHEL 9, Windows 2022, Fedora).
Imposta nome VM, namespace (= “folder” di vCenter), CPU/RAM, dischi, NIC.
Configura cloud-init (chiavi SSH, hostname, password) o sysprep per Windows.
Clicca Create VirtualMachine.

Il template fornito da Red Hat include già driver virtio, qemu-guest-agent e ottimizzazioni. Punto di partenza consigliato.

Creare una VM in CLI / GitOps

Per chi preferisce la riga di comando o il GitOps, la definizione è un singolo manifest YAML. Esempio minimo di una VM RHEL con cloud-init:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: rhel9-test
  namespace: lab-vm
  labels:
    app: lab
    os: rhel9
spec:
  running: true
  template:
    metadata:
      labels:
        kubevirt.io/domain: rhel9-test
    spec:
      domain:
        cpu:
          cores: 2
        resources:
          requests:
            memory: 4Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
            - name: default
              masquerade: {}
        machine:
          type: pc-q35-rhel9.2.0
      networks:
        - name: default
          pod: {}
      volumes:
        - name: rootdisk
          dataVolume:
            name: rhel9-test-root
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |
              #cloud-config
              user: cloud-user
              password: cambiami!
              chpasswd: { expire: False }
              ssh_authorized_keys:
                - ssh-ed25519 AAAA... user@laptop
              packages:
                - qemu-guest-agent
              runcmd:
                - systemctl enable --now qemu-guest-agent
  dataVolumeTemplates:
    - metadata:
        name: rhel9-test-root
      spec:
        source:
          pvc:
            namespace: openshift-virtualization-os-images
            name: rhel9
        storage:
          resources:
            requests:
              storage: 30Gi
          storageClassName: ocs-storagecluster-ceph-rbd

Lo applichi con:

oc apply -f rhel9-test.yaml

Operazioni base sulla VM (ciclo di vita)

Cosa vuoi fare	Comando	Equivalente vSphere
Avviare la VM	`virtctl start rhel9-test -n lab-vm`	Power On
Fermarla “soft”	`virtctl stop rhel9-test -n lab-vm`	Shut Down Guest OS
Forzare lo stop	`virtctl stop rhel9-test -n lab-vm --force`	Power Off
Riavviare	`virtctl restart rhel9-test -n lab-vm`	Reset
Mettere in pausa	`virtctl pause vm rhel9-test -n lab-vm`	Suspend
Aprire console seriale	`virtctl console rhel9-test -n lab-vm`	Serial console
Aprire console VNC	`virtctl vnc rhel9-test -n lab-vm`	Web console
SSH (con porta forwarding)	`virtctl ssh cloud-user@vm/rhel9-test.lab-vm`	SSH classico via IP
Live migrare	`virtctl migrate rhel9-test -n lab-vm`	vMotion

Vedere lo stato

# Lista VM e stato
oc get vm -n lab-vm

# Dettaglio (incluso IP, nodo, condizioni)
oc get vmi -n lab-vm rhel9-test -o wide

# Eventi
oc get events -n lab-vm --field-selector involvedObject.name=rhel9-test

Snapshot di una VM

# Creare
oc apply -f - <<EOF
apiVersion: snapshot.kubevirt.io/v1beta1
kind: VirtualMachineSnapshot
metadata:
  name: rhel9-test-pre-upgrade
  namespace: lab-vm
spec:
  source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: rhel9-test
EOF

# Lista
oc get vmsnapshot -n lab-vm

# Restore
oc apply -f - <<EOF
apiVersion: snapshot.kubevirt.io/v1beta1
kind: VirtualMachineRestore
metadata:
  name: rhel9-test-restore-1
  namespace: lab-vm
spec:
  target:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: rhel9-test
  virtualMachineSnapshotName: rhel9-test-pre-upgrade
EOF

⚠️ Snapshot ≠ backup. Vedi sezione 4.

3. Day 2 — Manutenzione, upgrade, patching

Mettere un nodo in manutenzione

Equivalente di “Maintenance Mode” su vSphere. In vSphere DRS sposta automaticamente le VM via vMotion. In OpenShift il flusso è:

# 1. Cordon: nessuna nuova VM/pod schedulato qui
oc adm cordon <nome-nodo>

# 2. Drain: live-migrate le VM, evict i pod
oc adm drain <nome-nodo> \
  --delete-emptydir-data \
  --ignore-daemonsets \
  --pod-selector=kubevirt.io=virt-launcher \
  --force

Per le VM, il drain triggera la live migration automatica verso altri nodi (se eligible).

C’è anche l’oggetto NodeMaintenance (richiede l’omonimo operator) che fa la stessa cosa in modo declarative:

apiVersion: nodemaintenance.medik8s.io/v1beta1
kind: NodeMaintenance
metadata:
  name: maintain-worker-01
spec:
  nodeName: worker-01.example.com
  reason: "Aggiornamento firmware NIC"

Quando hai finito:

oc adm uncordon <nome-nodo>
# oppure
oc delete nodemaintenance maintain-worker-01

Upgrade del cluster

Concettualmente: l’upgrade è “rolling” e gestito dal Cluster Version Operator. Drena un nodo, lo aggiorna (incluso il sistema operativo RHCOS), lo riporta su, passa al successivo. Le VM vengono live-migrate durante il drain.

# Vedere update disponibili
oc adm upgrade

# Avviare upgrade alla versione X
oc adm upgrade --to=4.20.5

# Stato durante l'upgrade
oc get clusterversion

Da console UI: Administration → Cluster Settings → Details → Update.

Upgrade dell’operator OpenShift Virtualization

L’operator si aggiorna separatamente dalla piattaforma OpenShift, tramite la sua subscription. Nei channel stable, l’aggiornamento è automatico una volta disponibile. È buona pratica:

fare l’upgrade di OpenShift prima;
poi consentire l’upgrade dell’operator Virtualization;
monitorare l’oggetto HyperConverged per il rollout.

Patching delle VM (non dei nodi)

Le VM contengono OS guest che vanno patchati come qualunque altro server: dnf update, yum update, apt upgrade, Windows Update. Niente di OpenShift-specifico. Le strade tipiche:

Ansible Automation Platform (consigliato per fleet di VM): playbook di patching schedulati, inventario dinamico via collection redhat.openshift_virtualization.
Image-based: ricrei l’immagine “golden” con le patch, fai roll-out delle VM dal nuovo template.
Tool tradizionali: Satellite, WSUS, ecc., dentro le VM.

4. Backup e Disaster Recovery

Snapshot vs Backup

	Snapshot	Backup
Dura giorni o settimane	❌ Sconsigliato	✅ Sì, anni se serve
Crash-consistent	Sì	Dipende
Application-consistent	Solo con qemu-ga + freeze	Sì, con agent
Sopravvive alla perdita del cluster	❌ No	✅ Sì (off-cluster)
Adatto per compliance	❌ No	✅ Sì

Lo snapshot è un punto di ripristino temporaneo, il backup è una copia che vive altrove.

Lo standard OADP

OADP (OpenShift API for Data Protection) è l’operator Red Hat ufficiale per il backup. Usa Velero sotto il cofano + plugin per VM (CSI snapshots, filesystem backup via Restic/Kopia).

Flusso tipico:

Installa OADP da OperatorHub.
Configura un DataProtectionApplication: object storage di destinazione (S3 / Azure Blob / GCS), credenziali, location di snapshot.
Definisci una Schedule con cron expression.
Crei oggetti Backup (manuali) o lasci che la Schedule li crei automaticamente.

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: vm-prod-daily
  namespace: openshift-adp
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
      - produzione-app
      - produzione-web
    snapshotVolumes: true
    ttl: 720h               # 30 giorni

Soluzioni partner (commerciali)

In molti scenari aziendali si usano soluzioni partner certificate, che hanno UI dedicate, ottimizzazioni specifiche per VM, retention/compliance avanzate, integrazione con sistemi tape e cloud:

Trilio for OpenShift — protezione dati nativa
Veeam Kasten K10 — uno dei leader del settore Kubernetes/VM
Portworx PX-Backup — integrato con storage Portworx
Veritas NetBackup — la scelta tipica per chi ha già NetBackup in casa
Commvault, Cohesity, Rubrik — anche loro hanno integrazione

Per la lista completa e certificata: Red Hat Ecosystem Catalog.

Disaster Recovery

Per DR multi-sito le strade principali:

Regional DR con ACM + ODF: Red Hat Advanced Cluster Management gestisce il fail-over di applicazioni e VM verso un cluster secondario, con replica dati a livello ODF/Ceph.
Replica a livello storage (NetApp SnapMirror, Pure ActiveDR, Dell PowerMax SRDF…) + ridichiarazione delle VM sul sito B.
Backup off-site + restore: per RTO non aggressivi, restore da backup OADP/partner sul sito secondario.

La scelta dipende da RTO/RPO richiesti, infrastruttura esistente e budget. Per applicazioni critiche con RPO ~zero, la combinazione ACM + ODF Regional DR è la più “Red Hat native”.

5. Sicurezza e compliance

Patching dei nodi

Su OpenShift il sistema operativo dei nodi è Red Hat CoreOS (RHCOS), un’immagine immutabile. Si aggiorna con il cluster via MachineConfigOperator: niente yum update sui nodi. È un cambio di mentalità: l’OS del nodo è gestito dal cluster, non dall’admin. È più sicuro (drift impossibile) ma richiede di fidarsi del processo di upgrade.

Hardening delle VM

Le pratiche di hardening sono identiche a quelle che già fai:

Patching guest OS (vedi sezione precedente)
Secure Boot + UEFI + vTPM (vedi modulo 5)
Cifratura dei dischi: a livello storage (es. encrypted PV su LUKS, OSD encryption in ODF) o dentro la VM (BitLocker, LUKS guest)
SSH/RDP solo dietro bastion, niente porte esposte direttamente
Network Policies in deny-by-default (vedi modulo 2)

Compliance del cluster

Per audit e compliance OpenShift offre:

Compliance Operator — scansiona il cluster contro profili come PCI-DSS, NIST, CIS Benchmark, e produce report.
File Integrity Operator — monitora l’integrità dei file su nodi RHCOS.
Audit log del Kubernetes API server, configurabili e forwardabili tramite ClusterLogForwarder.

6. Automazione: il “PowerCLI moderno”

Se in vSphere usavi PowerCLI per automatizzare, qui hai più strade, tutte basate sull’API Kubernetes. Tutte queste opzioni convivono — non sono alternative, spesso si combinano:

`oc` / `kubectl` + scripting

Per operazioni puntuali, scripting bash:

# Lista tutte le VM accese, formato CSV con namespace, nome, IP
oc get vmi -A -o jsonpath='{range .items[?(@.status.phase=="Running")]}{.metadata.namespace}{","}{.metadata.name}{","}{.status.interfaces[0].ipAddress}{"\n"}{end}'

Ansible + collection per OpenShift Virtualization

La collection ufficiale redhat.openshift_virtualization fornisce moduli per VM lifecycle:

- name: Crea una VM Linux
  hosts: localhost
  tasks:
    - name: Definisci la VM
      redhat.openshift_virtualization.kubevirt_vm:
        state: present
        name: rhel9-auto
        namespace: lab-vm
        cpu_cores: 2
        memory: 4Gi
        boot_source:
          source_pvc:
            name: rhel9
            namespace: openshift-virtualization-os-images
          size: 30Gi

Da Ansible Automation Platform puoi gestire tutto il fleet di VM in modo centralizzato.

GitOps con Argo CD

Il pattern che molti consigliano: VM definite in YAML, versionate in Git, applicate da Argo CD.

                Git (single source of truth)
                       │
                       ▼
                   Argo CD
                       │
           ┌───────────┼───────────┐
           ▼           ▼           ▼
       Cluster      Cluster      Cluster
        prod         dr           dev

Vantaggi: tracciabilità completa di chi ha cambiato cosa, rollback banale (git revert), DR (il cluster B può essere ricostruito in pochi minuti applicando il repo Git).

Esempio di manifest GitOps per Argo CD (semplificato):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: vm-produzione
  namespace: openshift-gitops
spec:
  source:
    repoURL: https://git.example.com/team/vm-definitions
    path: produzione
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

SDK Python e Go (kubernetes client)

Per integrazioni custom (es. tool interno di provisioning), gli SDK ufficiali Kubernetes funzionano con CRD KubeVirt. La libreria kubernetes (Python) e client-go (Go) sono il punto di partenza.

7. Migrare le VM da vSphere: MTV

Migration Toolkit for Virtualization (MTV) è lo strumento Red Hat ufficiale per portare VM da vSphere (o da Red Hat Virtualization, OpenStack, OVA) a OpenShift Virtualization.

Concetti MTV

Provider: una sorgente o destinazione (es. il tuo vCenter, oppure il cluster OpenShift).
NetworkMap: mappatura “questa rete vSphere → questa NetworkAttachmentDefinition OpenShift”.
StorageMap: mappatura “questo datastore vSphere → questa StorageClass OpenShift”.
Plan: l’insieme di VM da migrare, con riferimenti ai mapping.
Migration: l’esecuzione effettiva del plan.

Modalità di migrazione

Modalità	Come funziona	Downtime
Cold	VM spenta, dischi copiati, VM riaccesa su OpenShift	Tutto il tempo della copia
Warm	Pre-copia incrementale dei dischi mentre la VM è accesa, poi cutover finale corto	Solo il cutover (~minuti)

Per VM grandi o critiche: warm migration quasi sempre la scelta giusta. Tieni d’occhio la rete fra vCenter/ESXi e OpenShift: è dove passano i GB.

Workflow tipico

Installa l’operator MTV su OpenShift.
Configura il provider sorgente (vCenter URL, credenziali, certificato).
Configura il provider destinazione (di solito è “host”, il cluster OpenShift stesso).
Definisci NetworkMap e StorageMap.
Crea un Plan selezionando le VM da migrare.
Esegui il Plan — guarda lo stato dalla UI MTV.
Verifica le VM migrate (rete, IP, applicazioni).
Spegni le VM originali su vSphere.

💡 Consiglio operativo. Migra prima un piccolo gruppo di VM “non critiche” per validare il flusso, le mappature, il networking. Poi scala. Le sorprese vengono spesso da: NIC con MAC hardcodate nelle policy del firewall a monte, IP statici incompatibili con le subnet OpenShift, applicazioni che si aspettano di trovare un gateway con IP X.

8. Lab interattivi consigliati

Red Hat offre una serie di lab interattivi a cui puoi accedere senza dover montare un cluster: sono guidati, eseguibili dal browser, e gratuiti.

Quelli più rilevanti per chi viene da VMware:

Single Node OpenShift deployment con Assisted Installer
OpenShift Virtualization deploy via Assisted Installer
Kube Descheduler instance — configurazione guidata
Node Maintenance — workflow di messa in manutenzione
Manage and monitor VMs with ACM — gestione multi-cluster
Data protection — esempi con Trilio, Portworx, NetBackup
Regional Disaster Recovery con RHACM + ODF
Virtual infrastructure automation con Ansible

Li trovi tutti su redhat.com/en/interactive-labs (filtra “Virtualization”) e nella sezione Daily tasks del learning path Red Hat originale.

💡 Strategia di team: scegline 3–4, falli ognuno individualmente, poi mezza giornata di review collettiva con discussione delle differenze rispetto al modo di fare le stesse cose in vSphere.

Approfondimenti ufficiali

← Modulo 5 — Componenti delle VM | Avanti → Modulo 7 — Conclusione e next steps