OpenShift Virtualization vs VMware : Guide stratégique de migration

INTRODUCTION

Face aux incertitudes liées aux licences des hyperviseurs classiques comme VMware, de nombreux DSI explorent des alternatives. OpenShift Virtualization (basé sur KubeVirt) permet de faire converger les machines virtuelles et les conteneurs sur une seule plateforme Kubernetes. Ce guide technique vous aide à évaluer l'éligibilité de vos charges de travail et à planifier une migration sans interruption de service.

Prérequis

Cluster : OpenShift Container Platform (OCP) version 4.12+ recommandé.
Accès : Droits cluster-admin pour installer les opérateurs.
Stockage : Une StorageClass compatible RWX/RWO (ex: ODF, NFS, ou CSI compatible).
Réseau : Multus CNI configuré pour le pontage vers les réseaux VLAN existants.
CLI : oc et virtctl installés sur le poste d'administration.

Tutoriel pas à pas : Analyse et Activation

1. Grille de comparaison fonctionnelle

Avant de migrer, il est essentiel de comprendre les correspondances techniques.

Fonctionnalité	VMware vSphere	OpenShift Virtualization (KubeVirt)
Unité de base	VM (vmx)	VirtualMachine (CRD Kubernetes)
Live Migration	vMotion	Live Migration (KubeVirt)
Haute Dispo	VMware HA	Pod Eviction + ReplicaSet logic
Réseau	vSwitch / NSX	Pod Network + Multus (Bridge/SR-IOV)
Stockage	VMFS / vSAN	PV / PVC (CSI Driver)

2. Arbre de décision pour l'éligibilité (Mermaid)

Utilisez ce schéma pour décider quelles VMs migrer.

📊 Chargement du diagramme...

3. Installation de l'Opérateur

Pour activer la virtualisation, nous installons l'opérateur OpenShift Virtualization. Créez un fichier subscription.yaml.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  channel: stable

Appliquez la configuration :

oc new-project openshift-cnv
oc apply -f subscription.yaml

# NOTE: Attendre que le CSV soit installé avant de créer l'instance HyperConverged

4. Déploiement d'une VM de test

Voici un exemple de manifeste pour une VM Linux simple.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME_PLACEHOLDER
  namespace: TARGET_NAMESPACE
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
        resources:
          requests:
            memory: 2Gi
      volumes:
        - name: containerdisk
          containerDisk:
            image: REGISTRY_URL/fedora-cloud-container-disk:latest
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |-
              #cloud-config
              password: YOUR_SECURE_PASSWORD
              chpasswd: { expire: False }

Performance / Coûts 💸

Overhead CPU : KubeVirt ajoute une légère surcharge (processus qemu-kvm encapsulé dans un pod). Comptez environ 3 à 5% de perte par rapport au bare-metal, comparable à ESXi.
Modèle de coûts : Contrairement aux licences par socket/cœur de plus en plus onéreuses, OpenShift se licencie souvent au worker node (ou vCPU). La consolidation (VMs + Conteneurs sur les mêmes nœuds) permet de maximiser l'utilisation du matériel et de réduire le TCO global.
Économie de RAM : Kubernetes gère l'overcommitment de mémoire différemment (Request/Limit). Soyez vigilants sur le Swap qui n'est pas géré nativement comme sur ESXi.

Sécurité 🔐

Isolation sVirt : Chaque VM tourne dans un Pod, isolée par SELinux (sVirt). C'est une double couche de sécurité (Hyperviseur + Conteneur).
NetworkPolicies : Appliquez des politiques réseau Kubernetes standard pour restreindre le trafic entre vos VMs, chose complexe à faire avec des VLANs traditionnels.
Privilèges : Évitez de donner des droits root sur les nœuds aux conteneurs virt-launcher. Utilisez les SCC (Security Context Constraints) par défaut.

Observability 📈

OpenShift intègre nativement les métriques de virtualisation.

Console Web : Une vue dédiée "Virtualization" permet de voir le CPU, la RAM et les IOPS par VM.
Prometheus : Les métriques sont exposées via kubevirt_vm_resource_usage_cpu_cores. Exemple de requête PromQL pour la conso CPU :

rate(kubevirt_vmi_cpu_usage_seconds_total{name="VM_NAME_PLACEHOLDER"}[5m])

Tests / Validation ✅

Linting : Validez vos fichiers YAML avec kubeconform avant déploiement.
Dry-run : Utilisez le Migration Toolkit for Virtualization (MTV) en mode "analyse" pour détecter les incompatibilités (ex: CPU passthrough, disques partagés) sans lancer la migration réelle.
Smoke Test : Vérifiez l'accès console via virtctl console VM_NAME_PLACEHOLDER.

Rollback / Plan B ↩️

Si la migration d'une VM critique échoue :

Ne supprimez pas la VM source sur VMware immédiatement.
Arrêtez la VM sur OpenShift (running: false).
Réactivez la carte réseau de la VM sur vSphere.
Analysez les logs du pod virt-launcher pour comprendre l'échec (souvent lié au stockage ou au réseau).

Erreurs fréquentes & diagnostics

Symptôme : La VM reste en statut Scheduling.
- Cause : Pas assez de ressources ou manque de PVC compatible RWX pour la Live Migration.
- Solution : Vérifiez oc describe vm VM_NAME et assurez-vous que la StorageClass supporte le mode d'accès requis.
Symptôme : Perte de connectivité réseau.
- Cause : Le NetworkAttachmentDefinition (Multus) est mal configuré ou le VLAN n'est pas tagué sur le port du nœud.
- Solution : Testez la connectivité depuis un pod debug sur le même réseau secondaire.

Checklist de mise en prod

L'opérateur OpenShift Virtualization est à jour et sain.
Une StorageClass par défaut performante est définie.
Les NetworkAttachmentDefinitions (VLANs) sont créés et testés.
La stratégie de sauvegarde (ex: Velero ou OADP) inclut les PVs des VMs.
Les limites de ressources (Quotas) sont définies pour le namespace.
Les utilisateurs ont les rôles RBAC appropriés (ex: ne pas pouvoir supprimer les VMs).

FAQ

Q1. Peut-on faire tourner Windows sur OpenShift Virtualization ? R: Oui, Windows Server 2012R2, 2016, 2019 et 2022 sont pleinement supportés. Les drivers virtio (Windows Guest Tools) doivent être installés pour la performance.

Q2. La Live Migration fonctionne-t-elle comme vMotion ? R: Oui, mais elle nécessite un stockage partagé (RWX) et une configuration réseau correcte. Il peut y avoir une micro-coupure, généralement imperceptible pour l'application.

Conclusion

La bascule de VMware vers OpenShift Virtualization est une opportunité de moderniser votre dette technique tout en maîtrisant vos coûts. En traitant les VMs comme des objets Kubernetes, vous unifiez vos opérations. Commencez par migrer les environnements de développement pour valider la chaîne d'outils avec le Migration Toolkit.