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 vCenter Server.

Configuration de NSX-V

Pris en charge

Détails

NSX-V avec vSAN ou iSCSI sur vSphere Distributed Switch

Oui

Configuration de NSX-T préexistante

Non

Vous devez déployer un nouvel environnement NSX-T.

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-T Edge dans l'environnement NSX-T sont arrêtées. Si l'environnement NSX-T est en cours d'utilisation, le trafic sera interrompu.

Cross-vCenter NSX

(NSX-T 3.2.1 et versions ultérieures) Oui

(NSX-T 3.2.0) Oui, mais sans instances secondaires de NSX Manager

(NSX-T 3.2.1 et versions ultérieures) Uniquement pris en charge si vous choisissez le mode Migrer NSX for vSphere et la topologie définie par l'utilisateur.

(NSX-T 3.2.0) La migration d'un déploiement de site unique NSX-V qui contient un NSX Manager en mode principal, aucune instance secondaire de NSX Manager et des objets universels sur le site principal, est prise en charge. Un tel déploiement de site unique NSX-V est migré vers un environnement de site unique NSX-T (non fédéré) avec des objets locaux. La migration d'un déploiement Cross-vCenter NSX-V avec un NSX Manager principal et plusieurs instances secondaires de NSX Manager n'est pas prise en charge. Le coordinateur de migration migrera uniquement à partir d'une instance de NSX-V Manager disposant du rôle principal ou autonome. Vous pouvez modifier l'environnement NSX-V en modifiant l'état des gestionnaires secondaires afin de migrer chaque environnement NSX-V indépendamment.
Domaines de charge de travail VCF (NSX-T 3.2.1 et versions ultérieures) Oui

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 vRealize 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

  • NSX-V avec des workflows vRealize 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-T.

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-T. 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-T.

Paramètre régional

Non

NSX-T 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

(NSX-T 3.2.0) Non

(NSX-T 3.2.1 et versions ultérieures) Oui

(NSX-T 3.2.1 et versions ultérieures) 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-T. 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 :

  • Équilibrage 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-T 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-T

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

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

Pour plus d'informations, reportez-vous à la section Modes de migration.

Environnement de microsegmentation supporté par VLAN

Oui

NAT64

Non

Non pris en charge dans NSX-T.

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-T 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-T 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-T.

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-T.

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-T : 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-T : SecurityPolicy

Règle de pare-feu : nom

Oui

Règle de pare-feu : balise de règle

Oui

API NSX-V : ruleTag

API NSX-T : 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-T :

  • source_groups

API NSX-V :

  • destination/groupingObjectId

  • destination/ipAddress

API NSX-T :

  • 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-T :

  • 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-T : 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-T : /nat/USER/nat-rules

Règle NAT : balise de règle

Oui

API NSX-V : ruleTag

API NSX-T : rule_tag

Règle NAT : action

Oui

API NSX-V : action

API NSX-T : 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-T : source_network pour règle SNAT ou destination_network pour règle DNAT

Règle NAT : translatedAddress

Oui

API NSX-V : translatedAddress

API NSX-T : 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-T : journalisation

Règle NAT : activé

Oui

API NSX-V : activé

API NSX-T : désactivé

Règle NAT : description

Oui

API NSX-V : description

API NSX-T : description

Règle NAT : protocole

Oui

API NSX-V : protocole

API NSX-T : 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-T : Service

Règle NAT : port traduit

Oui

API NSX-V : translatedPort

API NSX-T : Translated_ports

Règle NAT : adresse source dans la règle DNAT

Oui

API NSX-V : dnatMatchSourceAddress

API NSX-T : source_network

Règle NAT :

adresse de destination dans la règle SNAT

Oui

API NSX-V : snatMatchDestinationAddress

API NSX-T : destination_network

Règle NAT :

port source dans la règle DNAT

Oui

API NSX-V : dnatMatchSourcePort

API NSX-T : Service

Règle NAT :

port de destination dans la règle SNAT

Oui

API NSX-V : snatMatchDestinationPort

API NSX-T : Service

Règle NAT : ID de règle

Oui

API NSX-V : ruleID

API NSX-T : 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-T. 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-T, 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-T. 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-T 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-T. 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-T 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-T et les modifications apportées ne sont pas migrées.

Équilibreur de charge

Le tableau suivant s'applique à la migration de l'équilibreur de charge NSX-V vers l'équilibreur de charge NSX-T (NLB) ou NSX-T Advanced Load Balancer (ALB). Pour plus d'informations sur la migration de l'équilibreur de charge NSX-V vers ALB, reportez-vous à la section Migration de NSX-V Load Balancer vers Advanced Load Balancer.

Configuration de NSX-V

Pris en charge

Détails

Moniteur/contrôles de santé pour :

  • LDAP

  • DNS

  • MSSQL

Voir les détails.

(NLB) Les moniteurs ne sont pas migrés.

(ALB) Les moniteurs LDAP et MSSQL ne sont pas migrés. Le moniteur DNS est migré si ALB dispose d'une licence d'entreprise, mais pas s'il dispose d'une licence de base.

Règles d'application

Non

NSX-V utilise des règles d'application basées sur HAProxy pour prendre en charge L7. Dans NSX-T, 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

(NLB) Non

(ALB) Oui

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.

(NLB) Les pools avec ces algorithmes ne sont pas migrés.

(ALB) Pris en charge si ALB dispose d'une licence d'entreprise. Avec une licence de base, vous recevrez des commentaires pour sélectionner un autre algorithme.

Pool isolé

Non

Membre du pool d'équilibreur de charge avec un port de moniteur différent

Voir les détails.

(NLB) Le membre du pool ayant un port de moniteur différent n’est pas migré.

(ALB) Le membre du pool est migré mais ne se trouvera pas dans la configuration du port de moniteur.

MinConn de membres du pool

Non

Extension de moniteur

Non

Persistance des ID de session SSL/table

(NLB) Non

(ALB) Oui

Persistance MSRDP/table de session

Non

Session d'application de cookie/table de session

(NLB) Non

(ALB) Oui

Persistance d'application

(NLB) Non

(ALB) Oui

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-T, 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-T 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-T.

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-T 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-T 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 :

  • Machine virtuelle

  • 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 : source/destination :

  • VM ne se trouvant pas sur les hôtes NSX-V

 Non NSX-T ne prend pas en charge les objets de référencement non connectés à des groupes de ports ou à des réseaux NSX-T. Ces objets seront perdus de la source ou de la destination à la fin de la migration. Pour éviter ce problème, utilisez des adresses IP dans NSX-V pour référencer ces objets avant la migration.

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-T, 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-T 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-T 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-T 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-T. 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-T 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-T.

Pour les services d'introspection réseau est-ouest dans NSX-T, 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-T.

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-T.

Services de partenaires : règles

Nom

Oui

ID de la 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-T. Le champ Appliqué à accepte uniquement les groupes et ce champ détermine l'étendue de la règle.

Dans NSX-T, 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-T 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 :
  1. Créez un groupe de sécurité fictif.
  2. 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.
  3. 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).
  4. 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-T 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-T.
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-T, 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-T. 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-T.
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-T, un seul emplacement DVFilter est utilisé et il redirige le trafic vers une chaîne de services. Après la migration vers NSX-T, 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-T.

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-T, 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-T.

Objets de regroupement et Service Composer

Les ensembles d'adresses IP et d'adresses MAC sont migrés vers NSX-T sous forme de groupes. Consultez Inventaire > Groupes dans l'interface Web de NSX-T 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-T sous forme de groupes. Consultez Inventaire > Groupes dans l'interface Web de NSX-T 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-T 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-T 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-T 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-T, le groupe de sécurité parent ne migre pas vers NSX-T.

Par exemple, une adresse IP définie avec plus de 2 millions de membres ne peut pas migrer vers NSX-T. 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-T, le groupe de sécurité ne migre pas vers NSX-T.

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-T, 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-T, 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-T, 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-T en tant que services. Consultez Inventaire > Services dans l'interface Web de NSX-T 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-T. Si un service ou un groupe de services n'est pas présent dans NSX-T, un nouveau service est créé dans NSX-T.

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-T pour un service ou un groupe de services modifié, un service est créé dans NSX-T 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-T 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-T 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-T 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-T ALGTypeServiceEntry.

Services de couche 7

Oui

Migré en tant qu'entrée de service NSX-T 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-T 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-T 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-T 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