VMware et licences Oracle : les 5 pièges à éviter absolument

Quand vous virtualisez Oracle sous VMware, la règle de licensing change du tout au tout. Beaucoup de DBA et d'administrateurs VMware le découvrent au moment d'un audit LMS — et la facture est salée. Voici les 5 pièges les plus fréquents que je rencontre chez mes clients.

Piège n°1 : compter les cœurs VMware au lieu des cœurs physiques

C'est l'erreur numéro un. Oracle ne reconnaît pas le soft partitioning de VMware. Peu importe le nombre de vCPU alloués à votre VM Oracle : Oracle considère tous les cœurs physiques du ou des hôtes où la VM est susceptible de tourner.

-- Exemple : hôte avec 2 sockets × 16 cœurs = 32 cœurs physiques
-- VM Oracle avec 4 vCPU
-- Oracle facture : 32 cœurs × facteur de licence, PAS 4

En cluster vSphere avec DRS activé, une VM Oracle peut théoriquement migrer sur n'importe quel hôte du cluster. Oracle considère alors tous les cœurs de tous les hôtes du cluster. Avec 4 hôtes de 32 cœurs, vous payez 128 cœurs même si votre VM n'en utilise que 4.

Ce qu'il faut faire : utiliser des DRS Rules (VM-VM Affinity) pour contraindre les VMs Oracle à un sous-ensemble d'hôtes, et documenter cette configuration pour l'audit.

Piège n°2 : ne pas activer le core factor

Sur VMware, Oracle applique un core factor de 0,5 pour les processeurs Intel/AMD. Cela signifie que 2 cœurs physiques comptent pour 1 licence.

Mon client pensait payer 32 licences pour son hôte 32 cœurs. En réalité, avec le core factor : 32 × 0,5 = 16 licences.

Mais attention : le core factor ne s'applique pas si Oracle ne reconnaît pas votre CPU comme éligible. Vérifiez la liste officielle des processeurs éligibles au core factor sur le site Oracle.

Piège n°3 : utiliser DRS sans exclusion

Le Dynamic Resource Scheduler de VMware déplace automatiquement les VMs pour équilibrer la charge. Si votre VM Oracle se déplace sur un hôte non licencié, vous êtes en infraction immédiate.

Hôte A (licencié Oracle)    ← VM Oracle initialement ici
Hôte B (NON licencié)       ← DRS déplace la VM → INFRACTION

Solution : créez un DRS Rule de type "Must run on hosts in group" avec un groupe d'hôtes dédié aux VMs Oracle. Désactivez DRS pour ce groupe ou mettez-le en "Manual".

Piège n°4 : oublier le vMotion manuel

Même avec DRS bien configuré, un administrateur peut faire un vMotion manuel vers un hôte non licencié pour une opération de maintenance. Si l'audit tombe à ce moment-là, c'est vous qui êtes responsable.

Procédure à mettre en place :

• Interdire le vMotion manuel des VMs Oracle sans validation DBA
• Tenir un registre des déplacements de VMs Oracle
• Utiliser Host Affinity Rules plutôt que la bonne volonté des équipes

Piège n°5 : ne pas documenter sa configuration VMware

Le plus gros risque n'est pas technique, c'est documentaire. Lors d'un audit LMS, si vous ne pouvez pas prouver que votre configuration empêche le déplacement des VMs Oracle, Oracle part du principe que tout le cluster est consommé.

La règle Oracle est simple : "soft partitioning is not permitted unless you can prove otherwise".

Checklist de documentation pour l'audit :

• [ ] Capture des DRS Rules applicables aux VMs Oracle
• [ ] Host groups vSphere avec leurs membres
• [ ] Preuve que les VMs Oracle n'ont jamais quitté leurs hôtes autorisés (logs vCenter)
• [ ] Contrat de maintenance à jour avec le core factor appliqué
• [ ] Schéma d'infrastructure signé par le DBA et le responsable infrastructure

À retenir : VMware ne vous protège pas du licensing Oracle par défaut. Ce n'est pas une question de "si" vous serez audité, mais de "quand". La documentation est aussi importante que la configuration technique.