Prise en charge détaillée des fonctionnalités pour la migration

Les fonctionnalités et configurations NSX-V qui peuvent être migrées sont répertoriées ci-dessous.

Prise en charge de plate-forme

Consultez la Matrice d'interopérabilité VMware pour voir les versions prises en charge d'ESXi et de VMware vCenter.

Configuration de NSX-V	Pris en charge	Détails
NSX-V avec vSAN ou iSCSI sur vSphere Distributed Switch	Oui
Configuration de NSX préexistante	Non	Vous devez déployer un nouvel environnement NSX. Si le mode de migration ne s'applique pas à une topologie définie par l'utilisateur, lors de l'étape Importer la configuration, toutes les interfaces du nœud NSX Edge dans l'environnement NSX sont arrêtées. Si l'environnement NSX est en cours d'utilisation, le trafic sera interrompu.
Cross-vCenter NSX	Oui	Uniquement pris en charge si vous choisissez le mode Migrer NSX for vSphere et la topologie définie par l'utilisateur.
NSX-V avec une plate-forme de gestion du cloud, une solution Stack intégrée ou une solution PaaS	Oui	La migration de NSX-V avec Aria Automation est prise en charge. Contactez votre représentant VMware avant de passer à la migration. La migration peut rompre les scripts et les intégrations si vous migrez les environnements intégrés : Par exemple : NSX-V et vCloud Director NSX-V avec solution de pile intégrée NSX-V avec une solution PaaS, telle que Pivotal Cloud Foundry, RedHat OpenShift Workflows de NSX-V avec Aria Operations

Fonctionnalités de vSphere et ESXi

Configuration de NSX-V	Pris en charge	Détails
Hôte ESXi déjà en mode de maintenance (aucune VM)	Oui
Network I/O Control (NIOC) version 3	Oui
Network I/O Control (NIOC) version 2	Non
Network I/O Control (NIOC) avec vNIC avec réservation	Non
Commutateur standard vSphere	Non	Les machines virtuelles et les interfaces VMkernel sur un VSS ne sont pas migrées. Les fonctionnalités de NSX-V appliquées au VSS ne peuvent pas être migrées.
vSphere Distributed Switch	Oui
ESXi sans état	Non
Profils d'hôte	Non
Mode de verrouillage d'ESXi	Non	Non pris en charge dans NSX.
Hôte ESXi en attente de la tâche de mode de maintenance.	Non
Hôte ESXi déconnecté dans le cluster vCenter	Non
FT vSphere	Non
vSphere DRS entièrement automatisé	Oui	Pris en charge à partir de vSphere 7.0
vSphere High Availability	Oui
ACL de filtrage du trafic	Non
Contrôle de santé vSphere	Non
SRIOV	Non
Épinglage de vmknic à la carte réseau physique	Non
VLAN privé	Non
dvPortGroup éphémère	Non
E/S DirectPath	Non
Sécurité L2	Non
Apprendre le commutateur sur le câble virtuel	Non
Passerelle matérielle (intégration du point de terminaison de tunnel avec le matériel de commutation physique)	Non
SNMP	Non
vNIC déconnecté dans la VM	Non	En raison de la limitation d'ESX 6.5, des entrées périmées peuvent être présentes sur DVFilter pour les VM déconnectées. Comme solution, redémarrez la VM.
Numéro de port VXLAN autre que 4789	Non
Mode de filtrage multidiffusion	Non
Hôtes avec plusieurs VTEP	Oui

Configuration système du dispositif NSX Manager

Configuration de NSX-V	Pris en charge	Détails
Paramètre de serveur/heure NTP	Oui
Configuration du serveur Syslog	Oui
Configuration de sauvegarde	Oui	Si nécessaire, modifiez la phrase secrète NSX-V pour qu'elle corresponde aux exigences de NSX. Elle doit comporter au moins 8 caractères et contenir les éléments suivants : Au moins une lettre minuscule Au moins une lettre majuscule Au moins un caractère numérique Au moins un caractère spécial
FIPS	Non	Activation/désactivation de FIPS non prise en charge par NSX.
Paramètre régional	Non	NSX ne prend en charge que les paramètres régionaux anglais
Certificat du dispositif	Non

Contrôle d'accès basé sur les rôles

Configuration de NSX-V	Pris en charge	Détails
Utilisateurs locaux	Non
Rôles NSX attribués à un utilisateur vCenter ajouté via LDAP	Oui	VMware Identity Manager doit être installé et configuré pour migrer des rôles d'utilisateur pour les utilisateurs LDAP.
Rôles NSX attribués à un groupe vCenter	Non

Certificats

Configuration de NSX-V	Pris en charge	Détails
Certificats (serveur, signés par une autorité de certification)	Oui	Cela s'applique aux certificats ajoutés via des API de magasin d'approbations uniquement.
Modifications de certificat pendant la migration	Oui	Les modifications de certificat sont prises en charge lorsque la migration est suspendue pour tous les modes de migration à l'exception de la migration de la mise en réseau vSphere. Non pris en charge lors de la migration des hôtes et des charges de travail.

Opérations

Détails	Pris en charge	Remarques
CDP de protocole de découverte	Reportez-vous aux notes.	Oui si vous effectuez la migration vers VDS 7.0. Non en cas de migration vers N-VDS.
LLDP de protocole de découverte	Oui	Le mode d'écoute est activé par défaut et ne peut pas être modifié dans NSX. Seul le mode Annoncer peut être modifié.
PortMirroring : Source de mise en miroir distante encapsulée (L3)	Oui	Seul le type de session L3 est pris en charge pour la migration
PortMirroring : PortMirroring distribué Source de mise en miroir distante Destination de mise en miroir distante Mise en miroir de ports distribués (héritage)	Non
IPFIX L2	Oui	LAG with IPFIX n'est pas pris en charge
IPFIX du Pare-feu distribué	Non
Apprentissage MAC	Oui	Vous devez activer (accepter) les transmissions forgées.
VTEP matériel	Non
Mode promiscuité	Non
Allocation des ressources	Non	vNIC activé avec l'allocation de ressources n'est pas pris en charge
IPFIX – Flux internes	Non	IPFIX avec flux internes n'est pas pris en charge

Commutateur

Configuration de NSX-V	Pris en charge	Détails
Pontage L2	Non
VLAN de jonction	Oui pour la migration sur place Non pour la migration « lift-and-shift »	Des groupes de port de liaison montante de jonction doivent être configurés avec une plage VLAN comprise entre 0 et 4094.
Configuration VLAN	Oui	La configuration avec VLAN uniquement (aucun VXLAN) est prise en charge.
Association et basculement : Équilibreur de charge Ordre de basculement de liaison montante	Oui	Options prises en charge pour l'équilibrage de charge (stratégie d'association) : Utiliser la commande de basculement explicite Route basée sur le hachage MAC source Les autres options d'équilibrage de charge ne sont pas prises en charge.
Association et basculement : Détection de panne réseau Notifier les commutateurs Stratégie inverse Ordre de restauration	Non
LACP	Oui	Pour VDS 7.0 et versions ultérieures, la fonctionnalité LACP n’est pas modifiée lors de la migration. Pour les versions antérieures de VDS, un nouveau commutateur N-VDS remplace le VDS. Cela entraînera une perte de trafic lors de la migration de l'hôte. IPFIX configuré sur DVS (pas DFW IPFIX) n'est pas pris en charge avec LACP

Sécurité des commutateurs et découverte d'adresses IP

Configuration de NSX-V	Pris en charge depuis la migration	Détails
Découverte d'adresses IP (ARP, ND, DHCPv4 et DHCPv6)	Oui	Les limites de liaison suivantes s'appliquent sur NSX pour la migration : 128 pour les adresses IP découvertes par ARP 128 pour les adresses IP découvertes par DHCPv4 15 pour les adresses IP découvertes par DHCPv6 15 pour les adresses IP découvertes par ND
SpoofGuard (manuel, TOFU, désactivé)	Oui
Sécurité des commutateurs (filtre BPDU, bloc de client DHCP, bloc de serveur DHCP, Protection contre les annonces du routeur)	Oui
Migration des liaisons de chemin de données à partir du module Sécurité des commutateurs dans NSX-V vers le module Sécurité des commutateurs dans NSX	Oui	Si SpoofGuard est activé, les liaisons sont migrées à partir du module Sécurité des commutateurs pour prendre en charge la suppression ARP. VSIP : la sécurité du commutateur n'est pas prise en charge, car les liaisons VSIP sont migrées en tant que règles configurées de manière statique.
Profils de découverte	Oui	Les profils ipdiscovery sont créés après la migration à l'aide de la configuration de découverte d'adresses IP pour le commutateur logique et de la configuration ARP et DHCP globale et de cluster.

Plan de contrôle central

Configuration de NSX-V	Pris en charge	Détails
Réplication VTEP par commutateur logique (VNI) et domaine de routage	Oui
Réplication MAC/IP	Non
Zones de transport NSX-V utilisant le mode de réplication multidiffusion ou hybride	Non
Zones de transport NSX-V utilisant le mode de réplication monodiffusion	Oui

Fonctionnalités NSX Edge

Pour obtenir des informations complètes sur les topologies prises en charge, reportez-vous à la section Topologies prises en charge.

Configuration de NSX-V	Pris en charge	Détails
Routage entre la passerelle Edge Service Gateway et le routeur logique ascendant	Oui	BGP est pris en charge. Les routes statiques sont prises en charge. OSPF est pris en charge.
Routage entre la passerelle Edge Services Gateway et le routeur logique distribué	Oui	Les routes sont converties en routes statiques après la migration.
Équilibreur de charge	Oui
Environnement de microsegmentation supporté par VLAN	Oui	Reportez-vous à la section Topologies prises en charge pour plus de détails.
NAT64	Non	Non pris en charge dans NSX.
Paramètres de niveau de nœud sur la passerelle Edge Services Gateway ou le routeur logique distribué	Non	Les paramètres de niveau de nœud, par exemple, serveur Syslog ou NTP, ne sont pas pris en charge. Vous pouvez configurer Syslog et NTP manuellement sur les nœuds NSX Edge.
IPv6	Non
Configuration du filtre de chemin inverse de monodiffusion (URPF) pour les interfaces de la passerelle Edge Services Gateway	Non	URPF sur les interfaces de passerelle NSX est défini sur Strict.
Interfaces de la passerelle Edge Services Gateway de configuration de l'unité de transmission maximale (MTU)	Non	Reportez-vous à Modifier le paramètre MTU global pour plus d'informations sur la modification de la MTU par défaut sur NSX.
Routage de multidiffusion IP	Non
Filtres de préfixe de redistribution de routes	Non
Provenance par défaut	Non	Non pris en charge dans NSX.

Edge Firewall

Configuration de NSX-V	Pris en charge	Détails
Section de pare-feu : nom complet	Oui	Les sections de pare-feu peuvent contenir un maximum de 1 000 règles. Si une section contient plus de 1 000 règles, elle est migrée sous forme de plusieurs sections.
Action pour la règle par défaut	Oui	API NSX-V : GatewayPolicy/action API NSX : SecurityPolicy.action
Configuration globale de pare-feu	Non	Des délais d'expiration par défaut sont utilisés
Règle de pare-feu	Oui	API NSX-V : firewallRule API NSX : SecurityPolicy
Règle de pare-feu : nom	Oui
Règle de pare-feu : balise de règle	Oui	API NSX-V : ruleTag API NSX : Rule_tag
Sources et destinations dans les règles de pare-feu : Regroupement des objets Adresses IP	Oui	API NSX-V : source/groupingObjectId source/ipAddress API NSX : source_groups API NSX-V : destination/groupingObjectId destination/ipAddress API NSX : destination_groups
Sources et destinations de règles de pare-feu : Groupe de vNIC	Non
Services (applications) dans les règles de pare-feu : Service Groupe de service Protocole/port/port source	Oui	API NSX-V : application/applicationId application/service/protocol application/service/port application/service/sourcePort API NSX : Services
Règle de pare-feu : correspondance traduite	Non	La correspondance traduite doit être « false ».
Règle de pare-feu : direction	Oui	Les deux API : direction
Règle de pare-feu : action	Oui	Les deux API : action
Règle de pare-feu : activé	Oui	Les deux API : activé
Règle de pare-feu : journalisation	Oui	API NSX-V : journalisation API NSX : connecté
Règle de pare-feu : description	Oui	Les deux API : description

NAT Edge

Configuration de NSX-V	Pris en charge	Détails
Règle NAT	Oui	API NSX-V : natRule API NSX : /nat/USER/nat-rules
Règle NAT : balise de règle	Oui	API NSX-V : ruleTag API NSX : rule_tag
Règle NAT : action	Oui	API NSX-V : action API NSX : action
Règle NAT : adresse d'origine (adresse source pour les règles SNAT et adresse de destination pour les règles DNAT.)	Oui	API NSX-V : originalAddress API NSX : source_network pour règle SNAT ou destination_network pour règle DNAT
Règle NAT : translatedAddress	Oui	API NSX-V : translatedAddress API NSX : translated_network
Règle NAT : application d'une règle NAT sur une interface spécifique	Non	Appliqué à doit être « any ».
Règle NAT : journalisation	Oui	API NSX-V : loggingEnabled API NSX : journalisation
Règle NAT : activé	Oui	API NSX-V : activé API NSX : désactivé
Règle NAT : description	Oui	API NSX-V : description API NSX : description
Règle NAT : protocole	Oui	API NSX-V : protocole API NSX : Service
Règle NAT : port d'origine (port source pour les règles SNAT, port de destination pour les règles DNAT)	Oui	API NSX-V : originalPort API NSX : Service
Règle NAT : port traduit	Oui	API NSX-V : translatedPort API NSX : Translated_ports
Règle NAT : adresse source dans la règle DNAT	Oui	API NSX-V : dnatMatchSourceAddress API NSX : source_network
Règle NAT : adresse de destination dans la règle SNAT	Oui	API NSX-V : snatMatchDestinationAddress API NSX : destination_network
Règle NAT : port source dans la règle DNAT	Oui	API NSX-V : dnatMatchSourcePort API NSX : Service
Règle NAT : port de destination dans la règle SNAT	Oui	API NSX-V : snatMatchDestinationPort API NSX : Service
Règle NAT : ID de règle	Oui	API NSX-V : ruleID API NSX : id et display_name

VPN L2

Configuration de NSX-V	Pris en charge	Détails
Configuration L2VPN basée sur IPSec à l'aide d'une clé prépartagée (PSK)	Oui	Pris en charge si la mise en réseau en cours d'étirement sur L2VPN est un commutateur logique de superposition. Non pris en charge pour les réseaux VLAN.
Configuration L2VPN basée sur IPSec à l'aide de l'authentification basée sur un certificat	Non
Configuration L2VPN basée sur SSL	Non
Configurations L2VPN avec optimisations de sortie locale	Non
Mode client L2VPN	Non

L3VPN

Configuration de NSX-V	Pris en charge	Détails
Dead Peer Detection	Oui	Dead Peer Detection prend en charge différentes options sur NSX-V et NSX. Vous pouvez envisager d'utiliser BGP pour accélérer la convergence ou configurer un homologue pour qu'il exécute DPD s'il est pris en charge.
Valeurs par défaut de Dead Peer Detection (DPD) modifiées pour : dpdtimeout dpdaction	Non	Dans NSX, dpdaction est défini sur « restart » et ne peut pas être modifié. Si le paramètre NSX-V de dpdtimeout est défini sur 0, dpd est désactivé dans NSX. Sinon, tous les paramètres dpdtimeout sont ignorés et la valeur par défaut est utilisée.
Valeurs par défaut de Dead Peer Detection (DPD) modifiées pour : dpddelay	Oui	NSX-V dpdelay est mappé à NSX dpdinternal.
Chevauchement de sous-réseaux locaux et homologues de deux sessions ou plus.	Non	NSX-V prend en charge les sessions de VPN IPSec basé sur les stratégies dans lequel les sous-réseaux locaux et homologues de deux ou plusieurs sessions se chevauchent mutuellement. Ce comportement n'est pas pris en charge sur NSX. Vous devez reconfigurer les sous-réseaux afin qu'ils ne se chevauchent pas avant de commencer la migration. Si ce problème de configuration n'est pas résolu, l'étape Migrer la configuration échoue.
Sessions IPSec dont le point de terminaison homologue est défini sur any.	Non	La configuration n'est pas migrée.
Modifications apportées à l'extension securelocaltrafficbyip.	Non	Le routeur de service NSX ne dispose pas de trafic généré localement qui doit être envoyé sur le tunnel.
Modifications apportées à ces extensions : auto, sha2_truncbug, sareftrack, leftid, leftsendcert, leftxauthserver, leftxauthclient, leftxauthusername, leftmodecfgserver, leftmodecfgclient, modecfgpull, modecfgdns1, modecfgdns2, modecfgwins1, modecfgwins2, remote_peer_type, nm_configured, forceencaps,overlapip, aggrmode, rekey, rekeymargin, rekeyfuzz, compress, metric,disablearrivalcheck, failureshunt,leftnexthop, keyingtries	Non	Ces extensions ne sont pas prises en charge sur NSX et les modifications apportées ne sont pas migrées.

Équilibreur de charge

Configuration de NSX-V	Pris en charge	Détails
Moniteur/contrôles de santé pour : LDAP DNS MSSQL	Voir les détails.	Les moniteurs ne sont pas migrés.
Règles d'application	Non	NSX-V utilise des règles d'application basées sur HAProxy pour prendre en charge L7. Dans NSX, les règles sont basées sur NGINX. Les règles d'application ne peuvent pas être migrées. Vous devez créer des règles après la migration.
Plage de ports du serveur virtuel L7	Non
IPv6	Non	Si IPv6 est utilisé dans le serveur virtuel, l'intégralité du serveur virtuel est ignorée. Si IPv6 est utilisé dans le pool, le pool serait toujours migré, mais le membre du pool associé serait supprimé.
Algorithmes URL, URI, HTTPHEADER	Voir les détails.	Les pools avec ces algorithmes ne sont pas migrés.
Pool isolé	Non
Membre du pool d'équilibreur de charge avec un port de moniteur différent	Voir les détails.	Le membre du pool ayant un port de moniteur différent n'est pas migré.
MinConn de membres du pool	Non
Extension de moniteur	Non
Persistance des ID de session SSL/table	Non
Persistance MSRDP/table de session	Non
Session d'application de cookie/table de session	Non
Persistance d'application	Non
Surveiller pour : Caractère d'échappement explicite Quitter Retard	Non
Surveiller pour : Envoyer Attendre Délai d'expiration Intervalle maxRetries	Oui
Réglage de Haproxy/IPVS	Non
Filtre d'adresse IP du pool Adresses IPv4	Oui	Les adresses IP IPv4 sont prises en charge. Si Any est utilisé, seules les adresses IPv4 du pool d'adresses IP sont migrées.
Filtre d'adresse IP du pool Adresses IPv6	Non
Pool contenant un objet de regroupement non pris en charge : Cluster Centre de données Groupe de ports distribués Ensemble d'adresses MAC Application virtuelle	Non	Si un pool inclut un objet de regroupement non pris en charge, ces objets sont ignorés et le pool est créé avec des membres d'objets de regroupement pris en charge. Si aucun membre d'objet de regroupement n'est pris en charge, un pool vide est créé.

DHCP et DNS

Tableau 1. Topologies de configuration DHCP

Configuration de NSX-V	Pris en charge	Détails
Relais DHCP configuré sur un routeur logique distribué pointant vers un serveur DHCP configuré sur une passerelle Edge Services Gateway directement connectée	Oui	L'adresse IP du serveur de relais DHCP doit être l'une des adresses IP de l'interface interne de la passerelle Edge Services Gateway. Le serveur DHCP doit être configuré sur une passerelle Edge Services Gateway qui est directement connectée au routeur logique distribué configuré avec le relais DHCP. L'utilisation de DNAT n'est pas prise en charge pour traduire une adresse IP de relais DHCP qui ne correspond pas à une interface interne de la passerelle Edge Services Gateway.
Relais DHCP configuré sur le routeur logique distribué uniquement, aucune configuration de serveur DHCP sur la passerelle Edge Services Gateway connectée	Non
Serveur DHCP configuré sur la passerelle Edge Services Gateway uniquement, aucune configuration de relais DHCP sur le routeur logique distribué connecté	Non

Tableau 2. Fonctionnalités de DHCP

Configuration de NSX-V	Pris en charge	Détails
Pools d'adresses IP	Oui
Liaisons statiques	Oui
Baux DHCP	Oui
Options de DHCP générales	Oui
Service DHCP désactivé	Non	Dans NSX, vous ne pouvez pas désactiver le service DHCP. Si un service DHCP est désactivé sur NSX-V, il n'est pas migré.
Option DHCP : « autre »	Non	Le champ « autre » des options DHCP n'est pas pris en charge pour la migration. Par exemple, l'option DHCP « 80 » n'est pas migrée. <dhcpOptions> <other> <code>80</code> <value>2f766172</value> </other> </dhcpOptions>
Pools d'adresses IP/liaisons orphelins	Non	Si des pools d'adresses IP ou des liaisons statiques sont configurés sur un serveur DHCP, mais ne sont utilisés par aucun commutateur logique connecté, ces objets sont ignorés lors de la migration.
DHCP configuré sur la passerelle Edge Service Gateway avec des commutateurs logiques connectés directement	Non	Pendant la migration, les interfaces de la passerelle Edge Service Gateway directement connectée sont migrées en tant que ports de service centralisés. Toutefois, NSX ne prend pas en charge le service DHCP sur un port de service centralisé, donc la configuration du service DHCP n'est pas migrée pour ces interfaces.

Tableau 3. Fonctionnalités de DNS

Configuration de NSX-V	Pris en charge	Détails
Vues de DNS	Oui	Seul le premier dnsView est migré vers la zone du redirecteur DNS par défaut de NSX.
Configuration de DNS	Oui	Vous devez fournir les adresses IP de l'écouteur DNS disponibles pour tous les nœuds Edge. Un message s'affiche lors de l'étape Résoudre la configuration pour vous y inviter.
DNS : VPN L3	Oui	Vous devez ajouter les adresses IP de l'écouteur DNS NSX récemment configurées dans la liste de préfixes de VPN L3 distants. Un message s'affiche lors de l'étape Résoudre la configuration pour vous y inviter.
DNS configuré sur la passerelle Edge Service Gateway avec des commutateurs logiques connectés directement	Non	Pendant la migration, les interfaces de la passerelle Edge Service Gateway directement connectée sont migrées en tant que ports de service centralisés. Toutefois, NSX ne prend pas en charge le service DNS sur un port de service centralisé, donc la configuration du service DNS n'est pas migrée pour ces interfaces.

Pare-feu distribué (DFW)

Configuration de NSX-V	Pris en charge	Détails
Pare-feu d'identité	Oui
Section - Nom Description TCP strict Pare-feu sans état	Oui	Si une section de pare-feu comporte plus de 1 000 règles, l'outil de migration migre les règles dans plusieurs sections de 1 000 règles chacune.
Sections universelles	Oui si le déploiement de NSX-V dispose d'une instance de NSX Manager en mode principal et d'aucune instance de NSX Manager secondaire.
Règle : source/destination : Adresse IP/Plage/CIDR Port logique Commutateur logique	Oui
Règle : source/destination : VM Port logique Groupe de sécurité/ensemble d'adresses IP/ensemble d'adresses MAC	Oui	mappe sur un groupe de sécurité
Règle : source/destination : Cluster Centre de données DVPG vSS Hôte	Non
Règle : source/destination : Commutateur logique universel	Oui si le déploiement de NSX-V dispose d'une instance de NSX Manager en mode principal et d'aucune instance de NSX Manager secondaire.
Règle : Appliqué à : ANY	Oui	correspond à Pare-feu distribué
Règle : Appliqué à : Groupe de sécurité Port logique Commutateur logique Machine virtuelle	Oui	mappe sur un groupe de sécurité
Règle : Appliqué à : Cluster Centre de données DVPG vSS Hôte	Non
Règle : Appliqué à : Commutateur logique universel	Non Oui si le déploiement de NSX-V dispose d'une instance de NSX Manager en mode principal et d'aucune instance de NSX Manager secondaire.
Règles désactivées dans le pare-feu distribué	Oui
Désactivation du pare-feu distribué au niveau du cluster	Non	Lorsque le pare-feu distribué est activé sur NSX, il est activé sur tous les clusters. Vous ne pouvez pas l'activer sur certains clusters et le désactiver sur d'autres.
Liste d'exclusion DFW	Non	Les listes d'exclusion DFW ne sont pas migrées. Vous devez les recréer sur NSX après la migration.

Services de partenaires : introspection réseau est-ouest

Configuration de NSX-V	Pris en charge	Détails
Service	Non	L'enregistrement du service n'est pas migré. Le partenaire doit enregistrer le service auprès de NSX avant la migration.
Modèle de fournisseur	Non	Le modèle du fournisseur n'est pas migré. Le partenaire doit enregistrer le modèle de fournisseur avec NSX avant la migration.
Profil du service	Non	Les profils de service ne sont pas migrés. Vous ou le partenaire devez créer les profils de service avant la migration. À l'étape Résoudre la configuration de la migration, vous serez invité à mapper chaque profil de service NSX-V à un profil de service NSX. Si vous ignorez le mappage des profils de service, les règles qui utilisent ces profils de service ne sont pas migrées. Une chaîne de services dans NSX sera créée pour chaque profil de service dans NSX-V. La chaîne de services est créée avec la Convention de dénomination suivante : Service-Chain-service_profile_name Le même profil de service est utilisé dans le chemin de transfert et le chemin inverse de la chaîne de services.
Instance de service	Non	Les machines virtuelles de service de partenaires (SVM) ne sont pas migrées. Les SVM de partenaire NSX-V ne peuvent pas être utilisées dans NSX. Pour les services d'introspection réseau est-ouest dans NSX, les machines virtuelles de service de partenaires doivent être déployées sur un segment de superposition.
Section Nom ID Description TCP strict Pare-feu sans état	Oui	Une section est mappée à une stratégie de redirection. L'ID est défini par l'utilisateur et n'est pas généré automatiquement dans NSX. Si une section de pare-feu dans NSX-V comporte plus de 1 000 règles, les règles seront migrées dans plusieurs sections de 1 000 règles chacune. Par exemple, si une section contient 2 500 règles, trois stratégies seront créées : stratégie 1 avec 1 000 règles, stratégie 2 avec 1 000 règles et stratégie 3 avec 500 règles. Les règles de pare-feu avec ou sans état dans NSX-V sont migrées vers des règles de redirection avec ou sans état dans NSX.
Services de partenaires : règles
Nom	Oui
ID de règle	Oui	L'ID de règle est généré par le système. Il peut être différent de l'ID de règle dans NSX-V.
Inverser la source	Oui
Inverser la destination	Oui
Source/Destination VM Groupe de sécurité Ensemble d'adresses IP vNIC	Oui
Services/groupes de services	Oui	Pour plus d'informations, reportez-vous au tableau Services et groupes de services.
Paramètres avancés Direction Type de paquet Balise de règle Commentaires Journal	Oui
Profil de service et action Nom du service Profil du service Action Liaisons de profils de service	Oui	Une liaison de profil de service peut avoir des groupes de ports virtuels distribués (DVPG), des commutateurs logiques et des groupes de sécurité en tant que membres. Une liaison de profil de service dans NSX-V est mappée au champ Appliqué à d'une règle de redirection dans NSX. Le champ Appliqué à accepte uniquement les groupes et ce champ détermine l'étendue de la règle. Dans NSX, la redirection de règle est au niveau d'une stratégie. Toutes les règles d'une stratégie de redirection ont la même étendue (Appliqué à). Le champ Appliqué à dans une règle de redirection NSX peut contenir 128 membres au maximum. Si le nombre de membres d'une liaison de profil de service dépasse 128, réduisez-les avant de démarrer la migration. Par exemple, supposons qu'une liaison de profil de service dispose de 140 membres (groupes de sécurité). Effectuez les étapes suivantes dans NSX-V avant de démarrer la migration : Créez un groupe de sécurité fictif. Transférez 13 groupes de sécurité à ce groupe de sécurité fictif. En d'autres termes, le groupe de sécurité fictif comporte 13 membres. Supprimez la liaison de ces 13 groupes de sécurité du profil de service. Vous disposez désormais de 127 membres dans la liaison de profil de service (140-13). Ajoutez le groupe de sécurité fictif à la liaison de profil de service. Désormais, le nombre total de membres dans la liaison de profil de service est de 128 (127 + 1).
Activer/Désactiver la règle	Oui

Segment de service

Un segment de service sera créé dans la zone de transport de superposition que vous sélectionnez à l'étape Résoudre la configuration de la migration. Dans l'environnement NSX-V, si la zone de transport VXLAN n'est pas préparée avec NSX-V, vous pouvez sélectionner la zone de transport de superposition par défaut dans NSX pour créer le segment de service. Si une ou plusieurs zones de transport VXLAN sont préparées avec NSX-V, vous devez sélectionner une zone de transport de superposition pour créer le segment de service dans NSX.

Priorité de profils de service

Dans NSX-V, un profil de service a une priorité. Si un service dispose de plusieurs profils de service et que plusieurs profils sont liés au même vNIC, le profil de service avec une priorité plus élevée est appliqué en premier sur le vNIC. Cependant, dans NSX, le profil de service n'a pas de priorité. Lorsque plusieurs règles de redirection ont le même paramètre Appliqué à, l'ordre de la règle détermine celle qui est atteinte en premier. En d'autres termes, les règles ayant une priorité de profil plus élevée seront placées avant les règles avec une priorité de profil inférieure dans le tableau de règles NSX. Pour obtenir un exemple détaillé, reportez-vous au scénario 2 dans Ordre des règles d'introspection réseau migrées dans NSX.

Priorité du service

Pour rediriger le trafic vers plusieurs services, NSX-V utilise plusieurs emplacements DVFilter dans le chemin de données d'insertion de services. Un emplacement DVFilter est utilisé pour rediriger le trafic vers un service. Un service dont la priorité est élevée est placé plus haut dans l'emplacement qu'un service avec une priorité faible. Dans NSX, un seul emplacement DVFilter est utilisé et il redirige le trafic vers une chaîne de services. Après la migration vers NSX, les règles qui utilisent un service de partenaires avec une priorité plus élevée sont placées avant les règles qui utilisent un service de partenaires avec une priorité inférieure. Pour obtenir un exemple détaillé, reportez-vous au scénario 3 dans Ordre des règles d'introspection réseau migrées dans NSX.

La redirection du trafic sur une vNIC vers plusieurs services de partenaires n'est pas prise en charge. La redirection vers un seul service de partenaires est prise en charge. Bien que toutes les règles NSX-V soient migrées vers NSX, les configurations de règle migrées utilisent une chaîne de services avec un seul profil de service. Vous ne pouvez pas modifier une chaîne de services existante qui est utilisée dans les règles de redirection.

Solution : pour rediriger le trafic sur un vNIC vers plusieurs services, créez une chaîne de services et définissez l'ordre des profils de service dans la chaîne de services. Mettez à jour les règles migrées pour utiliser cette nouvelle chaîne de services.

Service d'introspection réseau sur les machines virtuelles connectées à un réseau de VM

Dans l'environnement NSX-V, si des règles de service d'introspection réseau s'exécutent sur des machines virtuelles connectées à un réseau de machines virtuelles, ces machines virtuelles perdent la protection de la sécurité après la migration de l'hôte. Pour vous assurer que les règles d'introspection réseau sont appliquées sur les vNIC de ces machines virtuelles après la migration de l'hôte, vous devez connecter ces machines virtuelles à un segment NSX.

Objets de regroupement et Service Composer

Les ensembles d'adresses IP et d'adresses MAC sont migrés vers NSX sous forme de groupes. Consultez Inventaire > Groupes dans l'interface Web de NSX Manager.

Tableau 4. Ensembles d'adresses IP et d'adresses MAC

Configuration de NSX-V	Pris en charge	Détails
Ensembles d'adresses IP	Oui	Les ensembles d'adresses IP comportant jusqu'à 2 millions de membres (adresses IP, sous-réseaux d'adresses IP et plages d'adresses IP) peuvent être migrés. Les ensembles d'adresses IP avec plus de membres ne sont pas migrés.
Ensembles d'adresses MAC	Oui	Les ensembles d'adresses MAC comportant jusqu'à 2 millions de membres peuvent être migrés. Les ensembles d'adresses MAC avec plus de membres ne sont pas migrés.

Les groupes de sécurité sont pris en charge pour la migration avec les limites répertoriées. Les groupes de sécurité sont migrés vers NSX sous forme de groupes. Consultez Inventaire > Groupes dans l'interface Web de NSX Manager.

NSX-V possède des groupes de sécurité définis par le système et par l'utilisateur. Ils sont tous migrés vers NSX sous forme de groupes définis par l'utilisateur.

Le nombre total de « Groupes » après la migration peut ne pas être égal au nombre de groupes de sécurité sur NSX-V. Par exemple, une règle de pare-feu distribué contenant une machine virtuelle comme source serait migrée vers une règle contenant un nouveau groupe avec la machine virtuelle comme membre. Cela augmente le nombre total de groupes sur NSX après la migration.

Tableau 5. Groupes de sécurité

Configuration de NSX-V	Pris en charge	Détails
Groupe de sécurité avec des membres qui n'existent pas	Non	Si l'un des membres du groupe de sécurité n'existe pas, le groupe de sécurité n'est pas migré.
Groupe de sécurité qui contient un groupe de sécurité avec des membres non pris en charge	Non	Si des membres du groupe de sécurité ne sont pas pris en charge pour la migration, le groupe de sécurité n'est pas migré. Si un groupe de sécurité contient un groupe de sécurité dont des membres ne sont pas pris en charge, le groupe de sécurité parent n'est pas migré.
Exclure l'appartenance au groupe de sécurité	Non	Les groupes de sécurité avec un membre exclu directement ou indirectement (via l'imbrication) ne sont pas migrés
Adhésion statique au groupe de sécurité	Oui	Un groupe de sécurité peut contenir jusqu'à 500 membres statiques. Toutefois, les membres statiques générés par le système sont ajoutés si le groupe de sécurité est utilisé dans des règles de pare-feu distribué, diminuant ainsi la limite effective à 499 ou 498. Si le groupe de sécurité est utilisé dans des règles de couche 2 ou de couche 3, un membre statique généré par le système est ajouté au groupe de sécurité. Si le groupe de sécurité est utilisé dans des règles de couche 2 et de couche 3, deux membres statiques générés par le système sont ajoutés. Si des membres n'existent pas au cours de l'étape Résoudre la configuration, le groupe de sécurité n'est pas migré.
Types de membres du groupe de sécurité (Statique ou Entité appartient à) : Cluster Centre de données Groupe d'annuaires Groupe de ports distribués Groupe de ports hérité/réseau Pool de ressources vApp	Non	Si un groupe de sécurité contient l'un des types de membres non pris en charge, le groupe de sécurité n'est pas migré.
Types de membres du groupe de sécurité (Statique ou Entité appartient à) : Groupe de sécurité Ensembles d'adresses IP Ensembles d'adresses MAC	Oui	Les groupes de sécurité, les ensembles d'adresses IP et les ensembles d'adresses MAC sont migrés vers NSX sous forme de groupes. Si un groupe de sécurité NSX-V contient un ensemble d'adresses IP, un ensemble d'adresses MAC ou un groupe de sécurité imbriqué comme membre statique, les groupes correspondants sont ajoutés au groupe parent. Si l'un de ces membres statiques n'a pas été migré vers NSX, le groupe de sécurité parent ne migre pas vers NSX. Par exemple, une adresse IP définie avec plus de 2 millions de membres ne peut pas migrer vers NSX. Par conséquent, un groupe de sécurité qui contient une adresse IP définie avec plus de 2 millions de membres ne peut pas migrer.
Types de membres du groupe de sécurité (Statique ou Entité appartient à) : Commutateur logique (câble virtuel)	Oui	Si un groupe de sécurité contient des commutateurs logiques qui ne migrent pas vers des segments NSX, le groupe de sécurité ne migre pas vers NSX.
Types de membres du groupe de sécurité (Statique ou Entité appartient à) : Balise de sécurité	Oui	Si une balise de sécurité est ajoutée au groupe de sécurité en tant que membre statique ou en tant que membre dynamique utilisant Entité appartient à, la balise de sécurité doit exister pour que le groupe de sécurité soit migré. Si la balise de sécurité est ajoutée au groupe de sécurité en tant que membre dynamique (n'utilisant pas Entité appartient à), l'existence de la balise de sécurité n'est pas vérifiée avant la migration du groupe de sécurité.
Types de membres du groupe de sécurité (Statique ou Entité appartient à) : vNIC Machine virtuelle	Oui	Les vNIC et les VM sont migrées en tant que ExternalIDExpression. Les VM orphelines (VM supprimées des hôtes) sont ignorées lors de la migration du groupe de sécurité. Une fois que les groupes apparaissent sur NSX, les appartenances de VM et vNIC sont mises à jour après un certain temps. Pendant cette période intermédiaire, il peut y avoir des groupes temporaires et leurs groupes temporaires peuvent apparaître en tant que membres. Toutefois, une fois la migration de l'hôte terminée, ces groupes temporaires supplémentaires ne sont plus visibles.
Utilisation de l'opérateur « Correspond à l'expression régulière » pour l'appartenance dynamique	Non	Cela affecte la balise de sécurité et le nom de la VM uniquement. « Correspond à l'expression régulière » n'est pas disponible pour d'autres attributs.
Utilisation d'autres opérateurs disponibles pour les critères d'appartenance dynamique pour les attributs : Balise de sécurité Nom de la machine virtuelle Nom de l'ordinateur Nom du SE de l'ordinateur	Oui	Les opérateurs disponibles pour Nom de la machine virtuelle, Nom de l'ordinateur et Nom du SE de l'ordinateur sont Contient, Se termine par, Est égal à, Est différent de, Commence par. Les opérateurs disponibles pour la balise de sécurité sont Contient, Se termine par, Est égal à, Commence par.
Critères d'Entité appartient à	Oui	Les mêmes limitations pour la migration des membres statiques s'appliquent aux critères d'Entité appartient à. Par exemple, si vous disposez d'un groupe de sécurité qui utilise une entité appartenant à un cluster dans la définition, le groupe de sécurité n'est pas migré. Les groupes de sécurité qui contiennent des critères d'Entité appartient à combinés avec AND ne sont pas migrés.
Opérateurs de critères d'appartenance dynamique (AND, OR) dans le groupe de sécurité	Oui.	Lorsque vous définissez l'appartenance dynamique pour un groupe de sécurité NSX-V, vous pouvez configurer les éléments suivants : Un ou plusieurs ensembles dynamiques. Chaque ensemble dynamique peut contenir un ou plusieurs critères dynamiques. Par exemple, « Nom de la machine virtuelle contient Web ». Vous pouvez choisir de faire correspondre un ou tous les critères dynamiques d'un ensemble dynamique. Vous pouvez choisir de rechercher des correspondances avec AND ou OR entre des ensembles dynamiques. NSX-V ne limite pas le nombre de critères dynamiques, des jeux dynamiques, et vous pouvez avoir des combinaisons de AND et OR. Dans NSX, vous pouvez avoir un groupe comportant cinq expressions. Les groupes de sécurité NSX-V qui contiennent plus de cinq expressions ne sont pas migrés. Exemples de groupes de sécurité pouvant être migrés : Jusqu'à 5 ensembles dynamiques liés avec OR où chaque ensemble dynamique contient jusqu'à 5 critères dynamiques liés avec AND (All dans NSX-V). 1 ensemble dynamique contenant 5 critères dynamiques liés avec OR (Any dans NSX-V). 1 ensemble dynamique contenant 5 critères dynamiques liés avec AND (All dans NSX-V). Tous les types de membres doivent être identiques. 5 ensembles dynamiques liés avec AND et chaque ensemble dynamique contenant exactement 1 critère dynamique. Tous les types de membres doivent être identiques. L'utilisation de critères « Entité appartient à » avec des opérateurs AND n'est pas prise en charge. Toutes les autres combinaisons ou définitions d'un groupe de sécurité contenant des scénarios non pris en charge ne sont pas migrées.

Dans NSX-V, les balises de sécurité sont des objets qui peuvent être appliqués à des VM. Lors de la migration vers NSX, les balises de sécurité sont des attributs d'une VM.

Tableau 6. Balises de sécurité

Configuration de NSX-V	Pris en charge	Détails
Balises de sécurité	Oui	Si une VM dispose d'au moins 25 balises de sécurité appliquées, la migration des balises de sécurité est prise en charge. Si plus de 25 balises de sécurité sont appliquées, aucune balise n'est migrée. Remarque : si les balises de sécurité ne sont pas migrées, la VM n'est pas incluse dans les groupes définis par l'appartenance à une balise. Les balises de sécurité qui ne sont appliquées à aucune machine virtuelle ne sont pas migrées.

Les services et les groupes de services sont migrés vers NSX en tant que services. Consultez Inventaire > Services dans l'interface Web de NSX Manager.

Tableau 7. Services et groupes de services

Configuration de NSX-V	Pris en charge	Détails
Services et groupes de services (applications et groupes d'applications)	Oui	La plupart des services et des groupes de services par défaut sont mappés à des services NSX. Si un service ou un groupe de services n'est pas présent dans NSX, un nouveau service est créé dans NSX.
Groupes de services APP_ALL et APP_POP2	Non	Ces groupes de services définis par le système ne sont pas migrés.
Services et groupes de services avec des conflits de noms	Oui	Si un conflit de nom est identifié dans NSX pour un service ou un groupe de services modifié, un service est créé dans NSX avec un nom au format suivant : <NSXv-Application-Name> migré à partir de NSX-V
Groupes de services qui combinent des services de couche 2 à des services dans d'autres couches	Non
Groupes de services vides	Non	NSX ne prend pas en charge les services vides.
Services de couche 2	Oui	Les services de couche 2 NSX-V sont migrés en tant qu'entrée de service NSX EtherTypeServiceEntry.
Services de couche 3	Oui	En fonction du protocole, les services de couche 3 NSX-V sont migrés vers l'entrée de service NSX comme suit : Protocole TCP/UDP : L4PortSetServiceEntry Protocole ICMP/IPV6ICMP : ICMPTypeServiceEntry Protocole IGMP : IGMPTypeServiceEntry Autres protocoles : IPProtocolServiceEntry
Services de couche 4	Oui	Migré en tant qu'entrée de service NSX ALGTypeServiceEntry.
Services de couche 7	Oui	Migré en tant qu'entrée de service NSX PolicyContextProfile Si un port et un protocole ont été définis pour une application de couche 7 NSX-V, un service est créé dans NSX avec la configuration de port et de protocole appropriée et mappé à PolicyContextProfile.
Groupes de services de couche 7	Non
Règles de pare-feu distribué, de pare-feu Edge ou NAT qui contiennent le port et le protocole	Oui	NSX nécessite un service pour créer ces règles. S'il existe un service approprié, il est utilisé. Si aucun service approprié n'existe, un service est créé à l'aide du port et du protocole spécifiés dans la règle.

Tableau 8. Service Composer

Configuration de NSX-V	Pris en charge	Détails
Stratégies de sécurité de Service Composer	Oui	Les règles de pare-feu définies dans une stratégie de sécurité sont migrées vers NSX en tant que règles de pare-feu distribué. Les règles de pare-feu désactivées définies dans une stratégie de sécurité de Service Composer ne sont pas migrées. Les règles Guest Introspection ou les règles d'introspection réseau définies dans une stratégie de sécurité de Service Composer sont migrées. Si le statut de Service Composer n'est pas synchronisé, l'étape Résoudre la configuration affiche un avertissement. Vous pouvez ignorer la migration des stratégies de Service Composer en ignorant les sections de pare-feu distribué appropriées. Vous pouvez également restaurer la migration, synchroniser Service Composer avec le pare-feu distribué et redémarrer la migration.
Les stratégies de sécurité de Service Composer ne s'appliquent à aucun groupe de sécurité	Non

Configuration du serveur Active Directory

Configuration	Pris en charge	Détails
Serveur Active Directory (AD)	Non