La notizia che raccontiamo oggi potrebbe sembrare un semplice annuncio relativo alla dismissione di un prodotto da parte di un’azienda, ma in realtà ha un’importanza rilevante per tutto il mercato IT, specificamente per quanto riguarda l’ambito della virtualizzazione.

Il prossimo 31 agosto RHEV (Red Hat Enterprise Virtualization) entrerà nella fase Extended Life Phase, per essere poi definitivamente dismesso il 31 agosto 2026. Nella pratica significa che per il prodotto, che per più di quindici anni è stato alla base dell’offerta di virtualizzazione open-source di Red Hat (leggasi concorrente di VMWare), da qui al 2026 verranno forniti solo aggiornamenti critici e patch di sicurezza importanti.

Anche il supporto tecnico verrà limitato a determinate opzioni, vedi Knowledge Base e documentazione. Il tutto è spiegato in un articolo riservato ai clienti Red Hat, ma la sostanza è chiarissima: il prodotto RHEV andrà a morire.

Si capisce come questa non sia propriamente una breaking news, ma qualcosa che si sapeva da tempo (se ne parla dal 2022), sebbene proprio in questi giorni stiano circolando mail per tutti i clienti Red Hat che ricordano quanto succederà a breve, facendo riferimento alla pagina Red Hat Virtualization Lifecycle dove, per l’appunto, vengono indicate le tempistiche di cui abbiamo parlato.

Ora, perché questa situazione ha una rilevanza importante non solo per i clienti Red Hat, ma per tutto il mondo open-source? Per capirlo basta mettersi nei panni di qualcuno, diciamo Gino il sysadmin©, che solamente tre anni fa ha scelto di implementare nei propri datacenter il prodotto RHEV: ci sarebbe poco da stare allegri.

Per Gino il sysadmin© RHEV rappresentava una scelta coraggiosa rispetto alle controparti commerciali oltre che per il costo (nettamente più basso rispetto a VMWare) anche per la sua natura open-source. Se è vero in fatti che, in teoria, qualche alternativa open-source/commerciale esiste (vedi Proxmox o Xen), RHEV essendo promossa e sponsorizzata da Red Hat poteva davvero sembrare un porto felice supportato da una solida, solidissima, realtà di classe enterprise.

L’annuncio della sua dismissione è (stato) un brutto colpo per Gino il sysadmin© e l’open-source poiché si fa un gran parlare di open-source come scelta per evitare il vendor lock-in (ossia il rimanere vincolati ad un fornitore), ma all’atto pratico tornando a quanti hanno scelto RHEV come strategia di virtualizzazione a lungo termine anni fa, il passaggio ad un sistema alternativo comporterà pianto e stridore di denti.

Perché? Perché RHEV, che è (era) basato sul progetto open-source oVirt, ha (aveva) il “suo” modo di gestire le VM. Che è diverso da quello di VMWare, che è diverso da quello di Proxmox, che è diverso da quello di Xen, che è diverso persino dall’utilizzo di KVM in maniera nuda e cruda, magari mediante libvirt. Non che sia impossibile migrare, sia chiaro, ma solo a pensare di organizzare una strategia per l’export e l’import di centinaia, magari migliaia di macchine virtuali beh, viene un gran mal di testa.

Red Hat sin dalla pubblicazione della dismissione di RHEV ha reso chiaro che questo verrà dismesso in virtù di un altro prodotto, che però all’apparenza non c’entra nulla: OpenShift.

Ora, come è possibile che una distribuzione di Kubernetes (perché OpenShift è esattamente questo), ossia una piattaforma per la container orchestration, possa essere considerata un’alternativa ad un ambiente di virtualizzazione? Lo sanno anche i sassi, un container non è una macchina virtuale. Allora perché OpenShift? La risposta risiede in un nome: KubeVirt.

KubeVirt, che è integrato in OpenShift, offre la possibilità di eseguire macchine virtuali all’interno di un cluster Kubernetes, estendendo le capacità di orchestrazione di Kubernetes per includere anche la gestione delle risorse delle Virtual Machine. Utilizza delle Custom Resource di Kubernetes per definire le specifiche delle macchine virtuali e integra le funzionalità di rete e storage di Kubernetes per la connettività e la persistenza dei dati delle VM.

Le VM vengono sempre e comunque eseguite utilizzando un hypervisor come KVM, consentendo di combinare le prestazioni e l’isolamento delle VMs con la flessibilità e la scalabilità di Kubernetes, ma di fatto saranno dichiarate come segue:

piVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  annotations:
    vm.kubevirt.io/flavor: tiny
    vm.kubevirt.io/os: rhel8
    vm.kubevirt.io/validations: | 
      [ 
        { 
          "name": "minimal-required-memory",
          "path": "jsonpath::.spec.domain.resources.requests.memory",
          "rule": "integer",
          "message": "This VM requires more memory.",
          "min": 1610612736
        } 
      ] 
    vm.kubevirt.io/workload: server
  labels:
    app: rheltinyvm
    vm.kubevirt.io/template: rhel8-server-tiny
    vm.kubevirt.io/template.revision: "45"
    vm.kubevirt.io/template.version: 0.11.3
  name: rheltinyvm
spec:
  dataVolumeTemplates:
  - apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: rheltinyvm
    spec:
      pvc:
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 30Gi
      source:
        pvc:
          name: rhel
          namespace: kubevirt
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/domain: rheltinyvm
        kubevirt.io/size: tiny
    spec:
      domain:
        cpu:
          cores: 1 
          sockets: 1 
          threads: 1 
        devices:
          disks:
          - disk:
              bus: virtio
            name: rheltinyvm
          - disk:
              bus: virtio
            name: cloudinitdisk
          interfaces:
          - masquerade: {}
            name: default
          networkInterfaceMultiqueue: true
          rng: {}
        resources:
          requests:
            memory: 1.5Gi
      networks:
      - name: default
        pod: {}
      terminationGracePeriodSeconds: 180
      volumes:
      - dataVolume:
          name: rheltinyvm
        name: rheltinyvm
      - cloudInitNoCloud:
          userData: |-
            #cloud-config
            user: cloud-user
            password: lymp-fda4-m1cv
            chpasswd: { expire: False }
        name: cloudinitdisk

Semplice, no?

Certo, occorrerà imparare a gestire le cose, e se già nel 2022 Red Hat diceva che la OpenShift virtualization era “Not as scary as it seems” (non così spaventosa), c’è da scommettere come nel frattempo le cose si saranno già evolute e, probabilmente, partire da zero sarà abbastanza semplice.

Con un piccolo dettaglio, tolti i worker node (ossia dove le VM venivano lanciate), per far girare RHEV bastava una VM con almeno una CPU dual core ed almeno 4GB di RAM, mentre per far girare OpenShift, tolti nuovamente i worker nodes, sono necessarie tre macchine, con almeno 4 CPU ed almeno 16GB di RAM.

Oppure è chiaro, si va sul cloud, perché lì è tutto più semplice, giusto?

Tornando invece a Gino il sysadmin© di cui parlavamo sopra, beh, lì è tutta un’altra cosa. Probabilmente il suo pensiero potrebbe essere “open-source? Mai più.”.

Perché, alla fine, è una questione di fiducia. Quanto l’enterprise sentirà di potersi fidare dell’open-source a fronte di scelte come queste?

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.