Avevate scelto RHEV, la virtualizzazione made in Red Hat? Ricordate che nel vostro futuro ci saranno solo OpenShift… e KubeVirt!
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 15 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 3 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: cloudinitdiskSemplice, 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 3 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.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
