Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide d'administration d'Oracle VM Server for SPARC 2.1 Oracle VM Server for SPARC (Français) |
Partie I Logiciel Oracle VM Server for SPARC 2.1
1. Présentation du logiciel Oracle VM Server for SPARC
2. Installation et activation du logiciel
4. Configuration des services et du domaine de contrôle
5. Configuration des domaines invités
6. Configuration des domaines d'E/S
7. Utilisation des disques virtuels
8. Utilisation des réseaux virtuels
11. Gestion des configurations
12. Réalisation d'autres tâches d'administration
Partie II Logiciel Oracle VM Server for SPARC facultatif
13. Outil de conversion physique-à-virtuel Oracle VM Server for SPARC
14. Assistant de configuration Oracle VM Server for SPARC
15. Utilisation du logiciel MIB (Management Information Base ) Oracle VM Server for SPARC
16. Recherche du gestionnaire de domaines logiques
17. Utilisation de l'interface XML avec le gestionnaire de domaines logiques
Enregistrement et annulation de l'enregistrement
Actions du gestionnaire de domaines logiques
Ressources et propriétés du gestionnaire de domaines logiques
Ressource d'informations sur le domaine (ldom_info)
Ressource de serveur de disque virtuel (vds)
Ressource du volume de disque virtuel (vds_volume)
Ressource de commutateur virtuel (vsw)
Ressource de concentrateur de console virtuelle (vcc)
Ressource de périphérique d'E/S physique (physio_devise)
Ressource de configuration du SP (spconfig)
Ressource de configuration de la stratégie DRM (policy)
Ressource de service de canal de plan de données virtuelles (vdpcs)
Ressource de client de canal de plan de données virtuelles (vdpcc)
À la fin de l'initialisation de la communication, les messages XML définis par les domaines logiques sont envoyés. Il a deux types généraux de messages XML :
Les messages de demande et de réponse utilisent la balise <LDM_interface>. Ce type de message XML est utilisé pour communiquer les commandes et obtenir les résultats du gestionnaire de domaines logiques, comme lors de l'exécution des commandes utilisant l'interface de ligne de commande (CLI). Cette balise est également utilisée pour l'enregistrement et l'annulation de l'enregistrement des événements.
Les messages d'événement utilisent la balise <LDM_event>. Ce type de message XML est utilisé pour signaler de manière asynchrone les événements postés par le gestionnaire de domaines logiques.
L'interface XML des domaines logiques a deux formats différents :
Un format pour envoyer des commandes dans le gestionnaire de domaines logiques
Un autre format pour que le gestionnaire de domaines logiques réponde sur l'état du message entrant et les actions demandées dans le message.
Ces deux formats partagent de nombreuses structures XML communes, mais sont séparés dans cette présentation pour une meilleure compréhension de leurs différences.
Une demande XML entrante vers le gestionnaire de domaines logiques à son niveau le plus basique comprend une description d'une seule commande, s'appliquant à un seul objet. Les demandes plus complexes peuvent traiter plusieurs commandes et plusieurs objets par commande. Vous trouverez ci-dessous la structure d'une commande XML basique.
Exemple 17-1 Format d'une commande unique s'appliquant sur un seul objet
<LDM_interface version="1.0"> <cmd> <action>Place command here</action> <option>Place options for certain commands here</option> <data version="3.0"> <Envelope> <References/> <!-- Note a <Section> section can be here instead of <Content> --> <Content xsi:type="ovf:VirtualSystem_Type" id="Domain name"> <Section xsi:type="ovf:ResourceAllocationSection_type"> <Item> <rasd:OtherResourceType>LDom Resource Type</rasd:OtherResourceType> <gprop:GenericProperty key="Property name">Property Value</gprop:GenericProperty> </Item> </Section> <!-- Note: More Sections sections can be placed here --> </Content> </Envelope> </data> <!-- Note: More Data sections can be placed here --> </cmd> <!-- Note: More Commands sections can be placed here --> </LDM_interface>
Toutes les commandes envoyées au gestionnaire de domaines logiques doivent commencer par la balise <LDM_interface>. Tout document envoyé au gestionnaire de domaines logiques doit comporter une balise unique <LDM_interface> contenue dedans. La balise <LDM_interface> doit comprendre un attribut de version comme indiqué dans l'Exemple 17-1.
Dans la balise <LDM_interface>, le document doit inclure au moins une balise <cmd>. Chaque section <cmd> doit comporter uniquement une seule balise <action>. Utilisez la balise <action> pour décrire la commande à exécuter. Chaque balise <cmd> doit inclure au moins une balise <data> pour décrire les objets sur lesquels la commande doit être appliquée.
La balise <cmd> peut également avoir une balise <option>, qui est utilisée pour les options et les indicateurs associés à certaines commandes. Les commandes suivantes utilisent des options :
La commande remove-domain peut utiliser l'option -a.
La commande stop-domain peut utiliser l'option -f.
La commande cancel-operation peut utiliser l'option migration ou reconf.
La commande add-spconfig peut utiliser l'option -r autosave-name.
La commande remove-spconfig peut utiliser l'option -r.
La commande list-spconfig peut utiliser l'option -r autosave-name].
Chaque section <data> contient une description d'un objet correspondant à la commande indiquée. Le format de la section de données repose sur la portion de schéma XML de la spécification brouillon OVF (Open Virtualization Format). Le schéma définit une section <Envelope> qui contient une balise <References> (non utilisée par les domaines logiques) et des sections <Content> et <Section>.
Pour les domaines logiques, la section <Content> est utilisée pour identifier et décrire un domaine particulier. Le nom de domaine dans l'attribut id= du nœud <content> identifie le domaine. Dans la section <Content>, il ya une ou plusieurs sections <Section> décrivant les ressources du domaine comme requis par la commande spécifique.
Si vous devez uniquement identifier un nom de domaine, il est alors inutile d'utiliser des balises <Section>. Au contraire de cela, si aucun identifiant de domaine n'est nécessaire pour la commande, vous devez alors fournir une section <Section>, décrivant les ressources nécessaires à la commande, en dehors de la section <Content>, mais toujours dans la section <Envelope>.
Une section <data> ne doit pas contenir une balise <Envelope> si les informations de l'objet peuvent être induites. Cette situation s'applique principalement aux demandes de surveillance de tous les objets applicables à une action, à l'enregistrement des événements et aux demandes d'annulation d'enregistrement.
Pour permettre l'utilisation du schéma de spécification OVF afin de définir correctement tous les types d'objets, deux types OVF supplémentaires ont été définis :
Balise <gprop:GenericProperty>
Balise <Binding>
La balise <gprop:GenericProperty> a été définie pour traiter la propriété de n'importe quel objet pour lequel la spécification OVF n'a pas de définition. Le nom de la propriété est défini dans l'attribut key= du nœud et la valeur de la propriété est le contenu du nœud. La balise <binding> est utilisée dans la sous-commande list-bindings pour définir les ressources liées à d'autres ressources.
Une réponse XML sortante correspond étroitement à la structure de la demande entrante en termes de commandes et d'objets inclus, en ajoutant une section <Response> pour chaque objet et commande indiqué, ainsi qu'une section globale <Response> pour la demande. Les sections <Response> fournissent des informations d'état et des messages d'informations, comme décrit dans l'Exemple 17-2. Vous trouverez ci-dessous la structure d'une réponse à une demande XML basique.
Exemple 17-2 Format d'une réponse à une commande unique s'appliquant sur un seul objet
<LDM_interface version="1.0"> <cmd> <action>Place command here</action> <data version="3.0"> <Envelope> <References/> <!-- Note a <Section> section can be here instead of <Content> --> <Content xsi:type="ovf:VirtualSystem_Type" id="Domain name"> <Section xsi:type="ovf:ResourceAllocationSection_type"> <Item> <rasd:OtherResourceType> LDom Resource Type </rasd:OtherResourceType> <gprop:GenericProperty key="Property name"> Property Value </gprop:GenericProperty> </Item> </Section> <!-- Note: More <Section> sections can be placed here --> </Content> </Envelope> <response> <status>success or failure</status> <resp_msg>Reason for failure</resp_msg> </response> </data> <!-- Note: More Data sections can be placed here --> <response> <status>success or failure</status> <resp_msg>Reason for failure</resp_msg> </response> </cmd> <!-- Note: More Command sections can be placed here --> <response> <status>success or failure</status> <resp_msg>Reason for failure</resp_msg> </response> </LDM_interface>
Cette section <response>, qui est l'enfant direct de la section <LDM_interface>, indique le succès ou l'échec global de toute la demande. À moins que le document XML entrant ne sont pas correctement formé, la section <response> comprend uniquement une balise <status>. Si l'état de la réponse indique un succès, toutes les commandes sur tous les objets ont abouti. Si cette réponse est un échec et qu'il n'y a pas de balise <resp_msg>, une des commandes inclue dans la demande d'origine a échoué. La balise <resp_msg> est utilisée uniquement pour décrire certains problèmes avec le document XML lui-même.
La section <response> sous la section <cmd> alerte l'utilisateur du succès ou de l'échec de cette commande en particulier. La balise <status> indique si cette commande a abouti ou échoué. Tout comme pour la réponse globale, si la commande échoue, la section <response> comprend uniquement une balise <resp_msg> si le contenu de la section <cmd> de la demande n'est pas correctement formé. Sinon, l'état d'échec signifie qu'un des objets sur lesquels la commande a été exécutée a provoqué une erreur.
Enfin, la section <data> d'une section <cmd> comporte également une section <response>. Cela indique si la commande en cours d'exécution sur cet objet en particulier aboutit ou échoue. Si l'état de la réponse est SUCCESS, il n'y a pas de balise <resp_msg> dans la section <response>. Si l'état est FAILURE, il y a une ou plusieurs balises <resp_msg> dans la zone <response>, en fonction des erreurs rencontrées lors de l'exécution de la commande sur cet objet. Les erreurs des objets peuvent provenir de problèmes détectés lors de l'exécution de la commande ou d'un objet mal formé ou inconnu.
En plus de la section <response>, la section <data> peut contenir d'autres informations. Ces informations sont dans le même format qu'une zone <data> entrante, décrivant l'objet qui a provoqué l'erreur. Voir Balise <data>. Ces informations supplémentaires sont surtout utiles dans les cas suivants :
Lorsqu'une commande échoue sur une section <data> spécifique mais aboutit pour d'autres sections <data>
Lorsqu'une section <data> est transmise dans une commande et échoue pour certains domaines, mais aboutit pour d'autres