Skip navigation

NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。


前回の投稿は、こちらをどうぞ。

NSX Edge LB の API 操作を体験してみる。Part 1(はじめに)


手順について。


今回は、NSX API で One-Arm LB として使用する NSX Edge をデプロイします。

  1. API で指定するオブジェクト ID の確認
  2. NSX Edge のデプロイ

 

初期状態では、NSX Edge が2台だけデプロイされていて、

今回は 3台目の NSX Edge をデプロイします。

nsxapi-lb-p1-00.png

 

1. API で指定するオブジェクト ID の確認

 

NSX Edge を API でデプロイするときに、Web Client では 名前で指定していた vCenter インベントリのオブジェクトを、

ID で指定する必要があります。

色々な確認方法がありますが、今回は PowerCLI で簡易的に確認します。

 

まず、PowerCLI を起動して、vCenter に接続します。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

 

それぞれ、ID を確認しておきます。

 

データセンター: Datacenter Site A

PowerCLI> Get-Datacenter "Datacenter Site A" | ft -AutoSize Name,Id

nsxapi-lb-p1-01.png

 

リソースプール(クラスタ): Management & Edge Cluster

PowerCLI> Get-Cluster "Management & Edge Cluster" | ft -AutoSize Name,Id

nsxapi-lb-p1-02.png

 

ホスト: esx-04a.corp.local

PowerCLI> Get-VMHost "esx-04a.corp.local"  | ft -AutoSize Name,Id

nsxapi-lb-p1-03.png

 

データストア: ds-site-a-nfs01

PowerCLI> Get-Datastore "ds-site-a-nfs01"  | ft -AutoSize Name,Id

nsxapi-lb-p1-04.png

 

フォルダ: Edges

PowerCLI> Get-Folder "Edges" | ft -AutoSize Name,Id

nsxapi-lb-p1-05.png

 

論理スイッチの ID は、NSX API で確認します。

 

論理スイッチ: Web_Tier_01

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/virtualwires | xmllint --xpath '//virtualWire[name="Web_Tier_01"]/objectId' - | more

nsxapi-lb-p1-06.png

 

2. NSX Edge のデプロイ

 

「OneArm-LoadBalancer」 という名前で、Edge Service Gataway をデプロイします。

 

NSX Edge の設定

  • 名前: OneArm-LoadBalancer
  • HA: 設定なし
  • データセンター: Datacenter Site A → datacenter-21
  • Edge の制御レベルログ(ログレベル): 緊急

 

Appliance 配置パラメータ

  • Appliance のサイズ: コンパクト
  • リソースプール: Management & Edge Cluster → datacenter-21
  • ホスト: esx-04a.corp.local → host-46
  • データストア: ds-site-a-nfs01 → datastore-29
  • フォルダ: Edges → group-v261

 

CLI の設定

  • ユーザ名: admin
  • パスワード: VMware1!VMware1!
  • SSH アクセス(remoteAccess): 無効

 

インターフェースの設定

  • vNIC 番号: 0
  • 名前: WebNetwork
  • タイプ: 内部
  • 接続先: 論理スイッチ「Web_Tier_01」 → virtualwire-2
  • IP アドレス: 172.16.10.10
  • サブネットの接頭辞の長さ: 24
  • 接続ステータス: 接続中

 

ルーティングの設定

  • デフォルトゲートウェイ IP の構成: 172.16.10.1

 

これらの設定を指定した XML ファイル(edge-onearm-lb-deploy.txt)を作成します。

cat <<EOF > edge-onearm-lb-deploy.txt

<edge>

  <datacenterMoid>datacenter-21</datacenterMoid>

  <name>OneArm-LoadBalancer</name>

  <vseLogLevel>emergency</vseLogLevel>

  <appliances>

    <applianceSize>compact</applianceSize>

    <appliance>

      <resourcePoolId>domain-c41</resourcePoolId>

      <datastoreId>datastore-29</datastoreId>

      <hostId>host-46</hostId>

      <vmFolderId>group-v261</vmFolderId>

    </appliance>

  </appliances>

  <vnics>

    <vnic>

      <index>0</index>

      <name>WebNetwork</name>

      <type>internal</type>

      <portgroupId>virtualwire-2</portgroupId>

      <addressGroups>

        <addressGroup>

          <primaryAddress>172.16.10.10</primaryAddress>

          <subnetMask>255.255.255.0</subnetMask>

        </addressGroup>

      </addressGroups>

      <mtu>1500</mtu>

      <enableProxyArp>false</enableProxyArp>

      <enableSendRedirects>false</enableSendRedirects>

      <isConnected>true</isConnected>

    </vnic>

  </vnics>

  <cliSettings>

    <userName>admin</userName>

    <password>VMware1!VMware1!</password>

    <remoteAccess>false</remoteAccess>

  </cliSettings>

  <features>

    <routing>

      <staticRouting>

        <defaultRoute>

            <vnic>0</vnic>

            <mtu>1500</mtu>

            <gatewayAddress>172.16.10.1</gatewayAddress>

            <adminDistance>0</adminDistance>

        </defaultRoute>

      </staticRouting>

    </routing>

  </features>

</edge>

EOF

 

XML ファイルを読み込んで、API で NSX Edge をデプロイします。

cat edge-onearm-lb-deploy.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges

 

NSX Edge 「OneArm-LoadBalancer」が、今回は edge-5 としてデプロイされました。

nsxapi-lb-p1-07.png

 

デプロイ直後は NSX Edge ファイアウォールの設定が Deny になっています。

nsxapi-lb-p1-08.png

 

ラボのシナリオとは異なるので、デフォルトのファイアウォールルールの設定を変更します。

  • デフォルト トラフィックポリシー: 承諾(Accept)
  • ログ:無効化

 

XML ファイル(edgefw-default.txt)を作成します。

cat <<EOF > edgefw-default.txt

<firewallDefaultPolicy>

  <action>accept</action>

  <loggingEnabled>false</loggingEnabled>

</firewallDefaultPolicy>

EOF

 

XML ファイルを読み込んで、API で設定変更します。

cat edgefw-default.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-5/firewall/config/defaultpolicy

 

設定変更されました。

nsxapi-lb-p1-09.png

 

つづく。

NSX Edge LB の API 操作を体験してみる。Part 3(One-Arm LB の設定)

NSX Edge ロードバランサ(LB)を NSX API で設定変更してみます。

設定については、HOL-SDC-1603 VMware NSX Introduction の Module 4 のシナリオを参考にしました。

 

VMware Hands-on Labs(HoL)

http://labs.hol.vmware.com/HOL/catalogs/

 

NSX API については、API Guide が参考になります。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

HoL では、下記のように NSX API をためすことができます。

NSX-v の API を HoL で実行してみる。

 

今回も、ラボの vCenter Server Appliance(vcsa-01a)から curl コマンドで、

NSX Manager(192.168.110.15)にアクセスしています。

NSX での 論理 LB の機能は、NSX Edge(Edge Service Gataway)が受け持ちます。

NSX API で NSX Manager に設定変更をリクエストすることで、NSX Edge の設定が変更されます。

 

今回の流れ。

 

長くなってしまうので、今回も含めて 5回に分けて投稿します。

  1. はじめに ※この投稿。
  2. NSX Edge LB の API 操作を体験してみる。Part 2(NSX Edge のデプロイ)
  3. NSX Edge LB の API 操作を体験してみる。Part 3(One-Arm LB の設定)
  4. NSX Edge LB の API 操作を体験してみる。Part 4(LB メンバのステータス確認)
  5. NSX Edge LB の API 操作を体験してみる。Part 5(SSL オフロード)

 

手順は、だいたい下記のような感じになります。

 

まず、One Arm トポロジの NSX Edge LB を構成します。

ここでは、新規で NSX Edge(OneArm-LoadBalancer)を追加してから設定します。

 

NSX Edge をデプロイします。 ★Part 2

  1. API で指定するオブジェクト ID の確認
  2. NSX Edge のデプロイ

 

そして、One Arm の LB を構成します。 ★Part 3

  1. LB の有効化
  2. アプリケーション プロファイルの作成
  3. LB モニタの設定変更
  4. バックエンド プールの作成とメンバの追加
  5. 仮想サーバの作成

 

その後、LB メンバのステータス確認も API で実施してみます。★Part 4

 

最後に、SSL オフロードを構成します。 ★Part 5

In Line トポロジで配置されている既存の NSX Edge LB を、SSL 終端となるように設定変更します。

この構成では、Web サーバでされていた HTTPS の SSL(TLS)終端の処理が NSX Edge にオフロードされます。

ここまでとは異なり、既存の NSX Edge(Perimeter-Gateway)の設定変更です。

  1. SSL証明書の生成
    1. CSR 作成
    2. 自己署名による証明書の作成
  2. アプリケーションプロファイルの作成
  3. バックエンド プールの作成とメンバの追加
  4. 仮想サーバの設定変更

 

次回は、One Arm LB として設定する NSX Edge のデプロイです。

つづく。

NSX Edge LB の API 操作を体験してみる。Part 2(NSX Edge のデプロイ)

Oracle Linux 7 から、Python で vSphere を操作できるようにしてみようと思います。

※いわゆる Red Hat 系ディストリビューションなので RHEL 7.x や CentOS 7.x なども同様です。

 

pyvmomi という Python のライブラリを使用します。

これは、VMware の GitHub サイトにあります。


vmware/pyvmomi

https://github.com/vmware/pyvmomi

 

PyPI にも登録されているので、今回は pip コマンドでインストールします。

 

PyPI - the Python Package Index

pyvmomi

https://pypi.python.org/pypi/pyvmomi/6.0.0.2016.4

 

今回の環境。

 

Oracle Linux 7.2 にインストールします。

[root@vm01 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.2

 

Python のバージョンはこれです。

[root@vm01 ~]# python -V

Python 2.7.5

 

接続先は、vCenter Server Applicance 6.0 u1 です。

 

pyvmomi のインストール。

 

Oracle Linux 7.x は、デフォルトではパッケージがほとんどインストールされていないので、

今回は開発ツール(Development Tools)をグループインストールしてしまいます。

[root@vm01 ~]# yum groupinstall -y "Development Tools"

 

easy_install が含まれる python-setuptools をインストールします。

[root@vm01 ~]# yum install -y python-setuptools

 

pip をインストールします。

[root@vm01 ~]# easy_install pip

 

pip で、pyvmomi をインストールします。

[root@vm01 ~]# pip install pyvmomi

 

pyvmomi がインストールされました。

[root@vm01 ~]# pip freeze

backports.ssl-match-hostname==3.4.0.2

configobj==4.7.2

decorator==3.4.0

ethtool==0.8

iniparse==0.4

M2Crypto==0.21.1

pciutils==1.7.3

perf==0.1

pycurl==7.19.0

pygobject==3.14.0

pygpgme==0.3

pyliblzma==0.5.3

pyOpenSSL==0.13.1

python-dmidecode==3.10.13

pyudev==0.15

pyvmomi==6.0.0.2016.4

pyxattr==0.5.1

requests==2.10.0

rhnlib==2.5.65

six==1.10.0

slip==0.4.0

slip.dbus==0.4.0

urlgrabber==3.10

yum-metadata-parser==1.1.4

 

サンプルスクリプトのインストール。

 

サンプルスクリプトも VMware の GitHub サイトにあるので、git clone します。

[root@vm01 ~]# git clone https://github.com/vmware/pyvmomi-community-samples

 

下記のようなサンプルファイルが配置されます。

[root@vm01 ~]# cd pyvmomi-community-samples/samples/

[root@vm01 samples]# ls -1

README.md

__init__.py

add_disk_to_vm.py

add_vm_extra_config_tags.py

change_disk_mode.py

change_vm_cd_backend.py

change_vm_nic_state.py

change_vm_vif.py

clone_vm.py

create_folder_in_datacenter.py

create_random_marvel_vms.py

create_snapshot.py

delete_disk_from_vm.py

deploy_ovf.py

destroy_vm.py

esxi_perf_sample.py

execute_program_in_vm.py

export_vm.py

find_by_uuid.py

generate_html5_console.py

getallvms.py

getorphanedvms.py

getvnicinfo.py

hello_world_vcenter.py

hello_world_vcenter_with_yaml_recorder.py

list_datastore_cluster.py

list_datastore_info.py

list_dc_datastore_info.py

list_host_alarms.py

list_vmwaretools_status.py

make_dc_and_cluster.py

pyvmomi-to-suds.py

reboot_vm.py

reconfigure_host_for_ha.py

renamer.py

sessions_list.py

set_note.py

set_vcenter_motd.py

soft_reboot.py

suds-to-pyvmomi.py

tests

tools

upload_file_to_datastore.py

upload_file_to_vm.py

vSphereAutoRestartManager.py

vcenter_details.py

virtual_machine_device_info.py

virtual_machine_power_cycle_and_question.py

vminfo_quick.py

waitforupdates.py

 

動作確認。

 

ためしにサンプルスクリプト「hello_world_vcenter.py」で、vCenter(192.168.5.75)に接続してみます。

 

このスクリプトの使用方法です。

[root@vm01 samples]# python hello_world_vcenter.py --help

usage: hello_world_vcenter.py [-h] -s HOST [-o PORT] -u USER [-p PASSWORD]

 

 

Standard Arguments for talking to vCenter

 

 

optional arguments:

  -h, --help            show this help message and exit

  -s HOST, --host HOST  vSphere service to connect to

  -o PORT, --port PORT  Port to connect on

  -u USER, --user USER  User name to use when connecting to host

  -p PASSWORD, --password PASSWORD

                        Password to use when connecting to host

 

接続できました。

[root@vm01 samples]# python hello_world_vcenter.py -s 192.168.5.75 -u administrator@vsphere.local -p 'パスワード'

 

Hello World!

 

If you got here, you authenticted into vCenter.

The server is 192.168.5.75!

current session id: 52fa04cc-85ad-e576-3925-6d7f11776e22

Well done!

 

 

Download, learn and contribute back:

https://github.com/vmware/pyvmomi-community-samples

 

 

 

[root@vm01 samples]#

 

ためしに、対話モードの Python で ESXi (HostSystem)の情報を取得してみました。

[root@vm01 samples]# python

Python 2.7.5 (default, Nov 21 2015, 00:39:04)

[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from pyVim import connect

>>> from pyVmomi import vim

>>> si = connect.SmartConnect(host='192.168.5.75',user='administrator@vsphere.local',pwd='パスワード')

>>> content = si.RetrieveContent()

>>> host_view = content.viewManager.CreateContainerView(content.rootFolder,[vim.HostSystem],True)

>>> for h in host_view.view:

...   print 'HostName:', h.name

...   print 'Hardware:', h.hardware.systemInfo.vendor, h.hardware.systemInfo.model

...   print 'Version: ', h.summary.config.product.version, h.summary.config.product.build

...   print '---'

...

HostName: hv-h01.godc.lab

Hardware: HP ProLiant Micro Server

Version : 6.0.0 3029758

---

HostName: hv-d02.godc.lab

Hardware: Dell Inc. OptiPlex 9010

Version : 6.0.0 3073146

---

HostName: hv-d01.godc.lab

Hardware: Dell Inc. OptiPlex 780

Version : 6.0.0 3073146

---

HostName: hv-i01.godc.lab

Hardware: To Be Filled By O.E.M.

Version : 6.0.0 3247720

---

>>> quit()

[root@vm01 samples]#

 

このように Python から vSphere にアクセスすることができます。

 

ちなみに、VMOMI は VMware Managed Object Management Interface の略のようなので、

pyvmomi は Python の VMOMI ということなのでしょう。

 

VMware API Related Acronyms

http://www.virtuallyghetto.com/2010/08/vmware-api-related-acronyms.html

 

以上、pyvmomi で vCenter に接続してみる話でした。

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。


手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。 ★ここ

 

FW ルール セクションに FW ルールを追加して、通信が許可されたことを確認してみます。


FW ルール セクションに FW ルールを作成。


FW ルールごとに、XML ファイルを作成します。

XML で指定している 各オブジェクトの ID は、以前の投稿(下記)で確認ずみのものです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

「EXT to Web」 ルール

NSX 環境の外部から、Web 層ネットワークの VM に SSH と HTTPS の通信を許可します。

  • ソース: 任意
  • ターゲット: Security Group 「Web-tier」
  • サービス: SSH、HTTPS
  • 操作: 許可

 

「EXT to Web」 ルール用の XML ファイル(dfw-rule-ext2web.txt)

cat <<EOF > dfw-rule-ext2web.txt

<rule id="0" disabled="false" logged="false">

  <name>EXT to Web</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <destinations excluded="false">

    <destination>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>SSH</name>

      <value>application-305</value>

      <type>Application</type>

    </service>

    <service>

      <name>HTTPS</name>

      <value>application-67</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「Web to App」ルール

Web 層ネットワークの VM から、 App 層ネットワークの論理スイッチに接続されている VM に、

MyApp サービス(TCP 8443 番ポート)の通信を許可します。

  • ソース: Security Group 「Web-tier」
  • ターゲット:論理スイッチ 「App_Tier_01」
  • サービス: サービス 「MyApp」
  • 操作: 許可

 

Web to App」 ルール用の XML ファイル(dfw-rule-web2app.txt)

cat <<EOF > dfw-rule-web2app.txt

<rule id="0" disabled="false" logged="false">

  <name>Web to App</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MyApp</name>

      <value>application-371</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「App to Database」ルール

App 層ネットワークの論理スイッチに接続されている VM から DB 層ネットワークの論理スイッチに接続されている VM に、

MySQL サービスの通信を許可します。

  • ソース: 論理スイッチ「App_Tier_01」
  • ターゲット:論理スイッチ「DB_Tier_01」
  • サービス: サービス「MySQL」
  • 操作: 許可

 

「App to Database」 ルール用の XML ファイル(dfw-rule-app2db.txt)

cat <<EOF > dfw-rule-app2db.txt

<rule id="0" disabled="false" logged="false">

  <name>App to Database</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>DB_Tier_01</name>

      <value>virtualwire-4</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MySQL</name>

      <value>application-23</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

作成された FW ルールは、既存ルールの一番上に配置されるので、

今回は、ルールが下記の順になるように、作成順序を工夫しています。

 

FW ルールの順序。

  1. EXT to Web
  2. Web to App
  3. App to Database

 

FW ルールの作成順序。

  1. App to Database
  2. Web to App
  3. EXT to Web

 

※ただし今回の FW ルールでは、FW ルールセクション内で順序が異なっても問題になりません。

 

「App to Database」 ルールの作成

 

FW ルール セッション ID 1005 の ETag を取得して・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

FW ルールを作成します。

cat dfw-rule-app2db.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「Web to App」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-web2app.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「EXT to Web」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-ext2web.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

このような感じで実行します。

hol-1603-mod3-p6-01.png

 

確認

 

Web Client からでも、FW ルールが作成されていることが確認できます。

hol-1603-mod3-p6-02.png

 

Web テストページが表示可能になったことを確認します。

hol-1603-mod3-p6-03.png

 

Web サーバ「web-01a」 にSSH アクセスが可能になったことを確認します。

ちなみに、マイクロセグメンテーションを意識した FW ルール設定なので、

この状態では Web 層のネットワークに所属する VM 同士(web-01a と web-02a) でも

不要な通信は許可されていません。

hol-1603-mod3-p6-04.png

 

このような感じで、Web Client で設定できる FW 設定は、NSX API でも可能です。

XML で設定値を指定しているので複雑に見えるかもしれませんが、

API 実行時に変更が必要な設定値は、ある程度、環境によって限定されるはずです。

今回は XML ファイルを手作業で作成したり、ID を grep で探したりしていますが、

ちゃんとツールを作成すれば手作業より安全に NSX の FW 設定を管理できそうです。

 

以上、NSX API で DFW を設定してみる話でした。

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。 ★ここ
  6. セクションに FW ルールを作成。


今回は FW ルール作成の準備として、FW ルールのセクションを作成します。


FW ルール セクションの作成。

 

FW ルールのセクション「3-tier App」を作成します。

 

セクションを作成する場合、XML はセクション名(name)だけでも大丈夫です。

また、NSX API ガイドにあるように FW ルールを含めてセクションを作成することも可能です。

API ガイドを見た様子では、FW ルールの順序の入れ替えなどはセクション全体の更新となるようなので、

実際は FW ルールもセッションと同時に作成したほうが便利かもしれません。

 

ここでは下記の XML で空のセクションを作成して、後から FW ルールを作成してみます。

<section name="3-tier App"/>

 

API でセクションを作成します。

テキストの量が少なかったので、今回は XML ファイルを作成してません。

echo '<section name="3-tier App"/>' | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

「3-tier App」セクションは、ID 1005 で作成されました。

hol-1603-mod3-p5-01.png

 

Web Client でも「3-tier App」 セクションの作成が確認できます。

hol-1603-mod3-p5-02.png

 

この状態で、次回の投稿で FW ルールを追加してみます。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

参考: FW ルールセクションの作成。(FW ルール含む)

 

FW ルールも含めてセクションを作成する場合は、下記のような XML になります。

この XML を投入すれば今回の設定は終わりですが、HoL の「テキストの送信」で

この量のテキストを送信するのはつらいので、あえて今回は FW ルールを別作成にしました。

<section name="3-tier App" >

  <rule disabled="false" logged="false">

    <name>EXT to Web</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <destinations excluded="false">

      <destination>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>SSH</name>

        <value>application-305</value>

        <type>Application</type>

      </service>

      <service>

        <name>HTTPS</name>

        <value>application-67</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>Web to App</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MyApp</name>

        <value>application-371</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>App to Database</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>DB_Tier_01</name>

        <value>virtualwire-4</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MySQL</name>

        <value>application-23</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

</section>

 

ちなみに、FW セッションを作成する API では、FW ルールを含んでいても ETtag (If-Match ヘッダ)の指定は不要です。

上記の XML を「dfw-section-3tier.txt」 というファイルに保存してあるとすると、

下記のようなコマンドラインで FW セッションが作成できます。

cat dfw-section-3tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

まだつづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 6 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。 ★ここ
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここから、FW ルールの設定を変更します。

FW ルールで設定した通信のみ許可するため、まず FW のデフォルトルールを

すべて許可(Allow)される状態から、すべてブロックされる状態に変更します。

 

デフォルトの FW ルールを Allow → Block に変更。

 

「Default Section Layer3」セクションの「Default Rule」を、Allow から Block(deny)に変更します。

NSX API での FW ルールの設定変更では、まず XML ファイルを作成しておきます。

 

既存の FW ルールの情報は下記のようなコマンドラインで確認できるので、用意する XML の参考にします。

URL に含まれる ID は、前回の投稿で確認したものを指定しています。

  • 「Default Section Layer3」 の Section ID = 1003
  • 「Default Rule」 の Rule ID = 1001

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | xmllint --format -

 

今回は「Default Rule」ルールを設定変更するための XML を、「dfw-rule-default.txt」として用意します。

  • ルールの ID は、1001。※前回の投稿で確認した ID。
  • action で、Block に対応する「deny」を指定。

cat <<EOF > dfw-rule-default.txt

<rule id="1001" disabled="false" logged="false">

  <name>Default Rule</name>

  <action>deny</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

</rule>

EOF

 

FW ルールの設定を変更する NSX API では、ETag ヘッダの指定が必要なため、設定変更の対象となるリソースの ETag を確認しておきます。

ヘッダ情報を確認するため、下記の curl コマンドラインでは「-I」 オプションを付けています。

curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

hol-1603-mod3-p4-01.png


今回は、ETag の値を「ETAG」 という変数に代入して、コマンドラインで指定しています。

Etag の値を取得します。

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | grep ETag | awk '{print $2}'`

 

さきほど作成した XML ファイル(dfw-rule-default.txt) の内容で、FW ルールを設定変更します。

cat dfw-rule-default.txt | curl -k -s -u admin:VMware1! -X PUT -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

 

コマンドラインの実行結果から、action が deny になったことが確認できます。

hol-1603-mod3-p4-02.png

 

Web Client の情報を更新すると、ルールの Action が Allow から Block に変更されたことがわかります。

hol-1603-mod3-p4-03.png

 

「3-Tier Web App」のテストページが表示できなくなります。

hol-1603-mod3-p4-04.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM 「web-01a」 への SSH アクセスができなくなります。

hol-1603-mod3-p4-05.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。 ★ここ
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

NSX API では、URL や XML で設定対象を指定するときに、対象オブジェクトの ID 指定が必要になります。

そこで、各オブジェクトの ID を確認しておきます。

XML の出力結果を整形するため、パイプで 「xmllint --format -」 をつけています。

また、NSX API で取得した情報は、XML としてパースするわけではなく grep で簡易的に絞り込んでいます。

 

Transport Zone ID


Transport Zone の ID を確認しておきます。

今回の設定では、「Local-Transport-Zone-A」 という名前の Transport Zone を指定します。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes | xmllint --format - | grep -E "vdnscope-|name" | grep -B1 "Local-Transport-Zone-A"

 

ID には、「vdnscope-」 がつきます。

  • Local-Transport-Zone-A → vdnscope-1

hol-1603-mod3-p3-01.png

 

論理スイッチ ID

 

論理スイッチ「App_Tier_01」、「DB_Tier_01」 の ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | grep -E "virtualwire-|name" | grep -B1 -E "App_Tier_01|DB_Tier_01"

 

ID には、「virtualwire-」 がつきます。

  • App_Tier_01 → virtualwire-3
  • DB_Tier_01 → virtualwire-4

hol-1603-mod3-p3-02.png


セキュリティグループ ID

 

FW ルールで指定する、セキュリティグループの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/securitygroup/scope/globalroot-0 | xmllint --format - | grep -E "securitygroup-|name" | grep -B1 "Web-tier"

 

ID には、「securitygroup-」 がつきます。

hol-1603-mod3-p3-03.png

 

サービス ID

 

FW ルールで指定するサービスの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/application/scope/globalroot-0 | xmllint --format - | grep -E "objectId|name" | grep -B1 -E "SSH|HTTPS|MyApp|MySQL"

 

ID には、「application-」 がつきます。

  • HTTPS → application-67
  • SSH → application-305
  • MyApp → application-371 ※ここまでの手順で作成したサービス。
  • MySQL → application-23

hol-1603-mod3-p3-04.png

 

FW ルール セクション ID


「Default Section Layer3」セクションの情報を確認します。

ルール名に含まれる半角スペースは、URL エンコーディングの都合で 「%20」 としています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections?name=Default%20Section%20Layer3 | xmllint --format - | grep section

 

「Default Section Layer3」 セクションが ID = 1003 だということがわかります。

hol-1603-mod3-p3-05.png

 

FW ルール ID


ruleType=LAYER3 のルールで、ルール名に「default」 が含まれるルールの情報を取得してみます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config?ruleType=LAYER3\&name=default | xmllint --format - | grep -E "id=|name=" -A1

 

「Default Rule」 ルールが ID = 1001 だとわかります。

hol-1603-mod3-p3-06.png

 

つづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 1 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみようと思います。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。 ★ここ
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここでは、あとで FW ルールで通信許可のために指定する Service オブジェクトを作成します。

 

Service の作成

 

下記のサービスを作成します。

  • サービス名: MyApp
  • プロトコル: TCP
  • ボート番号: 8443

 

サービスの設定を記載した XML ファイルを作成します。

API ガイドをもとにすると、下記のような XML になりますが・・・

<application>

  <objectId></objectId>

  <type>

    <typeName/>

  </type>

  <description></description>

  <name>MyApp</name>

  <revision>0</revision>

  <objectTypeName></objectTypeName>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

 

今回は、デフォルト値でよいものは省略して、下記のように XML ファイルを作成しました。

cat <<EOF > app-myapp.txt

<application>

  <name>MyApp</name>

  <description/>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

EOF

 

作成した XML ファイルをもとに、API でサービスを作成します。

サービスは、API では「Application」 として扱われています。

cat app-myapp.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/application/globalroot-0

 

「MyApp」 サービスが、「application-371」 という ID で作成されたことがわかります。

hol-1603-mod3-p2-01.png

 

Web Client でも、サービスが作成されたことが確認できます。

サービスは、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager →

「Manage」 →「Grouping Objects」 →「Service」 で確認できます。

hol-1603-mod3-p2-02.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

これまで、VMware Hands-on Labs(HoL)で NSX API を試すポストをしてきました。

今回は、分散ファイアウォール(DFW)を、API で設定してみようと思います。

DFW の設定については、「HOL-SDC-1603 VMware NSX Introduction」の Module 3 シナリオをもとにしました。

 

VMware Hands-on Labs

http://labs.hol.vmware.com/HOL/catalogs/

 

同じく HOL-SDC-1603 をもとにした、以前のポストもどうぞ・・・

NSX-v の API を HoL で実行してみる。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

NSX API で NW 構成変更を体験してみる。Part 2(HOL-SDC-1603 Module 2 より)

 

NSX API ガイドは下記です。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

手順の流れ。

 

HoL のシナリオと同様の設定をしますが、グループオブジェクトの作成などは順番を工夫しています。

1 ~ 3 については、あとで FW ルールで指定するための準備です。

  1. Security Group の作成。 ★今回はここまで。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

今回も、ラボの vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

Lab の初期状態。

 

設定変更前の Lab の環境について Web Client で状態確認しておきます。

「Default Section Layer3」セクションにある「Default Rule」が、この環境でデフォルトになる FW ルールです。

Action が「Allow」になっています。

hol-1603-mod3-p1-01.png

 

Web ブラウザで、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod3-p1-02.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM、「web-01a」 に SSH でアクセスできます。

hol-1603-mod3-p1-03.png

 

Security Group の作成。

 

ラボのシナリオでは、FW ルールでの送信元と送信元として、Security Group を指定しています。

そのため、FW ルール作成の準備として Security Group を作成しておきます。

 

「web-01a」、「web-02a」 という VM を含む、「Web-tier」という名前の Security Group を作成します。

今回は、Security Group の作成と、VM の追加を同時に実施します。

Security Group の設定を記載する XML では VM ID の指定が必要なので、

ここでは PowerCLI で確認しておきます。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

PowerCLI> Get-VM web-0[12]a | sort Name | ft -AutoSize Name,Id

 

Security Group のメンバーにする VM のID がわかりました。

  • web-01a → vm-350
  • web-02a → vm-304

hol-1603-mod3-p1-04.png

 

XML ファイル(sg-web-tier.txt)を下記のように作成しておきます。

cat <<EOF > sg-web-tier.txt

<securitygroup>

  <objectId />

  <objectTypeName>SecurityGroup</objectTypeName>

  <name>Web-tier</name>

  <description></description>

  <scope>

    <id>globalroot-0</id>

    <objectTypeName>GlobalRoot</objectTypeName>

  </scope>

  <member>

    <name>web-01a</name>

    <objectId>vm-350</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

  <member>

    <name>web-02a</name>

    <objectId>vm-304</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

</securitygroup>

EOF

 

下記のコマンドラインで、Security Group を作成します。

cat sg-web-tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/securitygroup/bulk/globalroot-0

 

実行すると、作成された Security Group の ID がわかります。

「Web-tier」は、securitygroup-10 として作成されました。

hol-1603-mod3-p1-05.png

 

Web Client からも確認できます。

Security Group は、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager(192.168.110.15)→

「Manage」 →「Grouping Objects」 →「Security Group」 で確認できます。

hol-1603-mod3-p1-06.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)

前回、HOL-SDC-1603 の Module 1 をもとに、論理スイッチの作成して VM を接続してみました。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

 

今回は同じラボの Module 2 のシナリオをもとに、NSX Edge を API で設定変更してみようと思います。

 

設定変更対象の NSX Edge

 

設定変更対象の NSX Edge は、下記の 2つです。

 

Perimeter-Gateway

  • ルータや、FW などのネットワークサービスをを実現する VM。NSX Edge Service Gateway。※以下 ESG
  • Web Client では、Type: NSX Edge
  • 今回の環境での edge-id は「edge-2」

 

Distributed-Router

  • 分散ルーティングをコントロールする。分散論理ルータ。※以下 DLR
  • Web Client では、Type: Logical Router
  • 今回の環境での edge-id は「edge-4」

hol-1603-mod2-01.png

 

手順の流れ。

 

  1. ESG からインターフェース削除。
  2. DLR に論理インターフェース(LIF)を構成。※App 層、DB 層の間の分散ルーティングを可能にします。
  3. DLR で OSPF を構成。
  4. ESG で OSPF の設定を修正。※DLR と動的ルーティングが構成される。


※今回も、VCSA(vcsa-01a)から NSX Manager(192.168.110.15)に curl コマンドを実行しています。

※NSX Edge の追加と ECMP の構成は、今回は省略しています。

 

1. ESG からインターフェース削除。

 

まず、ESG から Internal_App と Internal_DB というインターフェースを削除します。

この時点では、どちらも ESG に構成されています。

 

Web Client から見た、ESG のインターフェースの状態です。

まだ Internal_App と Internal_DB が構成されています。

hol-1603-mod2-02.png

 

この時点では、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod2-03.png

 

API では、下記のコマンドラインでインターフェースの状態が確認できます。

ここで、論理スイッチの ID も表示されるので控えておきます。

  • App_Tier_01 → virtualwire-3
  • DB_Tier_01 → virtualwire-4

 

Internal_App インターフェースの確認

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/vnics/3 | xmllint --format -

 

Internal_DB インターフェースの確認

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/vnics/4 | xmllint --format -


ESG からインターフェースを削除します。

ちなみに、API からの設定変更は、Web Client とはことなり「Publish Changes」 ボタンををクリックするようなことなく、

即時反映されるようです。

 

Internal_App インターフェースの削除

curl -k -s -u admin:VMware1! -X DELETE https://192.168.110.15/api/4.0/edges/edge-2/vnics/3

 

Internal_DB  インターフェースの削除

curl -k -s -u admin:VMware1! -X DELETE https://192.168.110.15/api/4.0/edges/edge-2/vnics/4

 

API をコマンドラインで実行している様子です。

HoL なので「テキストの送信」(テキストをコンソールに送信)を使用しています。

hol-1603-mod2-04.png

 

ESG からインターフェースが削除されました。

hol-1603-mod2-05.png

 

そして、「3-Tier Web App」のテストページはエラーになります。

hol-1603-mod2-06.png

 

2. DLR に論理インターフェース(LIF)を構成。

 

この時点での、DLR のインターフェースの状態です。

まだ App 層、DB 層のネットワークに接続するインターフェースは作成されていません。

hol-1603-mod2-07.png

 

API では、下記のコマンドラインで確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-4/interfaces | xmllint --format -

 

DLR インターフェースを作成する API で指定する XML ファイル「dlr-if.txt」を作成します。

今回は、App_Interface、DB_Interface を同時に指定しています。

XML で指定している「virtualwire-3」と「virtualwire-4」は、それそれ App 層、DB 層のネットワークとして作成されている

論理スイッチの ID を指定しています。※先ほど ESG で確認したものを指定します。

cat <<EOF > dlr-if.txt

<interfaces>

  <interface>

    <name>App_Interface</name>

    <addressGroups>

      <addressGroup>

        <primaryAddress>172.16.20.1</primaryAddress>

        <subnetMask>255.255.255.0</subnetMask>

      </addressGroup>

    </addressGroups>

    <mtu>1500</mtu>

    <type>internal</type>

    <isConnected>true</isConnected>

    <connectedToId>virtualwire-3</connectedToId>

  </interface>

  <interface>

    <name>DB_Interface</name>

    <addressGroups>

      <addressGroup>

        <primaryAddress>172.16.30.1</primaryAddress>

        <subnetMask>255.255.255.0</subnetMask>

      </addressGroup>

    </addressGroups>

    <mtu>1500</mtu>

    <type>internal</type>

    <isConnected>true</isConnected>

    <connectedToId>virtualwire-4</connectedToId>

  </interface>

</interfaces>

EOF

 

DLR にインターフェースを追加します。

cat dlr-if.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-4/interfaces/?action=patch

 

インターフェースが追加されました。

hol-1603-mod2-08.png

 

ここまでで、App 層、DB 層での分散ルーティングが構成されます。

App 層の VM 「app-01a」 から DB 層の VM 「db-01a」 に Ping が飛ぶようになります。

※「DUP!」と出ることがあるのは HoL 特有の環境によるものです。

hol-1603-mod2-09.png

 

3. DLR で OSPF を構成。

 

ESG と DLR の間で動的ルーティングを構成するため、DLR に OSPF を有効化します。

 

まず、DLR に Router ID を設定します。

Router ID は、まだ未設定の状態です。

hol-1603-mod2-10.png

 

API での設定確認は、下記のコマンドラインで可能です。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-4/routing/config | xmllint --format -

 

API で指定する XML ファイル「rt-id.txt」 を作成しておきます。

cat <<EOF > rt-id.txt

<routingGlobalConfig>

  <routerId>192.168.5.2</routerId>

</routingGlobalConfig>

EOF

 

DLR に Router ID を設定します。

cat rt-id.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-4/routing/config/global

 

Router ID が 設定されました。

hol-1603-mod2-11.png


この時点の、DLR の OSPF 設定状態です。

hol-1603-mod2-12.png


DLR に OSPF の設定を投入する XML ファイル「dlr-ospf.txt」を作成しておきます。

ちなみに、この環境での DLR の Edge_Uplink インターフェースは vnic 2 で、

そこに OSPF エリア ID 10 を設定しています。

cat <<EOF > dlr-ospf.txt

<ospf>

  <enabled>true</enabled>

  <protocolAddress>192.168.5.3</protocolAddress>

  <forwardingAddress>192.168.5.2</forwardingAddress>

  <ospfAreas>

    <ospfArea>

      <areaId>51</areaId>

      <type>nssa</type>

      <authentication>

        <type>none</type>

      </authentication>

    </ospfArea>

    <ospfArea>

      <areaId>10</areaId>

      <type>normal</type>

      <authentication>

        <type>none</type>

      </authentication>

    </ospfArea>

  </ospfAreas>

  <ospfInterfaces>

    <ospfInterface>

      <vnic>2</vnic>

      <areaId>10</areaId>

      <cost>1</cost>

      <mtuIgnore>false</mtuIgnore>

    </ospfInterface>

  </ospfInterfaces>

  <redistribution>

    <enabled>true</enabled>

    <rules>

      <rule>

        <id>0</id>

        <from>

          <isis>false</isis>

          <ospf>false</ospf>

          <bgp>false</bgp>

          <static>false</static>

          <connected>true</connected>

        </from>

        <action>permit</action>

      </rule>

    </rules>

  </redistribution>

  <gracefulRestart>true</gracefulRestart>

</ospf>

EOF

 

DLR に OSPF を設定します。

cat dlr-ospf.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-4/routing/config/ospf

 

API 実行後の、DLR の OSPF 設定状態です。

hol-1603-mod2-13.png

 

4. ESG で OSPF の設定を修正。

 

この環境の ESG では、もともと OSPF が有効化されています。

この時点では、ESG が NSX 環境外部と接続する Uplink にだけ OSPF のエリア ID がマッピングされています。

ESG の DLR と通信するインターフェースに OSPF エリア ID を設定します。

hol-1603-mod2-14.png

 

HoL の環境で ESG むけの XML ファイル全体を作成するのは大変なので、

今回は ESG の現在の OSPF 設定を保存した XML ファイルに、(強引に)追加分の設定を追記します。

追加分の OSPF 設定の内容は下記で、OSPF の エリア ID 10 を、Transit_Network のインターフェースにマッピングしています。

<ospfInterface>

  <vnic>1</vnic>

  <areaId>10</areaId>

  <cost>1</cost>

  <mtuIgnore>false</mtuIgnore>

</ospfInterface>

 

コマンドラインで、ESG の OSPF 設定情報の XML を「esg-ospf_pre.txt」ファイルに保存して・・・

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/routing/config/ospf | xmllint --format - > esg-ospf_pre.txt

 

sed で、</ospfInterfaces> の前に今回設定したい XML 要素を追加して、「esg-ospf.txt」ファイルとして保存しています。

sed -e "s|</ospfInterfaces>|<ospfInterface><vnic>1</vnic><areaId>10</areaId><cost>1</cost><mtuIgnore>false</mtuIgnore></ospfInterface></ospfInterfaces>|" esg-ospf_pre.txt > esg-ospf.txt

 

そして、API で ESG に設定します。

cat esg-ospf.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/routing/config/ospf

 

ESG に、設定が反映されました。

hol-1603-mod2-15.png

 

これにより、ESG と DLR との間で OSPF による動的ルーティングが構成されました。

ESG に接続されている Web 層のネットワークと App 層のネットワークとが接続できるようになり、

手順の途中でエラーになっていたテストページも正常に表示できるようになります。

hol-1603-mod2-16.png

 

このように GUI(Web Client)から実施できる設定は、API からも可能です。

設定内容のわりに XML が大げさになることもある気がしますが、

API を利用して手順を自動化することで作業ミスの抑止などもできそうです。

 

以上、NSX API で NSX Edge の設定変更をしてみる話でした。

最近、HOL-SDC-1603 VMware NSX Introduction で NSX API を試す方法を紹介をしてみましたが・・・

NSX-v の API を HoL で実行してみる。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

 

よく見たら、下記のラボにも NSX API の紹介がありました。

 

HOL-SDC-1625 VMware NSX Advanced

MODULE 7 - NSX AUTOMATION

 

英語マニュアルのみのラボですが、

Firefox の RESTClient アドオンが用意されていて、GUI から NSX API 実行を試すことができます。

これは下記 URL のアドオンで、わりとよく使われている REST Client ではないかと思います。

RESTClient, a debugger for RESTful web services. :: Add-ons for Firefox

 

このラボで Firefox を起動すると、すでに RESTClient アドオンが利用可能になっています。

hol-nsx-1625-restclient-01.png

 

リクエスト送信前に、Authentication と Content-Type のヘッダを設定しておきます。

Authentication」→「Basic Authentication」をクリックして・・・

hol-nsx-1625-restclient-02.png

 

NSX Manager のログインユーザ名とパスワードを入力します。

※ラボでは admin ユーザを使用します。

hol-nsx-1625-restclient-03.png

 

「Headers」→「Custom Header」をクリックして・・・

hol-nsx-1625-restclient-04.png

 

Content-Type を設定します。

  • Name: Content-Type
  • Value: application/xml

hol-nsx-1625-restclient-05.png

 

あとはラボマニュアルや API Guide をもとに、ラボの「テキストの送信」を利用して API を実行します。

例えば API Guide にある、NSX Contrller の情報取得 API を実行する場合・・・

Query Controllers

 

Request:

GET https://NSX-Manager-IP-Address/api/2.0/vdn/controller

 

下記のような感じで指定して、「SEND」 ボタンを押すと Response に結果が表示されます。

  • Method は「GET」 。
  • URL では、NSX Manager のアドレスとして「nsxmgr-01a.corp.local」を指定。
  • Headers に Application と Content-Type が追加されている。
  • Body は、Request Body の指定が不要なので空欄のまま。

hol-nsx-1625-restclient-06.png

 

取得できた情報は、「Response Body (Preview)」タブに表示される情報が見やすいと思います。

XML 要素を折りたたむことができるので、下記では id が controller-1 の NSX Controller の情報だけ展開しています。

hol-nsx-1625-restclient-07.png


実際の運用やツールから API を利用することになると、この REST Client を使用することはないと思います。

しかし、導入が簡単で利用方法も簡単なので、API 自体の調査や、デバッグなどで便利です。

 

ちなみに、このラボ(HOL-SDC-1625)では、下記のような API 使用例が紹介されています。

  • NSX Controller の設定確認と Syslog 転送先設定
  • 論理スイッチの作成
    ※あわせて、指定が必要になる Transport Zone(Scope ID)の確認方法なども紹介されています。

 

実際のところ NSX Manager や Controller にはあまり設定要素がないので、

個人的には、論理スイッチの管理や vNIC の接続、ファイアウォール ルールのメンテナンスなどの方が

NSX API の使いどころなのではないかと思っています。

 

以上、NSX API を HoL で試す話の補足でした。

以前に、HoL で、NSX API を試す方法を紹介しました。

NSX-v の API を HoL で実行してみる。

 

今回は、HOL-SDC-1603 VMware NSX Introduction の Module 1 と同様の設定を

Web Client のかわりに curl コマンドで NSX API を実行して設定してみようと思います。

コマンドラインで指定している 192.168.110.15 は、NSX Manager の IP アドレスです。

 

手順の流れ

  1. 論理スイッチ「Prod_Logical_Switch」を作成する。
  2. 作成した論理スイッチと NSX Edge を接続する。
  3. VM「web-03a」と「web-04a」の vNIC を、作成した論理スイッチに接続する。
  4. 確認してみる。

 

1. 論理スイッチ作成。

 

まず、論理スイッチ「Prod_Logical_Switch」を作成します。

下記のような XML ファイルを作成しました。

 

ls-prod.txt

<virtualWireCreateSpec>

  <name>Prod_Logical_Switch</name>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

 

「テキストの送信」で、下記のようなコマンドを送信、実行して、ファイルを作成します。

cat <<EOF > ls-prod.txt

<virtualWireCreateSpec>

  <name>Prod_Logical_Switch</name>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

EOF

 

XML で指定している ID は、Web Client の NSX Edges 画面であたりがつきますが、

下記のような NSX Edge の情報を取得する API からでもわかります。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges | xmllint --format - | grep -e objectId -e name

hol-nsx-mod1-0.png

 

ファイルを読み込んで、論理スイッチを作成する API を実行します。

下記のようなコマンドラインを実行します。virtualwire は、論理スイッチのことです。

cat ls-prod.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

このような感じで実行します。例では virtualwire-5 という ID で、論理スイッチが作成されました。

hol-nsx-mod1-1.png

 

2. 論理スイッチと NSX Edge を接続。

 

作成した論理スイッチと、NSX Edge Service Gateway(ESG) を接続します。

この ESG は、Perimeter-Gateway の役割として配置されているものです。

 

XML は、下記のように Lab マニュアルでの設定値を指定しました。
portgroupId には、論理スイッチ作成時に表示された virtualwire-5 を指定します。

 

edge-if-prod.txt

<vnic>

  <name>Prod_Interface</name>

  <addressGroups>

    <addressGroup>

      <primaryAddress>172.16.40.1</primaryAddress>

      <subnetMask>255.255.255.0</subnetMask>

      <subnetPrefixLength>24</subnetPrefixLength>

    </addressGroup>

  </addressGroups>

  <mtu>1500</mtu>

  <type>internal</type>

  <isConnected>true</isConnected>

  <index>5</index>

  <portgroupId>virtualwire-5</portgroupId>

  <enableProxyArp>false</enableProxyArp>

  <enableSendRedirects>false</enableSendRedirects >

</vnic>


ファイルは、下記のように作成します。

cat <<EOF > edge-if-prod.txt

<vnic>

  <name>Prod_Interface</name>

  <addressGroups>

    <addressGroup>

      <primaryAddress>172.16.40.1</primaryAddress>

      <subnetMask>255.255.255.0</subnetMask>

      <subnetPrefixLength>24</subnetPrefixLength>

    </addressGroup>

  </addressGroups>

  <mtu>1500</mtu>

  <type>internal</type>

  <isConnected>true</isConnected>

  <index>5</index>

  <portgroupId>virtualwire-5</portgroupId>

  <enableProxyArp>false</enableProxyArp>

  <enableSendRedirects>false</enableSendRedirects >

</vnic>

EOF

 

上記のファイルを指定して、ESG のインターフェースを 5 を設定して論理スイッチを接続します。

edge-id として「edge-2」、インターフェースの Index として 5 を指定しています。

cat edge-if-prod.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/vnics/5

 

3. 論理スイッチに vNIC を接続。

 

作成した論理スイッチに、VM の vNIC を接続します。

このとき使用する XML では、VM と vNIC の ID が必要になります。


VM ID と vNIC ID の確認。

 

論理スイッチに VM の vNIC を接続するときには、VM と vNIC の ID を指定する必要があります。

NSX の API ガイドでは vCenter の Web UI 経由(/mob)で確認する方法が紹介されていますが、

HoL だと操作が大変なので、web-03a と web-04a に関係する ID を、PowerCLI で確認してしまいます。

 

まず PowerCLI を起動して、vCenter に接続します。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

 

VM の ID は、下記のコマンドラインでわかります。

UUID(ここでは PersistentId)の値も指定するケースがあるようなので、ついでに見ておきます。

PowerCLI> Get-VM web-0[34]a | ft -AutoSize Id,PersistentId

 

vNIC の ID は、下記のコマンドラインでわかります。

4000 から ID が付与されていますが、API で指定するときは

4000 → 000、4001 → 001 といったように読み替えるようです。

PowerCLI> Get-VM web-0[34]a | Get-NetworkAdapter | ft -AutoSize Parent,Id,Name

 

VM の ID がそれぞれ vm-305 と vm-306 だとわかります。

hol-nsx-mod1-2.png

vNIC の ID は、4000~ の数字です。

hol-nsx-mod1-3.png

 

論理スイッチに vNIC を接続する。

 

今回の XML の内容は、下記のようにしました。

 

vnic-attach_web-03a.txt

  • web-03a を Prod_Logical_Switch に接続する。
    • 502e58e2-c139-f2d9-5560-9df1ffa26b45 が web-03a を表します。
    • vnicUuid は、先頭が VM ID で、 「.000」が vNIC の順番によって変わります。
    • vitualwire-5 が、Prod_Logical_Switch を表します。

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>502e58e2-c139-f2d9-5560-9df1ffa26b45</objectId>

  <vnicUuid>502e58e2-c139-f2d9-5560-9df1ffa26b45.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

 

vnic-attach_web-04a.txt

  • web-04a を Prod_Logical_Switch に接続する。
  • 502ea036-ec16-45e1-2a61-a702e7f73d5a.000 と vm-306 は、どちらも web-04a を表します。
  • ためしに objectId を、vm-N 形式の VM ID を指定しても設定できました。
    ただし API Guide は UUID 指定なので、その方がよいかもしれません。
  • ちなみに、vnicUuid は vm-N 形式だとダメでした。

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>vm-306</objectId>

  <vnicUuid>502ea036-ec16-45e1-2a61-a702e7f73d5a.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

 

それぞれ、下記のようにファイル作成します。

 

web-03a 用

cat <<EOF > vnic-attach_web-03a.txt

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>502e58e2-c139-f2d9-5560-9df1ffa26b45 </objectId>

  <vnicUuid>502e58e2-c139-f2d9-5560-9df1ffa26b45.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

EOF


web-04a 用

cat <<EOF > vnic-attach_web-04a.txt

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>vm-306</objectId>

  <vnicUuid>502ea036-ec16-45e1-2a61-a702e7f73d5a.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

EOF

 

web-03a の vNIC を接続します。

cat vnic-attach_web-03a.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/virtualwires/vm/vnic

 

web-04a の vNIC を接続します。

cat vnic-attach_web-04a.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/virtualwires/vm/vnic

hol-nsx-mod1-6.png

 

4. 設定の確認。

 

Web Client でも、作成した論理スイッチ「Prod_Logical_Switch」が表示されます。

hol-nsx-mod1-4.png

 

ESG(Perimeter-Gateway) の vNIC 5 に、「Prod_Interface」 が設定されています。

hol-nsx-mod1-5.png


論理スイッチ「Prod_Logical_Switch」 に、VM が接続されています。

接続した VM 同士である web-03a から web-04a に Ping も飛びます。

hol-nsx-mod1-7.png

 

Lab の冒頭ということもあり簡単な設定内容の例でしたが、NSX API は多くの機能に対応しています。

REST API は今回の curl コマンドに限らず様々な言語、ツールから実行することができるので、

うまく利用すれば、ネットワーク構成変更を柔軟に自動化したりできそうです。

 

API ガイドはこちらです。

 

NSX vSphere API Guide

NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

以上、NSX API 体験でした。

NSX では、ネットワークにかかわる様々な機能を実現できます。

たとえば、VXLAN によるオーバーレイネットワーク構成、分散ルーティング、分散ファイアウォール・・・など。

それぞれを連携させて利用することができますが、

逆に、それぞれの機能を必要なものだけ利用することも可能です。

 

たとえば導入検討などで、実際は直接的に関係しない機能同士の影響が気になるケースもあると思います。

そういった場合にも、VMware Hands-on Labs(HoL)を利用して確認をすることができます。

 

今回は、HoL「HOL-SDC-1603 VMware NSX Introduction」で、(通常はそうする必要はありませんが)

あえて VXLAN を無効にして分散ファイアウォールをためしてみます。

 

VMware Hands-on Labs

http://labs.hol.vmware.com/HOL/catalogs/

 

準備として、あえて VXLAN を無効化。

 

HoL では、「Compute Cluster A」と「Compute ClusterB」というクラスタに検証用 VM が配置されています。

hol-nsx-1.png

 

この環境の VM は、初期状態では VXLAN の論理スイッチとなる「vxw-~」という分散ポートグループに接続されています。

これらの VM を、「vds_site_a_VM Network」という VXLAN とは関係のない普通の分散ポートグループに接続しました。

hol-nsx-2.png

 

そして、「Compute Cluster A」と「Compute ClusterB」を

Transport Zone からはずして、VXLAN も構成解除してしまいます。

hol-nsx-3.png

 

「Compute Cluster A」と「Compute ClusterB」は、すべての ESXi ホストで

VXLAN が未構成(Not Configured)で、Firewall が有効(Enabled)の状態にしました。

hol-nsx-4.png

 

vNIC を対象に、分散ファイアウォールのルールを投入してみる。

 

今回は動作確認のため、web-02a という VM の vNIC で、Ping(ICMP)を拒否するルールを設定してみました。

hol-nsx-5.png

 

Distributed Firewall のルールを追加して、設定反映(Publish Changes)します。

hol-nsx-6.png

 

web-01a から、ルールの対象である web-02a に ping を実行していたところ、

設定反映のタイミング(赤線のところ)から拒否されるようになりました。

hol-nsx-7.png

 

このような感じで、実際に検証機材を用意できない場合でも検証方法を工夫すれば、

ある程度 HoL の Lab マニュアルにないことでも簡易 PoC 的なことができそうだと思います。

 

以上、HoL の NSX 環境で工夫してみる話でした。

NSX では、API ガイドが公開されています。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

ためしに API を NSX Manager に実行してみたいのですが、

残念ながら NSX は評価版が一般公開されていません。

しかし、VMware Hands-on Labs(HoL)では NSX 環境を使用することができるので、そこで試してみようと思います。

 

VMware Hands-on Labs

http://labs.hol.vmware.com/HOL/catalogs/

 

HoL の Lab のうち、今回は「HOL-SDC-1603 VMware NSX Introduction」を使用します。

 

HOL-SDC-1603 VMware NSX Introduction の環境

 

HoL の NSX Manager のアドレスは、Web Client の

「Networking & Security」→「Installation」→「Management」タブ

を開くと確認できます。「192.168.110.15」が NSX Manager です。

nsx-api-00.png

 

この環境には、Web ブラウザの REST Cliet などがみあたらなかったので

vCenter(VCSA)の curl コマンドから API を実行してみます。

VCSA「vcsa-01a.corp.local」には、PuTTY から SSH でログインできます。

nsx-api-01.png

 

curl コマンドでの API 実行

 

API を実行する場合は、直接入力だとつらいので HoL の「テキストの送信」機能を使用します。

これで手元に、実行したコマンドラインや XML ファイルを残すことができます。

ためしに API から、論理スイッチを表示 / 作成してみます。

 

論理スイッチの表示

 

API ガイドを参考にして、下記のコマンドラインを実行してみました。

  • 論理スイッチは、「virtualwires」と指定します。※以前はこう呼ばれていました。
  • XML 表示を整形するために、パイプで xmllint をつけています。
  • 出力内容が多いので、パイプで more をつけています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | more

 

下記のような感じで、論理スイッチの情報が XML で表示されます。

nsx-api-02.png

 

表示量が多いので、とりあえず「| grep name」で絞ってみました。

nsx-api-03.png

 

Web Client からみた 論理スイッチ(Logical Switches)と同じ情報です。

nsx-api-04.png

 

論理スイッチの作成

 

「LS-test-01」という論理スイッチを作成してみます。

論理スイッチの作成は、表示とは異なり、XML ファイルを読み込ませます。

 

ls-test.txt ファイルの内容

<virtualWireCreateSpec>

  <name>LS-test-01</name>

  <description>Test LS</description>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

 

このファイルは、下記のように作成します。

cat <<EOF > ls-test.txt

<virtualWireCreateSpec>

  <name>LS-test-01</name>

  <description>Test LS</description>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

EOF

 

そして、下記のようにコマンドラインを実行します。

cat ls-test.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

実行する様子は、このようになります。

nsx-api-05.png

 

これで、論理スイッチが作成されました。

Web Client でも、論理スイッチの作成が確認できます。

nsx-api-06.png

 

このような感じで、HoL でも NSX API を実行できます。

 

以上、HoL で NSX API を試してみる話でした。

vSphere 6.0 U2 、ESXi 6.0 U2 がリリースされました。


VMware vCenter Server 6.0 Update 2 リリース ノート

http://pubs.vmware.com/Release_Notes/jp/vsphere/60/vsphere-vcenter-server-60u2-release-notes.html


VMware ESXi 6.0 Update 2 リリース ノート

http://pubs.vmware.com/Release_Notes/jp/vsphere/60/vsphere-esxi-60u2-release-notes.html

 

ESXi 6.0 U2 では、vSphere Client のかわりに

今まではFling として試験的に提供されていた Host Client がデフォルトで使用できるようになりました。

 

Host Client は、vSphere Client のかわりとなる HTMLベースの ESXi ホスト管理ツールです。

マニュアルもすでに公開されています。


VMware Host Client

VMware Host Client のドキュメント | VMware 日本


ESXi 6.0 U2 をインストールして https://ESXiのアドレス/ui/ でアクセス可能です。


ESXi に /ui なしでアクセスしたページにも「Open the VMware Host Client」 というリンクが用意されています。

※いきなり ~/ui のアドレスでアクセスすることも可能です。

esxi60u2-12.png


初回ログインでは、CEP(品質改善プログラムへの参加)の有無を聞かれます。

この画面の後ろの方を見るとわかるように、UI は標準で日本語対応しています。

esxi60u2-15.png

 

こんな画面です。

esxi60u2-16.png


ちなみに、ESXi 6.0 U2 には

Host Client の UI を提供する VIB がデフォルトでインストールされています。

[root@hv60n01:~] vmware -vl

VMware ESXi 6.0.0 build-3620759

VMware ESXi 6.0.0 Update 2

[root@hv60n01:~] esxcli software vib get -n esx-ui

VMware_bootbank_esx-ui_1.0.0-3617585

   Name: esx-ui

   Version: 1.0.0-3617585

   Type: bootbank

   Vendor: VMware

   Acceptance Level: VMwareCertified

   Summary: VMware Host Client

   Description: An embedded web UI for ESXi

   ReferenceURLs:

   Creation Date: 2016-03-03

   Depends: esx-version >= 5.0.0

   Conflicts:

   Replaces:

   Provides:

   Maintenance Mode Required: False

   Hardware Platforms Required:

   Live Install Allowed: True

   Live Remove Allowed: True

   Stateless Ready: True

   Overlay: False

   Tags:

   Payloads: esx-ui


Host Client は次のメジャーバージョンアップぐらいから提供になるのかと思ったら、予想より早くて驚きました。


以上、ESXi 6.0.U2 の Host Client の話でした。