Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Installation de vMX sur OpenStack

Lisez cette rubrique pour comprendre comment installer une instance vMX dans l’environnement OpenStack.

Préparation de l’environnement OpenStack pour l’installation de vMX

Assurez-vous que le fichier openstackrc est sourcé avant d’exécuter des commandes OpenStack.

Pour préparer l’environnement OpenStack à l’installation de vMX, effectuez les tâches suivantes :

Création des réseaux de neutrons

Vous devez créer les réseaux de neutrons utilisés par vMX avant de démarrer l’instance de vMX. Le réseau public est le réseau de neutrons utilisé pour le réseau de gestion (fxp0). Le réseau WAN est le réseau de neutrons sur lequel l’interface WAN pour vMX est ajoutée.

Pour afficher les noms des réseaux de neutrons, utilisez la neutron net-list commande.

Note:

Vous devez identifier et créer le type de réseaux dont vous avez besoin dans votre configuration OpenStack.

Vous pouvez utiliser ces commandes pour créer le réseau public :

  • Par exemple:

  • Pour virtio, vous pouvez utiliser ces commandes pour créer le réseau WAN :

    Par exemple:

  • Pour la SR-IOV, vous pouvez utiliser ces commandes pour créer le réseau WAN :

    Par exemple:

Préparation du noeud de contrôleur

Préparation du nœud de contrôleur pour vMX

Pour préparer le nœud de contrôleur :

  1. Configurez le nœud du contrôleur pour activer les pages volumineuses et l’affinité CPU en modifiant le scheduler_default_filters paramètre dans le fichier /etc/nova/nova.conf . Assurez-vous que les filtres suivants sont présents :

    Redémarrez le service de planification à l’aide de cette commande.

    • Pour Red Hat : systemctl restart openstack-nova-scheduler.service

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : service nova-scheduler restart

  2. Mettez à jour les quotas par défaut.
    Note:

    Nous recommandons ces valeurs par défaut, mais vous pouvez utiliser des valeurs différentes si elles sont adaptées à votre environnement. Assurez-vous que les quotas par défaut disposent d’un nombre suffisant de ressources allouées.

    Vérifiez les modifications à l’aide de la nova quota-defaults commande.

  3. Assurez-vous que le pack de chaleur est 5.0.1-6 ou version ultérieure. Ce paquet fait partie de rhel-7-server-openstack-8-rpms.

    Vérifiez la version à l’aide de la rpm -qa | grep heat commande.

    Mettez à jour le paquet de chaleur avec cette commande.

    • Pour Red Hat : yum update openstack-heat-engine

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : apt-get install heat-engine

  4. Assurez-vous que les packages lsb (redhat-lsb-core ou lsb-release) et numactl sont installés.

    • Pour Red Hat :

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) :

Configuration du nœud de contrôleur pour les interfaces virtio

Pour configurer les interfaces virtio :

  1. Activez le pilote du mécanisme VLAN en l’ajoutant vlan au type_drivers paramètre dans le fichier /etc/neutron/plugins/ml2/ml2_conf.ini .
  2. Ajoutez le mappage de pont au fichier /etc/neutron/plugins/ml2/ml2_conf.ini en ajoutant la ligne suivante :

    Par exemple, utilisez le paramètre suivant pour ajouter un mappage de pont pour le réseau physique physnet1 mappé au br-vlan du pont OVS.

  3. Configurez les plages de VLAN utilisées pour le réseau physique dans le fichier /etc/neutron/plugins/ml2/ml2_conf.ini , où physical-network-name est le nom du réseau de neutrons que vous avez créé pour le réseau WAN virtio.

    Par exemple, utilisez le paramètre suivant pour configurer les plages de VLAN utilisées pour le réseau physique physnet1.

  4. Redémarrez le serveur de neutrons.

    • Pour Red Hat : systemctl restart neutron-server

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : service neutron-server restart

  5. Ajoutez le pont OVS qui a été mappé au réseau physique et l’interface virtio (eth2).

    Par exemple, utilisez les commandes suivantes pour ajouter le pont OVS br-vlan et l’interface eth2 :

Configuration du nœud de contrôleur pour les interfaces SR-IOV

Note:

Si vous disposez de plusieurs interfaces SR-IOV, vous avez besoin d’une interface 10G physique dédiée pour chaque interface SR-IOV supplémentaire.
Note:

En mode SRIOV, la communication entre le moteur de routage (RE) et le moteur de transfert de paquets est activée à l’aide d’interfaces virtio sur un réseau OVS fournisseur VLAN. Pour cette raison, une interface physique donnée ne peut pas faire partie à la fois des réseaux VirtIO et SR-IOV.

Pour configurer les interfaces SR-IOV :

  1. Modifiez le fichier /etc/neutron/plugins/ml2/ml2_conf.ini à ajouter sriovnicswitch en tant que pilote de mécanisme et les plages de VLAN utilisées pour le réseau physique.

    Par exemple, utilisez le paramètre suivant pour configurer les plages de VLAN utilisées pour le réseau physique physnet2.

    Si vous ajoutez d’autres ports SR-IOV, vous devez ajouter la plage VLAN utilisée pour chaque réseau physique (en les séparant par une virgule). Par exemple, utilisez le paramètre suivant lors de la configuration de deux ports SR-IOV.

  2. Modifiez le fichier /etc/neutron/plugins/ml2/ml2_conf_sriov.ini pour ajouter des détails sur les périphériques PCI.
  3. Ajoutez le –-config-file /etc/neutron/plugins/ml2/ml2_conf_sriov.ini comme mis en surbrillance au fichier du serveur de neutrons.

    • Pour Red Hat :

      Modifiez le fichier /usr/lib/systemd/system/neutron-server.service comme indiqué.

      Utilisez la systemctl restart neutron-server commande pour redémarrer le service.

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) :

      Modifiez le fichier /etc/init/neutron-server.conf comme étant mis en surbrillance.

      Utilisez la service neutron-server restart commande pour redémarrer le service.

  4. Pour permettre une planification correcte des périphériques SR-IOV, le planificateur de calcul doit utiliser FilterScheduler avec le filtre PciPassthroughFilter.

    Assurez-vous que le filtre PciPassthroughFilter est configuré dans le fichier /etc/nova/nova.conf sur le nœud du contrôleur.

    Redémarrez le service de planificateur.

    • Pour Red Hat : systemctl restart openstack-nova-scheduler

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : service nova-scheduler restart

Préparation des nœuds de calcul

Préparation du nœud de calcul pour vMX

Note:

Vous n’avez plus besoin de configurer le nœud de calcul pour qu’il transmette des métadonnées aux instances vMX en incluant le config_drive_format=vfat paramètre dans le fichier /etc/nova/nova.conf .

Pour préparer le nœud de calcul :

  1. Configurez chaque nœud de calcul pour qu’il prenne en charge les pages énormes au démarrage et au redémarrage.

    • Pour Red Hat : ajoutez la configuration Huge Pages.

      Utilisez la mount | grep boot commande pour déterminer le nom du périphérique d’amorçage.

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : ajoutez la configuration Huge Pages à /etc/default/grub sous le GRUB_CMDLINE_LINUX_DEFAULT paramètre.

    Après le redémarrage, vérifiez que les pages volumineuses sont allouées.

    Le nombre de pages énormes dépend de la quantité de mémoire pour le VFP, de la taille des pages énormes et du nombre d’instances VFP. Pour calculer le nombre de pages énormes : (memory-for-vfp / huge-pages-size) * number-of-vfp

    Par exemple, si vous exécutez quatre instances vMX (quatre VFP) en mode performance en utilisant 12 Go de mémoire et 2 Mo de taille de pages énormes, le nombre de pages énormes calculé par la formule est de (12G/2M)*4 ou 24576.

    Note:

    À partir de la version 15.1F6 de Junos OS et des versions ultérieures, le mode de fonctionnement par défaut est le mode de fonctionnement par défaut. Pour plus d’informations, reportez-vous à la section Activation du mode Performance ou du Mode Lite.
    Note:

    Assurez-vous que vous disposez d’une mémoire physique suffisante sur le nœud de calcul. Elle doit être supérieure à la quantité de mémoire allouée aux pages volumineuses, car toutes les autres applications qui n’utilisent pas les pages volumineuses sont limitées par la quantité de mémoire restante après l’allocation des pages volumineuses. Par exemple, si vous allouez 24576 pages énormes et 2 millions de pages énormes, vous avez besoin de 24576 * 2 M ou 48 Go de mémoire pour les pages énormes.

    Vous pouvez utiliser la vmstat -s commande et examiner la mémoire totale et les valeurs de mémoire utilisée pour vérifier la quantité de mémoire restante pour d’autres applications qui n’utilisent pas Huge Pages.
  2. Activez IOMMU dans le fichier /etc/default/grub . Ajoutez la intel_iommu=on chaîne à n’importe quel texte existant pour le GRUB_CMDLINE_LINUX paramètre.

    Régénérez le fichier grub .

    • Pour Red Hat : grub2-mkconfig -o /boot/grub2/grub.cfg

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : update-grub

    Redémarrez le nœud de calcul.

  3. Ajout d’un pont pour le réseau Virtio et configuration physnet1 :

    Par exemple, un pont br-vlan OVS est ajouté. (C’est le même br-vlan qui a été ajouté dans bridge_mappings dans ml2_conf.ini ci-dessus sur le contrôleur. À ce pont, ajoutez l’interface eth2, qui peut être utilisée pour la communication Virtio entre les machines virtuelles.

    Dans /etc/neutron/plugins/ml2/openvswitch_agent.ini, ajoutez physnet1:br-vlan la chaîne :

    Redémarrez le service de neutrons.

    • Redhat :

      systemctl restart neutron-openvswitch-agent.service

      systemctl restart openstack-nova-compute.service

    • Ubuntu

      service nova-compute restart

      service neutron-plugin-openvswitch-agent restart

Configuration du nœud de calcul pour les interfaces SR-IOV

Note:

Si vous disposez de plusieurs interfaces SR-IOV, vous avez besoin d’une carte réseau Ethernet 10G physique pour chaque interface SR-IOV supplémentaire.

Pour configurer les interfaces SR-IOV :

  1. Chargez le pilote IXGBE modifié.

    Avant de compiler le pilote, assurez-vous que gcc et make sont installés.

    • Pour Red Hat :

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) :

    Déchargez le pilote IXGBE par défaut, compilez le pilote Juniper Networks modifié, puis chargez le pilote IXGBE modifié.

    Vérifiez la version du pilote sur l’interface eth4.

    Par exemple, dans l’exemple suivant, la commande affiche la version du pilote (3.19.1) :

  2. Créez la fonction virtuelle (VF) sur l’équipement physique. vMX ne prend actuellement en charge qu’une seule VF pour chaque interface SR-IOV (par exemple, eth4).

    Spécifiez le nombre de VF sur chaque carte réseau. La ligne suivante spécifie qu’il n’y a pas de VF pour eth2 (première carte réseau) et une VF pour eth4 (deuxième carte réseau avec interface SR-IOV).

    Pour vérifier que le VF a été créé, la sortie de la ip link show eth4 commande inclut la ligne suivante :

    Pour vous assurer que les interfaces sont opérationnelles et que le trafic SR-IOV peut les traverser, exécutez ces commandes pour terminer la configuration.

  3. Installez l’agent SR-IOV.

    • Pour Red Hat : sudo yum install openstack-neutron-sriov-nic-agent

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : sudo apt-get install neutron-plugin-sriov-agent

  4. Ajoutez le mappage de périphérique physique au fichier /etc/neutron/plugins/ml2/sriov_agent.ini en ajoutant la ligne suivante :

    Par exemple, utilisez le paramètre suivant pour ajouter un mappage de pont pour le réseau physique physnet2 mappé à l’interface SR-IOV eth4.

    Si vous ajoutez d’autres ports SR-IOV, vous devez ajouter le mappage de pont pour chaque réseau physique (séparé par une virgule). Par exemple, utilisez le paramètre suivant lors de l’ajout de l’interface SR-IOV eth5 pour le réseau physique physnet3.

  5. Modifiez le fichier de service de l’agent SR-IOV à ajouter –-config-file /etc/neutron/plugins/ml2/sriov_agent.ini comme mis en surbrillance.

    • Pour Red Hat :

      Modifiez le fichier /usr/lib/systemd/system/neutron-sriov-nic-agent.service comme indiqué.

      Activez et démarrez l’agent SR-IOV.

      Utilisez la systemctl status neutron-sriov-nic-agent.service commande pour vérifier que l’agent a démarré avec succès.

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) :

      Modifiez le fichier /etc/init/neutron-plugin-sriov-agent.conf comme mis en surbrillance.

      Assurez-vous que /etc/neutron/plugins/ml2/sriov_agent.ini a les bonnes permissions et que neutron est le groupe du fichier.

      Utilisez la service neutron-plugin-sriov-agent start commande pour démarrer l’agent SR-IOV.

      Utilisez la service neutron-plugin-sriov-agent status commande pour vérifier que l’agent a démarré avec succès.

  6. Modifiez le fichier /etc/nova/nova.conf pour ajouter l’entrée de liste d’autorisation PCI passthrough pour le périphérique SR-IOV.

    Par exemple, cette entrée ajoute une entrée pour l’interface SR-IOV eth4 pour le réseau physique physnet2.

    Si vous ajoutez d’autres ports SR-IOV, vous devez ajouter l’entrée de la liste d’autorisation PCI Passthrough pour chaque interface SR-IOV (séparée par une virgule). Par exemple, utilisez le paramètre suivant lors de l’ajout de l’interface SR-IOV eth5 pour le réseau physique physnet3.

    Redémarrez le service de nœud de calcul.

    • Pour Red Hat : systemctl restart openstack-nova-compute

    • Pour Ubuntu (à partir de Junos OS version 17.2R1) : service nova-compute restart

Installation de vMX

Après avoir préparé l’environnement OpenStack, vous devez créer des saveurs nova et des images d’aperçu pour les machines virtuelles VCP et VFP. Les scripts créent les saveurs et les images en fonction des informations fournies dans le fichier de configuration de démarrage.

Configuration du fichier de configuration vMX

Les paramètres nécessaires à la configuration de vMX sont définis dans le fichier de configuration de démarrage.

Pour configurer le fichier de configuration :

  1. Téléchargez le progiciel KVM vMX à partir de la page vMX et décompressez-le.

    tar xvf package-name

  2. Changez de répertoire pour l’emplacement des fichiers.

    cd package-location/openstack/scripts

  3. Modifiez le fichier texte vmx.conf à l’aide d’un éditeur de texte pour créer les saveurs d’une seule instance vMX.

    En fonction de vos besoins, assurez-vous que les paramètres suivants sont correctement définis dans le fichier de configuration vMX :

    • re-flavor-name

    • pfe-flavor-name

    • vcpus

    • memory-mb

    Reportez-vous à la section Spécification des paramètres du fichier de configuration vMX pour plus d’informations sur les paramètres.

    Exemple de fichier de configuration de démarrage du vMX

    Voici un exemple de fichier de configuration de démarrage vMX pour OpenStack :

Voir aussi

Spécification des paramètres du fichier de configuration vMX

Les paramètres nécessaires à la configuration de vMX sont définis dans le fichier de configuration de démarrage (scripts/vmx.conf). Le fichier de configuration de démarrage génère un fichier qui est utilisé pour créer des saveurs. Pour créer de nouvelles saveurs avec des paramètres ou memory-mb différentsvcpus, vous devez modifier le paramètre ou pfe-flavor-name correspondant re-flavor-name avant de créer les nouvelles saveurs.

Pour personnaliser la configuration, effectuez les tâches suivantes :

Configuration de l’hôte

Pour configurer l’hôte, accédez à HOST et spécifiez les paramètres suivants :

  • virtualization-type—Mode de fonctionnement ; doit être openstack.

  • compute—(Facultatif) Noms du nœud de calcul sur lequel exécuter les instances vMX dans une liste séparée par des virgules. Si ce paramètre est spécifié, il doit s’agir d’un nœud de calcul valide. Si ce paramètre est spécifié, les instances vMX lancées avec des variantes ne sont exécutées que sur les nœuds de calcul spécifiés.

    Si ce paramètre n’est pas spécifié, la sortie de la commande nova hypervisor-list fournit la liste des nœuds de calcul sur lesquels exécuter les instances vMX.

Configuration de la machine virtuelle VCP

Pour configurer la machine virtuelle VCP, vous devez fournir le nom du type.

Note:

Nous recommandons des valeurs uniques pour le re-flavor-name paramètre, car OpenStack peut créer plusieurs entrées portant le même nom.

Pour configurer la machine virtuelle VCP, accédez à CONTROL_PLANE et spécifiez les paramètres suivants :

  • re-flavor-name—Nom de la saveur nova.

  • vcpus—Nombre de vCPU pour le VCP ; Le minimum est de 1.

    Note:

    Si vous modifiez cette valeur, vous devez la modifier re-flavor-name avant d’exécuter le script pour créer des saveurs.

  • memory-mb—Quantité de mémoire pour le VCP ; La taille minimale est de 4 Go.

    Note:

    Si vous modifiez cette valeur, vous devez la modifier re-flavor-name avant d’exécuter le script pour créer des saveurs.

Configuration de la VM VFP

Pour configurer la machine virtuelle VFP, vous devez fournir le nom du type. En fonction de vos besoins, vous souhaiterez peut-être modifier la mémoire et le nombre de vCPU. Reportez-vous à la section Configuration matérielle minimale requise pour connaître la configuration matérielle minimale.

Pour configurer la machine virtuelle VFP, accédez à FORWARDING_PLANE et spécifiez les paramètres suivants :

  • pfe-flavor-name—Nom de la saveur nova.

  • memory-mb—Quantité de mémoire pour le VFP ; Le minimum est de 12 Go (mode performance) et de 4 Go (mode lite).

    Note:

    Si vous modifiez cette valeur, vous devez la modifier pfe-flavor-name avant d’exécuter le script pour créer des saveurs.

  • vcpus—Nombre de vCPU pour le VFP ; Le minimum est de 7 (mode performance) et de 3 (mode lite).

    Note:

    Si vous spécifiez moins de 7 vCPU, le VFP passe automatiquement en mode lite.
    Note:

    Si vous modifiez cette valeur, vous devez la modifier pfe-flavor-name avant d’exécuter le script pour créer des saveurs.

Création de modèles OpenStack

Pour créer des variantes pour VCP et VFP, vous devez exécuter le script sur le fichier de configuration de démarrage du vMX (vmx.conf).

Pour créer des versions OpenStack :

  1. Exécutez le avec le fichier de configuration de vmx_osp_create_flavor.py démarrage pour générer le fichier qui crée les vmx_osp_flavors.sh saveurs.

    ./vmx_osp_create_flavor.py vmx.conf

  2. Exécutez la vmx_osp_flavors.sh commande pour créer des saveurs.

    sh vmx_osp_flavors.sh

Installation d’images vMX pour VCP et VFP

Pour installer les images d’aperçu vMX OpenStack pour VCP et VFP, vous pouvez exécuter le vmx_osp_images.sh script. Le script ajoute l’image VCP au format qcow2 et le fichier VFP au format vmdk.

Pour installer les images VCP et VFP :

  1. Téléchargez le progiciel KVM vMX à partir de la page vMX et décompressez-le.

    tar xvf package-name

  2. Vérifiez l’emplacement des images logicielles à partir du package vMX non compressé. Voir Contenu du package vMX.

    ls package-location/images

  3. Remplacez le répertoire par l’emplacement des fichiers de script vMX OpenStack.

    cd package-location/openstack/scripts

  4. Exécutez le vmx_osp_images.sh script pour installer les images d’un coup d’œil.

    sh vmx_osp_images.sh vcp-image-name vcp-image-location vfp-image-name vfp-image-location

    Note:

    Vous devez spécifier les paramètres dans cet ordre.

    • vcp-image-name: nom de l’image du coup d’œil.

    • vcp-image-location: chemin d’accès absolu au fichier junos-vmx-x86-64*.qcow2 pour le lancement de VCP.

    • vfp-image-name: nom de l’image du coup d’œil.

    • vfp-image-location—Chemin d’accès absolu au fichier vFPC-*.img pour le lancement de VFP.

Par exemple, cette commande installe l’image VCP en tant que re-test à partir du fichier /var/tmp/junos-vmx-x86-64-17.1R1.8.qcow2 et l’image VFP en tant que fpc-test à partir du fichier /var/tmp/vFPC-20170117.img .

sh vmx_osp_images.sh re-test /var/tmp/junos-vmx-x86-64-17.1R1.8.qcow2 fpc-test /var/tmp/vFPC-20170117.img

Pour afficher les images d’un coup d’œil, utilisez la glance image-list commande.

Démarrage d’une instance vMX

Pour démarrer une instance vMX, effectuez les tâches suivantes :

Modification de la configuration initiale de Junos OS

Lorsque vous démarrez l’instance vMX, le fichier de configuration Junos OS qui se trouve dans package-location/openstack/vmx-components/vms/vmx_baseline.conf est chargé. Si vous devez modifier cette configuration, apportez des modifications à ce fichier avant de démarrer le vMX.

Note:

Si vous créez votre propre vmx_baseline.conf fichier ou déplacez le fichier, assurez-vous que lepackage-location fichier /openstack/vmx-components/vms/re.yaml fait référence au chemin d’accès correct.

Lancement de l’instance vMX

Pour créer et démarrer l’instance vMX :

  1. Modifiez ces paramètres dans le fichier d’environnement /openstack/1vmx.env correspondant àpackage-location votre configuration. Le fichier d’environnement est au format YAML à partir de Junos OS version 17.4R1.

    • net_id1: ID réseau du réseau neutronique existant utilisé pour le port WAN. Utilisez la neutron net-list commande pour afficher l’ID réseau.

    • public_network: ID réseau du réseau de neutrons existant utilisé pour le port de gestion (fxp0). Utilisez la neutron net-list | grep public commande pour afficher l’ID réseau.

    • fpc_img: remplacez ce paramètre par linux-img. Nom de l’image du coup d’œil pour le VFP ; identique au paramètre spécifié lors de l’exécution vfp-image-name du script pour installer les images vMX.

    • vfp_image—Nom de l’image du coup d’œil pour le VFP ; identique au paramètre spécifié lors de l’exécution vfp-image-name du script pour installer les images vMX (applicable pour Junos OS versions 17.3R1 et antérieures).

    • fpc_flav: remplacez ce paramètre par linux-flav. Nom de la saveur nova pour le VFP ; identique au pfe-flavor-name paramètre spécifié dans le fichier de configuration vMX.

    • vfp_flavor—Nom de la saveur nova pour le VFP ; identique au pfe-flavor-name paramètre spécifié dans le fichier de configuration de vMX (applicable pour Junos OS versions 17.3R1 et antérieures).

    • junos_flav—Nom de la saveur nova pour le VCP ; identique au re-flavor-name paramètre spécifié dans le fichier de configuration vMX.

    • vcp_flavor—Nom de la saveur nova pour le VCP ; identique au re-flavor-name paramètre spécifié dans le fichier de configuration de vMX (applicable pour Junos OS versions 17.3R1 et antérieures).

    • junos_img—Nom de l’image du coup d’œil pour le PCV ; identique au paramètre spécifié lors de l’exécution vcp-image-name du script pour installer les images vMX.

    • vcp_image—Nom de l’image du coup d’œil pour le PCV ; identique au paramètre spécifié lors de l’exécution vcp-image-name du script pour installer les images vMX (applicable pour Junos OS versions 17.3R1 et antérieures).

    • project_name: n’importe quel nom de projet. Toutes les ressources utiliseront ce nom comme préfixe.

    • gateway_ip: adresse IP de la passerelle.

  2. Démarrez l’instance vMX à l’aide de la heat stack-create –f 1vmx.yaml –e 1vmx.env vmx-name commande.

    Cet exemple de configuration démarre une instance vMX unique avec un port WAN et un FPC.

  3. Vérifiez que l’instance vMX est créée à l’aide de la heat stack-list | grep vmx-name commande.
  4. Vérifiez que les machines virtuelles VCP et VFP existent à l’aide de la nova-list commande.
  5. Accédez au VCP ou à la VM VFP à l’aide de la nova get-vnc-console nova-id novnc commande, où nova-id est l’ID de l’instance affiché dans la sortie de la nova-list commande.
Note:

Vous devez arrêter l’instance vMX avant de redémarrer le serveur hôte à l’aide de la commande request system halt.

Documentation connexe