Modulo 5 — Componenti delle VM

⏱ Tempo di lettura: ~10 minuti 🎯 Obiettivo: capire come si compone “internamente” una VM in OpenShift Virtualization rispetto a una VM vSphere — driver, agent, controller, vNIC, snapshot, clone, tag.

Punto di partenza: l’anatomia di una VM vSphere

Quando crei una VM in vSphere, di fatto stai assemblando un set di componenti virtuali che imitano un PC fisico:

• una CPU virtuale (con un numero di socket/core);
• una RAM virtuale;
• un controller SCSI/SATA/NVMe virtuale per i dischi;
• uno o più dischi virtuali (.vmdk);
• una o più vNIC (VMXNET3, E1000, ecc.);
• VMware Tools installato nel guest, che fornisce drivers paravirtualizzati e agent;
• tag e custom attributes per organizzare l’inventario.

Tutto questo è descritto in un file .vmx e gestito da vCenter.

In OpenShift Virtualization l’anatomia è simile, ma tutto è descritto in YAML come oggetto VirtualMachine (e a runtime diventa una VirtualMachineInstance, gestita da virt-launcher).

Tabella di mapping dei componenti VM

Componente vSphere	Equivalente OpenShift Virtualization
VMware Tools (agent + driver paravirtuali)	QEMU Guest Agent (qemu-ga) + driver virtio
VM dump (snapshot della memoria)	virtctl memory-dump
VM cloning	Clone CSI + oc patch / DataVolume source clone
Tag e custom attributes	Label e annotation Kubernetes
vNIC: VMXNET3, E1000, E1000e, SR-IOV	virtio-net (paravirtuale), e1000e (legacy), SR-IOV
Controller SCSI: PVSCSI, LSI Logic SAS, BusLogic	virtio-scsi (paravirtuale), SCSI, SATA
Controller NVMe	virtio-blk o NVMe
vBIOS / UEFI	SeaBIOS / OVMF (UEFI), con o senza Secure Boot
vTPM	vTPM (basato su swtpm)

QEMU Guest Agent: il “VMware Tools” di OpenShift Virtualization

Il QEMU Guest Agent è il componente paragonabile a VMware Tools: gira dentro la VM e dialoga con l’hypervisor tramite un canale virtio dedicato. Dà capacità come:

• Quiesce filesystem durante uno snapshot (per snapshot consistenti, equivalente del quiesce con VSS di Tools);
• Get IP e altri dati di inventory dal guest;
• Set hostname, gestione utenti via SSH, esecuzione comandi pre/post freeze;
• Graceful shutdown della VM (equivalente del power-off “soft” di vSphere).

L’installazione è semplicissima:

# Su RHEL / Fedora / CentOS Stream / Rocky / Alma
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

# Su Debian / Ubuntu
sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Su Windows il pacchetto è incluso nelle virtio-win drivers (ISO scaricabile dal Red Hat repository) — installa l’MSI dell’agent insieme ai driver paravirtuali.

💡 Senza QEMU Guest Agent una VM funziona, ma perdi feature. OpenShift non vedrà l’IP guest, il backup non sarà consistente, il free-page-reporting per l’overcommit RAM non funzionerà, e la dashboard mostrerà la VM “running but agent not connected”. Considera l’installazione obbligatoria, esattamente come fai con VMware Tools.

Driver virtio: il “paravirt” di KVM

Esattamente come VMXNET3/PVSCSI sono i driver paravirtualizzati VMware (più veloci dei loro corrispettivi hardware emulati), virtio è la famiglia di driver paravirtualizzati di KVM. È sviluppato come standard aperto e implementato a livello di kernel Linux mainline.

I principali:

Driver virtio	A cosa serve	Equivalente vSphere
virtio-net	NIC paravirtuale	VMXNET3
virtio-blk	Disk paravirtuale (a singolo dispositivo)	LSI Logic SAS / PVSCSI
virtio-scsi	Controller SCSI paravirtuale (più dischi su un controller)	PVSCSI
virtio-balloon	Balloon driver per memory reclamation	Balloon driver vSphere
virtio-rng	Sorgente di entropia paravirtuale	—
virtio-mem	Hot-plug RAM paravirtuale	Hot-add RAM vSphere

Per le VM Linux moderne (RHEL 7+, Ubuntu 18+, Debian 10+) i driver virtio sono già nel kernel: la VM li usa senza intervento.

Per Windows servono i virtio-win drivers, distribuiti come ISO. Le VM Windows in OpenShift Virtualization vanno create avendo cura di:

1. presentare l’ISO virtio-win al primo boot, oppure
2. usare un’immagine sysprep che li ha già installati, oppure
3. lasciar fare al “Windows Driver Update” via il template Windows fornito da Red Hat (consigliato: il template parte da una immagine sysprep con i driver già pronti).

NIC: virtio-net come default sensato

Per le NIC, in OpenShift Virtualization le opzioni più comuni sono:

• virtio (virtio-net) — la default. Best performance, supporto ampio. Richiede driver virtio nel guest.
• e1000e — emulazione di una vera NIC Intel. Supportato out-of-the-box praticamente da ogni OS, inclusi Windows non aggiornati. Performance inferiori a virtio.
• SR-IOV — passthrough di Virtual Function di una NIC fisica. Massima performance, ma vincola la VM a un nodo che ha quella NIC e disabilita la live migration in molti casi. Da usare solo per workload latency-sensitive (NFV, telco).

In pratica: virtio per tutto, e1000e per legacy, SR-IOV solo per casi specifici. Stesso ragionamento che facevi in vSphere.

Controller di storage

Per i dischi:

• virtio-blk — disk singolo, controller dedicato. Buona performance, semplice.
• virtio-scsi — controller SCSI paravirtuale: un controller, tanti dischi (consigliato per VM con molti dischi).
• SATA — emulazione SATA, utile come fallback per OS che non supportano virtio (raro oggi).
• SCSI — emulazione SCSI legacy.

Nelle VM definite via UI o tramite template, OpenShift sceglie spesso virtio di default sui dischi root e SCSI/SATA come secondario per CD-ROM (es. ISO di installazione).

Esempio YAML con un disco root virtio + un disco dati virtio-scsi:

spec:
  template:
    spec:
      domain:
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
            - name: datadisk
              disk:
                bus: scsi

VM clone: come si fa davvero

Tre modi principali di clonare:

1. Clone tramite DataVolume (CSI offload se supportato)

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: web02-root
spec:
  source:
    pvc:
      namespace: produzione-web
      name: web01-root            # ← PVC sorgente
  storage:
    resources:
      requests:
        storage: 50Gi
    storageClassName: ocs-storagecluster-ceph-rbd

Se il driver CSI supporta clone offload (Ceph, NetApp, Pure, vSphere CSI…), questa operazione è quasi istantanea: viene fatta dal backend storage senza copiare byte attraverso la rete. È l’equivalente del clone accelerato VAAI di vSphere.

2. Clone tramite VolumeSnapshot

Crei una snapshot del volume e poi un nuovo PVC dalla snapshot. Pattern utile quando vuoi clonare “uno stato passato” della VM, non lo stato corrente.

3. Clone via UI / virtctl

Per uso interattivo:

# Clone con virtctl (semplificato)
virtctl clone vm web01 --target-name web02 -n produzione-web

Snapshot della memoria (memory dump)

L’equivalente di “snapshot VM con memoria” si fa con:

virtctl memory-dump get web01 \
  --claim-name=web01-memdump-pvc \
  --create-claim

Crea un PVC con il dump della memoria della VM, utile per analisi forense o debugging di problemi specifici. È diverso dal VirtualMachineSnapshot, che salva lo stato dei dischi: qui salvi la RAM.

Tag e custom attributes → label e annotation

In vSphere usi tag e custom attributes per organizzare l’inventario (“ambiente: produzione”, “owner: team-pagamenti”, “compliance: PCI”). In OpenShift gli equivalenti naturali sono:

• Label → metadati query-abili, usati anche dallo scheduler e dalle NetworkPolicy
• Annotation → metadati informativi (più lunghi, non query-abili nei selector)

metadata:
  name: web01
  labels:
    ambiente: produzione
    team: pagamenti
    compliance: pci
    app: api-gateway
  annotations:
    description: "Web frontend cluster Milano - VM principale"
    owner-email: pagamenti@example.com
    cmdb-id: "VM-78234"

Le label diventano potentissime: puoi scrivere query come “tutte le VM team=pagamenti in ambiente=produzione”, filtrare dashboard, applicare NetworkPolicy. È il vero superpotere della virtualizzazione “Kubernetes-native”.

BIOS, UEFI, Secure Boot, vTPM

OpenShift Virtualization supporta sia SeaBIOS (legacy BIOS) che OVMF (UEFI). Per le VM moderne (Windows 11, RHEL 9 con secure boot…) UEFI è la scelta giusta:

spec:
  template:
    spec:
      domain:
        firmware:
          bootloader:
            efi:
              secureBoot: true
        features:
          smm:
            enabled: true            # richiesto da Secure Boot

Per la vTPM (necessaria a Windows 11 e a configurazioni BitLocker):

spec:
  template:
    spec:
      domain:
        devices:
          tpm: {}

Differenze chiave da tenere a mente

1. VMware Tools → QEMU Guest Agent, da installare sempre nelle VM. Niente agent = funzionalità ridotte.
2. Driver paravirtuali (virtio) sono lo standard. Per Windows servono virtio-win drivers, gestiti tramite ISO o template predisposti.
3. Tag → label: investi tempo a definire una buona tassonomia di label dal giorno 1, ti tornerà utile per scheduler, policy, dashboard.
4. Memory dump è un’operazione esplicita e separata dalle snapshot.
5. UEFI + Secure Boot + vTPM sono supportati e configurabili in modo dichiarativo: pratiche di hardening più semplici da industrializzare.

Best practice operative

• Template Red Hat per Windows e RHEL: parti da quelli ufficiali, non costruirti il tuo da zero. Hanno già driver virtio, qemu-ga, e ottimizzazioni.
• Convenzione di label aziendale: app, team, ambiente, criticita, compliance. Documentala una volta, applicala ovunque.
• Cloud-init / sysprep per personalizzare le VM al primo boot (hostname, utenti, chiavi SSH, configurazioni di rete). Equivalente delle “VM customization specifications” di vCenter.
• Test del clone offload sul tuo storage di destinazione prima di standardizzarlo: alcune StorageClass clonano in pochi secondi, altre in minuti se non c’è offload CSI.

Approfondimenti ufficiali

• Installing the QEMU guest agent
• VM cloning
• Memory dump comandi
• virtio-win drivers per Windows

---

← Modulo 4 — Observability | Avanti → Modulo 6 — Operazioni quotidiane