Volumes système avec Red Hat OpenShift ou Kubernetes en amont

Zusammenfassung: Cet article de la base de connaissances explique comment utiliser le référentiel Red Hat GitHub kubevirt-rawio-addon pour présenter des volumes système PowerMax à un environnement Red Hat OpenShift ou Upstream Kubernetes. ...

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Weisungen

Volumes système PowerMax

Les volumes système PowerMax sont de petits périphériques (généralement trois Mo) gravés à partir de disques dans PowerMax qui agissent comme des cibles SCSI pour les commandes Solutions Enabler. Les informations de configuration et d’état sont conservées dans un fichier de base de données hôte PowerMax, symapi_db.bin par défaut. Elle est connue sous le nom de base de données de configuration PowerMax. Elle réduit le nombre de requêtes de l’hôte sur les baies de stockage. Les volumes système doivent être des périphériques bruts afin que le système d’exploitation transmette simplement les commandes SCSI sans manipulation. Alors que les hôtes physiques fonctionnent toujours avec des volumes système (avec un système d’exploitation pris en charge), les hôtes virtuels sont limités à VMware à l’aide de mappages de périphériques bruts physiques (RDM), d’iSCSI dans l’invité sous Windows ou Linux, de NVMe/TCP dans l’invité sous Linux ou de périphériques d’intercommunication (carte réseau ou HBA). Cependant, seul VMware peut présenter un véritable appareil brut reconnu comme un volume système viable. D’autres solutions de virtualisation permettent à l’utilisateur de présenter les appareils comme « bruts », mais bloquent certaines commandes SCSI, empêchant ainsi leur utilisation en tant que volumes système. Solutions Enabler les étiquette en tant que volumes système, mais signale une erreur, comme indiqué ci-dessous.

En outre, si vous examinez les volumes système, ils affichent l’état « CLS » ou « closed ».

Par conséquent, vous ne pouvez pas passer les commandes SCSI nécessaires.

Pour tirer parti de cette solution, vous devez utiliser un protocole que Solutions Enabler prend en charge sur le système d’exploitation choisi. Reportez-vous à la documentation du produit.

Solution Red Hat GitHub

Dell a sollicité l’aide de Red Hat pour développer une solution de contournement pour les volumes système dans un environnement OpenShift pour certains de nos clients communs. À cette fin, ils ont créé une solution qui fonctionne à la fois pour OpenShift et Kubernetes en amont, avec de légères variations dans la mise en œuvre. Le dépôt GitHub s’appelle kubevirt-rawio-addon comme il se trouve ici : https://github.com/openshift-cnv/kubevirt-rawio-addon Le GitHub inclut un https://github.com/openshift-cnv/kubevirt-rawio-addon/blob/main/README.md readme.

Le module complémentaire permet d’installer plusieurs composants :

  • Modification des webhooks pour modifier les objets à la volée
  • Validation du webhook : un contrôle de sécurité spécifique à OpenShift
  • Configuration de la sécurité pour accorder des fonctionnalités privilégiées
  • Crochet de side-car 

Le side-car est un petit conteneur supplémentaire qui s’exécute avec le pod de la machine virtuelle et modifie la configuration de bas niveau de la machine virtuelle avant son démarrage. Il intercepte la configuration de la machine virtuelle générée par KubeVirt, trouve les disques annotés et définit rawio=yes. KubeVirt récupère ensuite le XML. L’architecture sous-jacente libvirt/QEMU prend en charge cela, mais ne l’expose pas, de sorte que cet ajustement mineur est nécessaire. Il est possible que KubeVirt expose cela à l’avenir, auquel cas la solution de contournement sera inutile.


  

Implémentation sur OpenShift

Le référentiel contient toutes les instructions d’implémentation de cette solution. Red Hat étant propriétaire de la solution, Dell recommande de suivre les instructions actuelles qui sont susceptibles d’être modifiées à l’avenir.  Dell ne mettra pas à jour l’article de la base de connaissances pour refléter ces modifications. Par courtoisie, nous fournissons les informations de base ci-dessous, mais nous encourageons les utilisateurs de cet article de la base de connaissances à les utiliser en même temps que le référentiel.

Comme indiqué, vous pouvez l’implémenter sur OpenShift ou Kubernetes en amont. Comme les étapes sont pour OpenShift, il y a quelques éléments à noter si vous faites Kubernetes en amont.

  • Si vous implémentez sur K8s vanille, vous devez avoir installé cert-manager. Si le pilote CSI PowerMax est installé, il est présent.
  • Si vous implémentez sur K8s vanille, vous avez besoin d’un espace de noms privilégié. Vous pouvez utiliser l’espace de nommage dans les scripts ou créer le vôtre, puis modifier les scripts.

Les deux scripts dont vous avez besoin pour l’implémentation se trouvent dans le dossier hack . Le rawio-setup.sh est le premier script et est le même pour les deux plates-formes, mais sachez qu’il repose sur l’espace de noms openshift-cnv qui n’est présent que sur OpenShift. Ajoutez l’espace de nommage ou créez-en un nouveau et modifiez le script pour K8s. Le script de création de machine virtuelle est propre à la plate-forme, mais utilise à nouveau l’espace de noms openshift-cnv. Pour OpenShift, c’est rawio-create-vm-openshift.sh. Les scripts sont conçus pour créer un environnement de test et devront être modifiés pour une configuration de production. En particulier, le script rawio-setup.sh crée un périphérique SCSI virtuel. Au lieu de cela, modifiez le script pour utiliser votre classe de stockage PowerMax. En outre, le script suppose un seul nœud pour la planification de la machine virtuelle. Modifiez-le pour l’autoriser à s’exécuter sur n’importe quel nœud de travail. Le script utilise un système d’exploitation Fedora pré-intégré.

Des exemples de scripts se trouvent dans la section Supplemental Content.

Étapes de base

N’oubliez pas que le CSI PowerMax ne peut pas créer un appareil inférieur à 50 Mo, même si vous demandez un volume système traditionnel de 3 Mo. Cela ne pose aucun problème.

Autres solutions de virtualisation

Aucune des solutions ci-dessous ne fonctionne avec ce référentiel Red Hat.

  • Solutions basées sur K8s telles que SUSE Harvester - SUSE doit développer sa propre solution
  • Les solutions KVM telles que Proxmox ou Oracle KVM (oVirt) ne sont pas basées sur KubeVirt et ne peuvent pas être utilisées



 

Weitere Informationen

rawio-setup.sh

 

#!/bin/bash

 

set -euo pipefail

 

if [ -z « ${KUBEVIRT_NAMESPACE :-} » ] ; Puis
  if kubectl get ns openshift-cnv &>/dev/null ; then
    NAMESPACE="openshift-cnv »
  Autre
    NAMESPACE="kubevirt »
  fi
Autre
  NAMESPACE="$KUBEVIRT_NAMESPACE »
fi

 

PVC_NAMESPACE="${PVC_NAMESPACE :-default} »
SC_NAME="powermax-2164-default »
PVC_NAME="scsi-rawio-pvc »

 

# Créer un espace de nommage s’il n’existe pas
kubectl get ns « $PVC_NAMESPACE » >/dev/null 2>&1 || kubectl create ns « $PVC_NAMESPACE »

 

# Créer du PVC
echo « Création d’un PVC $PVC_NAME dans l’espace de nommage $PVC_NAMESPACE... »

 

kubectl apply -f - <<EOF
apiVersion : v1
Genre: Revendication de volume persistant
Métadonnées:
  name : $PVC_NAME
  Noms: $PVC_ESPACE DE NOMMAGE
Spec:
  storageClassName : $SC_NAME
  volumeMode : Bloqué
  accessModes :
    - ReadWriteOnce (en anglais seulement)
  Ressources:
    Requêtes:
      Stockage: 8Mi
EOF

 

echo «  »
echo « === Setup complete === »
echo "StorageClass :   $SC_NAME"
echo "PVC :            $PVC_ESPACE DE NOMMAGE/$PVC_NAME"
echo «  »
 

*******************************************

rawio-create-vm-openshift.sh

 

#!/bin/bash

 

set -euo pipefail

 

PVC_NAMESPACE="${PVC_NAMESPACE :-default} »
PVC_NAME="${PVC_NAME :-scsi-rawio-pvc} »
VM_NAME="${VM_NAME :-rawio-test-vm} »
VM_SA="${VM_SA :-rawio-vm} »
CONTAINER_DISK="${CONTAINER_DISK :-quay.io/kubevirt/fedora-with-testtooling :v20240717-a087e7e} »
SCC_NAME="${SCC_NAME :-rawio-vm} »
KUBEVIRT_NAMESPACE="openshift-cnv »

 

echo « Création d’un compte de service $VM_SA dans l’espace de nommage $PVC_NAMESPACE »

 

kubectl apply -f - <<EOF
apiVersion : v1
Genre: Compte de service
Métadonnées:
  name : $VM_SA
  Noms: $PVC_ESPACE DE NOMMAGE
EOF

 

echo « Création de SCC $SCC_NAME pour le compte de service $VM_SA »

 

kubectl apply -f - <<EOF
apiVersion : security.openshift.io/v1
Genre: Contraintes de contexte de sécurité
Métadonnées:
  name : $SCC_NAME
Priorité: 11
allowPrivilegedContainer : false
allowHostDirVolumePlugin : true
allowHostNetwork : false
allowHostPorts : false
allowHostPID : false
allowHostIPC : false
allowedCapabilities :
  - NET_BIND_SERVICE
  - SYS_NICE
  - SYS_RAWIO
  - SETFCAP (en anglais seulement)
defaultAddCapabilities : []
seccompProfiles :
  - runtime/par défaut
  -Unconfined
  - localhost/kubevirt/kubevirt.json
Volumes:
  - "*"
readOnlyRootFilesystem : false
runAsUser :
  type : RunAsAny
seLinuxContext :
  type : RunAsAny
fsGroup :
  type : RunAsAny
supplementalGroups :
  type : RunAsAny
Utilisateurs:
  - Système :ServiceAccount :${PVC_NAMESPACE} :${VM_SA}
groups : []
EOF

 

echo « Création d’une machine virtuelle $VM_NAME dans l’espace de nommage $PVC_NAMESPACE »
echo "PVC :               $PVC_NAME"
echo "ServiceAccount :    $VM_SA"
echo "Container disk :    $CONTAINER_DISK"

 

kubectl apply -f - <<EOF
apiVersion : kubevirt.io/v1
Genre: VirtualMachine
Métadonnées:
  name : $VM_NAME
  Noms: $PVC_ESPACE DE NOMMAGE
  Annotations:
    kubevirt.io/rawioSupport : « lun0 »
Spec:
  En cours d’exécution : true
  Modèle:
    Métadonnées:
      Annotations:
        kubevirt.io/rawioSupport : « lun0 »
    Spec:
      Domaine:
        Cpu:
          Noyaux: 2
        Ressources:
          Requêtes:
            Mémoire: 2Gi
        Dispositifs:
          Rng: {}
          Disques:
            - Nom : disk0
              Disque:
                Bus : Virtio
            - Nom : LUN0
              LUN :
                Bus : SCSI
            -Nom: $VM_SA
              Disque:
                Bus : Virtio
      Volumes:
        - Nom : disk0
          containerDisk :
            Image: $CONTAINER_DISK
        - Nom : LUN0
          persistentVolumeClaim :
            nom_de_la_demande : $PVC_NAME
        -Nom: $VM_SA
          serviceAccount :
            serviceAccountName : $VM_SA
EOF

 

echo «  »
echo "VM $VM_NAME created. J’attends que ça commence...
echo « Watch with : kubectl get vmi -n $PVC_NAMESPACE $VM_NAME -w »
echo "Console :    virtctl console -n $PVC_NAMESPACE $VM_NAME"
echo «  »
echo « Nettoyage : »
echo " kubectl delete vm -n $PVC_NAMESPACE $VM_NAME »
echo " kubectl delete scc $SCC_NAME »

Betroffene Produkte

PowerMax, PowerMax, PowerMax 2000, PowerMax 2500, PowerMax 8000, PowerMax 8500, PowerMaxOS 10
Artikeleigenschaften
Artikelnummer: 000472526
Artikeltyp: How To
Zuletzt geändert: 03 Juni 2026
Version:  1
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.