Ignorer les liens de navigation
Quitter l'aperu
| Notes de version d'Oracle VM Server for SPARC 3.0 Oracle VM Server for SPARC (Français)

Périmètre de la recherche:

- Ce document
- Toute la bibliothque

## Problèmes connus

Cette section recense les problèmes d'ordre général et les bogues liés au logiciel Oracle VM Server for SPARC 3.0.

### Problèmes d'ordre général

Cette section décrit les problèmes matériels et logiciels connus pour cette version du logiciel Oracle VM Server for SPARC qui ne concernent pas qu'un numéro de bogue particulier. Des solutions sont proposées, le cas échéant.

#### Mise à niveau à partir d'un SE Oracle Solaris 10 antérieur au SE Oracle Solaris 10 5/08

Si le domaine de contrôle est mis à niveau à partir d'une version du SE Oracle Solaris 10 antérieure au SE Oracle Solaris 10 5/08 (ou sans le patch 127127-11) et si les volumes du gestionnaire de volumes ont été exportés en tant que disques virtuels, les moteurs de traitement des disques virtuels doivent être ré-exportés avec `options=slice` après la mise à niveau du Logical Domains Manager. Reportez-vous à la section Exportation de volumes et rétrocompatibilité du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

#### Les termes Processeur de service et Contrôleur système sont utilisés de manière interchangeable

Pour les besoins de la documentation d'Oracle VM Server for SPARC les termes Processeur de service et Contrôleur système sont utilisés de manière interchangeable.

#### Dans certaines circonstances, il arrive que la configuration de Solaris Volume Manager ou que les métapériphériques du domaine invité soient perdus

Si un domaine de service exécute une version du SE Oracle Solaris 10 antérieure à Oracle Solaris 10 8/11 et qu'il exporte une tranche de disque physique sous forme de disque virtuel vers un domaine invité, ce disque virtuel est présenté sur le domaine invité avec un ID de périphérique incorrect. Si ce domaine de service est ensuite mis à niveau vers Oracle Solaris 10 8/11, la tranche de disque physique exportée sous forme de disque virtuel est présentée sur le domaine invité sans ID de périphérique.

L'absence d'ID de périphérique pour le disque virtuel peut être à l'origine de problèmes au niveau des applications qui tentent de référencer l'ID de périphérique de disques virtuels. En particulier, Solaris Volume Manager risque de ne plus pouvoir détecter sa configuration ou d'accéder à ses métapériphériques.

Solution : Après avoir mis à niveau un domaine de service vers Oracle Solaris 10 8/11, si un domaine invité ne parvient pas à détecter sa configuration Solaris Volume Manager ou ses métapériphériques, suivez la procédure ci-dessous.

### Détection de la configuration ou des métapériphériques de Solaris Volume Manager d'un domaine invité

1. Initialisez le domaine invité.
2. Désactivez la fonction `devid` de Solaris Volume Manager en ajoutant les lignes suivantes au fichier `/kernel/dr/md.conf` :

       md_devid_destroy=1;
       md_keep_repl_state=1;

3. Réinitialisez le domaine invité.

   Après l'initialisation du domaine, la configuration de Solaris Volume Manager et les métapériphériques devraient être disponibles.

4. Examinez la configuration de Solaris Volume Manager pour vous assurer qu'elle est correcte.
5. Réactivez la fonction Solaris Volume Manager `devid` en supprimant du fichier `/kernel/drv/md.conf` les deux lignes que vous avez ajoutées à l'étape 2.
6. Réinitialisez le domaine invité.

   Lors de la réinitialisation, des messages semblables aux suivants s'affichent :

       NOTICE: mddb: unable to get devid for 'vdc', 0x10

   Il n'y a rien d'anormal à cela dans la mesure où aucun problème n'est signalé.

#### Canaux de domaines logiques et Logical Domains

Le nombre de canaux LDC (Logical Domain Channel) disponibles sur un domaine logique est limité. Les limites LDC sont :

Serveurs UltraSPARC T2, SPARC T3-1, SPARC T3-1B, SPARC T4-1 et SPARC T4-1B

  La limite LDC est 512.

UltraSPARC T2 Plus, les autres serveurs SPARC T3 et SPARC T4, SPARC T5, SPARC M5 et les systèmes Fujitsu M10

  La limite LDC est 768.

Cette restriction ne pose problème que lorsque le domaine de contrôle se voit allouer, en partie si ce n'est en totalité, le sous-système d'E/S. Cette restriction peut également poser problème en raison du nombre potentiellement important de LDC qui sont créés pour à la fois les communications de données d'E/S virtuelles et le contrôle Logical Domains Manager des autres domaines logiques.

Si vous essayez d'ajouter un service ou de lier un domaine, si bien que le nombre de canaux LDC dépasse la limite sur le domaine de contrôle, l'opération échoue avec un message d'erreur similaire au suivant :

    13 additional LDCs are required on guest primary to meet this request,
    but only 9 LDCs are available

Si de nombreux périphériques réseau virtuels sont connectés au même commutateur virtuel, vous pouvez réduire le nombre de canaux LDC affectés à l'aide des commandes `ldm add-vsw` ou `ldm set-vsw` pour définir la propriété `inter-vnet-link=off`. Lorsque cette propriété est définie sur `off`, les canaux LDC ne sont pas utilisés pour les communications inter-vnet. A la place, un canal LDC est affecté uniquement aux communications entre périphériques réseau virtuels et périphériques commutateurs virtuels. Reportez-vous à la page de manuel `ldm`(1M).

Remarque - Bien que la désactivation de l'affectation des canaux inter-vnet réduise le nombre de LDC, elle risque d'avoir une incidence négative sur les performances réseau entre invités.

La prise en compte des directives suivantes peut vous éviter de créer une configuration susceptible de dépasser les capacités des LCD sur le domaine de contrôle :

1. Le domaine de contrôle alloue environ 15 canaux LDC pour divers objectifs de communication avec l'hyperviseur, l'architecture de gestion des pannes FMA (Fault Management Architecture) et le contrôleur système (SC), indépendamment du nombre de domaines logiques par ailleurs configurés. Le nombre de canaux LDC alloués par le domaine de contrôle dépend de la plate-forme et de la version du logiciel utilisées.

2. Le domaine de contrôle alloue un canal LDC à chaque domaine logique, y compris lui-même, pour le trafic de contrôle.

3. Chaque service d'E/S virtuel sur le domaine de contrôle consomme un canal LDC pour chaque client connecté à ce service.

Par exemple, considérons une configuration avec un domaine de contrôle et 8 domaines logiques supplémentaires. Chaque domaine logique nécessite au moins :

- Réseau virtuel

- Disque virtuel

- Console virtuelle

En appliquant les directives, nous obtenons les résultats suivants (les nombres entre parenthèses correspondent au numéro de directive précédente à partir de laquelle la valeur a été dérivée) :

15(1) + 9(2) + 8 x 3(3) = 48 canaux LDC au total

Considérons maintenant un cas avec 45 domaines au lieu de 8 où chaque domaine comporte 5 disques virtuels, 5 réseaux virtuels et une console virtuelle. L'équation devient maintenant :

15 + 46 + 45 x 11 = 556 canaux LDC au total

Selon le nombre de canaux LDC pris en charge de votre plate-forme, le logiciel Logical Domains Manager accepte ou refuse les configurations.

#### Taille de la mémoire requise

Le logiciel Oracle VM Server for SPARC n'impose aucune limitation de taille pour la mémoire lors de la création d'un domaine. La taille de la mémoire requise est une caractéristique du système d'exploitation hôte. Certaines fonctions d'Oracle VM Server for SPARC risquent de ne pas fonctionner si la quantité de mémoire présente est inférieure à la taille recommandée. Pour le SE Oracle Solaris 10, reportez-vous à la section System Requirements and Recommendations du manuel Oracle Solaris 10 8/11 Installation Guide: Planning for Installation and Upgrade. Pour connaître la configuration système requise et les recommandations pour le SE Oracle Solaris 11, reportez-vous aux sections Oracle Solaris 11 Release Notes et Oracle Solaris 11.1 Release Notes .

La PROM OpenBoot a une contrainte de taille minimale pour un domaine. Actuellement, cette limite est de 12 méga-octets. Si vous avez un domaine dont la taille est inférieure, Logical Domains Manager étend automatiquement celui-ci à 12 méga-octets. La taille minimale d'un système Fujitsu M10 est limitée à 256 Mo. Reportez-vous aux notes de version de votre microprogramme système pour connaître la taille de la mémoire requise

La fonction de reconfiguration dynamique (DR) de la mémoire applique un alignement de 256 Mo sur l'adresse et la taille de la mémoire impliquées dans une opération donnée. Reportez-vous à la section Alignement de la mémoire du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

#### Initialisation d'un grand nombre de domaines

Vous pouvez initialiser le nombre de domaines suivants en fonction de votre plate-forme :

- Jusqu'à 256 sur les systèmes Fujitsu M10

- Jusqu'à 128 sur les systèmes SPARC M5 par domaine physique

- Jusqu'à 128 sur les systèmes SPARC T5

- Jusqu'à 128 sur les serveurs SPARC T4

- Jusqu'à 128 sur les serveurs SPARC T3

- Jusqu'à 128 sur les serveurs UltraSPARC T2 Plus

- Jusqu'à 64 sur les serveurs UltraSPARC T2

Si des CPU virtuelles non allouées sont disponibles, assignez-les au domaine de service afin de contribuer au traitement des demandes d'E/S virtuelles. Attribuez 4 à 8 CPU virtuelles au domaine de service si vous créez plus de 32 domaines. Dans les cas où les configurations de domaines maximales ne disposent que d'une CPU dans le domaine de service, ne placez pas une contrainte inutile sur cette CPU lors de la configuration et de l'utilisation du domaine. Les services de commutateur virtuel (`vsw`) doivent être répartis sur l'ensemble des adaptateurs réseau disponibles dans la machine. Par exemple, si vous initialisez 128 domaines sur un serveur Sun SPARC Enterprise T5240, créez quatre services `vsw`, chacun servant 32 instances réseau virtuelles (`vne```t). L'attribution de plus de 32 instances `vnet` par service `vsw` peut entraîner un blocage forcé du domaine du service.

Pour exécuter les configurations maximales, une machine nécessite une quantité de mémoire suffisante pour prendre en charge les domaines invités. La quantité de mémoire dépend de votre plate-forme et de votre SE. Reportez-vous à la documentation relative à votre plate-forme, Oracle Solaris 10 8/11 Installation Guide: Planning for Installation and Upgrade , Installing Oracle Solaris 11 Systems et Installing Oracle Solaris 11.1 Systems .

La mémoire libre et l'espace de swap utilisés dans un domaine invité augmentent lorsque les services `vsw` utilisés par le domaine fournissent des services à de nombreux réseaux virtuels (dans plusieurs domaines). Ceci est dû aux liaisons de poste à poste entre toutes les instances `vnet` connectées à `vsw`. Le domaine de service bénéficie d'une quantité de mémoire supplémentaire. La valeur minimale recommandée est 4 Go lorsque vous exécutez plus de 64 domaines. Démarrez les domaines par groupe de 10 ou moins et attendez qu'ils s'initialisent avant de démarrer le lot suivant. Ce conseil est également valable pour les systèmes d'exploitation des domaines. Vous pouvez réduire le nombre de liaisons en désactivant les canaux inter-vnet. Reportez-vous à la section Canaux LDC inter-Vnet du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

#### Arrêt et cycle d'alimentation d'un système Logical Domains

Si vous avez effectué des changements de configuration depuis le dernier enregistrement d'une configuration sur le contrôleur système, avant d'éteindre ou d'effectuer un cycle d'alimentation d'un système Logical Domains, veillez à enregistrer la dernière configuration que vous souhaitez conserver.

### Mise hors tension d'un système comportant plusieurs domaines actifs

1. Arrêtez et dissociez tous les domaines non E/S.
2. Arrêtez et dissociez tous les domaines d'E/S actifs.
3. Arrêtez le domaine `primary`.

   Puisqu'aucun autre domaine n'est lié, le microprogramme met automatiquement le système hors tension.

### Arrêt et redémarrage du système

1. Arrêtez et dissociez tous les domaines non E/S.
2. Arrêtez et dissociez tous les domaines d'E/S actifs.
3. Réinitialisez le domaine `primary`.

   Puisqu'aucun autre domaine n'est lié, le microprogramme effectue automatiquement un cycle d'alimentation du système avant de le réinitialiser. Lorsque le système redémarre, il initialise la dernière configuration Logical Domains enregistrée ou explicitement définie.

#### Taille de la mémoire requise différente de la mémoire allouée

Dans certaines circonstances, Logical Domains Manager arrondit l'allocation de mémoire requise au multiple supérieur suivant de 8 kilo-octets ou 4 mégaoctets. L'exemple suivant le démontre dans le résultat de la commande `ldm list-domain -l`, où la valeur de contrainte est inférieure à la taille réelle allouée :

    Memory:
              Constraints: 1965 M
              raddr          paddr5          size
              0x1000000      0x291000000     1968M

#### Persistance des variables Logical Domains

Les mises à jour de variables persistent après la réinitialisation du domaine, mais pas après un cycle d'alimentation du système, à moins qu'elles ne soient lancées à partir du microprogramme OpenBoot sur le domaine de contrôle ou suivies de l'enregistrement de la configuration sur le contrôleur système.

Dans ce contexte, il est important de noter qu'une réinitialisation du domaine de contrôle peut déclencher un cycle d'alimentation du système :

- Lorsque le domaine de contrôle se réinitialise, si aucun domaine invité n'est lié, et en l'absence de reconfiguration différée, le contrôleur système effectue un cycle d'alimentation du système.

- Lorsque le domaine de contrôle se réinitialise, si des domaines invités sont liés ou actifs (ou si le domaine de contrôle est en pleine reconfiguration différée), le contrôleur système n'effectue pas de cycle d'alimentation du système.

Les variables Logical Domains d'un domaine peuvent être spécifiées en suivant l'une des méthodes suivantes :

- A l'invite OpenBoot

- A l'aide de la commande `eeprom`(1M) du SE Oracle Solaris

- A l'aide de la CLI Logical Domains Manager (`ldm`)

- En modifiant, de manière limitée, à partir du contrôleur système avec la commande `bootmode` ; en fait, uniquement certaines variables et seulement dans la configuration `factory-default`

Le but est que les mises à jour de variables effectuées par l'une de ces méthodes persistent après les réinitialisations du domaine. Les mises à jour de variables se reflètent toujours dans toutes les configurations de domaine logique ultérieures enregistrées sur le contrôleur système.

Dans le logiciel Oracle VM Server for SPARC 3.0, il y a quelques cas où les mises à jour de variables ne persistent pas comme prévu :

- Toutes les méthodes de mise à jour d'une variable persistent pour toutes les réinitialisations de ce domaine. Toutefois, elles ne persistent pas après un cycle d'alimentation du système, sauf si une configuration de domaine logique ultérieure est enregistrée sur le contrôleur système. Les mises à jour d'une variable se font au moyen du microprogramme OpenBoot et des commandes `eeprom` et `ldm`. De plus, sur le domaine de contrôle, les mises à jour effectuées en utilisant le microprogramme OpenBoot persistent après un cycle d'alimentation du système, et ce, même sans enregistrer par la suite une nouvelle configuration de domaine logique sur le contrôleur système.

- Dans tous les cas, lors du rétablissement de la configuration usine par défaut à partir d'une configuration générée par Logical Domains Manager, toutes les variables Logical Domains reprennent au départ leurs valeurs par défaut.

Si vous craignez que les variables Logical Domains changent, procédez de l'une des manières suivantes :

- Accédez à l'invite `ok` du système et mettez à jour les variables.

- Mettez à jour les variables pendant que Logical Domains Manager est désactivé :

      # svcadm disable ldmd
      update variables
      # svcadm enable ldmd

- Si vous exécutez Live Upgrade, effectuez les opérations suivantes :

      # svcadm disable -t ldmd
      # luactivate be3
      # init 6

Si vous modifiez l'heure ou la date sur un domaine logique, par exemple en utilisant la commande `ntpdate`, le changement persiste après toutes les réinitialisations du domaine, mais pas après un cycle d'alimentation de l'hôte. Pour que les changements de date et d'heure persistent, enregistrez la configuration avec le changement en question sur le contrôleur système et initialisez à partir de cette configuration.

Les ID de bogue ont été conservées pour résoudre ces problèmes : 15375997, 15387338, 15387606 et 15415199.

#### Sun SNMP Management Agent d'Oracle ne prend pas en charge plusieurs domaines

Sun SNMP (Simple Network Management Protocol) Management Agent ne prend pas en charge plusieurs domaines. Seul un domaine global est pris en charge.

#### Reconfiguration retardée

Lorsqu'un domaine `primary` est à l'état de reconfiguration retardée, l'alimentation des ressources gérées par Oracle VM Server for SPARC est gérée uniquement après la réinitialisation du domaine `primary`. Les ressources gérées directement par le SE, telles que les CPU gérés par le Power Aware Dispatcher Solaris ne sont pas affectées par cet état.

#### Unités cryptographiques

Les unités cryptographiques discrètes sont uniquement présentes sur les systèmes UltraSPARC T2, UltraSPARC T2 Plus et SPARC T3.

La reconfiguration dynamique des unités cryptographiques vous permet d'ajouter ou de supprimer des unités cryptographiques d'un domaine. Logical Domains Manager détecte automatiquement si un domaine permet la reconfiguration dynamique des unités cryptographiques et active la fonctionnalité pour ce domaine uniquement. De plus, la reconfiguration dynamique des CPU n'est plus désactivée dans les domaines dont des unités cryptographiques sont liées et exécutent une version appropriée du SE Oracle Solaris.

#### Commande `ldmp2v convert` : des messages d'avertissement VxVM durant une initialisation

L'exécution de Veritas Volume Manager (VxVM) 5.x sur le SE Oracle Solaris 10 est la seule version prise en charge (testée) pour l'outil Oracle VM Server for SPARC P2V. Les versions antérieures de VxVM, comme 3.x et 4.x exécutées sur les systèmes d'exploitation Solaris 8 et Solaris 9 peuvent également fonctionner. Dans ces cas, la première initialisation après avoir exécuté la commande `ldmp2v convert` peut engendrer des messages d'avertissement concernant les pilotes VxVM. Vous pouvez ignorer ces messages. Vous pouvez supprimer les anciens packages `VRTS*` après l'initialisation du domaine invité.

    Boot device: disk0:a File and args:
    SunOS Release 5.10 Version Generic_139555-08 64-bit
    Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
    Use is subject to license terms.
    Hostname: normaal
    Configuring devices.
    /kernel/drv/sparcv9/vxdmp: undefined symbol 'romp'
    WARNING: mod_load: cannot load module 'vxdmp'
    WARNING: vxdmp: unable to resolve dependency, module 'misc/ted' not found
    /kernel/drv/sparcv9/vxdmp: undefined symbol 'romp'
    WARNING: mod_load: cannot load module 'vxdmp'
    WARNING: vxdmp: unable to resolve dependency, module 'misc/ted' not found
    /kernel/drv/sparcv9/vxio: undefined symbol 'romp'
    WARNING: mod_load: cannot load module 'vxio'
    WARNING: vxio: unable to resolve dependency, module 'drv/vxdmp' not found
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    WARNING: VxVM vxspec V-5-0-0 vxspec: vxio not loaded. Aborting vxspec load
    WARNING: vxspec : CANNOT INITIALIZE vxio DRIVER
    NOTICE: VxVM not started

#### Configuration requise pour le partitionnement forcé Oracle des licences logicielles

Pour plus d'informations sur les conditions requises pour le partitionnement forcé des licences Oracle, reportez-vous à la section Partitionnement : partitionnement du serveur/matériel.

#### Option de mise à niveau absente lors de l'utilisation de `ldmp2v prepare -R`

Le programme d'installation Oracle Solaris ne comporte pas l'option de mise à niveau lorsque le repère de partition de la tranche sur laquelle réside le système de fichiers root (`/`) n'est pas défini sur `root`. Cette situation se produit si le repère n'est pas défini de manière explicite lors de l'étiquetage du disque d'initialisation de l'invité. Vous pouvez utiliser la commande `format` pour définir le repère de partition comme suit :

    AVAILABLE DISK SELECTIONS:
    0. c0d0 <SUN-DiskImage-10GB cyl 282 alt 2 hd 96 sec 768>
      /virtual-devices@100/channel-devices@200/disk@0
    1. c4t2d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
      /pci@400/pci@0/pci@1/scsi@0/sd@2,0
    2. c4t3d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
      /pci@400/pci@0/pci@1/scsi@0/sd@3,0
    Specify disk (enter its number)[0]: 0
    selecting c0d0
    [disk formatted, no defect list found]
    format> p

    PARTITION MENU:
    0      - change `0' partition
    1      - change `1' partition
    2      - change `2' partition
    3      - change `3' partition
    4      - change `4' partition
    5      - change `5' partition
    6      - change `6' partition
    7      - change `7' partition
    select - select a predefined table
    modify - modify a predefined partition table
    name   - name the current table
    print  - display the current table
    label  - write partition map and label to the disk
    !<cmd> - execute <cmd>, then return
    quit

    partition> 0
    Part      Tag    Flag     Cylinders       Size            Blocks
    0 unassigned    wm       0              0         (0/0/0)          0

    Enter partition id tag[unassigned]: root
    Enter partition permission flags[wm]:
    Enter new starting cyl[0]: 0
    Enter partition size[0b, 0c, 0e, 0.00mb, 0.00gb]: 8g
    partition> label
    Ready to label disk, continue? y

    partition>

#### Le bloc de mémoire ajouté de manière dynamique ne peut être supprimé dynamiquement que dans sa totalité

Le bloc de mémoire ajouté de manière dynamique ne peut être supprimé dynamiquement que dans sa totalité. Cela implique qu'un sous-ensemble de ce bloc de mémoire ne peut pas être supprimé dynamiquement.

Cette situation se présente si un domaine dont la taille de mémoire est petite est dynamiquement augmenté, comme indiqué dans l'exemple suivant.

    # ldm list ldom1
    NAME  STATE FLAGS   CONS VCPU MEMORY UTIL UPTIME
    ldom1 active -n---- 5000 2    1G     0.4% 23h

    # ldm add-mem 16G ldom1

    # ldm rm-mem 8G ldom1
    Memory removal failed because all of the memory is in use.

    # ldm rm-mem 16G ldom1

    # ldm list ldom1
    NAME  STATE FLAGS   CONS VCPU MEMORY UTIL UPTIME
    ldom1 active -n---- 5000 2    1G     0.4% 23h

Solution : ajoutez dynamiquement de la mémoire en petites quantités pour réduire les risques de survenance de ce problème.

Reprise : réinitialisez le domaine.

#### `ldmp2v` : la méthode d'archivage `ufsdump` n'est plus utilisée avec cette commande

La restauration des archives `ufsdump` sur un disque virtuel soutenu par un fichier sur un système de fichiers UFS risque de provoquer le blocage du système. Dans ce cas, la commande `ldmp2v prepare` se ferme. Il est possible que vous rencontriez ce problème si vous restaurez manuellement des archives `ufsdump` pour préparer la commande `ldmp2v prepare -R /altroot` lorsque le disque virtuel est un fichier sur un système de fichiers UFS. En raison de la compatibilité avec les archives `ufsdump` crées précédemment, vous pouvez toujours utiliser la commande `ldmp2v prepare` pour restaurer des archives `ufsdump` sur les disques virtuels qui ne sont pas soutenus par un fichier sur un système de fichiers UFS. Toutefois, l'utilisation des archives `ufsdump` n'est pas recommandée.

#### Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée

N'essayez pas d'exécuter plusieurs opérations de configuration de CPU sur le domaine `primary` alors que sa reconfiguration est retardée. Si vous tentez d'effectuer plusieurs demandes de configuration de CPU, celles-ci seront rejetées.

Solution : effectuez l'une des opérations suivantes :

- Annulez la reconfiguration retardée, lancez-en une autre, puis demandez les modifications de configuration perdues de la dernière reconfiguration retardée.

- Réinitialisez le domaine de contrôle à l'aide du nombre erroné de CPU et effectuez les corrections d'allocation nécessaires après la réinitialisation du domaine.

### Restrictions de la migration de domaine

Les sections suivantes décrivent les restrictions qui s'appliquent à la migration de domaine. Les versions du microprogramme du système et du logiciel Logical Domains Manager doivent être compatibles pour que les migrations soient possibles. De même, la CPU doit répondre à certaines exigences pour que la migration de domaine fonctionne.

Remarque - Un domaine invité qui exécute une application sensible au réseau peut subir un bref retard ou une courte interruption pendant le déroulement de la migration.

#### Restrictions de version pour la migration

Si vous tentez une migration en direct à partir d'un domaine initialisé avec la version 8.4 ou une version ultérieure du microprogramme vers un système exécutant une ancienne version du microprogramme, la migration échoue. L'échec est dû à une incompatibilité entre l'API de l'hyperviseur des versions anciennes et celui des versions plus récentes du microprogramme. Dans ce cas, le message suivant apparaît :

    # ldm migrate ldg1 root@target
    Target Password:
    Domain ldg1 is using features of the system firmware that
    are not supported in the version of the firmware running on
    the target machine.

    Domain Migration of LDom ldg1 failed

Notez que vous pouvez effectuer une migration en direct d'un domaine initialisé sur un système équipé d'une version antérieure à la version 8.4 du microprogramme vers un système qui exécute la version 8.4 ou une version ultérieure du microprogramme.

#### Prise en charge de la migration `cpu-arch=generic` pour SPARC M5 et SPARC T5

ID de bogue 15805135 : dans Oracle VM Server for SPARC 3.0, il n'est pas possible de faire migrer un domaine d'un type de plate-forme différent (tel que SPARC T2, SPARC T2 Plus, SPARC T3 ou SPARC T4) vers une plate-forme SPARC T5 ou SPARC M5. Ce type de migration est impossible même si vous définissez `cpu-arch=generic`.

Pour les plates-formes SPARC T5 et SPARC M5, vous pouvez uniquement effectuer des opérations de migration entre des systèmes dont le type de plate-forme est identique, comme par exemple d'une plate-forme SPARC T5-2 à une plate-forme SPARC T5-8 ou d'une plate-forme SPARC M5-32 à une autre plate-forme SPARC M5-32. Cette restriction s'applique uniquement aux plates-formes SPARC T5 et SPARC M5.

#### Restrictions de la CPU pour la migration

Si le domaine à migrer exécute une version SE Oracle Solaris antérieure au SE Oracle Solaris 10 8/11, le message suivant peut s'afficher au cours de la migration :

    Domain domain-name is not running an operating system that is
    compatible with the latest migration functionality.

Les exigences et les restrictions suivantes en matière de CPU s'appliquent uniquement lorsque vous exécutez un SE antérieur au SE Oracle Solaris 10 8/11 :

- Des coeurs complets doivent être alloués au domaine migré. Si le nombre de threads dans le domaine à migrer est inférieur à un coeur complet, les threads supplémentaires ne sont disponibles à aucun domaine tant que le domaine migré n'est pas réinitialisé.

- Après une migration, la reconfiguration dynamique (DR) de la CPU est désactivée pour le domaine migré tant qu'il n'a pas été réinitialisé. A ce stade, vous pouvez utiliser la DR sur le domaine migré.

- La machine cible doit disposer de suffisamment de coeurs complets totalement libres pour fournir le nombre de threads requis pour le domaine migré. Après la migration, si un coeur complet n'est que partiellement utilisé par le domaine migré, les threads supplémentaires ne sont disponibles à aucun domaine tant que le domaine migré n'est pas réinitialisé.

Ces restrictions s'appliquent également lorsque vous tentez de migrer un domaine exécuté dans OpenBoot ou le débogeur de noyau. Reportez-vous à la section Migration d’un domaine à partir de la PROM OpenBoot ou un domaine en cours d’exécution dans le débogueur de noyau du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

### Problèmes liés à Oracle VM Server for SPARC MIB

Cette section récapitule les problèmes que vous risquez de rencontrer lors de l'utilisation du logiciel Oracle VM Server for SPARC Management Information Base (MIB).

#### La commande `snmptable` ne fonctionne pas avec l'option Version 2 ou Version 3

ID de bogue 15376861 : des tables SNMP vides sont renvoyées lorsque vous interrogez le logiciel Oracle VM Server for SPARC MIB 2.1 à l'aide de la commande `snmptable` et des options `-v2c` ou `-v3`. La commande `snmptable` avec l'option `-v1` fonctionne comme prévu.

Solution : utilisez l'option `-CB` pour utiliser uniquement `GETNEXT`, et non `GETBULK`, pour l'extraction des données. Reportez-vous à la section Procédure de récupération d’objets Oracle VM Server for SPARC MIB du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

### Bogues liés au logiciel Oracle VM Server for SPARC 3.0

Cette section récapitule les bogues que vous risquez de rencontrer lors de l'utilisation de cette version du logiciel. Les bogues les plus récents sont décrits en premier. Des solutions de contournement et des procédures de récupération sont spécifiées, le cas échéant.

#### La panique `send_mondo_set: timeout` se produit en cas d'utilisation de la commande `ldm stop` sur un domaine invité soumis à une charge de travail importante

ID de bogue 16486383 : affectez directement un périphérique ou bus PCI à un domaine invité auquel aucun coeur n'a été attribué à partir du `/SYS/DCU` où la carte PCI réside physiquement. Etant donné que l'hyperviseur réinitialise les périphériques PCI pour le compte des domaines invités, il est possible qu'au cours de chaque réinitialisation de domaine invité, un domaine comportant des coeurs sur le DCU connecté au périphérique PCI panique. Lorsque plusieurs périphériques PCI sont affectés à des invités non-DCU-local, le risque de panique augmente.

Solution : effectuez l'une des opérations solutions :

- Assurez-vous que lorsque vous affectez des périphériques PCI à un domaine invité, la carte se trouve physiquement dans le même DCU que les coeurs.

- Affectez manuellement les coeurs afin de disposer d'une certaine flexibilité pour le placement de la carte.

  Par exemple, pour un périphérique PCI sur `IOU0` (`pci_0` à `pci_15`), choisissez un coeur entre `0` et `127` et allouez-le au domaine.

      # ldm add-core cid=16 domain

  Visualisez les coeurs du système à l'aide de la commande suivante :

      # ldm ls-devices -a core

  Pour un périphérique PCI sur `IOU1` (`pci_16` à `pci_31`), choisissez un coeur entre `128` et `255`. Pour un périphérique PCI sur `IOU2` (`pci_32` à `pci_47`), choisissez un coeur entre `256` et `383`. Pour un périphérique PCI sur `IOU3` (`pci_48` à `pci_63`), choisissez un coeur entre `384` et `511`.

#### SPARC T5 et SPARC M5 : lors de l'utilisation de périphériques SR-IOV, les tentatives de dissocier ou de supprimer des ressources se bloquent et ne peuvent pas être arrêtées à l'aide de Ctrl-C

ID de bogue 16426940 : sur un système SPARC T5 ou SPARC M5 avec configuration SR-IOV, vous risquez de subir un blocage qui ne peut pas être arrêté à l'aide de Ctrl-C. Ce blocage se produit rarement lorsque vous utilisez la commande `ldm unbind` ou la commande `ldm rm-io`.

Solution : réinitialisez l'instance du SE Oracle Solaris qui s'exécute sur le domaine `primary`. Réinitialisez également les domaines invités exécutant des ressources d'E/S partagées par le domaine `primary`.

#### L'ajout dynamique d'un strand défectueux à un domaine peut entraîner une panique

ID de bogue 16301304 : dans certaines circonstances, un coeur défectueux n'est pas immédiatement mis sur liste noire par Logical Domains Manager. Par conséquent, il est possible d'ajouter des strands issus du coeur défectueux à un domaine. Si de tels strands sont ajoutés à l'aide de la reconfiguration dynamique de CPU virtuelle, le domaine invité panique et un message semblable au suivant s'affiche :

    panic[cpu10]/thread=2a1003e9c60: promif_start_cpu: failed to start cpu 12 (6)

Si un strand défectueux est ajouté à un domaine qui n'est pas en cours d'exécution, les messages suivants apparaissent sur la console lors du démarrage du domaine :

    NOTICE: cpux is not runnable and will not be brought online
    NOTICE: cpux removed from system

Ces messages apparaissent également lors de toutes les réinitialisations ultérieures. Ces messages ne posent pas problème dans le domaine en cours d'exécution, mais les CPU figurant dans la liste ne sont pas disponible au domaine invité.

Solution : pour éviter ces problèmes, écartez les strands défectueux de tous les domaines. Si les strands défectueux ne sont pas utilisés, ils ne peuvent pas avoir d'impact négatif sur les autres domaines du système.

#### Des sous-périphériques subordonnés à un périphérique PCIe retournent à l'état "sans nom"

ID de bogue 16299053 : lorsque vous désactivez un périphérique PCIe, un comportement inattendu peut s'ensuivre. Les sous-périphériques subordonnés au périphérique PCIe désactivé retournent à l'état "sans nom" tandis que le périphérique PCIe est toujours la propriété du domaine.

Solution : si vous décidez de désactiver un emplacement PCIe sur ILOM, assurez-vous que l'emplacement PCIe n'est pas affecté à un domaine à l'aide de la fonction d'E/S directes (DIO). En d'autres termes, assurez-vous d'abord que l'emplacement PCIe est affecté au domaine root correspondant avant de désactiver l'emplacement sur ILOM.

Si vous désactivez l'emplacement PCIe sur ILOM alors que l'emplacement PCIe est affecté à un domaine avec DIO, arrêtez le domaine concerné et réaffectez le périphérique au domaine root pour que le comportement soit normal.

#### SPARC M5-32 : `panic: mpo_cpu_add: Cannot read MD`

ID de bogue 16238762 : sur un serveur SPARC M5-32 avec au moins 2,4 To de mémoire, une tentative d'augmenter le nombre de CPU dans le domaine `primary` de 6 à 1056 CPU entraîne une panique du noyau et le message suivant s'affiche :

    mpo_cpu_add: Cannot read MD

La procédure suivante est à l'origine de la panique :

1. Procédez à la mise sous tension avec un DCU assigné à un hôte.

   Par exemple, affectez `DCU0` à `HOST0`.

2. Créez des domaines invités.

3. Enregistrez une configuration sur le processeur de service.

4. Mettez l'hôte hors tension.

5. Assignez un autre DCU à l'hôte.

   Par exemple, assignez `DCU1` à `HOST0`.

6. Mettez l'hôte sous tension.

   Le microprogramme vérifie que la configuration est "amorçable". Cette vérification garantit que toutes les CPU, la mémoire et les E/S présentes au moment de la création de la configuration le sont toujours. Le microprogramme génère également un nouveau PRI pour décrire la configuration de l'ensemble du système.

   La configuration est mise sous tension avec succès et les domaines invités sont initialisés.

7. Tentez d'ajouter de façon dynamique une CPU à un domaine existant.

   Logical Domains génère un nouveau GMD qui reflète les informations de latence correctes, mais le SE Oracle Solaris ne peut pas analyser les nouvelles informations et panique.

Solution : pour éviter la panique, n'effectuez pas les étapes énumérées dans la description du problème.

Toutefois, si vous avez déjà effectué ces étapes et que vous avez subi la panique, effectuez les opérations suivantes :

1. Effectuez une action après avoir initialisé une configuration enregistrée dans un domaine physique de taille moindre. Retirez une CPU de chaque domaine actif par exemple.

2. Réinitialisez le domaine.

3. Dissociez le domaine.

4. Liez à nouveau tout domaine lié.

5. Enregistrez une nouvelle configuration sur le processeur de service.

#### SPARC M5-32 : un basculement du complexe root risque d'entraîner une configuration de domaine invité d'E/S directes incorrecte

ID de bogue 16232834 : la plate-forme SPARC M5 comprend des disques à deux ports internes et les deux chemins associés. Un basculement du complexe root risque d'entraîner une configuration de domaine invité d'E/S directes incorrecte.

Solution : faites en sorte que les deux cartes EMS (PCIe Express Module) impaires ou les deux cartes EMS paires soient affectées au même domaine. Par exemple, si les deux cartes `EMS1` et `EMS3` sont affectées à un même domaine, les deux chemins d'accès au disque résident dans le domaine concerné. Il en va de même lorsque les cartes `EMS0` et `EMS2` sont affectées au même domaine.

Procédez comme suit :

1. Désactivez la fonction de basculement du complexe root à l'aide d'ILOM.

       -> set /HOSTx ioreconfigure=false

   x peut être remplacé par une valeur quelconque allant de `0` à `3`.

2. A l'aide de la commande `ldm add-io`, affectez les deux cartes EMS impaires ou les deux cartes EMS paires de la même unité d'E/S (IOU, I/O unit) à un domaine invité.

Dans cet exemple de configuration hôte formé d'une unité de configuration (DCU, domain configuration unit) à deux domaines, les commandes suivantes affectent des cartes EMS au domaine invité `ldg1`.

Les complexes root `pci_40` et `pci_44` sont tout d'abord supprimés du domaine de contrôle.

    # ldm rm-io pci_40 primary
    # ldm rm-io pci_44 primary

Puis les complexes root `pci_40` et `pci_42` sont ajoutés au domaine invité `ldg1`.

    # ldm add-io pci_40 lgd1
    # ldm add-io pci_44 lgd1

De même, vous pouvez affecter les complexes root `pci_48` et `pci_52` ou les quatre bus au domaine hôte.

Après avoir apporté ces modifications, affichez la configuration mise à jour à l'aide de la commande `ldm ls-io`.

    # ldm ls-io
    NAME                                      TYPE   BUS      DOMAIN   STATUS
    ----                                      ----   ---      ------   ------
    pci_32                                    BUS    pci_32   primary
    pci_33                                    BUS    pci_33   primary
    pci_34                                    BUS    pci_34   primary
    pci_35                                    BUS    pci_35   primary
    pci_36                                    BUS    pci_36   primary
    pci_37                                    BUS    pci_37   primary
    pci_38                                    BUS    pci_38   primary
    pci_39                                    BUS    pci_39   primary
    pci_40                                    BUS    pci_40   primary
    pci_41                                    BUS    pci_41   primary
    pci_42                                    BUS    pci_42   primary
    pci_43                                    BUS    pci_43   primary
    pci_44                                    BUS    pci_44   primary
    pci_45                                    BUS    pci_45   primary
    pci_46                                    BUS    pci_46   primary
    pci_47                                    BUS    pci_47   primary
    pci_48                                    BUS    pci_48   primary
    pci_49                                    BUS    pci_49   primary
    pci_50                                    BUS    pci_50   primary
    pci_51                                    BUS    pci_51   primary
    pci_52                                    BUS    pci_52   primary
    pci_53                                    BUS    pci_53   primary
    pci_54                                    BUS    pci_54   primary
    pci_55                                    BUS    pci_55   primary
    pci_56                                    BUS    pci_56   primary
    pci_57                                    BUS    pci_57   primary
    pci_58                                    BUS    pci_58   primary
    pci_59                                    BUS    pci_59   primary
    /SYS/IOU2/PCIE3                           PCIE   pci_32   primary  OCC
    /SYS/IOU2/EMS1/CARD/NET0                  PCIE   pci_32   primary  OCC
    /SYS/IOU2/EMS1/CARD/SCSI                  PCIE   pci_32   primary  OCC
    /SYS/IOU2/PCIE2                           PCIE   pci_33   primary  OCC
    /SYS/IOU2/PCIE5                           PCIE   pci_34   primary  EMP
    /SYS/IOU2/PCIE8                           PCIE   pci_35   primary  EMP
    /SYS/IOU2/PCIE11                          PCIE   pci_36   primary  EMP
    /SYS/IOU2/EMS3/CARD/NET0                  PCIE   pci_36   primary  OCC
    /SYS/IOU2/EMS3/CARD/SCSI                  PCIE   pci_36   primary  OCC
    /SYS/IOU2/PCIE10                          PCIE   pci_37   primary  OCC
    /SYS/IOU2/PCIE13                          PCIE   pci_38   primary  OCC
    /SYS/IOU2/PCIE16                          PCIE   pci_39   primary  OCC
    /SYS/IOU2/PCIE6                           PCIE   pci_40   primary  EMP
    /SYS/IOU2/EMS2/CARD/NET0                  PCIE   pci_40   primary  OCC
    /SYS/IOU2/EMS2/CARD/SCSI                  PCIE   pci_40   primary  OCC
    /SYS/IOU2/PCIE7                           PCIE   pci_41   primary  EMP
    /SYS/IOU2/PCIE4                           PCIE   pci_42   primary  EMP
    /SYS/IOU2/PCIE1                           PCIE   pci_43   primary  OCC
    /SYS/IOU2/PCIE14                          PCIE   pci_44   primary  OCC
    /SYS/IOU2/EMS4/CARD/NET0                  PCIE   pci_44   primary  OCC
    /SYS/IOU2/EMS4/CARD/SCSI                  PCIE   pci_44   primary  OCC
    /SYS/IOU2/PCIE15                          PCIE   pci_45   primary  OCC
    /SYS/IOU2/PCIE12                          PCIE   pci_46   primary  EMP
    /SYS/IOU2/PCIE9                           PCIE   pci_47   primary  EMP
    /SYS/IOU3/PCIE3                           PCIE   pci_48   primary  EMP
    /SYS/IOU3/EMS1/CARD/NET0                  PCIE   pci_48   primary  OCC
    /SYS/IOU3/EMS1/CARD/SCSI                  PCIE   pci_48   primary  OCC
    /SYS/IOU3/PCIE2                           PCIE   pci_49   primary  OCC
    /SYS/IOU3/PCIE5                           PCIE   pci_50   primary  OCC
    /SYS/IOU3/PCIE8                           PCIE   pci_51   primary  EMP
    /SYS/IOU3/PCIE11                          PCIE   pci_52   primary  EMP
    /SYS/IOU3/PCIE12                          PCIE   pci_52   primary  EMP
    /SYS/IOU3/EMS3/CARD/NET0                  PCIE   pci_52   primary  OCC
    /SYS/IOU3/EMS3/CARD/SCSI                  PCIE   pci_52   primary  OCC
    /SYS/IOU3/PCIE9                           PCIE   pci_53   primary  OCC
    /SYS/IOU3/PCIE10                          PCIE   pci_53   primary  OCC
    /SYS/IOU3/PCIE13                          PCIE   pci_54   primary  EMP
    /SYS/IOU3/PCIE14                          PCIE   pci_54   primary  EMP
    /SYS/IOU3/EMS4/CARD/NET0                  PCIE   pci_54   primary  OCC
    /SYS/IOU3/EMS4/CARD/SCSI                  PCIE   pci_54   primary  OCC
    /SYS/IOU3/PCIE15                          PCIE   pci_55   primary  EMP
    /SYS/IOU3/PCIE16                          PCIE   pci_55   primary  EMP
    /SYS/IOU3/PCIE6                           PCIE   pci_56   primary  OCC
    /SYS/IOU3/EMS2/CARD/NET0                  PCIE   pci_56   primary  OCC

#### SPARC M5-32 : problème lié aux disques accessibles via plusieurs chemins d'E/S directs

ID de bogue 16232834 : lorsque vous utilisez la commande `ldm add-vcpu` pour assigner des CPU à un domaine, le SE Oracle Solaris peut paniquer avec affichage du message suivant :

    panic[cpu16]/thread=c4012102c860: mpo_cpu_add: Cannot read MD

Cette panique se produit dans les cas suivants :

- Des DCU supplémentaires ont été attribués à un hôte

- L'hôte est démarré à l'aide d'une configuration SP précédemment enregistrée qui ne contient pas tout le matériel attribué à l'hôte.

Le domaine cible de l'opération `ldm add-vcpu` est le domaine qui panique. Le domaine est récupéré avec les CPU supplémentaires lors de la réinitialisation.

Solution : n'utilisez pas des configurations générées avec un nombre de ressources matérielles moindre que celui affecté à l'hôte.

Afin d'éviter ce problème, n'ajoutez pas de CPU selon la procédure détaillée dans la description du problème. Ou effectuez les opérations suivantes :

1. Générez une nouvelle configuration de processeur de service après l'ajout des DCU.

   Par exemple, la commande suivante crée une configuration nommée `new-config-more-dcus` :

       # ldm add-config new-config-more-dcus

2. Arrêtez le domaine.

3. Arrêtez l'hôte.

       -> stop /HOST

4. Démarrez l'hôte.

       -> start /HOST

#### Le périphérique `ixgbevf` des domaines SR-IOV risque d'être désactivé après la réinitialisation du domaine `primary`

ID de bogue 16224353 : après avoir réinitialisé le domaine primary, les instances `ixgbevf` du domaine `primary` risquent de ne pas fonctionner.

Solution : aucune.

#### Après la réinitialisation du domaine `primary` d'Oracle Solaris 10 1/13, une interface de fonction virtuelle risque de ne pas être automatiquement raccordée ou de ne pas se voir attribuer d'adresse IP

ID de bogue 16219069 : sur un domaine `primary` exécutant le SE Oracle Solaris 10 1/13, les interfaces de fonction virtuelle risquent de ne pas être automatiquement raccordées ou de ne pas se voir attribuer d'adresse IP sur la base du fichier `/etc/hostname.`vf-interface.

Ce problème se produit lorsque vous initialisez ou réinitialisez un système SPARC T3, SPARC T4 ou SPARC T5 exécutant le SE Oracle Solaris 10 1/13 sur le domaine `primary`. Ce problème affecte les fonctions virtuelles créées sur les fonctions physiques intégrées et sur les fonctions physiques additionnelles. Ce problème ne se produit pas lorsque vous initialisez une image de domaine invité Logical Domains.

#### Le plafonnement de consommation d'ILOM est supposé synchroniser les mises à jour d'ajustement avec les mises à jour `/SYS/VPS`

ID de bogue 16205895 : dans chaque domaine physique SPARC M5, le plafonnement de la consommation énergétique surveille le capteur de consommation énergétique du domaine concerné, `/SYS/VPS`, pour déterminer à quel moment les fréquences de CPU doivent être ajustées pour respecter la limite énergétique. Ce capteur n'est mis à jour que toutes les 20 à 30 secondes. Toutefois, le capteur est interrogé et les ajustements énergétiques sont effectués en fonction de cette valeur à quelques secondes d'intervalle. Les valeurs obsolètes de consommation d'énergie peuvent entraîner des pics dans les régulations et dérégulations des fréquences de CPU tandis que le système s'ajuste inutilement.

Solution : n'utilisez pas de plafonnement de la consommation énergétique.

#### Un domaine invité ne peut pas s'initialiser lorsque les périphériques prêtés par IOV sont désactivés

ID de bogue 16098592 : lorsqu'un périphérique de fonction physique ou de fonction virtuelle PCIe est prêté à un domaine invité, vous pouvez utiliser la CLI d'ILOM ou la structure de gestion des pannes pour marquer le périphérique comme désactivé dans la base de données dynamique (DDB, dynamic database). Au démarrage suivant du système (mise sous tension, réinitialisation), la configuration de l'hôte reflète l'état de la DDB à l'intention de l'hyperviseur au moyen du descripteur de la machine (lorsque des MD PRI/invités, etc. sont créés). L'hyperviseur désactive ces périphériques mais le SE Oracle Solaris ne sait pas que le périphérique est désactivé.

Lorsque le domaine invité qui contient ce périphérique est démarré, le domaine se bloque. Le domaine se bloque car l'instance d'Oracle Solaris propriétaire de la topologie Fabric PCIe ne peut pas afficher le périphérique étant donné que l'hyperviseur a désactivé le périphérique. Par conséquent, lorsque OBP tente de sonder les périphériques PCIe, l'hyperviseur bloque l'accès de sorte que l'OBP réessaye continuellement.

Solution : supprimez de ce domaine invité les périphériques qui sont passés à l'état `UNK` (inconnu) en procédant comme suit :

1. Arrêtez le domaine invité.

2. Supprimez du domaine invité les périphériques qui se trouvent dans l'état inconnu.

   Utilisez la commande `ldm rm-io`.

3. Redémarrez le domaine invité.

#### Panique `mutex_enter: bad mutex` dans le domaine `primary` une réinitialisation ou un arrêt

ID de bogue 16080855 : lors d'une réinitialisation ou d'un arrêt du domaine `primary`, le domaine `primary` peut subir une panique du noyau avec un message semblable au suivant :

    panic[cpu2]/thread=c40043b818a0: mutex_enter: bad mutex, lp=c4005fa01c88
    owner=c4005f70aa80 thread=c40043b818a0

    000002a1075c3630 ldc:ldc_mem_rdwr_cookie+20 (c4005fa01c80,
    c4004e2c2000,2a1075c37c8, 6c80000, 1, 0)
    %l0-3: 00000000001356a4 0000000000136800 0000000000000380
    00000000000002ff
    %l4-7: 00000000001ad3f8 0000000000000004 00000000ffbffb9c
    0000c4005fa01c88
    000002a1075c3710 vldc:i_vldc_ioctl_write_cookie+a4 (c4004c400030,
    380,ffbff898, 100003, 0, 70233400)
    %l0-3: 0000000006c80000 0000000000156dc8 0000000000000380
    0000000000100003
    %l4-7: 00000000702337b0 000002a1075c37c8 0000000000040000
    0000000000000000
    000002a1075c37f0 vldc:vldc_ioctl+1a4 (3101, c4004c400030,
    ffbff898,c4004c400000, c4004c438030, 0)
    %l0-3: 0000000000100003 0000000000000000 000000007b340400
    0000c4004c438030
    %l4-7: 0000c4004c400030 0000000000000000 0000000000000000
    0000000000000000
    000002a1075c38a0 genunix:fop_ioctl+d0 (c4004d327800, 0, ffbff898,
    100003,c4004384f718, 2a1075c3acc)
    %l0-3: 0000000000003103 0000000000100003 000000000133ce94
    0000c4002352a480
    %l4-7: 0000000000000000 0000000000000002 00000000000000c0
    0000000000000000
    000002a1075c3970 genunix:ioctl+16c (3, 3103, ffbff898, 3, 134d50, 0)
    %l0-3: 0000c40040e00a50 000000000000c6d3 0000000000000003
    0000030000002000
    %l4-7: 0000000000000003 0000000000000004 0000000000000000
    0000000000000000

Reprise : autorisez le domaine `primary` à se réinitialiser. Si le domaine primary est configuré pour ne pas se réinitialiser après un arrêt brutal, initialisez-le manuellement.

#### SPARC M5-32 : le contrôleur LSI-SAS est exporté de façon incorrecte avec SR-IOV.

ID de bogue 16071170 : sur un système SPARC M5-32, les contrôleurs SAS internes sont exportés en tant que contrôleurs SR-IOV bien que ces cartes ne prennent pas en charge SR-IOV.

Le journal d'Oracle VM Server for SPARC consigne les messages suivants lors de la tentative de création de la fonction physique sur ces cartes :

    Dec 11 04:27:54 warning: Dropping pf
    pci@d00/pci@1/pci@0/pci@0/pci@0/pci@4/LSI,sas@0: no IOV capable driver
    Dec 11 04:27:54 warning: Dropping pf
    pci@d80/pci@1/pci@0/pci@c/pci@0/pci@4/LSI,sas@0: no IOV capable driver
    Dec 11 04:27:54 warning: Dropping pf
    pci@c00/pci@1/pci@0/pci@c/pci@0/pci@4/LSI,sas@0: no IOV capable driver
    Dec 11 04:27:54 warning: Dropping pf
    pci@e00/pci@1/pci@0/pci@0/pci@0/pci@4/LSI,sas@0: no IOV capable driver

Le système est doté de quatre ports de contrôleur SAS LSI, chacun situé dans un IOU de l'assemblage SPARC M5-32. Cette erreur est signalée pour chaque port.

Solution : vous pouvez ignorer ces messages. Ces messages indiquent seulement que les contrôleurs SAS LSI du système sont compatibles avec SR-IOV, mais qu'aucune prise en charge de SR-IOV n'est disponible pour ce matériel.

#### Impossible de définir un MTU Jumbo pour les fonctions virtuelles `sxge` dans le domaine `primary` d'un système SPARC T5-1B

ID de bogue 16059331 : le pilote `sxge` ne peut pas définir les MTU Jumbo correctement pour ses fonctions virtuelles sur le domaine `primary`.

Solution : modifiez manuellement le fichier `/kernel/drv/sxge.conf` pour configurer le MTU Jumbo sur les interfaces de fonction virtuelle `sxge` dans le domaine invité.

#### Les ressources précédemment mises sur liste noire sont marquées à tort comme disponibles et en attente d'évacuation après un redémarrage de Logical Domains Manager

ID de bogue 16016576 : si Logical Domains Manager est redémarré, soit manuellement, soit en raison d'une réinitialisation du domaine de contrôle, toutes les ressources défectueuses qui ont été placées sur liste noire deviennent disponibles. Ces ressources sont à tort marquées comme disponibles et en attente d'évacuation, bien qu'elles aient été précédemment évacuées et ajoutées à la liste noire. Logical Domains Manager n'empêche pas l'ajout de telles ressources à un domaine.

Reprise : aucune récupération n'est nécessaire. Les ressources évacuées ne sont assignées à aucun domaine et n'affectent donc pas la configuration actuelle du système. Toutefois, étant donné que ces ressources étaient précédemment défectueuses, prenez garde de ne pas les attribuer à un domaine du système.

#### `ldmd` ne peut pas définir les valeurs des propriétés `mac-addr` et `alt-mac-addr` pour le périphérique `sxge`

ID de bogue 15974640 : la commande `ldm` ne parvient pas à définir correctement les valeurs des propriétés `mac-addr` et `alt-mac-addrs` pour le périphérique `sxge`. Par conséquent, le démon `ldmd` signale une adresse MAC incohérente. D'autre part, tous les groupements de liaisons basés sur l'adresse MAC de la VNIC échouent également.

#### Deux propriétés sont manquantes dans la sortie `ldm list-io -d` d'un périphérique `sxge` sur SPARC T5-1B

ID de bogue 15974547 : en cas d'exécution sur un système SPARC T5-1B comportant `sxge`, la sortie `ldm list-io -d` PF-device n'affiche pas les propriétés `max-vlans` ou `max-vf-mtu`. Ces propriétés sont présentes sur les systèmes SPARC T5-1B avec `ixgbe` ainsi que sur les systèmes autres que les lames.

La valeur de la propriété `max-vlans` est manquante. La valeur doit être égale à `0` car le périphérique `sxge` ne prend pas en charge le balisage VLAN du matériel. La valeur de propriété `max-vf-mtu` est fixée à `1500`, ce qui empêche le périphérique de fonction physique de définir le MTU Jumbo pour les fonctions virtuelles.

#### Restrictions supplémentaires pour la migration

ID de bogue 15858731 : pour les systèmes Fujitsu M10, la restriction suivante remplace les informations décrites dans la section Migration d’un domaine à partir de la PROM OpenBoot ou un domaine en cours d’exécution dans le débogueur de noyau du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

Lorsqu'un domaine à migrer est en cours d'exécution dans OpenBoot ou dans le débogueur de noyau (`kmdb`), la tentative de migration échoue toujours si la machine source ou cible est un système Fujitsu M10. Dans le cas où le domaine à migrer ne contient qu'une seule CPU, le message d'erreur suivant est susceptible de s'afficher :

    # ldm migrate ldg1 system2
    Non-cooperative migration is not supported on this platform.

#### Echec de `ldmconfig` : la solution pour l'ID de bogue 15972394 exclut la configuration `factory-default` non modifiée

ID de bogue 15829698 : la commande `ldmconfig` ne fonctionne pas avec le logiciel Oracle VM Server for SPARC 3.0 car elle fonctionne uniquement lorsque le système exécute une configuration `factory-default` non modifiée. Lorsqu'un bogue se produit dans Oracle VM Server for SPARC 3.0, la configuration est toujours signalée comme modifiée.

Solution : au lieu d'effectuer une installation initiale d'Oracle VM Server for SPARC 3.0, installez d'abord Oracle VM Server for SPARC 2.2 puis exécutez `ldmconfig`. Une fois que les domaines sont créés, effectuez la mise à niveau du package `SUNWldm` vers Oracle VM Server for SPARC 3.0.

#### La reconfiguration dynamique de CPU d'un très grand nombre de CPU virtuelles peut échouer

ID de bogue 15826354 : la reconfiguration dynamique d'un très grand nombre de CPU entraîne le renvoi d'un échec par le démon `ldmd`. Bien que `ldmd` arrive à expiration, l'opération de reconfiguration dynamique continue en arrière-plan et finit par aboutir. Néanmoins, `ldmd` n'est plus aligné avec le domaine résultant et les opérations de reconfiguration dynamique ultérieures risquent de ne pas être autorisées.

Par exemple :

    # ldm ls
    NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
    primary          active     -n-cv-  UART    7     20G      2.7%  0.4%  1h 41m
    ldg0             active     -n----  5000    761   16G       75%   51%  6m

    # ldm rm-vcpu 760 ldg0
    Request to remove cpu(s) sent, but no valid response received
    VCPU(s) will remain allocated to the domain, but might
    not be available to the guest OS
    Resource removal failed

    # ldm set-vcpu 1 ldg0
    Busy executing earlier command; please try again later.
    Unable to remove the requested VCPUs from domain ldg0
    Resource modification failed

    # ldm ls
    NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
    primary          active     -n-cv-  UART    7     20G      0.9%  0.1%  1h 45m
    ldg0             active     -n----  5000    761   16G      100%  0.0%  10m

Solution : attendez quelques minutes, puis réexécutez la commande `ldm set-vcpu` :

    # ldm set-vcpu 1 ldg0
    # ldm ls
    NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
    primary          active     -n-cv-  UART    7     20G      0.9%  0.1%  1h 50m
    ldg0             active     -n----  5000    1     16G       52%  0.0%  15m

Notez que 760 dépasse le maximum recommandé.

#### Le délai d'attente de la migration d'un domaine invité avec réseaux virtuels HIO et `cpu-arch=generic` expire lors de l'attente de la suspension du domaine

ID de bogue 15825538 : en cas d'exécution d'une migration en direct sécurisée (`ldm migrate`) sur un domaine logique configuré avec les fonctions d'interfaces d'E/S réseau hybrides (`mode=hybrid`) et de migration entre les CPU activées (`cpu-arch=generic`), le délai d'attente de la migration peut expirer et le domaine rester dans un état suspendu.

Reprise : redémarrez le domaine logique.

Solution : n'utilisez pas de périphériques de réseau virtuel d'E/S hybride pour une migration en direct entre les CPU.

#### SPARCT4-4 : impossible d'associer un domaine invité

ID de bogue 15825330 : Oracle VM Server for SPARC 3.0 se bloque au démarrage de certaines configurations SPARC T4-4 comportant une seule carte de processeur.

Solution : assurez-vous qu'il y a toujours une carte processeur dans les emplacements dédiés aux processeurs 0 et 1. Le redémarrage du système dans une configuration de ce type permet au logiciel de démarrerOracle VM Server for SPARC 3.0.

#### Un domaine invité peut paniquer lorsque qu'une reconfiguration dynamique de CPU est effectuée après une migration entre les CPU

ID de bogue 15825060 : lorsque vous utilisez la migration en direct pour migrer un domaine créé sur un système SPARC T3 ou SPARC T4 vers un système UltraSPARC T2 ou UltraSPARC T2 Plus, l'opération de reconfiguration dynamique des CPU qui en découle peut entraîner une panique du système. Le message de panique affiché est similaire à ce qui suit :

    panic[cpu8]/thread=2a102491c60: cpu8: dev_mondo queue
    configuration failed, error 6

Reprise : aucune.

Solution : lorsque vous migrez un domaine créé sur un système SPARC T3 ou SPARC T4 vers un système UltraSPARC T2 ou UltraSPARC T2 Plus, ne migrez pas de domaine actif. Arrêtez plutôt le domaine avant de démarrer le processus de migration.

#### Echec de la réinitialisation du domaine invité lorsque la mémoire est très fragmentée

ID de bogue 15824270 : il est possible qu'un domaine qui exécute le SE Oracle Solaris 11.1 et dont les cessions de mémoires sont très fragmentées ne puisse pas se réinitialiser. Dans ce cas, le message suivant s'affiche :

    ERROR: Last Trap: Fast Data Access MMU Miss

Solution : essayez d'abord de varier la taille de la mémoire associée au domaine invité qui ne s'initialise pas. Si cette solution échoue ou si le domaine `primary` est affecté, arrêtez le système et redémarrez dans une autre configuration de processeur de service.

#### La reconfiguration dynamique des CPU disponibles entraîne une panique `lpl_topo_verify fail -5`

ID de bogue 15823255 : un domaine sur un système SPARC M5 comportant deux DCU ou plus est susceptible de subir une panique dans les conditions suivantes :

- Le domaine doit être configuré avec deux DCU au moins

- Un seul DCU est configuré avec des CPU

- Les autres DCU ne doivent pas être configurés avec des CPU, mais avec de la mémoire

- L'une des opérations suivantes entraîne la panique :

  - Démarrage ou arrêt des CPU

  - Réalisation d'une reconfiguration dynamique des CPU

  - Création ou suppression d'un jeu de processeurs

  - Ajout ou suppression de processeurs d'un jeu de processeurs

Vous pouvez voir le message d'erreur grave sur la console et dans le fichier `/var/adm/messages` lorsque le système se réinitialise :

    panlc [cpu4]/thread=0x30012a008: : lpl_topo_verify failed: -5

Solution : effectuez les opérations suivantes :

1. Evitez d'effectuer les opérations susceptibles d'entraîner la panique.

2. Ajoutez la ligne suivante dans le fichier `/etc/system` :

       set lgrp_topo_levels=2

3. Réinitialisez le système.

   Après la réinitialisation du système, vous pouvez en toute sécurité effectuer les opérations qui provoquaient la panique.

#### Les domaines root ne peuvent pas présenter de dépendances à d'autres domaines root

ID de bogue 15823203 : les périphériques d'extrémité PCIe ou les fonctions virtuelles SR-IOV d'un domaine root propriétaire d'un bus PCIe ne peuvent pas être assignés à un autre domaine root. En revanche, un périphérique d'extrémité PCIe ou une fonction virtuelle de bus PCIe peuvent être affectés au domaine root propriétaire du bus.

#### Un domaine invité panique après une migration lorsque des coeurs sont ajoutés

ID de bogue 15822313 : sur un système qui exécute le SE Oracle Solaris 11.1, l'exécution d'opérations de reconfiguration dynamique (DR) de CPU sur un domaine qui a été migré peut entraîner une panique du domaine invité.

Solution : n'exécutez pas les opérations de DR des CPU du gestionnaire de domaine tant que le domaine migré n'a pas été réinitialisé.

#### Panique du domaine invité lorsque la propriété `threading` est modifiée de `max-throughput` à `max-ipc`

ID de bogue 15821246 : sur un système qui exécute le SE Oracle Solaris 11.1, la modification de la valeur de la propriété `threading` sur un domaine migré de `max-ipc` à `max-throughput` peut entraîner une panique sur le domaine invité.

Solution : ne modifiez pas le statut de la propriété `threading` d'un domaine invité tant qu'il n'a pas été réinitialisé.

#### Le domaine de contrôle bloque lors d'une réinitialisation avec deux domaines d'E/S directs actifs

ID de bogue 15820741 : sur un système Oracle Solaris 11.1 comportant deux domaines avec des configurations d'E/S directes, le domaine de contrôle peut se bloquer lors de la réinitialisation.

Reprise : pour effectuer une reprise après un blocage de la réinitialisation, effectuez une remise à zéro du domaine de contrôle en lançant la commande suivante sur le processeur de service :

    -> reset -f /HOST/domain/control

#### `ldm rm-io` doit accepter `--dry-run` en tant qu'alias pour `-n`

ID de bogue 15818302 : vous ne pouvez pas spécifier l'option `--dry-run` pour la commande `ldm rm-io`.

Solution : utilisez plutôt l'option `-n`.

#### SPARC T3 et SPARC T4 : un domaine comportant un périphérique réseau virtuel ou un commutateur virtuel soumis à une forte charge de travail risque de paniquer

ID de bogue 15816287 : dans de rares circonstances, un domaine logique risque de paniquer si son périphérique réseau virtuel ou son commutateur virtuel est soumis à une charge de travail importante.

Solution : appliquez l'une des solutions de contournement. Il est préférable de mettre en oeuvre la solution `/etc/system` pour limiter l'impact sur les performances du système.

- Ajoutez la ligne suivante au fichier `/etc/system` pour tous les domaines comportant un commutateur virtuel, puis réinitialisez les domaines concernés pour que les modifications prennent effet :

      set vsw:vsw_ldc_tx_serialize=1

- Définissez la valeur de la propriété `extended-mapin-space` sur `off` pour tous les domaines comportant un périphérique réseau virtuel ou un commutateur virtuel.

      # ldm set-domain extended-mapin-space=off ldom

#### Des problèmes de migration surviennent entre les systèmes dont les versions de microprogramme installées sont différentes

ID de bogue 15815409 : la migration d'un domaine actif peut échouer si la machine source et la machine cible exécutent différentes versions de microprogramme système. Ce type d'échec se produit dans les situations suivantes :

- SPARC T3 ou SPARC T4. La machine source exécute une version de microprogramme antérieure à la version 8.1.5 et la machine cible exécute au minimum la version 8.1.5.

- UltraSPARC T2 ou UltraSPARC T2 Plus. La machine source exécute une version de microprogramme antérieure à la version 7.4.3 et la machine cible exécute au minimum la version 7.4.3.

Reprise : effectuez une des actions suivantes :

- Installez le microprogramme système approprié sur le système qui exécute la version antérieure du microprogramme système :

  - SPARC T3 ou SPARC T4. Installez au minimum la version 8.1.5 du microprogramme système.

  - UltraSPARC T2 ou UltraSPARC T2 Plus. Installez au minimum la version 7.4.3 du microprogramme système.

- Si vous ne pouvez pas mettre à niveau le système qui exécute le microprogramme antérieur, installez la version 8.2.2.b du microprogramme système sur le système qui exécute le nouveau microprogramme.

Solution : arrêtez le domaine avant d'effectuer la migration.

#### Absence d'un message d'erreur lorsqu'un ajout de reconfiguration dynamique de mémoire est en partie réussi.

ID de bogue 15812823 : dans les cas où la mémoire restante est faible, les blocs de mémoire ne peuvent pas tous être utilisés pour l'opération de DR de la mémoire en raison d'espace mémoire insuffisant. Cependant, ces blocs de mémoire sont inclus dans l'espace de mémoire libre. La situation peut conduire à ce qu'une quantité moins importante que prévu soit ajoutée au domaine. Aucun message d'erreur n'apparaît lorsque cette situation se produit.

Solution : aucune.

#### Panique du domaine primary ou invité en cas de migration ou d'annulation de la liaison d'un domaine invité comportant des périphériques réseau d'E/S hybrides.

ID de bogue 15803617 : le domaine `primary` ou un domaine invité actif risque de paniquer durant une opération de migration en direct ou d'annulation de la liaison si le domaine est configuré avec des périphériques réseau virtuels d'E/S hybrides.

Reprise : redémarrez le domaine affecté.

Solution : n'utilisez pas de périphériques réseau virtuels d'E/S hybrides.

#### Echec de l'arrêt du domaine à l'aide des commandes `ldm stop` ou `ldm stop -f`

ID de bogue 15801579 : dans de rares circonstances, il est impossible d'arrêter un domaine à l'aide des commandes `ldm stop` ou `ldm stop -f`. En général, ce problème survient uniquement si un autre problème entraîne un blocage forcé du domaine ou que le domaine effectue des réinitialisations en boucle très rapides.

Solution : si vous ne pouvez pas vous connecter directement au domaine, essayez de lancer plusieurs fois la commande `ldm stop -f`. Il se peut que l'hyperviseur ne puisse pas arrêter le domaine pendant le délai d'exécution de cette commande.

Si cette solution ne permet pas de régler le problème, effectuez un cycle d'alimentation du système.

#### Structures PCIe inaccessibles pour les domaines invités lorsque 11 domaines ou plus possèdent des périphériques PCIe

ID de bogue 15789903 : si le domaine de contrôle est réinitialisé lorsque des périphériques d'extrémité PCIe sont affectés à 11 domaines invités ou plus, les périphériques PCIe sont inaccessibles sur le domaine invité.

Reprise : arrêtez et redémarrez les domaines invités affectés.

Solution : configurez une relation de dépendance de domaine entre le domaine de contrôle et les domaines invités ayant des périphériques d'extrémité PCIe leur étant assignés. La relation de dépendance suivante garantit que les domaines avec des périphériques d'extrémité PCIe sont automatiquement arrêtés lorsque le domaine de contrôle est réinitialisé pour quelque raison que ce soit :

    primary# ldm set-domain failure-policy=stop primary
    primary# ldm set-domain master=primary ldom

#### Echec de la recréation d'un domaine avec des fonctions virtuelles PCIe à partir d'un fichier XML

ID de bogue 15783851 : un problème peut survenir lors de la recréation d'une configuration à partir d'un fichier XML représentant de façon incorrecte les contraintes de la fonction virtuelle.

Ce problème survient lorsque vous utilisez la commande `ldm list-constraints -x` pour enregistrer la configuration d'un domaine possédant des fonctions virtuelles PCIe.

Si vous recréez ultérieurement le domaine à l'aide de la commande `ldm add-domain -i`, les fonctions virtuelles d'origine n'existent pas, une tentative de liaison de domaine échoue et le message d'erreur suivant s'affiche :

    No free matching PCIe device...

Même si vous créez les fonctions virtuelles manquantes, une autre tentative de liaison de domaine échoue et contient les mêmes messages d'erreur car les fonctions virtuelles sont déclassées en tant que périphériques PCIe par la commande `ldm add-domain`.

Solution : utilisez la commande `ldm list-io` pour enregistrer les informations relatives aux fonctions virtuelles, puis utilisez la commande `ldm rm-dom` pour détruire chaque domaine affecté. Utilisez ensuite la commande `ldm create-vf` pour créer toutes les fonctions virtuelles requises. Vous pouvez désormais utiliser la commande `ldm` pour regénérer les domaines. Lorsque vous utilisez la commande `ldm add-io` pour ajouter chaque fonction virtuelle, cette dernière est correctement classée en tant que périphérique de fonction virtuelle afin de pouvoir détecter le domaine.

Pour plus d'informations sur la regénération d'une configuration de domaine utilisant des fonctions virtuelles, reportez-vous à la section Echec de la création d'un nouveau domaine avec périphériques de fonction virtuelle correct par la commande `ldm init-system`.

#### Emission de messages d'erreur incorrects lorsque le domaine de contrôle utilise des coeurs partiels au lieu de coeurs complets

ID de bogue 15783608 : lorsque vous faites basculer le domaine de contrôle d'une utilisation de coeurs physiquement limités à une utilisation de ressources de CPU non limitées, le message superflu suivant peut s'afficher :

    Whole-core partitioning has been removed from domain primary,because
    dynamic reconfiguration has failed and the domain is now configured
    with a partial CPU core.

Solution : vous pouvez ignorer ce message.

#### Echec de la création d'un nouveau domaine avec périphériques de fonction virtuelle correct par la commande `ldm init-system`

ID de bogue 15783031 : lorsque vous utilisez la commande `ldm list-constraints -x` pour enregistrer les contraintes vers un fichier XML, les détails de la fonction virtuelle ne sont pas enregistrés. Par conséquent, lorsque la configuration est redéfinie sur `factory-default` et que la commande `ldm init-system` est exécutée pour recréer la configuration enregistrée, les fonctions virtuelles ne sont pas créées et la tentative de liaison des domaines échoue.

Solution : si une configuration existante possède des fonctions virtuelles, enregistrez toutes les informations relatives à ces fonctions virtuelles. Vous pourrez ensuite utiliser ces informations pour recréer manuellement les fonctions virtuelles avant d'exécuter la commande `ldm init-system`.

La procédure suivante permet d'enregistrer toutes les informations relatives aux fonctions virtuelles à utiliser ultérieurement.

1. Enregistrez la configuration du domaine dans un fichier, `vfs.txt`, en vue de la création de nouvelles fonctions virtuelles.

       primary# ldm list-io -l -p | grep "type=VF" >vfs.txt

   Une entrée de fonction virtuelle type apparaît dans le fichier `vfs.txt` comme suit :

       |dev=pci@400/pci@1/pci@0/pci@4/network@0,83|alias=/SYS/MB/NET0/IOVNET.PF1.VF1|
       status=RDY|domain=ldg1|type=VF|class=NETWORK
       |proptype=class|mac-addr=00:14:4f:f9:74:d0
       |proptype=class|vlan-ids=3,5,7
       |proptype=class|mtu=1500
       |proptype=device|unicast-slots=6

   La première ligne est volontairement divisée en deux lignes pour une meilleure lisibilité. Il s'agit d'une seule et même ligne dans le fichier `vfs.txt`.

2. Redéfinissez le domaine sur la configuration `factory-default`.

3. Réinitialisez le domaine de contrôle.

4. Créez les fonctions virtuelles en fonction des informations du fichier `vfs.txt`.

   Pour chacune de ces entrées utilisez la commande `ldm create-vf`pour recréer la fonction virtuelle avec son nom et ses propriétés d'origine. Utilisez la commande suivante pour l'exemple de fonction virtuelle :

       primary# ldm create-vf mac-addr=00:14:4f:f9:74:d0 vid=3,5,7 mtu=1500 \
       unicast-slots=6 /SYS/MB/NET0/IOVNET.PF1

   Pour des détails relatifs aux propriétés `class` et `device`, reportez-vous à la page de manuel `ldm`(1M).

   Remarque - Le nom de la fonction virtuelle est généré à partir du nom de sa fonction physique parent. Par conséquent, exécutez les commandes `ldm create-vf` en augmentant l'ordre numérique selon la partie fonction virtuelle du nom. Par exemple, la fonction physique `/SYS/MB/NET0/IOVNET.PF1` contient les fonctions virtuelles enfant suivantes :

       /SYS/MB/NET0/IOVNET.PF1.VF0 mac-addr=00:14:4f:f9:74:d0
       /SYS/MB/NET0/IOVNET.PF1.VF1 mac-addr=00:14:4f:f9:74:d1

   Les commandes suivantes créent les fonctions virtuelles :

       primary# ldm create-vf mac-addr=00:14:4f:f9:74:d0 /SYS/MB/NET0/IOVNET.PF1
       Created new VF: /SYS/MB/NET0/IOVNET.PF1.VF0
       primary# ldm create-vf mac-addr=00:14:4f:f9:74:d1 /SYS/MB/NET0/IOVNET.PF1
       Created new VF: /SYS/MB/NET0/IOVNET.PF1.VF1

   La première commande `ldm create-vf` entraîne le passage du système en mode reconfiguration retardée.

5. Assurez-vous que la nouvelle configuration inclut les fonctions virtuelles que vous avez créées manuellement.

       primary# ldm list-io -l -p | grep "type=VF" >vfs.after.txt

   Comparez le contenu du fichier `vfs.after.txt` à celui du fichier `vfs.txt`.

6. Réinitialisez le domaine de contrôle.

7. Reconfigurez un domaine à partir d'un fichier XML.

       primary# ldm init-system -i file.xml

#### Arrêt brutal et redémarrage possibles de Logical Domains Manager en cas de modification simultanée de nombreux domaines

ID de bogue 15782994: Logical Domains Manager risque de s'arrêter brutalement et de redémarrer si vous tentez une opération concernant de nombreux domaines. Ce problème risque de se produire lorsque vous tentez d'apporter des modifications à la configuration de la mise en réseau virtuelle et qu'un grand nombre de périphériques réseau virtuels est situé sur le même commutateur virtuel dans plusieurs domaines. En règle générale, ce problème survient lorsqu'environ 90 domaines ou plus possèdent des périphériques réseau virtuels connectés au même commutateur virtuel et que la propriété `inter-vnet-link` est activée (le comportement par défaut). Confirmez le diagnostic en recherchant le message suivant dans le fichier journal `ldmd` et un fichier `core` dans le répertoire `/var/opt/SUNWldm` :

    Frag alloc for 'domain-name'/MD memory of size 0x80000 failed

Solution : évitez de créer un trop grand nombre de périphériques de réseau virtuel connectés au même commutateur virtuel. Le cas échéant, définissez la propriété `inter-vnet-link` sur `off` dans le commutateur virtuel. N'oubliez pas que cette option risque d'avoir une incidence négative sur les performances du réseau entre les domaines invités.

#### Tentatives de dépassement du nombre maximum d'emplacements Unicast de fonctions physiques `ixgbe` et de fonctions virtuelles sans échec

ID de bogue 15780217 : lorsque vous tentez de définir plus d'emplacements unica de fonctions physiques `ixgbe` et de fonctions virtuelles que le maximum autorisé par la limite, la commande réussit. Tentative de dépassement de la limite maximale censée entraîner un échec mais n'en entraînant aucun.

Utilisez la commande suivante pour identifier le nombre maximal d'emplacements unicast pris en charge par le périphérique :

    # ldm list-io -d pf-name

Assurez-vous ensuite que le nombre total d'emplacements unicas attribué à chaque fonction physique ne dépasse pas la valeur maximale.

#### Domaine de contrôle nécessitant le coeur le plus bas du système

ID de bogue 15778392 : le domaine de contrôle requiert le coeur le plus bas du système. Par conséquent, si l'ID coeur 0 est le noyau le plus bas, il ne peut pas être partagé avec un autre domaine si vous souhaitez appliquer la contrainte whole-core au domaine de contrôle.

Par exemple, si le coeur le plus bas dans le système est l'ID coeur 0, le domaine de contrôle doit ressembler à la sortie suivante :

    # ldm ls -o cpu primary
    NAME
    primary

    VCPU
    VID    PID    CID    UTIL STRAND
    0      0      0      0.4%   100%
    1      1      0      0.2%   100%
    2      2      0      0.1%   100%
    3      3      0      0.2%   100%
    4      4      0      0.3%   100%
    5      5      0      0.2%   100%
    6      6      0      0.1%   100%
    7      7      0      0.1%   100%

#### Démon `ldmd` indisponible en ligne

ID de bogue 15777490 : le service SMF (Service Management Facility) du démon `ldmd` n'est pas disponible en ligne lorsque le logiciel Oracle VM Server for SPARC 2.2 est installé sur un domaine de contrôle exécutant les versions du SE Oracle Solaris postérieures au SE Oracle Solaris 10 10/09. Cette situation survient car une dépendance SMF explicite a été ajoutée sur le service SMF `svc:/ldoms/agents`.

Solution : installez le patch 142909-17 qui prend désormais en charge le service SMF `svc:/ldoms/agents`, `ldmad`, dont dépend `ldmd`.

#### Non-réactivité des commandes `ldm` exécutées sur le système cible après annulation d'une migration

ID de bogue 15776752 : si vous annulez une migration en direct, le contenu de la mémoire de l'instance de domaine créé sur la cible doit être “nettoyé” par l'hyperviseur. Ce processus de nettoyage est effectué pour des raisons de sécurité et doit être terminé afin que la mémoire puisse être renvoyée vers le pool de mémoire libre. Durant la progression du nettoyage, les commandes `ldm` deviennent non réactives. Par conséquent, Logical Domains Manager semble suspendu.

Reprise : attendez la fin de la demande de nettoyage avant de tenter d'exécuter les autres commandes `ldm`. Ce processus peut être long. Par exemple, un domaine invité comptant 500 Go de mémoire peut mettre jusqu'à 7 minutes pour terminer le processus sur un serveur SPARC T4 ou jusqu'à 25 minutes sur un serveur SPARC T3.

#### Non-fonctionnement de certaines cartes Emulex lorsqu'elles sont assignées à un domaine d'E/S

ID de bogue 15776319 : sur un système qui exécute le SE Oracle Solaris sur le domaine de contrôle et le domaine d'E/S, certaines cartes Emulex affectées au domaine d'E/S ne fonctionnent pas correctement car celles-ci ne reçoivent pas les interruptions. Toutefois, lorsqu'elles sont affectées au domaine de contrôle, ces mêmes cartes fonctionnent correctement.

Ce problème survient avec les cartes Emulex suivantes :

- Emulex 2-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM2)

- Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE2FC-EB4-N)

- Emulex 4-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM4)

- Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-Z)

- Emulex 8-Gigabit/Sec PCI Express Single and Dual FC Host Adapter (SG-XPCIE1(2)FC-EM8-N)

Solution : aucune.

#### Panique du domaine invité lors de l'exécution de la commande `cputrack` lors de l'une migration vers un système SPARC T4

ID de bogue 15776123 : si la commande `cputrack` est exécutée sur un domaine invité pendant la migration de ce domaine vers un système SPARC T4, le domaine invité peut paniquer sur la machine cible après avoir été migré.

Solution : n'exécutez pas la commande `cputrack` durant la migration d'un domaine invité vers un système SPARC T4.

#### Oracle Solaris 11 : signalement d'usurpation et d'échec RD Oracle Solaris par les DRM

ID de bogue 15775668 : un domaine doté d'une stratégie de priorité supérieure peut voler des ressources de CPU virtuelles à partir d'une stratégie de priorité inférieure. Pendant que cette action de “vol” est en cours, les messages d'avertissement suivants peuvent s'afficher dans le journal `ldmd` toutes les 10 secondes :

    warning: Unable to unconfigure CPUs out of guest domain-name

Solution : vous pouvez ignorer ces messages qui vous induisent en erreur.

#### Limitation du nombre maximum de fonctions virtuelles qu'il est possible d'affecter à un domaine

ID de bogue 15775637 : un domaine d'E/S possède un nombre limité de ressources d'interruptions disponibles par complexe root.

Sur les systèmes SPARC T3 et SPARC T4, la limite est fixée à environ 63 vecteurs MSI/X. Chaque fonction virtuelle `igb` utilise trois interruptions. La fonction virtuelle `ixgbe` utilise deux interruptions.

Si vous affectez un grand nombre de fonctions virtuelles à un domaine, le domaine manque de ressources système pour prendre en charge ces périphériques. Des messages similaires au message suivant peuvent s'afficher :

    WARNING: ixgbevf32: interrupt pool too full.
    WARNING: ddi_intr_alloc: cannot fit into interrupt pool

#### Signalement, au terme de la migration, de temps de disponibilité aléatoires par un domaine invité recourant à la migration entre plusieurs CPU

ID de bogue 15775055 : après la migration d'un domaine entre deux machines possédant des fréquences de CPU différentes; le temps de disponibilité signalé par la commande `ldm list` peut être incorrect. Ces résultats incorrects surviennent car le temps de disponibilité est calculé par rapport à la fréquence `STICK` de la machine sur laquelle le domaine est exécuté. Si la fréquence `STICK` diffère entre les machines source et cible, le temps de disponibilité apparaît incorrect à l'échelle.

Le temps de disponibilité signalé et affiché par le domaine invité lui-même est correct. En outre, toute la comptabilisation effectuée par le SE Oracle Solaris dans le domaine invité est correcte.

#### Oracle Solaris 10 : panique susceptible d'être entraînée par le pilote `ixgbe` lorsque l'initialisation se fait à partir d'une carte Intel Dual Port Ethernet Controller X540

ID de bogue 15773603 : lorsque l'initialisation se fait à partir d'une carte Intel dual port Ethernet Controller X540, le pilote `ixgbe` d'Oracle Solaris 10 peut entraîner une panique du système. Cette panique survient car le lecteur possède une horloge à haute priorité qui empêche les autres disques de se connecter.

Solution : réinitialisez le système.

#### La version 8.2.0 du microprogramme système contient une nouvelle version de la base de données `scvar`

ID de bogue 15772090 : la version 8.2.0 du microprogramme du système contient une nouvelle version de la base de données `scvar` qui rétablit les paramètres par défaut au terme de l'installation.

Solution : notez la configuration Oracle VM Server for SPARC en cours d'exécution ou toute modification apportée aux propriétés de diagnostic du système avant l'installation du microprogramme du système. Utilisez la commande `show`d'ILOM. Par exemple :

    -> show /HOST/domain/configs

Après l'installation du microprogramme et avant la mise sous tension du système, utilisez la commande `set` d'ILOM. Par exemple :

    -> set /HOST/bootmode config=config-name

A ce stade, les configurations Oracle VM Server for SPARC sont conservées. Vous devez néanmoins choisir entre l'initialisation d'une configuration particulière ou la configuration `factory-default`.

Les valeurs de la propriété reviennent aux valeurs par défaut au terme de l'installation du microprogramme :

    /HOST
       Properties:
       autorunonerror
       ioreconfigure

    /HOST/bootmode
       Properties:
       config

    /HOST/diag
       Properties:
       error_reset_level
       error_reset_verbosity
       hw_change_level
       hw_change_verbosity
       level
       mode
       power_on_level
       power_on_verbosity
       trigger
       verbosity

    /HOST/domain/control
       Properties:
       auto-boot
       boot_guests

    /HOST/tpm
       Properties:
       enable
       activate
       forceclear

    /SYS
       Properties:
       keyswitch_state

    /SP/powermgmt
       Properties:
       policy

#### Destruction de l'ensemble des fonctions virtuelles et renvoi des emplacements vers le domaine root n'entraînant aucune restauration des ressources de complexe root

ID de bogue 15765858 : les ressources situées sur le complexe root ne sont pas restaurées après la destruction de l'ensemble des fonctions virtuelles et le renvoi des emplacements vers le domaine root.

Solution : définissez l'option `iov` sur `off` pour le bus PCIe spécifique.

    primary# ldm start-reconf primary
    primary# ldm set-io iov=off pci_0

#### Désactivation conseillée de l'option `ldm remove-io` des cartes PCIe possédant des ponts PCIe vers PCI

ID de bogue 15761509 : utilisez uniquement les cartes PCIe prenant en charge la fonction d'E/S directes (DIO) qui sont répertoriées dans ce support document.

Solution : utilisez la commande `ldm add-io` pour rajouter la carte au domaine `primary`.

#### Echec probable de la commande `ldm stop` en cas d'émission immédiatement après une commande `ldm start`

ID de bogue 15759601 : si vous émettez une commande `ldm stop` immédiatement après une commande `ldm start`, la commande `ldm stop` risque d'échouer avec l'erreur suivante :

    LDom domain stop notification failed

Solution : relancez la commande `ldm stop`.

#### `init-system` ne restaure pas les contraintes de coeur nommées pour les domaines invités à partir des fichiers XML enregistrés

ID de bogue 15758883 : la commande `ldm init-system` ne parvient pas à restaurer les contraintes de coeur des CPU nommés pour les domaines invités à partir d'un fichier XML enregistré.

Solution : effectuez les opérations suivantes :

1. Créez un fichier XML pour le domaine primary.

       # ldm ls-constraints -x primary > primary.xml

2. Créez un fichier XML pour le ou les domaines invités.

       # ldm ls-constraints -x ldom[,ldom][,...] > guest.xml

3. Effectuez un cycle d'alimentation du système et initialisez une configuration usine par défaut.

4. Appliquez la configuration XML au domaine `primary`.

       # ldm init-system -r -i primary.xml

5. Réinitialisez le système.

6. Appliquez la configuration XML aux domaines invités.

       # ldm init-system -f -i guest.xml

#### Risque d'échec de la configuration dû à l'utilisation d'`ldm set-io` pour modifier deux fois de suite la valeur de `pvid`

ID de bogue 15753523 : l'utilisation répétée de la commande `ldm set-io` pour modifier la valeur de la propriété `pvid` d'une fonction virtuelle risque d'entraîner une définition inappropriée de la valeur `pvid` sur le matériel de la fonction virtuelle.

Solution : patientez quelques secondes avant d'exécuter à nouveau la commande `ldm set-io`.

#### Panique du système lors de la réinitialisation d'un domaine `primary` possédant un très grand nombre de fonctions virtuelles affectées

ID de bogue 15750727 : un système panique lorsque vous réinitialisez un domaine `primary` auquel un très grand nombre de fonctions virtuelles est assigné.

Solution : effectuez l'une des opérations solutions :

- Diminuez le nombre de fonctions virtuelles pour réduire le nombre de fonctions virtuelles ayant échoué. Cette modification peut maintenir la puce active.

- Créez plusieurs pools IRM (Interrupt Resource Management) pour la fonction virtuelle `ixgbe` étant donné qu'un seul pool IRM est créé pour toutes les fonctions virtuelles `ixgbe` sur le système.

#### Message d'erreur SR-IOV vague : `Create vf failed`

ID de bogue 15748555 : lorsque vous tentez de créer une fonction virtuelle supplémentaire par rapport au nombre maximum de fonctions virtuelles configurables pour un périphérique de fonction physique, le message `Create vf failed` est émis. Ce message d'erreur n'exprime pas clairement le motif de l'échec.

#### SE Oracle Solaris 11 : l'utilisation des E/S directes pour retirer des emplacements PCIe multiples du domaine `primary` peut entraîner la panique d'un système SPARC T-Series multisocket ou une panique de Système Fujitsu M10 au moment de la réinitialisation

ID de bogue 15748357 : votre système peut paniquer si vous utilisez des E/S directes (`ldm remove-io`) pour retirer plusieurs emplacements PCIe d'un système SPARC T-Series ou d'un système Fujitsu M10 multisocket. Ce problème se produit quand les chemins vers les emplacements PCIe sont similaires (sauf pour le chemin complexe de root). La panique peut se produire après le retrait des emplacements PCIe et la réinitialisation du domaine `primary`. Pour plus d'informations sur la fonction d'E/S directe (DIO), reportez-vous à la section Assignation des périphériques d’extrémité PCIe du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

Par exemple, si vous supprimez les emplacements `/SYS/MB/PCIE5` (`pci@500/pci@2/pci@0/pci@0`) et `/SYS/MB/PCIE4` (`pci@400/pci@2/pci@0/pci@0`) dont les noms de chemin sont similaires, le SE Oracle Solaris 11 risque de paniquer lors de la prochaine initialisation.

La commande `ldm list-io` est exécutée après la suppression des emplacements PCIe `/SYS/MB/PCIE4` et `/SYS/MB/PCIE5`.

    # ldm list-io
    IO              PSEUDONYM       DOMAIN
    --              ---------       ------
    pci@400         pci_0           primary
    niu@480         niu_0           primary
    pci@500         pci_1           primary
    niu@580         niu_1           primary

    PCIE                       PSEUDONYM       STATUS  DOMAIN
    ----                       ---------       ------  ------
    pci@400/pci@2/pci@0/pci@8  /SYS/MB/PCIE0   OCC     primary
    pci@400/pci@2/pci@0/pci@4  /SYS/MB/PCIE2   OCC     primary
    pci@400/pci@2/pci@0/pci@0  /SYS/MB/PCIE4   OCC
    pci@400/pci@1/pci@0/pci@8  /SYS/MB/PCIE6   OCC     primary
    pci@400/pci@1/pci@0/pci@c  /SYS/MB/PCIE8   OCC     primary
    pci@400/pci@2/pci@0/pci@e  /SYS/MB/SASHBA  OCC     primary
    pci@400/pci@1/pci@0/pci@4  /SYS/MB/NET0    OCC     primary
    pci@500/pci@2/pci@0/pci@a  /SYS/MB/PCIE1   OCC     primary
    pci@500/pci@2/pci@0/pci@6  /SYS/MB/PCIE3   OCC     primary
    pci@500/pci@2/pci@0/pci@0  /SYS/MB/PCIE5   OCC
    pci@500/pci@1/pci@0/pci@6  /SYS/MB/PCIE7   OCC     primary
    pci@500/pci@1/pci@0/pci@0  /SYS/MB/PCIE9   OCC     primary
    pci@500/pci@1/pci@0/pci@5  /SYS/MB/NET2    OCC     primary
    #

Solution : ne supprimez pas tous les emplacements qui ont des noms de chemin similaires. Supprimez plutôt un seul emplacement PCIe.

Vous pouvez également insérer les cartes PCIe dans des emplacements qui n'ont pas de chemins similaires, puis les utiliser avec la fonctionnalité d'E/S directes.

#### Echec de l'autorisation des transitions DR whole-core par le coeur partiel `primary`

ID de bogue 15748348 : lorsque le domaine `primary` partage le coeur physique le plus bas (généralement `0`) avec un autre domaine, toute tentative de définir la contrainte de coeur complet (whole-core) pour le domaine `primary` échoue.

Solution : effectuez les opérations suivantes :

1. Déterminez le coeur lié le plus bas partagé par les domaines.

       # ldm list -o cpu

2. Dissociez tous les threads de CPU du coeur le plus bas de tous les domaines autres que le domaine `primary`.

   Par conséquent, les threads de CPU du coeur le plus bas ne sont pas partagés et sont disponibles pour être liés au domaine `primary`.

3. Définissez la contrainte whole-core en effectuant l'une des opérations suivantes :

   - Liez les threads de CPU au domaine `primary` et définissez la contrainte whole-core à l'aide de la commande `ldm set-vcpu -c`.

   - Utilisez la commande `ldm set-core` pour lier les threads de CPU et définissez la contrainte whole-core en une seule étape.

#### Après la réinitialisation d'un domaine `primary`, les fonctions virtuelles `igb` et `ixgbe` affectées au domaine `primary` deviennent défectueuses

ID de bogue 15747047 : les périphériques de la fonction virtuelle `igb` et `ixgbe` deviennent défectueux après la réinitialisation du domaine `primary`. Ces fonctions virtuelles sont attribuées au domaine `primary`. La configuration système possède uniquement un domaine `primary`. Aucun domaine invité ou domaine d'E/S n'est configuré.

La commande `fmadm faulty` montre que chaque fonction virtuelle est défectueuse. La commande `fmadm repair` vous permet de récupérer à partir des erreurs mais l'état défectueux est renvoyé à chaque fois que vous réinitialisez le domaine `primary`.

Solution : utilisez la commande `fmadm repair` pour la récupération après incident à chaque fois que vous réinitialisez le domaine `primary`.

#### Affichage de l'état UNK ou INV par la commande `ldm list-io` après l'initialisation

ID de bogue 15738561 : la commande `ldm list-io` peut afficher l'état UNK ou INV pour les emplacements PCIe et les fonctions virtuelles SR-IOV si la commande s'exécute immédiatement après l'initialisation du domaine `primary`. Ce problème est causé par le délai de la réponse de l'agent Logical Domains à partir du SE Oracle Solaris.

Ce problème a uniquement été signalé sur un nombre limité de systèmes.

Solution : l'état des emplacements PCIe et les fonctions virtuelles sont automatiquement mis à jour après réception des informations par l'agent Logical Domains.

#### La migration d'un domaine à mémoire très volumineuse sur un serveur SPARC T4-4s a pour effet de paniquer le domaine sur le système cible.

ID de bogue 15731303 : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire. Utilisez la commande `ldm list -o mem` pour afficher la configuration de mémoire de votre domaine. Certaines configurations de mémoire comportant plusieurs blocs équivalant à un total supérieur à 500 risquent de paniquer avec une pile ressemblant à ce qui suit :

    panic[cpu21]/thread=2a100a5dca0:
    BAD TRAP: type=30 rp=2a100a5c930 addr=6f696e740a232000 mmu_fsr=10009

    sched:data access exception: MMU sfsr=10009: Data or instruction address
    out of range context 0x1

    pid=0, pc=0x1076e2c, sp=0x2a100a5c1d1, tstate=0x4480001607, context=0x0
    g1-g7: 80000001, 0, 80a5dca0, 0, 0, 0, 2a100a5dca0

    000002a100a5c650 unix:die+9c (30, 2a100a5c930, 6f696e740a232000, 10009,
    2a100a5c710, 10000)
    000002a100a5c730 unix:trap+75c (2a100a5c930, 0, 0, 10009, 30027b44000,
    2a100a5dca0)
    000002a100a5c880 unix:ktl0+64 (7022d6dba40, 0, 1, 2, 2, 18a8800)
    000002a100a5c9d0 unix:page_trylock+38 (6f696e740a232020, 1, 6f69639927eda164,
    7022d6dba40, 13, 1913800)
    000002a100a5ca80 unix:page_trylock_cons+c (6f696e740a232020, 1, 1, 5,
    7000e697c00, 6f696e740a232020)
    000002a100a5cb30 unix:page_get_mnode_freelist+19c (701ee696d00, 12, 1, 0, 19, 3)
    000002a100a5cc80 unix:page_get_cachelist+318 (12, 1849fe0, ffffffffffffffff, 3,
    0, 1)
    000002a100a5cd70 unix:page_create_va+284 (192aec0, 300ddbc6000, 0, 0,
    2a100a5cf00, 300ddbc6000)
    000002a100a5ce50 unix:segkmem_page_create+84 (18a8400, 2000, 1, 198e0d0, 1000,
    11)
    000002a100a5cf60 unix:segkmem_xalloc+b0 (30000002d98, 0, 2000, 300ddbc6000, 0,
    107e290)
    000002a100a5d020 unix:segkmem_alloc_vn+c0 (30000002d98, 2000, 107e000, 198e0d0,
    30000000000, 18a8800)
    000002a100a5d0e0 genunix:vmem_xalloc+5c8 (30000004000, 2000, 0, 0, 80000, 0)
    000002a100a5d260 genunix:vmem_alloc+1d4 (30000004000, 2000, 1, 2000,
    30000004020, 1)
    000002a100a5d320 genunix:kmem_slab_create+44 (30000056008, 1, 300ddbc4000,
    18a6840, 30000056200, 30000004000)
    000002a100a5d3f0 genunix:kmem_slab_alloc+30 (30000056008, 1, ffffffffffffffff,
    0, 300000560e0, 30000056148)
    000002a100a5d4a0 genunix:kmem_cache_alloc+2dc (30000056008, 1, 0, b9,
    fffffffffffffffe, 2006)
    000002a100a5d550 genunix:kmem_cpucache_magazine_alloc+64 (3000245a740,
    3000245a008, 7, 6028f283750, 3000245a1d8, 193a880)
    000002a100a5d600 genunix:kmem_cache_free+180 (3000245a008, 6028f2901c0, 7, 7,
    7, 3000245a740)
    000002a100a5d6b0 ldc:vio_destroy_mblks+c0 (6028efe8988, 800, 0, 200, 19de0c0, 0)
    000002a100a5d760 ldc:vio_destroy_multipools+30 (6028f1542b0, 2a100a5d8c8, 40,
    0, 10, 30000282240)
    000002a100a5d810 vnet:vgen_unmap_rx_dring+18 (6028f154040, 0, 6028f1a3cc0, a00,
    200, 6028f1abc00)
    000002a100a5d8d0 vnet:vgen_process_reset+254 (1, 6028f154048, 6028f154068,
    6028f154060, 6028f154050, 6028f154058)
    000002a100a5d9b0 genunix:taskq_thread+3b8 (6028ed73908, 6028ed738a0, 18a6840,
    6028ed738d2, e4f746ec17d8, 6028ed738d4)

Solution : évitez de procéder à la migration de domaines comptant plus de 500 Go de mémoire.

#### Echec de la suppression d'un grand nombre de CPU d'un domaine invité

ID de bogue ID 15726205 : le message d'erreur suivant peut s'afficher lorsque vous tentez de supprimer un grand nombre de CPU d'un domaine invité.

    Request to remove cpu(s) sent, but no valid response received
    VCPU(s) will remain allocated to the domain, but might
    not be available to the guest OS
    Resource modification failed

Solution : arrêtez le domaine invité avant de supprimer plus de 100 CPU.

#### Impossible d'utiliser les opérations d'enfichage à chaud d'Oracle Solaris pour supprimer à chaud un périphérique d'extrémité PCIe

ID de bogue 15721872 : vous ne pouvez pas utiliser les opérations d'enfichage à chaud pour supprimer à chaud un périphérique d'extrémité PCIe lorsque celui-ci a été supprimé du domaine `primary` à l'aide de la commande `ldm rm-io`. Pour savoir comment remplacer ou retirer un périphérique d'extrémité PCIe, reportez-vous à la section Procédure de modification matérielle PCIe du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

#### La validation de disque virtuel échoue pour un disque physique sans tranche 2

ID de bogue 15713809 : si un disque physique est configuré avec une tranche 2 dont la taille est 0, vous risquez de rencontrer les problèmes suivants :

- Si vous utilisez la commande `ldm add-vdsdev` pour ajouter un disque physique en tant que moteur de traitement pour un disque virtuel, la commande échoue :

      # ldm add-vdsdev /dev/dsk/c3t1d0s2 vol@primary-vds0
      Path /dev/dsk/c3t1d0s2 is not valid on service domain primary

  Installez l'ID de patch 147708-01 sur le domaine `primary` et les domaines de service, puis redémarrez le service `svc:/ldoms/agents`.

- Si vous utilisez la commande `ldm bind` pour lier un domaine comportant un tel disque en tant que moteur de traitement d'un disque virtuel, la commande échoue :

      # ldm bind ldg3
      Path /dev/dsk/c3t1d0s2 is not valid on service domain primary

  Vous pouvez contourner ce problème en utilisant l'option `-q` de la commande `ldm bind` :

      # ldm bind -q ldg3

Une autre solution consiste à désactiver définitivement la validation du disque effectuée par les commandes `ldm add-vdsdev` et `ldm bind`. Ainsi, vous n'avez pas besoin de spécifier l'option `-q`. Désactivez définitivement la validation du disque en mettant à jour la propriété `device_validation` du service `ldmd` :

    # svccfg -s ldmd setprop ldmd/device_validation=value
    # svcadm refresh ldmd
    # svcadm restart ldmd

Spécifiez la valeur `0` pour désactiver la validation des périphériques de disque et réseau. Spécifiez la valeur `1` pour désactiver la validation des périphériques de disque tout en maintenant la validation des périphériques réseau.

Les valeurs possibles pour la propriété `device_validation` sont :

`0`

  Désactive la validation de tous les périphériques

`1`

  Active la validation des périphériques réseau

`2`

  Active la validation des périphériques de disque

`3`

  Active la validation des périphériques de disque et réseau

`-1`

  Active la validation pour tous les types de périphériques (valeur définie par défaut)

#### Panique de la commande `nxge` lors de la migration d'un domaine invité comportant des périphériques réseau virtuels d'E/S virtuels et hybrides

ID de bogue 15710957 : lorsqu'un domaine invité chargé a une configuration d'E/S hybrides et que vous tentez de le migrer, la commande `nxge` risque de paniquer.

Solution : ajoutez la ligne suivante au fichier `/etc/system` sur le domaine `primary` et sur tout domaine de service faisant partie de la configuration d'E/S hybrides pour le domaine :

    set vsw:vsw_hio_max_cleanup_retries = 0x200

#### Blocage de toutes les commandes `ldm` lorsque des ressources NFS partagées sont absentes des migrations

ID de bogue 15708982 : une migration initialisée ou en cours, ou toute commande `ldm` se bloque. Cette situation se produit lorsque le domaine à migrer utilise un système de fichiers partagé issu d'un autre système et que ce système de fichiers n'est plus partagé.

Solution : restaurez l'accessibilité du système de fichiers partagé.

#### Le service d'agent de Logical Domains n'est pas disponible en ligne si le service de journal système n'est pas en ligne

ID de bogue 15707426 : si le service de journal système `svc:/system/system-log`, ne démarre pas et n'est pas en ligne, le service d'agent de Logical Domains n'est pas disponible en ligne non plus. Lorsque le service d'agent de Logical Domains n'est pas en ligne, les commandes `virtinfo`, `ldm add-vsw`, `ldm add-vdsdev` et `ldm list-io` risquent de ne pas se comporter normalement.

Solution : assurez-vous que le service `svc:/ldoms/agents:default` est activé et en ligne :

    # svcs -l svc:/ldoms/agents:default

Si le service `svc:/ldoms/agents:default` est hors ligne, vérifiez qu'il est actif et que tous les services dépendants sont en ligne.

#### Un interblocage de noyau provoque le blocage de la machine pendant une migration

ID de bogue 15704500 : la migration d'un domaine invité actif peut se bloquer et la machine source peut ne plus répondre. Quand ce problème se produit, le message suivant est écrit dans la console et le fichier `/var/adm/messages` :

    vcc: i_vcc_ldc_fini: cannot close channel 15

    vcc: [ID 815110 kern.notice] i_vcc_ldc_fini: cannot
    close channel 15

Notez que le numéro de canal désigne le numéro de canal interne de Oracle Solaris, lequel peut être différent pour chaque message d'avertissement.

Solution : avant de faire migrer le domaine, déconnectez-vous de la console du domaine invité.

Reprise : arrêtez et redémarrez la machine source.

#### La stratégie DRM et la sortie `ldm list` présentent un nombre de CPU virtuelles différent du nombre de CPU virtuelles réellement contenues dans le domaine invité

ID de bogue 15702475 : le message `No response` peut s'afficher dans le journal de Oracle VM Server for SPARC lorsque la stratégie DRM d'un domaine chargé expire après une réduction significative du nombre de CPU. La sortie `ldm list` montre qu'il y a plus de ressources CPU affectées au domaine que celles affichées dans la sortie `psrinfo`.

Solution : utilisez la commande `ldm set-vcpu` pour redéfinir le nombre de CPU du domaine sur la valeur présentée dans la sortie `psrinfo`.

#### Migration en direct d'un domaine dépendant d'un domaine maître inactif sur la machine cible entraînant l'erreur de la commande `ldmd` avec une erreur de segmentation

ID de bogue 15701865 : si vous tentez une migration en direct d'un domaine dépendant d'un domaine inactif sur la machine cible, le démon `ldmd` échoue avec une erreur de segmentation et le domaine de la machine cible est redémarré. Vous pouvez néanmoins effectuer une migration, mais pas une migration en direct.

Solution : effectuez l'une des actions suivantes avant de tenter la migration en direct :

- Supprimez la dépendance invitée du domaine à migrer.

- Démarrez le domaine maître sur la machine cible.

#### Echec du rétablissement du nombre par défaut de CPU virtuelles pour un domaine migré par la stratégie DRM lorsque la stratégie a été supprimée ou qu'elle a expiré

ID de bogue 15701853 : si vous effectuez une migration de domaine alors qu'une stratégie DRM est en vigueur et que, par la suite, la stratégie DRM expire ou est supprimée du domaine migré, DRM ne parvient pas à restaurer le nombre d'origine de CPU virtuelles sur le domaine.

Solution : si un domaine est migré alors qu'une stratégie DRM est active, puis que cette dernière expire ou est supprimée, redéfinissez le nombre de CPU virtuelles. Utilisez la commande `ldm set-vcpu` pour définir le nombre de CPU virtuelles sur la valeur d'origine sur le domaine.

#### Echec de délai d'attente de CPU virtuelles lors de la reconfiguration dynamique

ID de bogue 15701258 : l'exécution de la commande `ldm set-vcpu 1` sur un domaine invité contenant plus de 100 CPU virtuelles et quelques unités de chiffrement ne parvient pas à supprimer les CPU virtuelles. Les CPU virtuelles ne sont pas supprimées en raison d'un échec du délai d'attente de la reconfiguration dynamique. Les unités de chiffrement, par contre, sont bien supprimées

Solution : utilisez la commande `ldm rm-vcpu` pour supprimer l'ensemble du contenu du domaine invité à l'exception des CPU virtuelles. Ne supprimez pas plus de 100 CPU virtuelles à la fois.

#### Motif de l'échec de migration non signalé lorsque l'adresse MAC du système entre en conflit avec une autre adresse MAC

ID de bogue 15699763 : un domaine ne peut pas être migré s'il contient une adresse MAC en double. En général, lorsqu'une migration échoue pour ce motif, le message d'échec affiche l'adresse MAC en double. Cependant, dans de rares circonstances, ce message d'échec ne signale pas l'adresse MAC en double.

    # ldm migrate ldg2 system2
    Target Password:
    Domain Migration of LDom ldg2 failed

Solution : assurez-vous que les adresses MAC sur la machine cible sont uniques.

#### Des opérations de migration simultanées dans des “directions opposées” risquent d'entraîner le blocage de `ldm`

ID de bogue 15696986 : si deux commandes `ldm migrate` sont émises simultanément dans des “directions opposées,” elles risquent de se bloquer et de ne jamais aboutir. Une situation avec des directions opposées se présente lorsque vous démarrez simultanément une migration de la machine A vers la machine B ou une migration de la machine B vers la machine A.

Le blocage se produit même si les processus de migration sont initialisés en tant que simulations à l'aide de l'option `-n`. Lorsque ce problème se produit, toutes les autres commandes `ldm` risquent de se bloquer.

Solution : aucune.

#### Echec de la suppression d'un grand nombre de CPU d'un domaine de contrôle

ID de bogue 15677358 : utilisez une reconfiguration retardée plutôt qu'une reconfiguration dynamique pour supprimer plus de 100 CPU du domaine de contrôle (également appelé domaine `primary`). Utilisez les étapes suivantes :

1. Utilisez la commande `ldm start-reconf primary` pour mettre le domaine de contrôle en mode de reconfiguration retardée.

2. Supprimez le nombre de ressources de CPU de votre choix.

   Si vous vous trompez lors de la suppression des ressources de CPU, ne tentez pas d'exécuter une nouvelle demande de suppression de CPU tant que le domaine de contrôle est à l'état de reconfiguration retardée. Le cas échéant, les commandes échoueront (reportez-vous à la section Une seule opération de configuration de CPU peut être exécutée durant une reconfiguration retardée). Au lieu de cela, annulez l'opération de reconfiguration retardée à l'aide de la commande `ldm cancel-reconf`, et recommencez.

3. Réinitialisez le domaine de contrôle.

#### Le système exécutant le SE Oracle Solaris 10 8/11 sur lequel la stratégie élastique est définie peut se bloquer

ID de bogue 15672651 et 15731467 : vous pouvez observer des blocages du SE à la connexion ou au cours de l'exécution de commandes lorsque les conditions suivantes sont réunies :

- Le SE Oracle Solaris 10 8/11 est exécuté sur un système SPARC `sun4v`

- La fonction de gestion de l'alimentation élastique est définie sur le processeur de service ILOM du système.

Solution : appliquez le patch ID 147149-01.

#### La commande `pkgadd` ne parvient pas à définir les entrées ACL sur `/var/svc/manifest/platform/sun4v/ldmd.xml`

ID de bogue 15668881 : lorsque vous utilisez la commande `pkgadd` pour installer le package `SUNWldm.v` depuis un répertoire exporté via NFS à partir d'un produit Sun ZFS Storage Appliance, le message d'erreur suivant peut s'afficher :

    cp: failed to set acl entries on /var/svc/manifest/platform/sun4v/ldmd.xml

Solution : ignorez ce message.

#### SPARC T3-1 : problème lié aux disques accessibles via plusieurs chemins d'E/S directes

ID de bogue 15668368 : un système SPARC T3-1 peut être installé avec des disques double port, lesquels peuvent être accessibles via deux périphériques d'E/S directes différents. Dans ce cas, l'assignation de ces périphériques d'E/S directes à des domaines différents entraîne parfois l'utilisation des disques par les deux domaines et une incidence mutuelle sur l'utilisation réelle de ces disques.

Solution : n'assignez pas des périphériques d'E/S directes ayant accès au même ensemble de disques sur différents domaines d'E/S. Pour déterminer si votre système T3-1 contient des disques à deux ports, exécutez la commande suivante sur le SP :

    -> show /SYS/SASBP

Si la sortie contient la valeur `fru_description`, le système correspondant contient des disques double port :

    fru_description = BD,SAS2,16DSK,LOUISE

Lorsque des disques double port sont présents dans le système, assurez-vous que les deux périphériques d'E/S directes suivants sont toujours assignés au même domaine :

    pci@400/pci@1/pci@0/pci@4  /SYS/MB/SASHBA0
    pci@400/pci@2/pci@0/pci@4  /SYS/MB/SASHBA1

#### Les opérations de suppression de la reconfiguration dynamique de la mémoire avec plusieurs instances `nxge` NIU associées peuvent se bloquer indéfiniment et ne pas s'effectuer entièrement

ID de bogue 15667770 : lorsque plusieurs instances `nxge` NIU sont associées sur un domaine, les commandes `ldm rm-mem` et `ldm set-mem` utilisées pour supprimer la mémoire du domaine ne s'exécutent pas entièrement. Pour déterminer si le problème est survenu durant une opération de suppression de mémoire, surveillez l'avancement de l'opération au moyen de la commande `ldm list -o status`. Vous rencontrerez peut-être ce problème si le pourcentage d'avancement reste constant pendant plusieurs minutes.

Reprise : annulez la commande `ldm rm-mem` or `ldm set-mem`.

Solution : annulez la commande `ldm rm-mem` ou `ldm set-mem`, puis vérifiez si une quantité de mémoire suffisante a été supprimée. Si ce n'est pas le cas, une autre commande de suppression de mémoire pourra être effectuée sans erreur afin de supprimer une plus petite quantité de mémoire.

Si le problème est survenu sur le domaine `primary`, procédez comme suit :

1. Lancez une opération de reconfiguration différée sur le domaine primary.

       # ldm start-reconf primary

2. Assignez la quantité de mémoire souhaitée au domaine.

3. Réinitialisez le domaine `primary`.

Si le problème survient sur un autre domaine, arrêtez-le avant de modifier la quantité de mémoire assignée au domaine.

#### L'exécution de la commande `ldm stop -a` sur des domaines participant à une relation maître-esclave laisse l'esclave avec l'indicateur défini sur `stopping`

ID de bogue 15664666 : lorsqu'une relation de dépendance de réinitialisation est créée, la commande `ldm stop -a` peut entraîner le redémarrage au lieu de l'arrêt seul d'un domaine participant à une relation de dépendance de réinitialisation.

Solution : exécutez d'abord la commande `ldm stop` pour le domaine maître. Exécutez ensuite la commande `ldm stop` pour le domaine esclave. Si l'arrêt initial du domaine esclave échoue, exécutez la commande `ldm stop -f` pour le domaine esclave.

#### La migration d'un domaine sur laquelle une stratégie DRM par défaut est active entraîne l'assignation de toutes les CPU disponibles à un domaine cible

ID de bogue 15655513 : suite à la migration d'un domaine actif, l'utilisation des CPU dans le domaine migré peut considérablement augmenter pendant un intervalle de temps très court. Si une stratégie de gestion des ressources dynamique (DRM) est en vigueur pour le domaine au moment de la migration, Logical Domains Manager risque d'ajouter des CPU. En particulier, si les propriétés `vcpu-max` et `attack` n'ont pas été définies pendant l'ajout de la stratégie, la valeur par défaut `unlimited` a pour effet l'ajout au domaine migré de toutes les CPU non liées sur la machine cible.

Reprise : aucune reprise n'est nécessaire. Une fois que l'utilisation des CPU redescend en dessous de la limite supérieure définie par la stratégie DRM, Logical Domains Manager supprime automatiquement les CPU.

#### Une adresse MAC en cours d'utilisation peut être réaffectée

ID de bogue 15655199 : il arrive qu'une adresse MAC active ne soit pas détectée et soit réaffectée à tort.

Solution : vérifiez manuellement que les adresses MAC actives ne puissent pas être réaffectées.

#### Impossible de créer une configuration de domaine sur le processeur de service pour `ldmconfig`

ID de bogue 15654965 : le script `ldmconfig` ne peut pas créer correctement une configuration de domaines logique stockée sur le processeur de service.

Solution : n'effectuez pas de cycle d'alimentation du système une fois le script `ldmconfig` terminé et le domaine réinitialisé. Réalisez plutôt la procédure manuelle suivante :

1. Ajoutez la configuration au processeur de service.

       # ldm add-spconfig new-config-name

2. Supprimez la configuration `primary-with-clients` du processeur de service.

       # ldm rm-spconfig primary-with-clients

3. Arrêtez et redémarrez le système.

Si vous n'effectuez pas cette procédure avant le cycle d'alimentation du système, la présence de la configuration `primary-with-client` désactive les domaines. Dans ce cas, vous devez relier les domaines un à un, puis les démarrer à l'aide de la commande `ldm start -a`. Une fois les invités initialisés, répétez cette séquence pour initialiser les domaines invités automatiquement après le cycle d'alimentation.

#### La migration non coopérative de domaines Oracle Solaris peut se bloquer si `cpu0` est hors ligne

ID de bogue 15653424 : la migration d'un domaine actif peut échouer s'il exécute une version antérieure au SE Oracle Solaris 10 10/09 et que la CPU portant le plus petit numéro est à l'état `hors ligne`. L'opération échoue lorsque Logical Domains Manager recourt à la reconfiguration dynamique des CPU jusqu'à ce qu'il ne reste qu'une seule CPU dans le domaine. Ce faisant, Logical Domains Manager tente de supprimer du domaine toutes les CPU sauf celle portant le plus petit numéro, mais puisque celle-ci est hors ligne, l'opération échoue.

Solution : avant d'effectuer la migration, assurez-vous que la CPU portant le plus petit numéro est à l'état `en ligne`.

#### La reconfiguration dynamique de la mémoire est désactivée à la suite de l'annulation d'une migration

ID de bogue 15646293 : suite à la suspension d'un domaine Oracle Solaris 10 9/10 dans le cadre d'une opération de migration, la reconfiguration dynamique de la mémoire est désactivée. Cette action ne survient que si la migration réussit ou si elle a été annulée, en dépit du fait que le domaine demeure sur la machine source.

#### Echec possible de la reconfiguration dynamique des valeurs MTU de périphériques réseau virtuel

ID de bogue 15631119 : si vous modifiez l'unité de transmission maximale (MTU) d'un périphérique réseau virtuel sur le domaine de contrôle, une opération de reconfiguration différée est déclenchée. Si vous annulez ensuite la reconfiguration différée, la valeur MTU du périphérique n'est pas rétablie à sa valeur initiale.

Reprise : réexécutez la commande `ldm set-vnet` pour définir la valeur MTU sur sa valeur initiale. La redéfinition de la valeur MTU a pour effet de placer le domaine de contrôle en mode de reconfiguration différée que vous devez désactiver. La valeur MTU résultante est à présent la valeur MTU correcte initiale.

    # ldm set-vnet mtu=orig-value vnet1 primary
    # ldm cancel-op reconf primary

#### Un domaine migré avec des MAU contient une seule CPU lorsque le SE cible ne prend pas en charge la reconfiguration dynamique d'unités cryptographiques

ID de bogue 15606220 : à partir de la version Logical Domains 1.3, un domaine peut être migré même s'il est lié à plusieurs unités cryptographiques.

Dans les circonstances suivantes, la machine cible ne contient qu'une seule CPU une fois la migration effectuée :

- La machine cible exécute Logical Domains 1.2

- Le domaine de contrôle sur la machine cible exécute une version du SE Oracle Solaris non compatible avec la reconfiguration dynamique d'unités cryptographiques

- Vous migrez un domaine contenant des unités cryptographiques

Une fois la migration terminée, le domaine cible redevient normalement opérationnel, mais se trouve à l'état d'exclusion sélective (une seule CPU).

Solution : préalablement à la migration, supprimez les unités cryptographiques de la machine source exécutant Logical Domains 1.3.

Réduction des risques : pour éviter de rencontrer ce problème, effectuez l'une des étapes suivantes, voire les deux :

- Installez le logiciel Oracle VM Server for SPARC sur la machine cible.

- Installez le patch ID 142245-01 sur le domaine de contrôle de la machine cible ou effectuez une mise à niveau vers, au minimum, le SE Oracle Solaris 10 10/09.

#### Le message d'échec de migration concernant de réels échecs de liaison de mémoire d'adresses manque de clarté

ID de bogue 15605806 : dans certaines situations, la migration échoue avec le message d'erreur, et la commande `ldmd` signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cette situation peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source (comme indiqué par `ldm ls-devices -a mem`).

    Unable to bind 29952M memory region at real address 0x8000000
    Domain Migration of LDom ldg0 failed

Cause : cet échec est causé par l'incapacité de satisfaire les exigences de congruence entre l'adresse réelle et l'adresse physique sur la machine cible.

Solution : arrêtez le domaine et effectuez une migration à froid. Vous pouvez également réduire la taille de la mémoire sur le domaine invité de 128 Mo, ce qui permet à la migration de s'effectuer pendant que le domaine est actif.

#### La suppression dynamique de toutes les unités cryptographiques d'un domaine entraîne l'arrêt de SSH

ID de bogue 15600969 : si toutes les unités cryptographiques matérielles sont supprimées de manière dynamique dans un domaine actif, la structure cryptographique ne peut pas recourir aux fournisseurs cryptographiques de logiciels sans erreur, et arrête l'ensemble des connexions `ssh`.

Reprise : rétablissez les connexions `ssh` après avoir supprimé les unités cryptographiques du domaine.

Solution : définissez la propriété `UseOpenSSLEngine=no` du fichier `/etc/ssh/sshd_config` sur le côté serveur et exécutez la commande `svcadm restart ssh`.

Après cette opération, aucune des connexions `ssh` ne recourt plus aux unités cryptographiques matérielles (et ne tire donc plus parti des améliorations des performances qui y sont associées) et les connexions `ssh` ne sont plus arrêtées lorsque des unités cryptographiques sont supprimées.

#### La carte fibre 10 Gigabit Ethernet double, PCI Express Atlas affiche quatre sous-périphériques dans la sortie `ldm list-io -l`

ID de bogue 15597025 : lorsque vous exécutez la commande `ldm ls-io -l` sur un système équipé d'une carte fibre 10 Gigabit Ethernet double, PCI Express (X1027A-Z), la sortie peut afficher les informations suivantes :

    primary# ldm ls-io -l
    ...
    pci@500/pci@0/pci@c PCIE5 OCC primary
    network@0
    network@0,1
    ethernet
    ethernet

La sortie affiche quatre sous-périphériques même si la carte Ethernet ne possède que deux ports. Cette anomalie se présente si la carte comporte quatre fonctions PCI. Deux de ces fonctions sont désactivées en interne et s'affichent comme étant des ports `ethernet` dans la sortie `ldm ls-io -l`.

Solution : vous pouvez ignorer les entrées `ethernet` dans la sortie `ldm ls-io -l`.

#### `ldm` : ces commandes mettent beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés

ID de bogue 15572184 : une commande `ldm` risque de mettre beaucoup de temps à répondre lorsque plusieurs domaines sont initialisés. Si vous exécutez une commande `ldm` à ce stade, elle peut sembler se bloquer. Sachez que la commande `ldm` revient normalement, une fois que la tâche attendue est effectuée. Lorsque la commande revient, le système doit répondre normalement aux commandes `ldm`.

Solution : évitez d'initialiser plusieurs domaines à la fois. Toutefois, si vous y êtes contraint, évitez d'exécuter d'autres commandes `ldm` tant que le système ne retourne pas à son état de fonctionnement normal. Par exemple, patientez environ deux minutes sur des serveurs Sun SPARC Enterprise T5140 et T5240 et environ quatre minutes sur le serveur Sun SPARC Enterprise T5440 Server ou Netra T5440.

#### Oracle Solaris 11 : les zones configurées à l'aide d'une interface réseau automatique risquent de ne pas pouvoir démarrer

ID de bogue 15560811 : dans Oracle Solaris 11, les zones configurées à l'aide d'une interface réseau automatique (`anet`) risquent de ne pas démarrer dans un domaine possédant uniquement des périphériques de réseau virtuel Logical Domains.

- Solution 1 : affectez un ou plusieurs périphériques réseau physique au domaine invité. Utilisez la fonctionnalité d'affectation de bus PCIe, d'E/S directes (DIO) ou la fonctionnalité SR-IOV pour affecter un NIC physique au domaine.

- Solution 2 : si la configuration requise pour la configuration des zones consiste en une configuration entre les zones du domaine, créez un périphérique `etherstub`. Utilisez le périphérique `etherstub` en tant que “liaison inférieure” dans la configuration des zones afin que les cartes NIC virtuelles soient créées sur le périphérique `etherstub`.

- Solution 3 : utilisez une affectation de lien exclusive pour attribuer un périphérique de réseau virtuel Logical Domains à une zone. Affectez des périphériques de réseau virtuel au domaine en fonction de vos besoins. Vous pouvez également choisir de désactiver les liens inter-vnet afin de créer un grand nombre de périphériques de réseau virtuel.

#### Oracle Solaris 10 : les périphériques réseau virtuels ne sont pas créés correctement sur le domaine de contrôle

ID de bogue 15560201 : il arrive que la commande `ifconfig` indique que le périphérique n'existe pas après l'ajout d'un périphérique de réseau virtuel ou de disque virtuel à un domaine. Ce problème survient car l'entrée `/devices` n'a pas été créée.

Bien que ce problème ne devrait pas se produire en fonctionnement normal, l'erreur peut se présenter lorsque le numéro d'instance d'un périphérique réseau virtuel ne correspond pas à celui répertorié dans le fichier `/etc/path_to_inst`.

Par exemple :

    # ifconfig vnet0 plumb
    ifconfig: plumb: vnet0: no such interface

Le numéro d'instance d'un périphérique virtuel est indiqué dans la colonne DEVICE de la sortie `ldm list` :

    # ldm list -o network primary
    NAME
    primary

    MAC
     00:14:4f:86:6a:64

    VSW
     NAME         MAC               NET-DEV DEVICE   DEFAULT-VLAN-ID PVID VID MTU  MODE
     primary-vsw0 00:14:4f:f9:86:f3 nxge0   switch@0 1               1        1500

    NETWORK
     NAME   SERVICE              DEVICE    MAC               MODE PVID VID MTU
     vnet1  primary-vsw0@primary network@0 00:14:4f:f8:76:6d      1        1500

Le numéro d'instance (`0` pour les deux périphériques `vnet` et `vsw` de la sortie affichée précédemment) peut être comparé au numéro d'instance indiqué dans le fichier `path_to_inst` afin de s'assurer qu'ils sont identiques.

    # egrep '(vnet|vsw)' /etc/path_to_inst
    "/virtual-devices@100/channel-devices@200/virtual-network-switch@0" 0 "vsw"
    "/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"

Solution : si les numéros d'instance ne sont pas identiques, supprimez le périphérique de réseau virtuel ou de commutateur virtuel. Ensuite, rajoutez-le en spécifiant explicitement le numéro d'instance requis en définissant la propriété `id`.

Vous pouvez également modifier manuellement le fichier `/etc/path_to_inst`. Reportez-vous à la page de manuel `path_to_inst`(4).

| Attention - Soyez attentif à l'avertissement donné dans la page de manuel qui indique que des changements apportés au fichier `/etc/path_to_inst` doivent l'être avec toutes les précautions possibles.

#### Les cartes NIU/XAUI récemment ajoutées ne sont pas visibles pour le SE hôte si le logiciel Logical Domains est configuré

ID de bogue15555509 : si le logiciel Logical Domains est configuré sur un système et que vous ajoutez une autre carte réseau XAUI, celle-ci n'est pas visible après l'arrêt et le redémarrage de la machine.

Reprise : pour que la carte XAUI récemment ajoutée soit visible dans le domaine de contrôle, suivez les étapes ci-dessous :

1. Définissez et effacez une variable factice dans le domaine de contrôle.

   Les commandes suivantes utilisent une variable factice appelée `fix-xaui`> :

       # ldm set-var fix-xaui=yes primary
       # ldm rm-var fix-xaui primary

2. Enregistrez la configuration modifiée sur le processeur de service (SP) en écrasant l'actuelle.

   Les commandes suivantes utilisent une configuration appelée `fix-config1` :

       # ldm rm-spconfig config1
       # ldm add-spconfig config1

3. Effectuez une réinitialisation de reconfiguration sur le domaine de contrôle.

       # reboot -- -r

   A ce stade, vous pouvez configurer les réseaux récemment disponibles pour que le logiciel Logical Domains puisse les utiliser.

#### Panique possible du domaine d'E/S ou du domaine invité lors d'une initialisation à partir de `e1000g`

ID de bogue 15543982 : vous pouvez configurer deux domaines au maximum avec des complexes root PCI-E dédiés sur des systèmes tels que le Sun Fire T5240. Ces systèmes sont dotés de deux CPU UltraSPARC T2 Plus et de deux complexes root d'E/S.

`pci@500` et `pci@400` sont les deux complexes root du système. Le domaine `primary` contient toujours au moins un complexe root. Un second domaine peut être configuré avec un complexe root non assigné ou non lié.

La structure (ou noeud terminal) `pci@400` contient la carte réseau intégrée `e1000g`. Une panique de domaine peut survenir dans les circonstances suivantes :

- Si le système est configuré avec un domaine `primary` contenant `pci@500` et un second domaine contenant `pci@400`

  Remarque - Sur certaines lames, le domaine `primary` (disque système) est par défaut présent sur le bus `pci@400`.

- Le périphérique `e1000g` de la structure `pci@400` est utilisé pour initialiser le second domaine

Evitez les périphériques réseau suivants s'ils sont configurés dans un domaine qui n'est pas le domaine primary :

    /pci@400/pci@0/pci@c/network@0,1
    /pci@400/pci@0/pci@c/network@0

Si ces conditions sont réunies, le domaine panique en générant une erreur PCI-E fatale.

Evitez une telle configuration, ou si vous l'utilisez, n'initialisez pas le système à partir des périphériques répertoriés.

#### Les liaisons de groupe de consoles et de port explicites ne sont pas migrées

ID de bogue 15527921 : au cours d'une migration, le groupe de consoles et le port explicitement assignés sont ignorés, et une console avec les propriétés par défaut est créée pour le domaine cible. Cette console est créée en utilisant le nom du domaine cible comme groupe de consoles et un port disponible sur le premier concentrateur de console virtuelle (`vcc`) du domaine de contrôle. S'il y a un conflit avec le nom de groupe par défaut, la migration échoue.

Reprise : pour restaurer les propriétés de la console explicite à la suite d'une migration, dissociez le domaine cible et définissez manuellement les propriétés souhaitées à l'aide de la commande `ldm set-vcons`.

#### La migration n'échoue pas si un `vdsdev` a un moteur de traitement différent sur la cible

ID de bogue 15523133 : si le disque virtuel sur la machine cible ne pointe pas vers le même moteur de traitement de disque que celui utilisé sur la machine source, le domaine migré ne peut pas accéder au disque virtuel à l'aide du moteur de traitement de disque. L'accès au disque virtuel sur le domaine risque de se bloquer.

Actuellement, Logical Domains Manager vérifie uniquement que les noms des volumes de disque virtuel correspondent entre machines source et cible. Dans ce cas de figure, aucun message d'erreur n'est affiché si les moteurs de traitement de disque ne correspondent pas.

Solution : assurez-vous, lors de la configuration du domaine cible, de recevoir un domaine migré que le volume de disque (`vdsdev`) fait correspondre au moteur de traitement de disque utilisé sur le domaine source.

Reprise : effectuez l'une des procédures suivantes si vous déterminez que le périphérique de disque virtuel sur la machine cible pointe vers un moteur de traitement de disque incorrect :

- Migrez le domaine et corrigez le `vdsdev`.

  1. Remigrez le domaine vers la machine source.

  2. Corrigez le volume `vdsdev` sur la cible de sorte qu'il pointe vers le bon moteur de traitement de disque.

  3. Remigrez le domaine vers la machine cible.

- Arrêtez et dissociez le domaine sur la cible, puis corrigez le volume `vdsdev`. Si le système d'exploitation prend en charge la reconfiguration dynamique des E/S et que le disque virtuel incorrect n'est pas utilisé sur le domaine (c.-à-d. qu'il ne s'agit pas du disque d'initialisation et qu'il est démonté), procédez comme suit :

  1. Exécutez la commande `ldm rm-vdisk` pour supprimer le disque.

  2. Corrigez le volume `vdsdev`.

  3. Exécutez la commande `ldm add-vdisk` pour rajouter le disque virtuel.

#### La migration ne permet pas toujours la liaison de mémoire si la quantité de mémoire disponible est suffisante sur la cible

ID de bogue 15523120 : dans certaines situations, la migration échoue et la commande `ldmd` signale que la liaison de la mémoire nécessaire pour le domaine source est impossible. Cela peut se produire même si la quantité totale de mémoire disponible sur la machine cible est supérieure à celle utilisée par le domaine source.

Cet échec se produit car la migration de plages de mémoire spécifiques utilisées par le domaine source nécessite que des plages de mémoire compatibles soient également disponibles sur la cible. Si aucune plage de mémoire compatible n'est trouvée pour une plage de mémoire donnée dans la source, la migration échoue.

Reprise : si vous rencontrez ce problème, essayez de migrer le domaine en modifiant l'utilisation de la mémoire sur la machine cible. Pour ce faire, dissociez n'importe quel domaine logique actif sur la cible.

Exécutez la commande `ldm list-devices -a mem` pour déterminer la quantité de mémoire disponible et son utilisation. Envisagez également de réduire la quantité de mémoire assignée à un autre domaine.

#### Logical Domains Manager ne démarre pas si la machine n'est pas mise en réseau et qu'un client NIS est exécuté

ID de bogue 15518409 : si vous ne disposez pas d'un réseau configuré sur votre machine et qu'un client NIS (Network Information Services, services d'information réseau) est actif, Logical Domains Manager ne démarre pas sur votre système.

Solution : désactivez le client NIS sur la machine non mise en réseau :

    # svcadm disable nis/client

#### Logical Domains Manager affiche les domaines migrés à l'état de transition lorsqu'ils sont déjà initialisés

ID de bogue 15516245 : il peut arriver qu'un domaine logique actif semble être à l'état de transition au lieu de normal longtemps après avoir été initialisé ou à la suite de la migration de domaines. Ce problème mineur est anodin, et le domaine est entièrement fonctionnel. Pour déterminer quel indicateur est défini, consultez le champ `flags` dans la sortie de la commande `ldm list -l -p` ou le champ `FLAGS` de la commande `ldm list`, qui affiche `-n----` pour normal ou `-t----` pour transition.

Reprise : après la réinitialisation suivante, le domaine affiche l'état correct.

#### Impossible de se connecter à la console d'un domaine migré sauf si le service `vntsd` est redémarré

ID de bogue 15513998 : il arrive qu'il soit impossible de se connecter à la console d'un domaine qui vient d'être migré.

Solution : redémarrez le service SMF `vntsd` pour activer les connexions à la console :

    # svcadm restart vntsd

Remarque - Cette commande déconnecte toutes les connexions de console actives.

#### Il arrive que l'exécution de la commande `uadmin 1 0` à partir d'un système Logical Domains ne retourne pas le système à l'invite OK

ID de bogue 15511551 : il arrive qu'un système Logical Domains ne revienne pas à l'invite `ok` après une réinitialisation consécutive à l'exécution de la commande `uadmin 1 0` à partir de la ligne de commande. Ce comportement anormal se présente uniquement si la variable Logical Domains `auto-reboot?` est définie sur `true`. Si `auto-reboot?` est définie sur `false`, la commande génère le résultat attendu.

Solution : exécutez la commande suivante à la place :

    uadmin 2 0

Ou, exécutez la commande avec la variable `auto-reboot?` toujours définie sur `false`.

#### Logical Domains Manager met parfois plus de 15 minutes pour arrêter un domaine

ID de bogue 15505014 : l'arrêt d'un domaine ou le nettoyage de la mémoire peut prendre plus de 15 minutes avec une seule CPU et une configuration de mémoire très importante. Durant l'arrêt, les CPU d'un domaine sont utilisées pour nettoyer l'ensemble de la mémoire détenue par le domaine. Le temps mis pour effectuer le nettoyage peut être assez long si une configuration donnée est déséquilibrée, par exemple, si un domaine à une seule CPU comporte 512 giga-octets de mémoire. Ce délai de nettoyage prolongé vient augmenter le temps nécessaire pour arrêter un domaine.

Solution : assurez-vous que les configurations de mémoire importante (>100 giga-octets) comportent au moins un coeur.

#### Si le SE Oracle Solaris 10 5/08 est installé sur un domaine de service et que vous tentez une initialisation réseau du SE Oracle Solaris 10 8/07 sur un domaine invité du domaine de service, il arrive que l'installation se bloque

ID de bogue 15482406 : si vous tentez une initialisation réseau du SE Oracle Solaris 10 8/07 sur un domaine invité servi par un domaine de service exécutant le SE Oracle Solaris 10 5/08, il arrive que l'installation se bloque sur le domaine invité.

Solution : patchez le miniroot de l'image d'installation réseau du SE Oracle Solaris 10 8/07 à l'aide du patch ID 127111-05.

#### La commande `scadm` peut se bloquer à la suite d'une réinitialisation d'un contrôleur système ou d'un processeur de service

ID de bogue 15469227 : la commande `scadm` d'un domaine de contrôle exécutant le système d'exploitation Solaris 10 11/06 ou ultérieur peut se bloquer à la suite d'une réinitialisation de contrôleur système. Le système ne parvient pas à rétablir correctement une connexion après une réinitialisation de contrôleur système.

Solution : réinitialisez l'hôte pour rétablir la connexion avec le contrôleur système.

Reprise : réinitialisez l'hôte pour rétablir la connexion avec le contrôleur système.

#### Une installation réseau simultanée de plusieurs domaines échoue lorsqu'il s'agit d'un groupe de consoles commun

ID de bogue 15453968 : une installation réseau simultanée de plusieurs domaines invités échoue sur les systèmes ayant un groupe de consoles commun.

Solution : procédez à une installation réseau uniquement sur des domaines invités ayant chacun leur propre groupe de consoles. Cette panne se rencontre uniquement sur les domaines ayant un groupe de consoles commun partagé entre plusieurs domaines à installation réseau.

#### `ldc_close: (0xb) unregister failed, 11` Messages d'avertissement

ID de bogue 15426914 : le message d'avertissement suivant peut s'afficher sur la console du système ou être consigné dans le journal système :

    ldc_close: (0xb) unregister failed, 11

Notez que le chiffre entre parenthèses désigne le numéro de canal interne d'Oracle Solaris, lequel peut être différent pour chaque message d'avertissement.

Solution : vous pouvez ignorer ces messages.

#### Un domaine invité comportant un nombre trop important de réseaux virtuels sur le même réseau utilisant DHCP peut devenir non réactif

ID de bogue ID 15422900 : si vous configurez plus de quatre réseaux virtuels (`vnet`s) dans un domaine invité sur le même réseau utilisant le protocole DHCP (Dynamic Host Configuration Protocol), le domaine peut devenir non réactif pour traiter le trafic réseau.

Solution : définissez `ip_ire_min_bucket_cnt` et `ip_ire_max_bucket_cnt` sur des valeurs plus grandes comme 32, si vous disposez de huit interfaces.

Reprise : Exécutez une commande `ldm stop-domain` ldom suivie d'une commande `ldm start-domain` ldom sur le domaine invité (ldom) en question.

#### Les variables OpenBoot PROM ne peuvent pas être modifiées par la commande `eeprom` lorsque Logical Domains Manager est en cours d'exécution

ID de bogue 15387338 : ce problème est sommairement décrit dans la section Persistance des variables Logical Domains et concerne uniquement le domaine de contrôle.

#### Impossible de définir des clés de sécurité durant l'exécution de Logical Domains

ID de bogue 15370442 : l'environnement Logical Domains ne prend pas en charge la définition ou la suppression de clés d'initialisation de connexion WAN à partir du SE Oracle Solaris à l'aide de la commande `ickey`(1M). Toutes les opérations `ickey` échouent avec le message d'erreur suivant :

    ickey: setkey: ioctl: I/O error

De plus, les clés d'initialisation via connexion WAN qui sont définies en utilisant le microprogramme OpenBoot sur des domaines logiques autres que le domaine de contrôle ne sont pas mémorisées après la réinitialisation du domaine. Sur ces domaines, les clés définies à partir du microprogramme OpenBoot sont valides uniquement pour un seul usage.

#### Le comportement de la commande `ldm stop-domain` n'est pas toujours très clair

ID de bogue 15368170 : dans certains cas, le comportement de la commande `ldm stop-domain` est déroutant.

    # ldm stop-domain -f ldom

Si le domaine est dans le débogueur du module noyau, avec l'invite `kmdb`(1), la commande `ldm stop-domain` échoue avec le message d'erreur suivant :

    LDom <domain-name> stop notification failed

### Erreurs identifiées dans la documentation

Cette section contient les erreurs de documentation qui n'ont pas été identifiées à temps pour être modifiées dans cette version d'Oracle VM Server for SPARC 3.0.

#### Page de manuel `ldm`(1M) : les commandes de virtualisation d'E/S ne permettent pas de lancer automatiquement une reconfiguration retardée

De nombreuses sections dans la page de manuel `ldm`(1M) indiquent que les commandes de virtualisation d'E/S permettent de lancer automatiquement une reconfiguration retardée. Cette information est erronée. Si nécessaire, lancez manuellement une reconfiguration retardée.

#### Page de manuel `ldm`(1M) : la fonctionnalité de création dynamique de fonctions virtuelles n'est pas prise en charge

La section relative à la création de fonctions virtuelles de la page de manuel `ldm`(1M) indique que pour créer des fonctions virtuelles de façon dynamique, vous devez impérativement définir la propriété `iov` pour le complexe root parent.” Cette fonction n'est pas prise en charge dans la version 3.0 d'Oracle VM Server for SPARC.

#### Page de manuel `ldm`(1M) : seule la commande `ldm add-spconfig -r` permet d'effectuer une reprise manuelle

La description de l'option `-r` dans la page de manuel `ldm`(1M) indique actuellement que les sous-commandes `add-spconfig`, `list-spconfig` et `remove-spconfig` utilisent cette option pour effectuer une reprise manuelle. Cette information est erronée. Seule la commande `ldm add-spconfig -r` peut être utilisée à cette fin.

#### Restrictions supplémentaires pour la migration

Pour les systèmes Fujitsu M10, la restriction suivante remplace les informations décrites dans la section Migration d’un domaine à partir de la PROM OpenBoot ou un domaine en cours d’exécution dans le débogueur de noyau du manuel Guide d’administration d’Oracle VM Server for SPARC 3.0.

Lorsqu'un domaine à migrer est en cours d'exécution dans OpenBoot ou dans le débogueur de noyau (`kmdb`), la tentative de migration échoue toujours si la machine source ou cible est un système Fujitsu M10. Dans le cas où le domaine à migrer ne contient qu'une seule CPU, le message d'erreur suivant est susceptible de s'afficher :

    # ldm migrate ldg1 system2
    Non-cooperative migration is not supported on this platform.

Copyright © 2007, 2013, Oracle et/ou ses affiliés. Tous droits réservés. Notice légale |