layout: doc description: Create storage repositories for use in your XenServer environment.—

Création d’un référentiel de stockage

Vous pouvez utiliser l’assistant de création de nouveaux référentiels de stockage dans XenCenter pour créer des référentiels de stockage (SR). L’assistant vous guide tout au long des étapes de configuration. Vous pouvez également utiliser l’interface de ligne de commande et la commande sr-create. La commande sr-create crée un SR sur le substrat de stockage (pouvant détruire toutes les données existantes). Il crée également l’objet API SR et un enregistrement PBD correspondant, ce qui permet aux machines virtuelles d’utiliser le stockage. Lors de la création réussie du SR, le PBD est automatiquement branché. Si l’indicateur shared=true SR est défini, un enregistrement PBD est créé et connecté pour chaque XenServer du pool de ressources.

Si vous créez un SR pour le stockage IP (iSCSI ou NFS), vous pouvez configurer l’un des éléments suivants en tant que réseau de stockage : la carte réseau qui gère le trafic de gestion ou une nouvelle carte réseau pour le trafic de stockage. Pour attribuer une adresse IP à une carte réseau, reportez-vous à la section Configurer une carte réseau de stockage dédiée.

Tous les types de XenServer SR prennent en charge le redimensionnement VDI, le clonage rapide et les snapshots. Les SR basées sur le type LVM SR (local, iSCSI ou HBA) fournissent un provisionnement léger pour les nœuds parents instantanés et masqués. Les autres types de SR (EXT3/EXT4, NFS, GFS2) prennent en charge le provisionnement fin complet, y compris pour les disques virtuels actifs.

Avertissements :

Lorsque les VDI VHD ne sont pas attachés à une machine virtuelle, par exemple pour un instantané VDI, ils sont stockés en tant que provisionnement fin par défaut. Si vous tentez de rattacher le VDI, assurez-vous qu’il y a suffisamment d’espace disque disponible pour que le VDI soit provisionné de manière dense. Les clones VDI sont provisionnés de manière épaisse.

XenServer ne prend pas en charge les snapshots au niveau du SAN externe d’un LUN, quel que soit le type de SR.

N’essayez pas de créer un SR lorsque l’ID de LUN du LUN de destination est supérieur à 255. Assurez-vous que votre cible expose le LUN avec un ID de LUN inférieur ou égal à 255 avant d’utiliser ce LUN pour créer un SR.

Si vous utilisez le provisionnement dynamique sur un SR basé sur des fichiers, veillez à surveiller l’espace libre sur votre SR. Si l’utilisation du SR atteint 100 %, les écritures supplémentaires des machines virtuelles échouent. Ces échecs d’écriture peuvent entraîner le gel ou le blocage de la machine virtuelle.

Les tailles VDI maximales prises en charge sont les suivantes :

Format du référentiel de stockage	Taille maximale de VDI
EXT3/EXT4	2 TiB
GFS2 (avec iSCSI ou HBA)	16 Tio
XFS	16 Tio
LVM	2 TiB
LVMoFCOE (obsolète)	2 TiB
LVMoHBA	2 TiB
LVMoiSCSI	2 TiB
NFS	2 TiB
SMB	2 TiB

LVM local

Le type LVM local présente les disques au sein d’un groupe de volumes rattaché localement.

Par défaut, XenServer utilise le disque local de l’hôte physique sur lequel il est installé. Le gestionnaire de volume logique Linux (LVM) est utilisé pour gérer le stockage des machines virtuelles. Un VDI est implémenté au format VHD dans un volume logique LVM de la taille spécifiée.

Remarque :

La taille de bloc d’un LUN LVM doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Considérations sur les performances LVM

La fonctionnalité d’instantané et de clonage rapide pour les SR basés sur LVM s’accompagne d’une surcharge de performances inhérente. Lorsque des performances optimales sont requises, XenServer prend en charge la création de VDI au format brut en plus du format VHD par défaut. La fonctionnalité de capture instantanée XenServer n’est pas prise en charge sur les VDI bruts.

Avertissement :

N’essayez pas de créer un instantané d’une machine virtuelle à laquelle des disques type=raw sont connectés. Cette action peut entraîner la création d’un instantané partiel. Dans ce cas, vous pouvez identifier les VDI d’instantanés orphelins en cochant le champ snapshot-of, puis en les supprimant.

Création d’un SR LVM local

Un SR LVM est créé par défaut lors de l’installation de l’hôte.

Les paramètres de configuration du périphérique pour les SR LVM sont les suivants :

Nom du paramètre	Description	Requis ?
`device`	Nom du périphérique sur l’hôte local à utiliser pour le SR. Vous pouvez également fournir une liste de noms séparés par des virgules.	Oui

Pour créer une SR LVM locale sur /dev/sdb, utilisez la commande suivante.

    xe sr-create host-uuid=valid_uuid content-type=user \
    name-label="Example Local LVM SR" shared=false \
    device-config:device=/dev/sdb type=lvm
<!--NeedCopy-->

EXT3/EXT4 local

L’utilisation d’EXT3/EXT4 permet le provisionnement fin sur le stockage local. Toutefois, le type de référentiel de stockage par défaut est LVM car il offre des performances d’écriture cohérentes et empêche le stockage de trop commit. Si vous utilisez EXT3/EXT4, vous pouvez constater une réduction des performances dans les cas suivants :

Lors de l’exécution d’opérations de cycle de vie des machines virtuelles telles que la création et la suspendre/reprise de la machine virtuelle
Lors de la création de fichiers volumineux à partir de la machine virtuelle

Les SR du disque local EXT3/EXT4 doivent être configurés à l’aide de l’interface de ligne de commande XenServer.

Le fait qu’un EXT SR local utilise EXT3 ou EXT4 dépend de la version de XenServer qui l’a créé :

Si vous avez créé le fichier EXT SR local sur une version antérieure de Citrix Hypervisor ou XenServer, puis que vous l’avez mis à niveau vers XenServer 8, il utilise EXT3.
Si vous avez créé le fichier EXT SR local sur XenServer 8, il utilise EXT4.

Remarque :

La taille de bloc d’un disque EXT3/EXT4 doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Création d’un SR EXT4 local (`ext`)

Paramètres de configuration du périphérique pour les SR ext :

Nom du paramètre	Description	Requis ?
`device`	Nom du périphérique sur l’hôte local à utiliser pour le SR. Vous pouvez également fournir une liste de noms séparés par des virgules.	Oui

Pour créer un SR EXT4 local sur /dev/sdb, utilisez la commande suivante :

    xe sr-create host-uuid=valid_uuid content-type=user \
       name-label="Example Local EXT4 SR" shared=false \
       device-config:device=/dev/sdb type=ext
<!--NeedCopy-->

XFS local

L’utilisation de XFS permet un provisionnement léger sur le stockage local. Le type XFS local vous permet de créer des périphériques de stockage locaux avec des blocs physiques de 4 Ko sans nécessiter une taille de bloc logique de 512 octets.

Création d’un XFS SR local

Paramètres de configuration de l’appareil pour les SR XFS :

Nom du paramètre	Description	Requis ?
`device`	Nom du périphérique sur l’hôte local à utiliser pour le SR. Vous pouvez également fournir une liste de noms séparés par des virgules.	Oui

Pour créer un XFS SR local sur /dev/sdb, utilisez la commande suivante :

    xe sr-create host-uuid=valid_uuid content-type=user \
       name-label="Example Local XFS SR" shared=false \
       device-config:device=/dev/sdb type=xfs
<!--NeedCopy-->

udev

Le type udev représente les périphériques connectés à l’aide du gestionnaire de périphériques udev en tant que VDI.

XenServer possède deux SR de type udev qui représentent le stockage amovible. L’un concerne le disque CD ou DVD situé dans le lecteur de CD ou de DVD-ROM physique de l’hôte XenServer. L’autre concerne un périphérique USB branché sur un port USB de l’hôte XenServer. Les VDI qui représentent le média vont et viennent lorsque des disques ou des clés USB sont insérés et retirés.

ISO

Le type ISO gère les images CD stockées sous forme de fichiers au format ISO. Ce type SR est utile pour créer des bibliothèques ISO partagées.

Les types ISO SR suivants sont disponibles :

nfs_iso: Le type NFS ISO SR gère les images de CD stockées sous forme de fichiers au format ISO disponibles sous forme de partage NFS.
cifs: Le type SR de partage de fichiers Windows (SMB/CIFS) gère les images de CD stockées sous forme de fichiers au format ISO disponibles sous forme de partage Windows (SMB/CIFS).

Si vous ne spécifiez pas le type de stockage à utiliser pour le SR, XenServer utilise le paramètre de configuration de l’appareil location pour décider du type.

Paramètres de configuration de l’appareil pour les SR ISO :

Nom du paramètre	Description	Requis ?
`location`	Chemin d’accès au montage.	Oui
`type`	Type de stockage à utiliser pour le SR : `cifs` ou `nfs_iso`.	Non
`nfsversion`	Pour le type de stockage NFS, version du protocole NFS à utiliser : 3, 4, 4.0 ou 4.1.	Non
`vers`	Pour le type de stockage CIFS/SMB, version de SMB à utiliser : 1.0 ou 3.0. La valeur par défaut est 3.0.	Non
`username`	Pour le type de stockage CIFS/SMB, si un nom d’utilisateur est requis pour le serveur de fichiers Windows.	Non
`cifspassword_secret`	(Recommandé) Pour le type de stockage CIFS/SMB, vous pouvez transmettre un secret au lieu d’un mot de passe pour le serveur de fichiers Windows.	Non
`cifspassword`	Pour le type de stockage CIFS/SMB, si un mot de passe est requis pour le serveur de fichiers Windows. Nous vous recommandons d’utiliser le paramètre `cifspassword_secret` à la place.	Non

Remarque :

Lors de l’exécution de la commande sr-create, nous vous recommandons d’utiliser l’argument device-config:cifspassword_secret au lieu de spécifier le mot de passe sur la ligne de commande. Pour plus d’informations, consultez Secrets.

Pour les référentiels de stockage qui stockent une bibliothèque d’ISO, le paramètre content-type doit être défini sur iso, par exemple :

    xe sr-create host-uuid=valid_uuid content-type=iso  type=iso name-label="Example ISO SR" \
      device-config:location=<path_to_mount> device-config:type=nfs_iso
<!--NeedCopy-->

Vous pouvez utiliser NFS ou SMB pour monter l’ISO SR. Pour plus d’informations sur l’utilisation de ces types de SR, consultez NFS et SMB .

Nous vous recommandons d’utiliser la version 3 de SMB pour monter ISO SR sur un serveur de fichiers Windows. La version 3 est sélectionnée par défaut car elle est plus sécurisée et robuste que la version 1.0 pour SMB. Toutefois, vous pouvez installer ISO SR à l’aide de SMB version 1 à l’aide de la commande suivante :

     xe sr-create content-type=iso type=iso shared=true device-config:location=<path_to_mount>
     device-config:username=<username> device-config:cifspassword=<password> \
     device-config:type=cifs device-config:vers=1.0 name-label="Example ISO SR"
<!--NeedCopy-->

Prise en charge des logiciels iSCSI

XenServer prend en charge les SR partagés sur les LUN iSCSI. L’iSCSI est pris en charge à l’aide de l’initiateur iSCSI logiciel Open-iSCSI ou à l’aide d’un adaptateur de bus hôte (HBA) iSCSI compatible. Les étapes d’utilisation des adaptateurs HBA iSCSI sont identiques à celles des adaptateurs HBA Fibre Channel. Les deux étapes sont décrites dans Créer un adaptateur HBA LVM sur Fibre Channel/Fibre Channel over Ethernet/iSCSI partagé ou SAS SR.

La prise en charge iSCSI partagée à l’aide de l’initiateur iSCSI logiciel est implémentée sur la base du gestionnaire de volumes Linux (LVM). Cette fonctionnalité offre les mêmes avantages en termes de performances que les VDI LVM dans le boîtier de disque local. Les SR iSCSI partagés utilisant l’initiateur hôte basé sur un logiciel peuvent renforcer l’agilité des machines virtuelles grâce à la migration en direct : les machines virtuelles peuvent être démarrées sur n’importe quel hôte XenServer d’un pool de ressources et migrées entre eux sans interruption notable.

Les SR iSCSI utilisent la totalité du LUN spécifié au moment de la création et ne peuvent pas couvrir plus d’un LUN. La prise en charge CHAP est fournie pour l’authentification du client, tant pendant l’initialisation du chemin de données que pendant les phases de découverte des LUN

Remarque :

La taille de bloc d’un LUN iSCSI doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Configuration iSCSI de l’hôte XenServer

Tous les initiateurs et cibles iSCSI doivent avoir un nom unique pour garantir qu’ils peuvent être identifiés de manière unique sur le réseau. Un initiateur possède une adresse d’initiateur iSCSI et une cible possède une adresse cible iSCSI. Collectivement, ces noms sont appelés noms qualifiés iSCSI ou IQN.

Les hôtes XenServer prennent en charge un seul initiateur iSCSI qui est automatiquement créé et configuré avec un IQN aléatoire lors de l’installation de l’hôte. L’initiateur unique peut être utilisé pour se connecter simultanément à plusieurs cibles iSCSI.

Les cibles iSCSI fournissent généralement un contrôle d’accès à l’aide de listes IQN des initiateurs iSCSI. Toutes les cibles/LUN iSCSI auxquelles votre hôte XenServer accède doivent être configurées pour autoriser l’accès par l’IQN initiateur de l’hôte. De même, les cibles/LUN à utiliser en tant que SR iSCSI partagés doivent être configurés pour autoriser l’accès à tous les IQN d’hôte du pool de ressources.

Remarque :

Les cibles iSCSI qui ne fournissent pas de contrôle d’accès limitent généralement l’accès aux LUN à un seul initiateur pour garantir l’intégrité des données. Si un LUN iSCSI est utilisé comme SR partagé entre plusieurs hôtes d’un pool, assurez-vous que l’accès multi-initiateur est activé pour le LUN spécifié.

La valeur IQN de l’hôte XenServer peut être ajustée à l’aide de XenCenter ou à l’aide de l’interface de ligne de commande avec la commande suivante lors de l’utilisation de l’initiateur logiciel iSCSI :

    xe host-param-set uuid=valid_host_id other-config:iscsi_iqn=new_initiator_iqn
<!--NeedCopy-->

Avertissement :

Chaque cible et chaque initiateur iSCSI doivent avoir un IQN unique. Si un identifiant IQN non unique est utilisé, des données corrompues ou un déni d’accès au LUN peuvent se produire.

Ne modifiez pas l’IQN de l’hôte XenServer auquel sont connectés des SR iSCSI. Cela peut entraîner des échecs de connexion à de nouvelles cibles ou à des SR existants.

Stockage logiciel FCoE (obsolète)

Le logiciel FCoE fournit un cadre standard auquel les fournisseurs de matériel peuvent brancher leur carte réseau compatible FCoE et bénéficier des mêmes avantages qu’un FCoE basé sur le matériel. Cette fonctionnalité élimine la nécessité d’utiliser des adaptateurs HBA coûteux.

Remarque :

Le logiciel FCoE est obsolète et sera supprimé dans une prochaine version.

Avant de créer un stockage FCoE logiciel, effectuez manuellement la configuration requise pour exposer un LUN à l’hôte. Cette configuration inclut la configuration de la structure FCoE et l’allocation de LUN au nom mondial public (PWWN) de votre réseau SAN. Une fois cette configuration terminée, le LUN disponible est monté sur le CNA de l’hôte en tant que périphérique SCSI. Le périphérique SCSI peut ensuite être utilisé pour accéder au LUN comme s’il s’agissait d’un périphérique SCSI connecté localement. Pour plus d’informations sur la configuration du commutateur physique et de la baie pour prendre en charge FCoE, consultez la documentation fournie par le fournisseur.

Remarque :

Le logiciel FCoE peut être utilisé avec Open vSwitch et un pont Linux en tant que back-end réseau.

Créer un SR FCoE logiciel

Avant de créer un SR FCoE logiciel, les clients doivent s’assurer que des cartes réseau compatibles FCoE sont connectées à l’hôte.

Les paramètres de configuration du périphérique pour les SR FCoE sont les suivants :

Nom du paramètre	Description	Requis ?
`SCSIid`	L’ID de bus SCSI du LUN de destination	Oui

Exécutez la commande suivante pour créer un SR FCoE partagé :

    xe sr-create type=lvmofcoe \
    name-label="FCoE SR" shared=true device-config:SCSIid=SCSI_id
<!--NeedCopy-->

Adaptateurs de bus hôte matériels (HBA)

Cette section traite des différentes opérations nécessaires à la gestion des adaptateurs HBA SAS, Fibre Channel et iSCSI.

Exemple de configuration de l’adaptateur HBA iSCSI QLogic

Pour plus d’informations sur la configuration des adaptateurs HBA Fibre Channel et iSCSI QLogic, consultez lehttps://cavium.com()site Web de [Cavium].

Une fois le HBA physiquement installé sur l’hôte XenServer, procédez comme suit pour configurer le HBA :

Définissez la configuration réseau IP pour le HBA. Cet exemple suppose que le port DHCP et HBA est 0. Spécifiez les valeurs appropriées si vous utilisez un adressage IP statique ou un adaptateur HBA multiport.
```
/opt/QLogic_Corporation/SANsurferiCLI/iscli -ipdhcp 0

```

Ajoutez une cible iSCSI persistante au port 0 du HBA.

/opt/QLogic_Corporation/SANsurferiCLI/iscli -pa 0 iscsi_target_ip_address
<!--NeedCopy-->

Utilisez la commande xe sr-probe pour forcer une nouvelle analyse du contrôleur HBA et afficher les LUN disponibles. Pour plus d’informations, voir S onde un SRet Créer un LVM partagé sur Fibre Channel / Fibre Channel over Ethernet / iSCSI HBA ou SAS SR.

Suppression des entrées de périphériques SAS, FC ou iSCSI basées sur l’adaptateur HBA

Remarque :

Cette étape n’est pas obligatoire. Nous recommandons que seuls les utilisateurs avancés effectuent ce processus si cela est nécessaire.

Chaque LUN basé sur un adaptateur HBA possède une entrée de chemin de périphérique globale correspondante /dev/disk/by-scsibus sous le format <SCSIid>-<adapter>:<bus>:<target>:<lun> et un chemin de périphérique standard sous /dev. Pour supprimer les entrées de périphérique pour les LUN qui ne sont plus utilisés en tant que SR, procédez comme suit :

Utilisez sr-forget ou sr-destroy, selon le cas, supprimez le SR de la base de données hôte XenServer. Reportez-vous à la section Supprimer les SRpour plus de détails.
Supprimez la configuration de zonage dans le SAN pour le LUN souhaité sur l’hôte souhaité.
Utilisez la commande sr-probe pour déterminer les valeurs ADAPTER, BUS, TARGET et LUN correspondant au LUN à supprimer. Pour plus d’informations, sondez un SR.

Supprimez les entrées du périphérique avec la commande suivante :

echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete
<!--NeedCopy-->

Avertissement :

Vérifiez que vous êtes certain du LUN que vous supprimez. La suppression accidentelle d’un LUN requis pour le fonctionnement de l’hôte, tel que le périphérique de démarrage ou racine, rend l’hôte inutilisable.

Stockage LVM partagé

Le type LVM partagé représente les disques en tant que volumes logiques au sein d’un groupe de volumes créé sur un LUN iSCSI (FC ou SAS).

Remarque :

La taille de bloc d’un LUN iSCSI doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Créez une LVM partagée sur iSCSI SR à l’aide de l’initiateur iSCSI Software

Paramètres de configuration du périphérique pour les SR LVMoISCSI :

Nom du paramètre	Description	Requis ?
`target`	L’adresse IP ou le nom d’hôte du serveur de fichiers iSCSI qui héberge le SR. Il peut également s’agir d’une liste de valeurs séparées par des virgules.	Oui
`targetIQN`	Adresse cible IQN du serveur de fichiers iSCSI qui héberge le SR	Oui
`SCSIid`	L’ID de bus SCSI du LUN de destination	Oui
`chapuser`	Le nom d’utilisateur à utiliser pour l’authentification CHAP	Non
`chappassword_secret`	(Recommandé) ID secret du mot de passe à utiliser pour l’authentification CHAP. Transmettez un secret au lieu d’un mot de passe.	Non
`chappassword`	Le mot de passe à utiliser pour l’authentification CHAP. Nous vous recommandons d’utiliser le paramètre `chappassword_secret` à la place.	Non
`port`	Le numéro de port réseau sur lequel interroger la cible	Non
`usediscoverynumber`	L’index d’enregistrement iSCSI spécifique à utiliser	Non
`incoming_chapuser`	Le nom d’utilisateur utilisé par le filtre iSCSI pour s’authentifier auprès de l’hôte	Non
`incoming_chappassword`	Mot de passe utilisé par le filtre iSCSI pour s’authentifier auprès de l’hôte	Non

Remarque :

Lors de l’exécution de la commande sr-create, nous vous recommandons d’utiliser l’argument device-config:chappassword_secret au lieu de spécifier le mot de passe sur la ligne de commande. Pour plus d’informations, consultez Secrets.

Pour créer un SR LVMOISCSI partagé sur un LUN spécifique d’une cible iSCSI, utilisez la commande suivante.

    xe sr-create host-uuid=valid_uuid content-type=user \
    name-label="Example shared LVM over iSCSI SR" shared=true \
    device-config:target=target_ip= device-config:targetIQN=target_iqn= \
    device-config:SCSIid=scsci_id \
    type=lvmoiscsi
<!--NeedCopy-->

Créez un adaptateur HBA LVM sur Fibre Channel/Fibre Channel over Ethernet/iSCSI partagé ou SAS SR

Les SR de type LVMoHBA peuvent être créés et gérés à l’aide de l’interface de ligne de commande xe ou de XenCenter.

Paramètres de configuration du périphérique pour les SR LVMoHBA :

Nom du paramètre	Description	Requis ?
`SCSIid`	ID SCSI de l’appareil	Oui

Pour créer un SR LvMoHBA partagé, effectuez les étapes suivantes sur chaque hôte du pool :

Zonez un ou plusieurs LUN sur chaque hôte XenServer du pool. Ce processus est très spécifique à l’équipement SAN utilisé. Pour plus d’informations, consultez la documentation de votre SAN.
Si nécessaire, utilisez l’interface de ligne de commande HBA incluse dans l’hôte XenServer pour configurer le HBA :
- Emulex : /bin/sbin/ocmanager
- QLogic FC : /opt/QLogic_Corporation/SANsurferCLI
- QLogic iSCSI : /opt/QLogic_Corporation/SANsurferiCLI
Pour obtenir un exemple de configuration de l’adaptateur HBA iSCSI QLogic, voir Adaptateurs de bus hôte matériel (HBA) dans la section précédente. Pour plus d’informations sur les adaptateurs HBA Fibre Channel et iSCSI, consultez les sites Web Broadcom et Cavium .

Utilisez la commande sr-probe pour déterminer le chemin d’accès global du LUN du HBA au périphérique. La commande sr-probe force une nouvelle analyse des adaptateurs HBA installés sur le système afin de détecter les nouveaux LUN qui ont été zonés sur l’hôte. La commande renvoie une liste de propriétés pour chaque LUN trouvé. Spécifiez le paramètre host-uuid pour vous assurer que la sonde se produit sur l’hôte souhaité.

Le chemin d’accès global au périphérique renvoyé en tant que propriété <path> est commun à tous les hôtes du pool. Par conséquent, ce chemin doit être utilisé comme valeur pour le paramètre device-config:device lors de la création du SR.

Si plusieurs LUN sont présents, utilisez le fournisseur, la taille du LUN, le numéro de série du LUN ou l’ID SCSI de la propriété <path> pour identifier le LUN souhaité.

    xe sr-probe type=lvmohba \
    host-uuid=1212c7b3-f333-4a8d-a6fb-80c5b79b5b31
    Error code: SR_BACKEND_FAILURE_90
    Error parameters: , The request is missing the device parameter, \
    <?xml version="1.0" ?>
    <Devlist>
        <BlockDevice>
            <path>
                /dev/disk/by-id/scsi-360a9800068666949673446387665336f
            </path>
            <vendor>
                HITACHI
            </vendor>
            <serial>
                730157980002
            </serial>
            <size>
                80530636800
            </size>
            <adapter>
                4
            </adapter>
            <channel>
                0
            </channel>
            <id>
                4
            </id>
            <lun>
                2
            </lun>
            <hba>
                qla2xxx
            </hba>
        </BlockDevice>
        <Adapter>
            <host>
                Host4
            </host>
            <name>
                qla2xxx
            </name>
            <manufacturer>
                QLogic HBA Driver
            </manufacturer>
            <id>
                4
            </id>
        </Adapter>
    </Devlist>
<!--NeedCopy-->

Sur le coordinateur du pool, créez le SR. Spécifiez le chemin d’accès global au périphérique renvoyé dans la propriété <path> de sr-probe. Les PBD sont créés et branchés automatiquement pour chaque hôte du pool.
```
    xe sr-create host-uuid=valid_uuid \
    content-type=user \
    name-label="Example shared LVM over HBA SR" shared=true \
    device-config:SCSIid=device_scsi_id type=lvmohba

```

Remarque :

Vous pouvez utiliser la fonction XenCenter Repair Storage Repair Storage Repository pour réessayer la création de PBD et le branchement des parties de l’opération sr-create. Cette fonction peut être utile dans les cas où le zonage des LUN était incorrect pour un ou plusieurs hôtes d’un pool lors de la création du SR. Corrigez le zonage des hôtes concernés et utilisez la fonction Réparer le référentiel de stockage au lieu de supprimer et de recréer le SR.

Stockage par blocs GFS2 partagé à provisionnement léger

Le provisionnement fin utilise mieux le stockage disponible en allouant de l’espace de stockage sur disque aux VDI au fur et à mesure que les données sont écrites sur le disque virtuel, plutôt que d’allouer à l’avance la taille virtuelle complète du VDI. Le provisionnement fin vous permet de réduire considérablement la quantité d’espace requise sur une baie de stockage partagée et, partant, votre coût total de possession (TCO).

Le provisionnement fin pour le stockage en mode bloc partagé présente un intérêt particulier dans les cas suivants :

Vous souhaitez une efficacité accrue de l’espace. Les images sont allouées de manière clairsemée et non épaisse.
Vous souhaitez réduire le nombre d’opérations d’E/S par seconde sur votre baie de stockage. Le GFS2 SR est le premier type de SR à prendre en charge la mise en cache de lecture du stockage sur le stockage en mode bloc partagé.
Vous utilisez une image de base commune pour plusieurs machines virtuelles. Les images des machines virtuelles individuelles utilisent alors généralement encore moins d’espace.
Vous utilisez des instantanés. Chaque instantané est une image et chaque image est désormais fragmentée.
Votre stockage ne prend pas en charge NFS et prend uniquement en charge le stockage en mode bloc. Si votre stockage prend en charge NFS, nous vous recommandons d’utiliser NFS au lieu de GFS2.
Vous souhaitez créer des VDI dont la taille est supérieure à 2 Tio. Le GFS2 SR prend en charge les VDI d’une taille maximale de 16 Tio.

Remarque :

Nous vous recommandons de ne pas utiliser un SR GFS2 avec un VLAN en raison d’un problème connu dans lequel vous ne pouvez pas ajouter ou supprimer des hôtes sur un pool en cluster si le réseau en cluster se trouve sur un VLAN non destiné à la gestion.

Le type GFS2 SR partagé crée un système de fichiers GFS2 sur un LUN iSCSI ou HBA. Les VDI sont stockés dans le GFS2 SR sous forme de fichiers au format d’image QCOW2.

Pour plus d’informations sur l’utilisation du stockage GFS2, consultez la section Stockage par blocs GFS2 partagé à provisionnementfin.

NFS et SMB

Les partages sur des serveurs NFS (qui prennent en charge n’importe quelle version de NFSv4 ou NFSv3) ou sur des serveurs SMB (qui prennent en charge SMB 3) peuvent être utilisés immédiatement comme SR pour les disques virtuels. Les VDI sont stockés au format Microsoft VHD uniquement. En outre, comme ces SR peuvent être partagés, les VDI stockés sur des SR partagés permettent :

Machines virtuelles à démarrer sur n’importe quel hôte XenServer d’un pool de ressources
Migration de machines virtuelles entre les hôtes XenServer d’un pool de ressources à l’aide de la migration en direct (sans interruption notable)

Important :

La prise en charge de SMB3 est limitée à la possibilité de se connecter à un partage à l’aide du protocole 3. Les fonctionnalités supplémentaires telles que le basculement transparent dépendent de la disponibilité des fonctionnalités dans le noyau Linux en amont et ne sont pas prises en charge dans XenServer 8.

Le protocole SMB en cluster n’est pas pris en charge par XenServer.

Pour NFSv4, seul le type d’authentificationAUTH_SYS est pris en charge.

Le stockage SMB est disponible pour les clients de XenServer Premium Edition.

Pour le stockage NFS et SMB, il est fortement recommandé d’utiliser un réseau de stockage dédié, utilisant au moins deux liaisons liées, idéalement vers des commutateurs réseau indépendants dotés d’une alimentation redondante.

Lorsque vous utilisez un stockage SMB, ne supprimez pas le partage du stockage avant d’avoir détaché le SMB SR.

Les VDI stockés sur des SR basées sur des fichiers sont finement provisionnés. Le fichier image est alloué lorsque la machine virtuelle écrit des données sur le disque. Cette approche présente l’avantage considérable que les fichiers image de la machine virtuelle n’occupent que l’espace de stockage nécessaire. Par exemple, si un VDI de 100 Go est alloué à une machine virtuelle et qu’un système d’exploitation est installé, le fichier VDI reflète uniquement la taille des données du système d’exploitation écrites sur le disque plutôt que la totalité des 100 Go.

Les fichiers VHD peuvent également être chaînés, ce qui permet à deux VDI de partager des données communes. Dans les cas où une machine virtuelle basée sur des fichiers est clonée, les machines virtuelles résultantes partagent les données sur disque communes au moment du clonage. Chaque machine virtuelle procède à ses propres modifications dans une version isolée de copie sur écriture du VDI. Cette fonctionnalité permet de cloner rapidement des machines virtuelles basées sur des fichiers à partir de modèles, ce qui facilite le provisionnement et le déploiement très rapides de nouvelles machines virtuelles.

Remarque :

La longueur maximale prise en charge des chaînes VHD est de 30.

Les implémentations SRs et VHD basées sur des fichiers dans XenServer supposent qu’elles ont un contrôle total sur le répertoire SR sur le serveur de fichiers. Les administrateurs ne doivent pas modifier le contenu du répertoire SR, car cette action risque d’endommager le contenu des VDI.

XenServer a été conçu pour un stockage d’entreprise qui utilise de la RAM non volatile pour fournir des accusés de réception rapides des demandes d’écriture tout en maintenant un degré élevé de protection des données en cas de défaillance. XenServer a été testé de manière approfondie par rapport au stockage Network Appliance FAS2020 et FAS3210, à l’aide de Data OnTap 7.3 et 8.1

Avertissement :

Étant donné que les VDI sur des SR basés sur des fichiers sont créés en tant que configuration dynamique, les administrateurs doivent s’assurer que les SR basés sur des fichiers disposent de suffisamment d’espace disque pour tous les VDI requis. Les hôtes XenServer ne garantissent pas la présence de l’espace requis pour les VDI sur les SR basés sur des fichiers.

Assurez-vous de surveiller l’espace libre sur votre SR. Si l’utilisation du SR atteint 100 %, les écritures supplémentaires des machines virtuelles échouent. Ces échecs d’écriture peuvent entraîner le gel ou le blocage de la machine virtuelle.

Créer un NFS SR (NFS) partagé

Pour créer un SR NFS, vous devez fournir le nom d’hôte ou l’adresse IP du serveur NFS. Vous pouvez créer le SR sur n’importe quel chemin de destination valide ; utilisez la commande sr-probe pour afficher la liste des chemins de destination valides exportés par le serveur.

Dans les scénarios où XenServer est utilisé avec un stockage bas de gamme, il attend prudemment que toutes les écritures soient confirmées avant de transmettre des accusés de réception aux machines virtuelles. Cette approche entraîne un coût de performance notable et peut être résolue en définissant le stockage pour présenter le point de montage SR en tant qu’exportation en mode asynchrone. Les exportations asynchrones reconnaissent les écritures qui ne se trouvent pas réellement sur le disque. Considérez soigneusement les risques d’échec dans ces situations.

Remarque :

Le serveur NFS doit être configuré pour exporter le chemin spécifié vers tous les hôtes du pool. Si cette configuration n’est pas effectuée, la création du SR et le branchement de l’enregistrement PBD échouent.

L’implémentation XenServer NFS utilise le protocole TCP par défaut. Si votre situation le permet, vous pouvez configurer l’implémentation pour utiliser le protocole UDP dans les scénarios où les performances peuvent être améliorées. Pour effectuer cette configuration, spécifiez le paramètre device-config sur useUDP=true lors de la création d’un SR.

Les device-config paramètres suivants sont utilisés avec les SR NFS :

Nom du paramètre	Description	Requis ?
`server`	Adresse IP ou nom d’hôte du serveur NFS	Oui
`serverpath`	Chemin, y compris le point de montage NFS, vers le serveur NFS qui héberge le SR	Oui
`nfsversion`	Spécifie la version de NFS à utiliser. Si vous le spécifiez `nfsversion="4"`, le SR utilise NFS v4.0, v4.1 ou v4.2, selon ce qui est disponible. Si vous souhaitez sélectionner une version plus spécifique de NFS, vous pouvez spécifier `nfsversion="4.0"`, etc. Vous ne pouvez spécifier qu’une seule valeur pour `nfsversion`.	Non
`useUDP`	Configurez le SR pour qu’il utilise le protocole UDP plutôt que le protocole TCP par défaut.	Non

Par exemple, pour créer un SR NFS partagé sur 192.168.1.10:/export1, en utilisant n’importe quelle version 4 de NFS mise à disposition par le serveur de fichiers, utilisez la commande suivante :

    xe sr-create content-type=user \
    name-label="shared NFS SR" shared=true \
    device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
    device-config:nfsversion="4"
<!--NeedCopy-->

Pour créer un SR NFS non partagé sur 192.168.1.10:/export1, en utilisant spécifiquement la version 4.0 de NFS, exécutez la commande suivante :

    xe sr-create host-uuid=host_uuid content-type=user \
    name-label="Non-shared NFS SR" \
    device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
    device-config:nfsversion="4.0"
<!--NeedCopy-->

Créer un SR SMB partagé (SMB)

Pour créer un SR SMB, indiquez le nom d’hôte ou l’adresse IP du serveur SMB, le chemin d’accès complet du partage exporté et les informations d’identification appropriées.

Paramètres de configuration du périphérique pour les SR SMB :

Nom du paramètre	Description	Requis ?
`server`	Chemin complet pour partager sur le serveur	Oui
`username`	Compte utilisateur avec accès RW pour partager	Facultatif
`password_secret`	(Recommandé) ID secret pour le mot de passe du compte utilisateur, qui peut être utilisé à la place du mot de passe.	Facultatif
`password`	Mot de passe du compte utilisateur. Nous vous recommandons d’utiliser le paramètre `password_secret` à la place.	Facultatif

Remarque :

Lors de l’exécution de la commande sr-create, nous vous recommandons d’utiliser l’argument device-config:password_secret au lieu de spécifier le mot de passe sur la ligne de commande. Pour plus d’informations, consultez Secrets.

Par exemple, pour créer un SR SMB partagé sur 192.168.1.10:/share1, utilisez la commande suivante :

    xe sr-create content-type=user \
    name-label="Example shared SMB SR" shared=true \
    device-config:server=//192.168.1.10/share1 \
    device-config:username=valid_username device-config:password_secret=valid_password_secret type=smb
<!--NeedCopy-->

Pour créer un SR SMB non partagé, exécutez la commande suivante :

    xe sr-create host-uuid=host_uuid content-type=user \
    name-label="Non-shared SMB SR" \
    device-config:server=//192.168.1.10/share1 \
    device-config:username=valid_username device-config:password_secret=valid_password_secret type=smb
<!--NeedCopy-->

HBA LVM sur matériel

Le type d’adaptateur HBA LVM sur matériel représente les disques en tant que disques durs virtuels sur des volumes logiques au sein d’un groupe de volumes créé sur un LUN d’adaptateur HBA qui fournit, par exemple, une prise en charge matérielle iSCSI ou FC.

Les hôtes XenServer prennent en charge les réseaux SAN Fibre Channel via des adaptateurs de bus hôte (HBA) Emulex ou QLogic. Toute la configuration Fibre Channel requise pour exposer un LUN Fibre Channel à l’hôte doit être effectuée manuellement. Cette configuration inclut les périphériques de stockage, les périphériques réseau et le HBA au sein de l’hôte XenServer. Une fois la configuration FC terminée, le HBA expose à l’hôte un périphérique SCSI soutenu par le LUN FC. Le périphérique SCSI peut ensuite être utilisé pour accéder au LUN FC comme s’il s’agissait d’un périphérique SCSI connecté localement.

Utilisez la commande sr-probe pour répertorier les périphériques SCSI basés sur des LUN présents sur l’hôte. Cette commande force une recherche de nouveaux périphériques SCSI reposant sur des LUN. La valeur du chemin renvoyée par sr-probe pour un périphérique SCSI basé sur un LUN est cohérente sur tous les hôtes ayant accès au LUN. Par conséquent, cette valeur doit être utilisée lors de la création de SR partagés accessibles par tous les hôtes d’un pool de ressources.

Les mêmes fonctionnalités s’appliquent aux adaptateurs HBA iSCSI QLogic.

Voir Créer des référentiels de stockage pour plus de détails sur la création de SR FC et iSCSI partagés basés sur un adaptateur HBA.

Remarque :

Le support XenServer pour Fibre Channel ne prend pas en charge le mappage direct d’un LUN vers une machine virtuelle. Les LUN basés sur un adaptateur HBA doivent être mappés à l’hôte et spécifiés pour une utilisation dans un SR. Les VDI de la SR sont exposés aux machines virtuelles en tant que périphériques de bloc standard.

La taille de bloc d’un LUN LVM sur HBA doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).