28 Integrating NSX for vSphere #

The NSX Manager is the centralized network management component of NSX. It provides a single point of configuration and REST API entry-points.

The NSX Manager is installed as a virtual appliance on one of the ESXi hosts within the vSphere environment. This guide will cover installing the appliance on one of the ESXi hosts within the control-plane cluster. For more detailed information, refer to VMware's NSX Installation Guide.

To install the NSX Manager, download the virtual appliance from VMware and deploy the appliance within vCenter onto one of the ESXi hosts. For information on deploying appliances within vCenter, refer to VMware's documentation for ESXi 5.5 or 6.0.

During the deployment of the NSX Manager appliance, be aware of the following:

When prompted, select Accept extra configuration options. This will present options for configuring IPv4 and IPv6 addresses, the default gateway, DNS, NTP, and SSH properties during the installation, rather than configuring these settings manually after the installation.

Note

The IP address assigned to the NSX Manager must be able to resolve reverse DNS.

Power on the NSX Manager virtual machine after it finishes deploying and wait for the operating system to fully load. When ready, carry out the following steps to have the NSX Manager use single sign-on (SSO) and to register the NSX Manager with vCenter:

Note

When configuring SSO, use Lookup Service Port 443 for vCenter version 6.0. Use Lookup Service Port 7444 for vCenter version 5.5.

SSO makes vSphere and NSX more secure by allowing the various components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately. For more details, refer to VMware's documentation on Configure Single Sign-On.

Both the Lookup Service URL and the vCenter Server sections should have a status of connected when configured properly.

Log into the vSphere Web Client (log out and and back in if already logged in). The NSX Manager will appear under the Networking & Security section of the client.

Note

The Networking & Security section will not appear under the vSphere desktop client. Use of the web client is required for the rest of this process.

The NSX controllers serve as the central control point for all logical switches within the vSphere environment's network, and they maintain information about all hosts, logical switches (VXLANs), and distributed logical routers.

NSX controllers will each be deployed as a virtual appliance on the ESXi hosts within the control-plane cluster to form the NSX Controller cluster. For details about NSX controllers and the NSX control plane in general, refer to VMware's NSX documentation.

Important

Whatever the size of the NSX deployment, the following conditions must be met:

• Each NSX Controller cluster must contain three controller nodes. Having a different number of controller nodes is not supported.

• Before deploying NSX Controllers, you must deploy an NSX Manager appliance and register vCenter with NSX Manager.

• Determine the IP pool settings for your controller cluster, including the gateway and IP address range. DNS settings are optional.

• The NSX Controller IP network must have connectivity to the NSX Manager and to the management interfaces on the ESXi hosts.

Log in to the vSphere web client and do the following steps to add the NSX controllers:

Important

Three NSX controllers is mandatory. VMware recommends configuring a DRS anti-affinity rule to prevent the controllers from residing on the same ESXi host. See more information about DRS Affinity Rules.

During Host Preparation, the NSX Manager:

The NSX kernel modules are packaged in VIB (vSphere Installation Bundle) files. They run within the hypervisor kernel and provide services such as distributed routing, distributed firewall, and VXLAN bridging capabilities. These files are installed on a per-cluster level, and the setup process deploys the required software on all ESXi hosts in the target cluster. When a new ESXi host is added to the cluster, the required software is automatically installed on the newly added host.

Before beginning the NSX host preparation process, make sure of the following in your environment:

To prepare the vSphere clusters for NSX:

Important

After host preparation:

• A host reboot is not required

• If you add a host to a prepared cluster, the NSX VIBs are automatically installed on the host.

• If you move a host to an unprepared cluster, the NSX VIBs are automatically uninstalled from the host. In this case, a host reboot is required to complete the uninstall process.

VXLAN is configured on a per-cluster basis, where each vSphere cluster that is to participate in NSX is mapped to a vSphere Distributed Virtual Switch (DVS). When mapping a vSphere cluster to a DVS, each ESXi host in that cluster is enabled for logical switches. The settings chosen in this section will be used in creating the VMkernel interface.

Configuring transport parameters involves selecting a DVS, a VLAN ID, an MTU size, an IP addressing mechanism, and a NIC teaming policy. The MTU for each switch must be set to 1550 or higher. By default, it is set to 1600 by NSX. This is also the recommended setting for integration with OpenStack.

To configure the VXLAN transport parameters:

When configuring the VXLAN transport network, consider the following:

Each VXLAN tunnel will need a segment ID to isolate its network traffic. Therefore, it is necessary to configure a segment ID pool for the NSX VXLAN network to use. If an NSX controller is not deployed within the vSphere environment, a multicast address range must be added to spread traffic across the network and avoid overloading a single multicast address.

For the purposes of the example in these instructions, do the following steps to assign a segment ID pool. Otherwise, follow best practices as outlined in VMware's documentation.

A transport zone controls which hosts a logical switch can reach and has the following characteristics.

Note

OpenStack has only been verified to work with a single transport zone within a vSphere NSX-v environment. Other configurations are currently not supported.

For more information on transport zones, refer to VMware's Add A Transport Zone.

To create a transport zone:

With vSphere environment setup completed, the OpenStack can be deployed. The following sections will cover creating virtual machines within the vSphere environment, configuring the cloud model and integrating NSX-v neutron core plugin into the OpenStack:

In summary, integrating NSX with vSphere has four major steps:

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost third-party-import.yml

ardana > ~/ardana/hos-init.bash

ardana > cd ~/ardana-extensions/ardana-extensions-nsx/vmware/examples/models/entry-scale-nsx
ardana > cp -R entry-scale-nsx ~/openstack/my_cloud/definition

#
# (c) Copyright 2017 SUSE LLC
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#
---
product:
  version: 2
pass-through:
  global:
    vmware:
      - username: VCENTER_ADMIN_USERNAME
        ip: VCENTER_IP
        port: 443
        cert_check: false
        # The password needs to be encrypted using the script
        # openstack/ardana/ansible/ardanaencrypt.py on the deployer:
        #
        # $ cd ~/openstack/ardana/ansible
        # $ export ARDANA_USER_PASSWORD_ENCRYPT_KEY=ENCRYPTION_KEY
        # $ ./ardanaencrypt.py
        #
        # The script will prompt for the vCenter password. The string
        # generated is the encrypted password. Enter the string
        # enclosed by double-quotes below.
        password: "ENCRYPTED_PASSWD_FROM_ARDANAENCRYPT"

        # The id is is obtained by the URL
        # https://VCENTER_IP/mob/?moid=ServiceInstance&doPath=content%2eabout,
        # field instanceUUID.
        id: VCENTER_UUID
  servers:
    -
      # Here the 'id' refers to the name of the node running the
      # esx-compute-proxy. This is identical to the 'servers.id' in
      # servers.yml. There should be one esx-compute-proxy node per ESX
      # resource pool.
      id: esx-compute1
      data:
        vmware:
          vcenter_cluster: VMWARE_CLUSTER1_NAME
          vcenter_id: VCENTER_UUID
    -
      id: esx-compute2
      data:
        vmware:
          vcenter_cluster: VMWARE_CLUSTER2_NAME
          vcenter_id: VCENTER_UUID

# (c) Copyright 2017 SUSE LLC
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#
---
  product:
    version: 2
  configuration-data:
    - name: NSX-CONFIG-CP1
      services:
        - nsx
      data:
        # (Required) URL for NSXv manager (e.g - https://management_ip).
        manager_uri: 'https://NSX_MGR_IP

        # (Required) NSXv username.
        user: 'admin'

        # (Required) Encrypted NSX Manager password.
        # Password encryption is done by the script
        # ~/openstack/ardana/ansible/ardanaencrypt.py on the deployer:
        #
        # $ cd ~/openstack/ardana/ansible
        # $ export ARDANA_USER_PASSWORD_ENCRYPT_KEY=ENCRYPTION_KEY
        # $ ./ardanaencrypt.py
        #
        # NOTE: Make sure that the NSX Manager password is encrypted with the same key
        # used to encrypt the VCenter password.
        #
        # The script will prompt for the NSX Manager password. The string
        # generated is the encrypted password. Enter the string enclosed
        # by double-quotes below.
        password: "ENCRYPTED_NSX_MGR_PASSWD_FROM_ARDANAENCRYPT"
        # (Required) datacenter id for edge deployment.
        # Retrieved using
        #    http://VCENTER_IP_ADDR/mob/?moid=ServiceInstance&doPath=content
        # click on the value from the rootFolder property. The datacenter_moid is
        # the value of the childEntity property.
        # The vCenter-ip-address comes from the file pass_through.yml in the
        # input model under "pass-through.global.vmware.ip".
        datacenter_moid: 'datacenter-21'
        # (Required) id of logic switch for physical network connectivity.
        # How to retrieve
        # 1. Get to the same page where the datacenter_moid is found.
        # 2. Click on the value of the rootFolder property.
        # 3. Click on the value of the childEntity property
        # 4. Look at the network property. The external network is
        #    network associated with EXTERNAL VM in VCenter.
        external_network: 'dvportgroup-74'
        # (Required) clusters ids containing OpenStack hosts.
        # Retrieved using http://VCENTER_IP_ADDR/mob, click on the value
        # from the rootFolder property. Then click on the value of the
        # hostFolder property. Cluster_moids are the values under childEntity
        # property of the compute clusters.
        cluster_moid: 'domain-c33,domain-c35'
        # (Required) resource-pool id for edge deployment.
        resource_pool_id: 'resgroup-67'
        # (Optional) datastore id for edge deployment. If not needed,
        # do not declare it.
        # datastore_id: 'datastore-117'

        # (Required) network scope id of the transport zone.
        # To get the vdn_scope_id, in the vSphere web client from the Home
        # menu:
        #   1. click on Networking & Security
        #   2. click on installation
        #   3. click on the Logical Netowrk Preparation tab.
        #   4. click on the Transport Zones button.
        #   5. Double click on the transport zone being configure.
        #   6. Select Manage tab.
        #   7. The vdn_scope_id will appear at the end of the URL.
        vdn_scope_id: 'vdnscope-1'

        # (Optional) Dvs id for VLAN based networks. If not needed,
        # do not declare it.
        # dvs_id: 'dvs-68'

        # (Required) backup_edge_pool: backup edge pools management range,
        # - edge_type>[edge_size]:MINIMUM_POOLED_EDGES:MAXIMUM_POOLED_EDGES
        # - edge_type: service (service edge) or  vdr (distributed edge)
        # - edge_size:  compact ,  large (by default),  xlarge  or  quadlarge
        backup_edge_pool: 'service:compact:4:10,vdr:compact:4:10'

        # (Optional) mgt_net_proxy_ips: management network IP address for
        # metadata proxy. If not needed, do not declare it.
        # mgt_net_proxy_ips: '10.142.14.251,10.142.14.252'

        # (Optional) mgt_net_proxy_netmask: management network netmask for
        # metadata proxy. If not needed, do not declare it.
        # mgt_net_proxy_netmask: '255.255.255.0'

        # (Optional) mgt_net_moid: Network ID for management network connectivity
        # Do not declare if not used.
        # mgt_net_moid: 'dvportgroup-73'

        # ca_file: Name of the certificate file. If insecure is set to True,
        # then this parameter is ignored. If insecure is set to False and this
        # parameter is not defined, then the system root CAs will be used
        # to verify the server certificate.
        ca_file: a/nsx/certificate/file

        # insecure:
        # If true (default), the NSXv server certificate is not verified.
        # If false, then the default CA truststore is used for verification.
        # This option is ignored if "ca_file" is set
        insecure: True
        # (Optional) edge_ha: if true, will duplicate any edge pool resources
        # Default to False if undeclared.
        # edge_ha: False
        # (Optional) spoofguard_enabled:
        # If True (default), indicates NSXV spoofguard component is used to
        # implement port-security feature.
        # spoofguard_enabled: True
        # (Optional) exclusive_router_appliance_size:
        # Edge appliance size to be used for creating exclusive router.
        # Valid values: 'compact', 'large', 'xlarge', 'quadlarge'
        # Defaults to 'compact' if not declared.  # exclusive_router_appliance_size:
        'compact'

ardana > cd ~/openstack/my_cloud/definition
ardana > git commit -A -m "Configuration changes for NSX deployment"
ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
 -e \encrypt="" -e rekey=""

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml
ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > export ARDANA_USER_PASSWORD_ENCRYPT_KEY=PASSWORD_KEY
ardana > ansible-playbook -i hosts/verb_hosts site.yml
ardana > ansible-playbook -i hosts/verb_hosts ardana-cloud-configure.yml

The NSX Manager is the centralized network management component of NSX. It provides a single point of configuration and REST API entry-points.

The NSX Manager is installed as a virtual appliance on one of the ESXi hosts within the vSphere environment. This guide will cover installing the appliance on one of the ESXi hosts within the control-plane cluster. For more detailed information, refer to VMware's NSX Installation Guide.

To install the NSX Manager, download the virtual appliance from VMware and deploy the appliance within vCenter onto one of the ESXi hosts. For information on deploying appliances within vCenter, refer to VMware's documentation for ESXi 5.5 or 6.0.

During the deployment of the NSX Manager appliance, be aware of the following:

When prompted, select Accept extra configuration options. This will present options for configuring IPv4 and IPv6 addresses, the default gateway, DNS, NTP, and SSH properties during the installation, rather than configuring these settings manually after the installation.

Note

The IP address assigned to the NSX Manager must be able to resolve reverse DNS.

Power on the NSX Manager virtual machine after it finishes deploying and wait for the operating system to fully load. When ready, carry out the following steps to have the NSX Manager use single sign-on (SSO) and to register the NSX Manager with vCenter:

Note

When configuring SSO, use Lookup Service Port 443 for vCenter version 6.0. Use Lookup Service Port 7444 for vCenter version 5.5.

SSO makes vSphere and NSX more secure by allowing the various components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately. For more details, refer to VMware's documentation on Configure Single Sign-On.

Both the Lookup Service URL and the vCenter Server sections should have a status of connected when configured properly.

Log into the vSphere Web Client (log out and and back in if already logged in). The NSX Manager will appear under the Networking & Security section of the client.

Note

The Networking & Security section will not appear under the vSphere desktop client. Use of the web client is required for the rest of this process.

The NSX controllers serve as the central control point for all logical switches within the vSphere environment's network, and they maintain information about all hosts, logical switches (VXLANs), and distributed logical routers.

NSX controllers will each be deployed as a virtual appliance on the ESXi hosts within the control-plane cluster to form the NSX Controller cluster. For details about NSX controllers and the NSX control plane in general, refer to VMware's NSX documentation.

Important

Whatever the size of the NSX deployment, the following conditions must be met:

• Each NSX Controller cluster must contain three controller nodes. Having a different number of controller nodes is not supported.

• Before deploying NSX Controllers, you must deploy an NSX Manager appliance and register vCenter with NSX Manager.

• Determine the IP pool settings for your controller cluster, including the gateway and IP address range. DNS settings are optional.

• The NSX Controller IP network must have connectivity to the NSX Manager and to the management interfaces on the ESXi hosts.

Log in to the vSphere web client and do the following steps to add the NSX controllers:

Important

Three NSX controllers is mandatory. VMware recommends configuring a DRS anti-affinity rule to prevent the controllers from residing on the same ESXi host. See more information about DRS Affinity Rules.

During Host Preparation, the NSX Manager:

The NSX kernel modules are packaged in VIB (vSphere Installation Bundle) files. They run within the hypervisor kernel and provide services such as distributed routing, distributed firewall, and VXLAN bridging capabilities. These files are installed on a per-cluster level, and the setup process deploys the required software on all ESXi hosts in the target cluster. When a new ESXi host is added to the cluster, the required software is automatically installed on the newly added host.

Before beginning the NSX host preparation process, make sure of the following in your environment:

To prepare the vSphere clusters for NSX:

Important

After host preparation:

• A host reboot is not required

• If you add a host to a prepared cluster, the NSX VIBs are automatically installed on the host.

• If you move a host to an unprepared cluster, the NSX VIBs are automatically uninstalled from the host. In this case, a host reboot is required to complete the uninstall process.

VXLAN is configured on a per-cluster basis, where each vSphere cluster that is to participate in NSX is mapped to a vSphere Distributed Virtual Switch (DVS). When mapping a vSphere cluster to a DVS, each ESXi host in that cluster is enabled for logical switches. The settings chosen in this section will be used in creating the VMkernel interface.

Configuring transport parameters involves selecting a DVS, a VLAN ID, an MTU size, an IP addressing mechanism, and a NIC teaming policy. The MTU for each switch must be set to 1550 or higher. By default, it is set to 1600 by NSX. This is also the recommended setting for integration with OpenStack.

To configure the VXLAN transport parameters:

When configuring the VXLAN transport network, consider the following:

Each VXLAN tunnel will need a segment ID to isolate its network traffic. Therefore, it is necessary to configure a segment ID pool for the NSX VXLAN network to use. If an NSX controller is not deployed within the vSphere environment, a multicast address range must be added to spread traffic across the network and avoid overloading a single multicast address.

For the purposes of the example in these instructions, do the following steps to assign a segment ID pool. Otherwise, follow best practices as outlined in VMware's documentation.

Each VXLAN tunnel will need a segment ID to isolate its network traffic. Therefore, it is necessary to configure a segment ID pool for the NSX VXLAN network to use. If an NSX controller is not deployed within the vSphere environment, a multicast address range must be added to spread traffic across the network and avoid overloading a single multicast address.

For the purposes of the example in these instructions, do the following steps to assign a segment ID pool. Otherwise, follow best practices as outlined in VMware's documentation.

A transport zone controls which hosts a logical switch can reach and has the following characteristics.

Note

OpenStack has only been verified to work with a single transport zone within a vSphere NSX-v environment. Other configurations are currently not supported.

For more information on transport zones, refer to VMware's Add A Transport Zone.

To create a transport zone:

With vSphere environment setup completed, the OpenStack can be deployed. The following sections will cover creating virtual machines within the vSphere environment, configuring the cloud model and integrating NSX-v neutron core plugin into the OpenStack:

Within the vSphere environment, create the OpenStack compute proxy virtual machines. There needs to be one neutron compute proxy virtual machine per ESXi compute cluster.

For the minimum NSX hardware requirements, refer to Table 28.2, “NSX Hardware Requirements for Baremetal Integration”. Also be aware of the networking model to use for the VM network interfaces, see Table 28.3, “NSX Interface Requirements”:

If ESX VMs are to be used as nova compute proxy nodes, set up three LAN interfaces in each virtual machine as shown in the table below. There is at least one nova compute proxy node per cluster.

28.2.2.4.9.1 Advanced Configuration Option #

  

Important

Within vSphere for each in the virtual machine:

• In the Options section, under Advanced configuration parameters, ensure that disk.EnableUUIDoption is set to true.

• If the option does not exist, it must be added. This option is required for the OpenStack deployment.

• If the option is not specified, then the deployment will fail when attempting to configure the disks of each virtual machine.

ardana > eval $(ssh-agent)
ardana > ssh-add ~/.ssh/id_rsa

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost third-party-import.yml

ardana > ~/ardana/hos-init.bash

ardana > cd ~/ardana-extensions/ardana-extensions-nsx/vmware/examples/models/entry-scale-nsx
ardana > cp -R entry-scale-nsx ~/openstack/my_cloud/definition

#
# (c) Copyright 2017 SUSE LLC
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#
---
product:
  version: 2
pass-through:
  global:
    vmware:
      - username: VCENTER_ADMIN_USERNAME
        ip: VCENTER_IP
        port: 443
        cert_check: false
        # The password needs to be encrypted using the script
        # openstack/ardana/ansible/ardanaencrypt.py on the deployer:
        #
        # $ cd ~/openstack/ardana/ansible
        # $ export ARDANA_USER_PASSWORD_ENCRYPT_KEY=ENCRYPTION_KEY
        # $ ./ardanaencrypt.py
        #
        # The script will prompt for the vCenter password. The string
        # generated is the encrypted password. Enter the string
        # enclosed by double-quotes below.
        password: "ENCRYPTED_PASSWD_FROM_ARDANAENCRYPT"

        # The id is is obtained by the URL
        # https://VCENTER_IP/mob/?moid=ServiceInstance&doPath=content%2eabout,
        # field instanceUUID.
        id: VCENTER_UUID
  servers:
    -
      # Here the 'id' refers to the name of the node running the
      # esx-compute-proxy. This is identical to the 'servers.id' in
      # servers.yml. There should be one esx-compute-proxy node per ESX
      # resource pool.
      id: esx-compute1
      data:
        vmware:
          vcenter_cluster: VMWARE_CLUSTER1_NAME
          vcenter_id: VCENTER_UUID
    -
      id: esx-compute2
      data:
        vmware:
          vcenter_cluster: VMWARE_CLUSTER2_NAME
          vcenter_id: VCENTER_UUID

# (c) Copyright 2017 SUSE LLC
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#
---
  product:
    version: 2
  configuration-data:
    - name: NSX-CONFIG-CP1
      services:
        - nsx
      data:
        # (Required) URL for NSXv manager (e.g - https://management_ip).
        manager_uri: 'https://NSX_MGR_IP

        # (Required) NSXv username.
        user: 'admin'

        # (Required) Encrypted NSX Manager password.
        # Password encryption is done by the script
        # ~/openstack/ardana/ansible/ardanaencrypt.py on the deployer:
        #
        # $ cd ~/openstack/ardana/ansible
        # $ export ARDANA_USER_PASSWORD_ENCRYPT_KEY=ENCRYPTION_KEY
        # $ ./ardanaencrypt.py
        #
        # NOTE: Make sure that the NSX Manager password is encrypted with the same key
        # used to encrypt the VCenter password.
        #
        # The script will prompt for the NSX Manager password. The string
        # generated is the encrypted password. Enter the string enclosed
        # by double-quotes below.
        password: "ENCRYPTED_NSX_MGR_PASSWD_FROM_ARDANAENCRYPT"
        # (Required) datacenter id for edge deployment.
        # Retrieved using
        #    http://VCENTER_IP_ADDR/mob/?moid=ServiceInstance&doPath=content
        # click on the value from the rootFolder property. The datacenter_moid is
        # the value of the childEntity property.
        # The vCenter-ip-address comes from the file pass_through.yml in the
        # input model under "pass-through.global.vmware.ip".
        datacenter_moid: 'datacenter-21'
        # (Required) id of logic switch for physical network connectivity.
        # How to retrieve
        # 1. Get to the same page where the datacenter_moid is found.
        # 2. Click on the value of the rootFolder property.
        # 3. Click on the value of the childEntity property
        # 4. Look at the network property. The external network is
        #    network associated with EXTERNAL VM in VCenter.
        external_network: 'dvportgroup-74'
        # (Required) clusters ids containing OpenStack hosts.
        # Retrieved using http://VCENTER_IP_ADDR/mob, click on the value
        # from the rootFolder property. Then click on the value of the
        # hostFolder property. Cluster_moids are the values under childEntity
        # property of the compute clusters.
        cluster_moid: 'domain-c33,domain-c35'
        # (Required) resource-pool id for edge deployment.
        resource_pool_id: 'resgroup-67'
        # (Optional) datastore id for edge deployment. If not needed,
        # do not declare it.
        # datastore_id: 'datastore-117'

        # (Required) network scope id of the transport zone.
        # To get the vdn_scope_id, in the vSphere web client from the Home
        # menu:
        #   1. click on Networking & Security
        #   2. click on installation
        #   3. click on the Logical Netowrk Preparation tab.
        #   4. click on the Transport Zones button.
        #   5. Double click on the transport zone being configure.
        #   6. Select Manage tab.
        #   7. The vdn_scope_id will appear at the end of the URL.
        vdn_scope_id: 'vdnscope-1'

        # (Optional) Dvs id for VLAN based networks. If not needed,
        # do not declare it.
        # dvs_id: 'dvs-68'

        # (Required) backup_edge_pool: backup edge pools management range,
        # - edge_type>[edge_size]:MINIMUM_POOLED_EDGES:MAXIMUM_POOLED_EDGES
        # - edge_type: service (service edge) or  vdr (distributed edge)
        # - edge_size:  compact ,  large (by default),  xlarge  or  quadlarge
        backup_edge_pool: 'service:compact:4:10,vdr:compact:4:10'

        # (Optional) mgt_net_proxy_ips: management network IP address for
        # metadata proxy. If not needed, do not declare it.
        # mgt_net_proxy_ips: '10.142.14.251,10.142.14.252'

        # (Optional) mgt_net_proxy_netmask: management network netmask for
        # metadata proxy. If not needed, do not declare it.
        # mgt_net_proxy_netmask: '255.255.255.0'

        # (Optional) mgt_net_moid: Network ID for management network connectivity
        # Do not declare if not used.
        # mgt_net_moid: 'dvportgroup-73'

        # ca_file: Name of the certificate file. If insecure is set to True,
        # then this parameter is ignored. If insecure is set to False and this
        # parameter is not defined, then the system root CAs will be used
        # to verify the server certificate.
        ca_file: a/nsx/certificate/file

        # insecure:
        # If true (default), the NSXv server certificate is not verified.
        # If false, then the default CA truststore is used for verification.
        # This option is ignored if "ca_file" is set
        insecure: True
        # (Optional) edge_ha: if true, will duplicate any edge pool resources
        # Default to False if undeclared.
        # edge_ha: False
        # (Optional) spoofguard_enabled:
        # If True (default), indicates NSXV spoofguard component is used to
        # implement port-security feature.
        # spoofguard_enabled: True
        # (Optional) exclusive_router_appliance_size:
        # Edge appliance size to be used for creating exclusive router.
        # Valid values: 'compact', 'large', 'xlarge', 'quadlarge'
        # Defaults to 'compact' if not declared.  # exclusive_router_appliance_size:
        'compact'

ardana > cd ~/openstack/my_cloud/definition
ardana > git commit -A -m "Configuration changes for NSX deployment"
ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
 -e \encrypt="" -e rekey=""

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml
ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > export ARDANA_USER_PASSWORD_ENCRYPT_KEY=PASSWORD_KEY
ardana > ansible-playbook -i hosts/verb_hosts site.yml
ardana > ansible-playbook -i hosts/verb_hosts ardana-cloud-configure.yml