Skip navigation
1 2 3 Previous Next

にほんごVMware

330 posts

vCenter Server Appliance(VCSA)は、GUI からだけでなく CLI でもデプロイすることができます。

 

以前に下記のような投稿をしましたが・・・

VCSA 6.5 U1 を CLI デプロイしてみる。(vCenter + embedded-PSC)

VCSA 6.0 を CLI Install してみる。(External PSC + vCenter)

 

今回は VCSA 6.7 を CLI デプロイしてみます。

  • VCSA は vCenter Server 6.7.0a (Build 8546234)を利用しています。
  • Enhanced Linked Mode(ELM)で 2台を vCenter をデプロイします。

 

ISO イメージ ファイルのマウント。

デプロイを実行する OS で、VCSA の ISO イメージファイルをマウントします。

今回は Windows 10 の PowerShell から実行しています。

ISO イメージファイルは下記を使用しました。

  • VMware-VCSA-all-6.7.0-8546234.iso

 

Dドライブとしてマウントした場合は、下記フォルダに vcsa-deploy.exe があります。

PS> D:

PS> cd  vcsa-cli-installer/win32/

 

JSON ファイルの作成。(1台目)

デプロイ パラメータを指定した JSON ファイルを作成します。

JSON ファイルのサンプルのファイルが、ISO ファイルの vcsa-cli-installer/templates/install フォルダに

「embedded_vCSA_~.json」という名前で用意されています。

今回は ESXi にデプロイする「_on_ESXi.json」を利用しました。

PS> ls D:\vcsa-cli-installer\templates\install | select Name

 

 

Name

----

PSC_first_instance_on_ESXi.json

PSC_first_instance_on_VC.json

PSC_replication_on_ESXi.json

PSC_replication_on_VC.json

embedded_vCSA_on_ESXi.json

embedded_vCSA_on_VC.json

embedded_vCSA_replication_on_ESXi.json

embedded_vCSA_replication_on_VC.json

vCSA_on_ESXi.json

vCSA_on_VC.json

 

1台目の vCenter は、下記のように JSON を作成しました。

以前の VCSA のパラメータは deployment.option といった ドット区切りでしたが、

deployment_option のような「_」区切りになっています。

 

JSON 内で指定するホスト名(FQDN)は、あらかじめ DNS サーバに登録して

名前解決できるようにしておきます。

指定しているホスト名や IP アドレスなどのパラメータは、うちのラボのものです。

パスワードをファイル内で指定しない場合は、install 実行の途中で対話的な入力になります。

 

C:\work\lab-vc-01.json

lab-vc-01.json · GitHub

{

    "__version": "2.13.0",

    "__comments": "deploy a VCSA with an embedded-PSC on an ESXi host.",

    "new_vcsa": {

        "esxi": {

            "hostname": "infra-esxi-06.go-lab.jp",

            "username": "root",

            "password": "VMware1!",

            "deployment_network": "dvpg-vc-deploy-0000",

            "datastore": "vsanDatastore"

        },

        "appliance": {

            "thin_disk_mode": true,

            "deployment_option": "tiny",

            "name": "lab-vc-01"

        },

        "network": {

            "ip_family": "ipv4",

            "mode": "static",

            "ip": "192.168.10.11",

            "dns_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "prefix": "24",

            "gateway": "192.168.10.1",

            "system_name": "lab-vc-01.go-lab.jp"

        },

        "os": {

            "password": "VMware1!",

            "ntp_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "ssh_enable": true

        },

        "sso": {

            "password": "VMware1!",

            "domain_name": "vsphere.local"

        }

    },

    "ceip": {

        "settings": {

            "ceip_enabled": false

        }

    }

}

 

JSON ファイルの作成。(2台目)

2台目の vCenter は、下記のように JSON を作成しました。

ELM の2台目なので、1台目とは、VM 名やネットワーク設定以外に赤字の部分で違いがあります。

 

C:\work\lab-vc-02.json

lab-vc-02.json · GitHub

{

    "__version": "2.13.0",

    "__comments": "deploy a VCSA with an embedded-PSC as a replication partner to another embedded-VCSA, on an ESXi host.",

    "new_vcsa": {

        "esxi": {

            "hostname": "infra-esxi-06.go-lab.jp",

            "username": "root",

            "password": "VMware1!",

            "deployment_network": "dvpg-vc-deploy-0000",

            "datastore": "vsanDatastore"

},

        "appliance": {

            "thin_disk_mode": true,

            "deployment_option": "tiny",

            "name": "lab-vc-02"

        },

        "network": {

            "ip_family": "ipv4",

            "mode": "static",

            "ip": "192.168.10.12",

            "dns_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "prefix": "24",

            "gateway": "192.168.10.1",

            "system_name": "lab-vc-02.go-lab.jp"

        },

        "os": {

            "password": "VMware1!",

            "ntp_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "ssh_enable": true

        },

        "sso": {

        "password": "VMware1!",

            "domain_name": "vsphere.local",

            "first_instance": false,

            "replication_partner_hostname": "lab-vc-01.go-lab.jp",

            "sso_port": 443

        }

    },

    "ceip": {

        "settings": {

            "ceip_enabled": false

        }

    }

}

 

VCSA のデプロイ。(1台目)

作成した JSON ファイルを指定して、vcsa-deploy.exe を実行します。

ちなみに・・・

  • vCenter 登録ずみで DRS が有効な ESXi にデプロイする場合は、
    処理中に DRS で VCSA が移動されてしまうと失敗するので
    ESXi ではなく vCenter にむけてデプロイするか、アフィニティ ルールで工夫する必要があります。
  • vDS / 分散ポートグループを指定してデプロイする場合は、
    分散ポートグループのポートバインドを「短期」にしておきます。

 

確認をしておきます。

以前のバージョンとはオプションが異なり「--verify-only 」ではなく「--precheck-only」で確認をします。

「--accept-eula」も必要になりました。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula --precheck-only C:\work\lab-vc-01.json

 

デプロイします。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula C:\work\lab-vc-01.json

 

VCSA のデプロイ。(2台目)

確認をしておきます。

この時点で 1台目の VCSA がないとエラーになります。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula --precheck-only C:\work\lab-vc-02.json

 

デプロイします。

このとき、1台目の VCSA のスナップショットを取得しておくと

失敗した時の再試行が簡単になります。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula C:\work\lab-vc-02.json

 

これで、ELM の vCenter が利用できるようになります。

すでに 1台目の VCSA の vSphere Client / vSphere Web Client にログインしている場合は、

ログインしなおすと VCSA が2つ見えるようになります。

vcsa67-elm.png

 

VCSA 6.7 では embedded-PSC(PSC と vCenter を 1つの VM に含む)での

ELM が推奨となったので、その検証環境の作成などに便利かなと思います。

 

以上、VCSA 6.7 の CLI インストールでした。

PowerCLI で、VM を構成するファイルの情報を取得することができます。

そして、VM の定義情報が記載されている .vmx ファイルのパスも取得できます。

ここでは、.vmx ファイルのパスを取得して

ついでにそのパスをもとに ESXi に VM の再登録をしてみます。

 

今回は「vm01」という名前の VM を対象とします。

vm01 という VM 名は PowerCLI で接続している vCenter のインベントリで重複しないようにしてあります。

コマンドラインで都度 VM 名を変更しなくてよいように、$vm_name という変数で扱います。

PowerCLI> $vm_name = "vm01"

 

あらかじめ Connect-VIServer で vCenter に接続してあります。

PowerCLI から 複数の vCenter への接続は下記のような感じになります。(古い投稿ですが)

PowerCLI から複数の vCenter に接続する方法。

 

VM は hv-d01.go-lab.jp という ESXi ホストでパワーオン状態です。

PowerCLI> Get-VM $vm_name | select Name,ResourcePool,Folder,VMHost,PowerState | fl

 

Name         : vm01

ResourcePool : Resources

Folder       : vm

VMHost       : hv-d01.go-lab.jp

PowerState   : PoweredOn

 

 

PowerCLI から見た VM のファイル。

VM のファイルは、下記のように情報を確認できます。

.vmx ファイルは Type が「config」になっています。

ちなみに、.vmx や .vmdk といった VM を構成するファイルだけでなく

VM のログファイル(vmware.log)の情報も含まれていることがわかります。

PowerCLI> (Get-VM $vm_name).ExtensionData.LayoutEx.File | select Key,Type,Size,Name | ft -AutoSize

 

 

Key Type                 Size Name

--- ----                 ---- ----

  0 config               2998 [ds-nfs-repo-01] vm01/vm01.vmx

  1 nvram                8684 [ds-nfs-repo-01] vm01/vm01.nvram

  2 snapshotList            0 [ds-nfs-repo-01] vm01/vm01.vmsd

  3 diskDescriptor        549 [ds-nfs-repo-01] vm01/vm01_2.vmdk

  4 diskExtent     1609957376 [ds-nfs-repo-01] vm01/vm01_2-flat.vmdk

  5 log                231426 [ds-nfs-repo-01] vm01/vmware-1.log

  6 log                233220 [ds-nfs-repo-01] vm01/vmware.log

  7 swap                    0 [ds-nfs-repo-01] vm01/vm01-a5ede08e.vswp

  8 uwswap                  0 [ds-nfs-repo-01] vm01/vmx-vm01-2783830158-1.vswp

 

 

コマンドラインを工夫すれば、複数の VM の .vmx のパスを一覧することもできます。

ホストの障害対応や、vSphere の移行作業などで VM の格納先を記録しておく際に利用できます。

PowerCLI> Get-VM test*,vm* | select Name,@{N="vmx_path";E={($_.ExtensionData.LayoutEx.File | where {$_.Type -eq "config"}).Name}} | Sort-Object Name

 

 

Name        vmx_path

----        --------

test-web-01 [vsanDatastore] 532a455b-a477-02ce-4958-f44d3065d53c/test-web-01.vmx

test-web-02 [vsanDatastore] 8f2a455b-6c94-6930-3200-f44d3065d53c/test-web-02.vmx

vm01        [ds-nfs-repo-01] vm01/vm01.vmx

 

 

vm01 の .vmx ファイルのパスだけ取得して、これ以降は変数 $vmx_path で扱います。

PowerCLI> $vmx_path = (Get-VM $vm_name).ExtensionData.LayoutEx.File | where {$_.Type -eq "config"} | %{$_.Name}

PowerCLI> $vmx_path

[ds-nfs-repo-01] vm01/vm01.vmx

 

vCenter / ESXi への VM 再登録。

VM の再登録で、vCenter をまたいだ VM の移動をしてみます。

  • 移動先の ESXi への VM 登録の際に、New-VM コマンドで .vmx ファイルのパスを指定します。
  • 移動元 / 先の ESXi には、ds-nfs-repo-01 という名前で同一の NFS データストアをマウントしています。

 

ds-nfs-repo-01 データストアをマウントしている ESXi は、下記のように確認できます。

  • ここでの「Name」は ESXi の名前です。
  • 元 / 先 NFS データストアの構成確認は今回は省略して、データストア名のみをもとにしています。
  • vm01 のいる hv-d01.go-lab.jp だけが独立した vCenter「vc-sv01.go-lab.jp」の ESXi 6.5 配下にいて、
    それ以外の ESXi 6.7 は vCenter「infra-vc-01.go-lab.jp」の配下にいます。

PowerCLI> Get-Datastore ds-nfs-repo-01 | Get-VMHost | Sort-Object Name | select @{N="vCenter";E={$_.Uid -replace ".*@|:.

*",""}},Name,ConnectionState,Version

 

 

vCenter               Name                    ConnectionState Version

-------               ----                    --------------- -------

vc-sv01.go-lab.jp     hv-d01.go-lab.jp              Connected 6.5.0

infra-vc-01.go-lab.jp infra-esxi-01.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-02.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-03.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-04.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-05.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-06.go-lab.jp       Connected 6.7.0

 

 

それでは vm01 を停止して、移動元 vCenter のインベントリから削除します。

VM のファイル自体を削除しないように、Remove-VM には「-DeletePermanently」を付与しないで実行ます。

PowerCLI> Get-VM $vm_name | Stop-VM -Confirm:$false

PowerCLI> Get-VM $vm_name | Remove-VM -Confirm:$false

 

移動先 vCenter のインベントリの ESXi のうちの 1台に(infra-esxi-06.go-lab.jp)に VM を登録します。

ついでに登録先の リソースプールと、「-Location」でVM のフォルダを指定しています

PowerCLI> New-VM -Name $vm_name -VMFilePath $vmx_path -VMHost "infra-esxi-06.go-lab.jp" -Location "lab-vms-01" -ResourcePool "rp-02-lab"

 

そして VM を起動します。

※VM 起動時に「コピー」と「移動」どちらかの質問メッセージがでた場合は「移動」を選択します。

PowerCLI> Get-VM $vm_name | Start-VM

 

これで VM の移動ができました。

PowerCLI> Get-VM $vm_name | select Name,ResourcePool,Folder,VMHost,PowerState | fl

 

Name         : vm01

ResourcePool : rp-02-lab

Folder       : lab-vms-01

VMHost       : infra-esxi-06.go-lab.jp

PowerState   : PoweredOn

 

 

vSphere 6.x では Cross-vCenter での vMotion も可能ですが、

実行するための前提条件で引っかかったりする場合には

このような VM の移動もできたりします。

 

以上、PowerCLI で .vmx ファイルの情報を取得して利用する話でした。

今回は、ラボ環境などで定期的に不要 VM を一括削除するための工夫についてです。

あらかじめ 削除禁止 VM のリスト ファイルを用意しておき、

そこに記載されていない VM を PowerCLI で一括削除してみます。

 

今回の PowerCLI 10.1 を利用しています。

あらかじめ vCenter に接続しておきます。

PowerCLI> Connect-VIServer <vCenter アドレス>

 

まず、削除したくない VM のリストファイルを作成しておきます。

PowerCLI> cat .\VM-List_HomeLab-Infra.txt

infra-backup-01

infra-dns-01

infra-dns-02

infra-jbox-02

infra-ldap-02s

infra-nsxctl-01-NSX-controller-1

infra-nsxdlr-01-0

infra-nsxesg-01-0

infra-nsxmgr-01

infra-pxe-01

infra-repo-01

infra-sddc-01

infra-vrli-01

infra-vrni-01

infra-vrni-proxy-01

infra-vrops-01

ol75-min-01

 

このリストファイルは、下記のように vCenter 実機の情報から

ベースとなる作成しておくと間違いが少ないかなと思います。

PowerCLI> Get-VM | Sort-Object Name | %{$_.Name} | Out-File -Encoding utf8 -FilePath .\VM-List_HomeLab-Infra.txt

 

今回は、下記のようなスクリプトを作成しました。

cleanup_list_vm.ps1 · GitHub

# Cleanup VMs

# Usage:

#   PowerCLI> ./cleanup_list_vm.ps1 <VM_List.txt>

 

$vm_list_file = $args[0]

if($vm_list_file.Length -lt 1){"リストを指定して下さい。"; exit}

if((Test-Path $vm_list_file) -ne $true){"リストが見つかりません。"; exit}

$vm_name_list = gc $vm_list_file |

    where {$_ -notmatch "^$|^#"} | Sort-Object | select -Unique

 

function step_mark {

    param (

        [String]$step_no,

        [String]$step_message

    )

    ""

    "=" * 60

    "Step $step_no $step_message"

    ""

}

 

$vms = Get-VM | sort Name

$delete_vms = @()

$vms | % {

    $vm = $_

    if($vm_name_list -notcontains $vm.Name){

        $delete_vms += $vm

    }

}

 

step_mark 1 "削除VM一覧"

$delete_vms | ft -AutoSize Name,PowerState,Folder,ResourcePool

 

$check = Read-Host "上記のVMを削除しますか? yes/No"

if($check -ne "yes"){"削除せず終了します。"; exit}

 

step_mark 2 "VM削除"

$delete_vms | % {

    $vm = $_

    if($vm.PowerState -eq "PoweredOn"){

        "Stop VM:" + $vm.Name

        $vm = $vm | Stop-VM -Confirm:$false

    }

    "Delete VM:" + $vm.Name

    $vm | Remove-VM -DeletePermanently -Confirm:$false

}

 

下記のように削除禁止 VM のリスト ファイルを指定して、

スクリプトを実行します。

PowerCLI> .\cleanup_list_vm.ps1 .\VM-List_HomeLab-Infra.txt

 

============================================================

Step 1 削除VM一覧

 

 

Name               PowerState Folder     ResourcePool

----               ---------- ------     ------------

infra-ldap-02s_old PoweredOff 01-Infra   rp-01-infra

test-ldap-01m      PoweredOff test-ldap  rp-02-lab

test-ldap-01s      PoweredOff test-ldap  rp-02-lab

test-vm-01          PoweredOn lab-vms-01 rp-02-lab

test-vm-02          PoweredOn lab-vms-01 rp-02-lab

test-vm-31          PoweredOn 02-Lab     rp-02-lab

 

 

上記のVMを削除しますか? yes/No: yes

 

============================================================

Step 2 VM削除

 

Delete VM:infra-ldap-02s_old

Delete VM:test-ldap-01m

Delete VM:test-ldap-01s

Stop VM:test-vm-01

Delete VM:test-vm-01

Stop VM:test-vm-02

Delete VM:test-vm-02

Stop VM:test-vm-31

Delete VM:test-vm-31

 

 

PowerCLI>

 

これで、定期的なラボのクリーンアップなどが簡単になるはずです。

ただし、VM 削除は失敗すると大変なことになるので、

スクリプトは入念に例外制御や実行テストが必要かなと思います。

 

以上、PowerCLI での VM 削除の工夫についての話でした。

vSAN データストアにネステッド ESXi (ゲスト OS として ESXi をインストール)を配置するときに、

仮想ディスクのフォーマット エラー対策などで物理サーバ側の ESXi で

/VSAN/FakeSCSIReservations を有効にします。

 

参考: How to run Nested ESXi on top of a VSAN datastore?

https://www.virtuallyghetto.com/2013/11/how-to-run-nested-esxi-on-top-of-vsan.html

 

今回は、PowerCLI で /VSAN/FakeSCSIReservations を有効にしてみます。

 

vSAN クラスタに参加している ESXi のみに設定するため、

対象クラスタを取得してから、パイプで設定コマンドに渡します。

 

今回の対象クラスタは infra-cluster-01 です。

PowerCLI> Get-Cluster infra-cluster-01 | select Name,VsanEnabled

 

Name             VsanEnabled

----             -----------

infra-cluster-01        True

 

 

対象の ESXi です。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,ConnectionState,PowerState,Version,Build | ft -AutoSize

 

Name                    ConnectionState PowerState Version Build

----                    --------------- ---------- ------- -----

infra-esxi-01.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-02.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-03.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-04.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-05.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-06.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

 

 

現状の設定を確認しておきます。

VSAN.FakeSCSIReservations は、まだ無効の「0」です。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,{$_|Get-AdvancedSetting VSAN.FakeSCSIReservations}

 

Name                    $_|Get-AdvancedSetting VSAN.FakeSCSIReservations

----                    ------------------------------------------------

infra-esxi-01.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-02.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-03.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-04.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-05.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-06.go-lab.jp VSAN.FakeSCSIReservations:0

 

 

設定変更します。

VSAN.FakeSCSIReservations を、有効の「1」にします。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | Get-AdvancedSetting VSAN.FakeSCSIReservations | Set-AdvancedSetting -Value 1 -Confirm:$false

 

設定変更されました。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,{$_|Get-AdvancedSetting VSAN.FakeSCSIReservations}

 

Name                    $_|Get-AdvancedSetting VSAN.FakeSCSIReservations

----                    ------------------------------------------------

infra-esxi-01.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-02.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-03.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-04.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-05.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-06.go-lab.jp VSAN.FakeSCSIReservations:1

 

 

下記のように列名の表示などを調整することもできます。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,@{N="VSAN.FakeSCSIReservations";E={($_|Get-AdvancedSetting VSAN.FakeSCSIReservations).Value}}

 

Name                    VSAN.FakeSCSIReservations

----                    -------------------------

infra-esxi-01.go-lab.jp                         1

infra-esxi-02.go-lab.jp                         1

infra-esxi-03.go-lab.jp                         1

infra-esxi-04.go-lab.jp                         1

infra-esxi-05.go-lab.jp                         1

infra-esxi-06.go-lab.jp                         1

 

 

設定が統一されているか、グルーピングして確認することもできます。

VSAN.FakeSCSIReservations が「1」の ESXi ホストをグルーピングして、

6台すべての設定が統一されていることがわかります。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | Get-AdvancedSetting VSAN.FakeSCSIReservations | Group-Object Name,Value | select Count,Name,{$_.Group.Entity}

 

Count Name                         $_.Group.Entity

----- ----                         ---------------

    6 VSAN.FakeSCSIReservations, 1 {infra-esxi-01.go-lab.jp, infra-esxi-02.go-lab.jp, infra-esxi-03.go-lab.jp, infra...

 

 

下記のようにシンプルに表示することもできます。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Get-AdvancedSetting VSAN.FakeSCSIReservations | Group-Object Name,Value | select Count,Name

 

Count Name

----- ----

    6 VSAN.FakeSCSIReservations, 1

 

 

以上、vSAN データストアのネステッド ESXi ラボでの PowerCLI 利用例でした。

VM の仮想 CD/DVD ドライブからメディアを切断するときに、

Linux ゲストでマウントしたままだと、質問メッセージがでて VM が停止してしまいます。

しかも、ゲスト OS でアンマウントしている場合でも、

なぜか同様に VM が停止してしまうことがあります。

そこで PowerCLI を利用して、VM を起動したままの状態で メディアを取り出してみます。

 

メディア切断時の VM の状態。

仮想 CD/DVD ドライブからメディアを取り出そうとすると、下記のような状態になります。

eject-vm-stop-01.png

 

この状態では、下記のように質問に応答するまで VM が停止してしまいます。

eject-vm-stop-02.png

 

この状態を回避するには、下記の KB のように対象 VM にパラメータを追加します。

 

マウントされた CDROM が切断された後、Linux 仮想マシンが応答しない (2144053)

https://kb.vmware.com/kb/2144053?lang=ja

 

PowerCLI でのパラメータ追加~メディア切断。

下記のような PowerCLI スクリプトを作成してみました。

  • KB にあるパラメータを VM に追加。
  • VM の 仮想 CD/DVD ドライブからメディア切断。
  • パラメータを VM から削除。

 

eject_cd_no-msg.ps1 · GitHub

$vm_name = $args[0]

 

Get-VM $vm_name | % {

    $vm = $_

   

    # Add AdvancedSetting

    $vm | New-AdvancedSetting -Name cdrom.showIsoLockWarning -Value "FALSE" -Confirm:$false |

        ft -AutoSize Entity,Name,Value

    $vm | New-AdvancedSetting -Name msg.autoanswer -Value "TRUE" -Confirm:$false |

        ft -AutoSize Entity,Name,Value

   

    # Eject

    $cd_drive = $vm | Get-CDDrive |

        Set-CDDrive -NoMedia -Connected:$false -Confirm:$false

        $cd_drive | Select-Object `

        @{N="VM";E={$_.Parent.Name}},

        @{N="StartConnected";E={$_.ConnectionState.StartConnected}},

        @{N="Connected";E={$_.ConnectionState.Connected}},

        IsoPath

 

    # Remove AdvancedSetting

    $vm | Get-AdvancedSetting -Name cdrom.showIsoLockWarning | Remove-AdvancedSetting -Confirm:$false

    $vm | Get-AdvancedSetting -Name msg.autoanswer | Remove-AdvancedSetting -Confirm:$false

}

 

Connect-VIServerで vCenter に接続したうえで、

下記のようなコマンドラインで実行します。

PowerCLI> .\eject_cd_no-msg.ps1 <VM の名前>

 

下記のような感じで、仮想 CD/DVD ドライブからメディアを取り出すことができます。

メディアを取り出すことで、最後の IsoPath が空欄になっています。

PowerCLI> .\eject_cd_no-msg.ps1 lab-ldap02

 

Entity     Name                     Value

------     ----                     -----

lab-ldap02 cdrom.showIsoLockWarning FALSE

 

Entity     Name           Value

------     ----           -----

lab-ldap02 msg.autoanswer TRUE

 

VM         StartConnected Connected IsoPath

--         -------------- --------- -------

lab-ldap02          False     False

 

PowerCLI>

 

ちなみに今回の環境は vCenter 6.5 U1 / ESXi 6.5 U1 / PowerCLI 10.1 です。

 

以上、PowerCLI で 仮想 CD/DVD ドライブからメディア切断してみる話でした。

PowerNSX で、NSX の Syslog 転送先のサーバを設定してみます。

 

PowerNSX では、Syslog サーバ設定そのもののコマンドは用意されていないので、

Invoke-NsxWebRequest で NSX API から設定します。

今回の環境は、vCenter 6.7a / NSX-v 6.4.1 / PowerCLI 10.1 / PowerNSX 3.0 です。

 

NSX Manager の Syslog Server 設定。

API リファレンスは下記です。

Working With the Appliance Manager

VMware NSX for vSphere API documentation

 

XML ファイルを用意します。

今回は Syslog サーバとして 192.168.1.223 を指定しています。

 

syslog-nsx-manager.xml

<syslogserver>

  <syslogServer>192.168.1.223</syslogServer>

  <port>514</port>

  <protocol>UDP</protocol>

</syslogserver>

XML ファイルを読み込んで、Invoke-NsxWebRequest  を使用して NSX API で設定します。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-manager.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/1.0/appliance-management/system/syslogserver" -body $xml_text

 

Syslog サーバのアドレスが設定されたことを確認します。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/1.0/appliance-management/system/syslogserver"

PowerNSX> [xml]$data.Content | select -ExpandProperty syslogserver

 

syslogServer  port protocol

------------  ---- --------

192.168.1.223 514  UDP

 

 

NSX Controller の Syslog Server 設定。

NSX Controller は、Object ID を指定して仮想アプライアンスそれぞれで設定をします。

 

API リファレンスは下記です。

Working With NSX Controllers

VMware NSX for vSphere API documentation

 

まず NSX Controller の Object ID を確認しておきます。

NSX では 3台の NSX Controller を配置しますが、私のラボではリソースの都合で 1台だけです。

PowerNSX> Get-NsxController | select name,id

 

name            id

----            --

infra-nsxctl-01 controller-1

 

 

XML ファイルを用意しておきます。

 

syslog-nsx-controller.xml

<controllerSyslogServer>

  <syslogServer>192.168.1.223</syslogServer>

  <port>514</port>

  <protocol>UDP</protocol>

  <level>INFO</level>

</controllerSyslogServer>

 

Manager と同様、Invoke-NsxWebRequest  で設定します。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-controller.xml

PowerNSX> Invoke-NsxWebRequest -method POST -URI "/api/2.0/vdn/controller/controller-1/syslog" -body $xml_text

 

転送先の Syslog サーバが設定されました。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/2.0/vdn/controller/controller-1/syslog"

PowerNSX> [xml]$data.Content | select -ExpandProperty controllerSyslogServer

 

syslogServer  port protocol level

------------  ---- -------- -----

192.168.1.223 514  UDP      INFO

 

 

NSX Edge の Syslog Server 設定。

NSX Edge の ESG / DLR Control VM の Syslog 転送先を設定してみます。

これらの Syslog 転送をするには、仮想アプライアンスから Syslog サーバに

通信できる(ルーティングがされている)必要があります。

 

API リファレンスは下記です。

Working With NSX Edge

VMware NSX for vSphere API documentation

 

下記のような XML ファイルを用意しておきます。

 

syslog-nsx-edge.xml

<syslog>

  <protocol>udp</protocol>

  <serverAddresses>

    <ipAddress>192.168.1.223</ipAddress>

  </serverAddresses>

</syslog>

 

NSX Edge Service Gateway(ESG)の Object ID を確認しておきます。

PowerNSX> Get-NsxEdge -Name infra-nsxesg-01 | select name,id

 

name            id

----            --

infra-nsxesg-01 edge-1

 

 

Invoke-NsxWebRequest  で設定します。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-edge.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/4.0/edges/edge-1/syslog/config" -body $xml_text

 

設定が反映されたことを確認します。

取得した XML は、Format-XML でも確認できます。

Syslog サービスも、自動的に有効(enabled = true)になります。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/4.0/edges/edge-1/syslog/config"

PowerNSX> $data.Content | Format-XML

<?xml version="1.0" encoding="UTF-8"?>

<syslog>

  <version>12</version>

  <enabled>true</enabled>

  <protocol>udp</protocol>

  <serverAddresses>

    <ipAddress>192.168.1.223</ipAddress>

  </serverAddresses>

</syslog>

 

DLR Control VM の Object ID も確認します。

PowerNSX> Get-NsxLogicalRouter | select name,id

 

name            id

----            --

infra-nsxdlr-01 edge-5

 

 

DLR Control VM も NSX Edge アプライアンスによるものなので、

ESG と同様の XML、API で Syslog 転送先サーバを設定できます。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-edge.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/4.0/edges/edge-5/syslog/config" -body $xml_text

 

転送先の Syslog サーバが設定できたことが確認できます。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/4.0/edges/edge-5/syslog/config"

PowerNSX> $data.Content | Format-XML

<?xml version="1.0" encoding="UTF-8"?>

<syslog>

  <version>2</version>

  <enabled>true</enabled>

  <protocol>udp</protocol>

  <serverAddresses>

    <ipAddress>192.168.1.223</ipAddress>

  </serverAddresses>

</syslog>

 

これでネットワーク環境に問題がなければ、

それぞれの NSX コンポーネントから Syslog サーバにログが転送されるはずです。

ちなみに今回は vRealize Log Insight(vRLI)にログ転送しています。

 

転送先サーバで、ホスト名などをもとにログが受信できていることを確認することになりますが、

vRLI では「管理」→「ホスト」画面のあたりから、受信しているホストを確認できたりします。

nsx-to-vrli-01.png

 

インタラクティブ分析でホスト名などをもとに受信確認するときは、

hostname を「ユニークカウント」時系列でグループ化すると、

各時間帯ごとにホスト単位の受信有無を確認しやすいかなと思います。

nsx-to-vrli-02.png

 

以上、PowerNSX で NSX の Syslog サーバを設定してみる話でした。

前回の投稿で、NSX の Edge Service Gateway(ESG)で DHCP サーバ、

分散論理ルータ(DLR)で DHCP リレー エージェントを構成しました。

NSX ESG / DLR で DHCP Server / Relay を構成してみる。

 

今回は PowerNSX で同様の環境を構成してみます。

ただし前回とは異なり、実際に使用する場面を想定して

一度のみ設定すればよいものは省略して下記のようにしています。

  • ESG での DHCP サービスの有効化 → 設定ずみ
  • 論理スイッチの作成と DLR への接続
  • ESG への IP プール作成
  • DLR での DHCP リレー サーバの登録 → 設定ずみ
  • DLR での DHCP リレー エージェントの指定
  • VM の作成 ~ 論理スイッチへの接続

 

nsx-edge-dhcp-powernsx.png

 

使用する環境は、前回の投稿と同様です。

あらかじめ、vCenter / NSX Manager には接続ずみです。

PowerNSX での NSX への接続方法について。

 

論理スイッチの作成と DLR への接続。

まず、DHCP を利用するネットワークの論理スイッチ「ls-lab-vms-01」を作成します。

PowerNSX> Get-NsxTransportZone infra-tz-01 | New-NsxLogicalSwitch ls-lab-vms-01

 

論理スイッチを DLR に接続します。

このときに、ゲートウェイのアドレス(10.0.1.1)も指定します。

PowerNSX> Get-NsxLogicalRouter -Name infra-nsxdlr-01 | New-NsxLogicalRouterInterface -Name if-ls-lab-vms-01 -ConnectedTo (Get-NsxLogicalSwitch ls-lab-vms-01) -PrimaryAddress 10.0.1.1 -SubnetPrefixLength 24 -Type internal

 

論理スイッチを接続した DLR インターフェースの index を確認しておきます。

PowerNSX> Get-NsxLogicalRouter -Name infra-nsxdlr-01 | Get-NsxLogicalRouterInterface -Name if-ls-lab-vms-01 | Format-List name,connectedToName,index

 

name            : if-ls-lab-vms-01

connectedToName : ls-lab-vms-01

index           : 10

 

 

ESG への IP プール作成。

PowerNSX では、ESG のネットワーク サービス関連のものがあまり充実していないので、

IP プールの作成は、Invoke-NsxWebRequest で NSX API を利用します。

似たもので Invoke-NsxRestMethod もありますが、これは非推奨になっています。

 

まず、IP プールの内容を定義した XML を作成しておきます。

 

esg_dhcp_pool_10.0.1.1.xml

<ipPool>

  <ipRange>10.0.1.100-10.0.1.199</ipRange>

  <subnetMask>255.255.255.0</subnetMask>

  <defaultGateway>10.0.1.1</defaultGateway>

  <domainName>go-lab.jp</domainName>

  <primaryNameServer>192.168.1.101</primaryNameServer>

  <secondaryNameServer>192.168.1.102</secondaryNameServer>

  <leaseTime>86400</leaseTime>

  <autoConfigureDNS>false</autoConfigureDNS>

  <allowHugeRange>false</allowHugeRange>

</ipPool>

 

ESG の Object ID を確認しておきます。

PowerNSX> Get-NsxEdge -Name infra-nsxesg-01 | Format-List name,id

 

name : infra-nsxesg-01

id   : edge-1

 

 

XML ファイルを読み込んで、IP プールを作成します。

API のメソッドについては、下記のリファレンスを参考にします。

VMware NSX for vSphere API documentation

 

ESG の edgeId については、先ほど確認したものを指定します。

XML でキャストするとエラーになってしまうので [String] としています。

PowerNSX> [String]$xml_text = Get-Content ./esg_dhcp_pool_10.0.1.1.xml

PowerNSX> Invoke-NsxWebRequest -method POST -URI "/api/4.0/edges/edge-1/dhcp/config/ippools" -body $xml_text

 

DLR での DHCP リレー エージェントの指定。

DHCP リレー エージェントについても Invoke-NsxWebRequest で設定します。

まず、XML を作成します。

 

DLR の edgeId を確認しておきます。

PowerNSX> Get-NsxLogicalRouter -Name infra-nsxdlr-01 | Format-List name,id

 

name : infra-nsxdlr-01

id   : edge-5

 

 

DLR の DHCP リレー設定を取得しておきます。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/4.0/edges/edge-5/dhcp/config/relay"

PowerNSX> $data.Content | Format-XML

<?xml version="1.0" encoding="UTF-8"?>

<relay>

  <relayServer>

    <ipAddress>10.0.0.1</ipAddress>

  </relayServer>

</relay>

PowerNSX>

 

XML ファイルを用意します。

vnicIndex には DLR インターフェースの index、

giAddress には DLR インターフェースに設定したゲートウェイ アドレスを指定します。

今後ネットワークを増設してリレー エージェントが追加される場合は relayAgent 要素が増えます。

 

dlr_dhcp_relay.xml

<?xml version="1.0" encoding="UTF-8"?>

<relay>

  <relayServer>

    <ipAddress>10.0.0.1</ipAddress>

  </relayServer>

  <relayAgents>

    <relayAgent>

      <vnicIndex>10</vnicIndex>

      <giAddress>10.0.1.1</giAddress>

    </relayAgent>

  </relayAgents>

</relay>

 

DLR に、リレー エージェントを含む DHCP リレー設定を反映します。

PowerNSX> [String]$xml_text = Get-Content ./dlr_dhcp_relay.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/4.0/edges/edge-5/dhcp/config/relay" -body $xml_text

 

VM の作成 ~ 論理スイッチへの接続。

既存の VM から VM を作成します。

PowerNSX> Get-Template vm-template-01 | New-VM -ResourcePool infra-cluster-01 -Datastore vsanDatastore -Name test-vm-01

 

VM を論理スイッチに接続します。

PowerNSX> Get-VM test-vm-01 | Connect-NsxLogicalSwitch -LogicalSwitch (Get-NsxLogicalSwitch ls-lab-vms-01)

 

VM を起動します。

PowerNSX> Get-VM test-vm-01 | Start-VM

 

少し待つと、DHCP プールのレンジから IP アドレスが設定されます。

PowerNSX> Get-VM test-vm-01 | Get-VMGuest

 

State          IPAddress            OSFullName

-----          ---------            ----------

Running        {10.0.1.100, fe80... Oracle Linux 7 (64-bit)

 

 

以上、NSX Edge の DHCP Relay を PowerNSX で設定してみる話でした。

NSX では、NSX Edge の提供するネットワークサービスとして、

DHCP サービスを利用できます。

DHCP サービスの管理

DHCP リレーの設定

 

そこで、Edge Service Gateway(ESG)を DHCP サーバ、

分散論理ルータ(DLR)を DHCP リレー エージェントにして、

論理スイッチ配下の VM が DHCP を利用できるようにしてみます。

 

今回の環境について。

下記の環境を使用します。

  • vCenter 6.7a
  • NSX-v 6.4.1
  • ESG / DLR はデプロイ済み。
  • 論理スイッチ配下の VM が DHCP サーバ(ESG)まで到達できるように、
    ESG / DLR はルーティングを設定済み

 

下記のような構成です。

nsx-edge-dhcp.png

ESG(NSX Edge)と DLR はデプロイ済みです。

esg-dhcp-01.png

 

ESG では、10.0.0.1 の内部インターフェースから DHCP サービスを提供します。

DLR の DHCP リレー サーバのアドレスは、この IP アドレスを指定します。

esg-dhcp-22.png

 

DLR 配下の、論理スイッチ「ls-lab-vms-01」のネットワークで DHCP サービスを利用します。

この論理スイッチは、DLR のインターフェース「if-lab-vms-01」に接続されています。

esg-dhcp-21.png

 

ESG での DHCP サーバ設定。

ESG の「管理」→「DHCP」→「プール」を開いて、

「+」をクリックして IP プールを追加します。

esg-dhcp-02.png

 

環境にあわせて、DHCP で自動設定するパラメータを入力します。

今回は 10.0.1.0/24 のネットワーク向けに、開始 / 終了 IP アドレスと

デフォルトゲートウェイを入力しています。

デフォルトゲートウェイは、論理スイッチを DLR に接続したときに指定した IP アドレスを指定します。

esg-dhcp-03.png

 

「開始」ボタンをクリックしてから、「変更の発行」をします。

esg-dhcp-04.png

 

DLR での DHCP リレーエージェント設定。

DLR では「管理」→「DHCP リレー」を開いて設定します。

「DHCP リレーのグローバル設定」は「変更」ボタンから DHCP リレー サーバの登録、

「DHCP リレー エージェント」は「+」ボタンからインターフェースの登録をします。

esg-dhcp-11.png

 

DHCP リレー サーバとして、ESG の内部インターフェース(Internal)の IP アドレスを入力します。

ESG 側のインターフェースは「アップリンク」ではなく「内部」にしておきます。

esg-dhcp-12.png

 

DHCP リレー エージェントのインターフェースは、

DHCP を利用をする VM を接続した、論理スイッチ接続のインターフェースと、

その IP アドレスを指定します。

esg-dhcp-13.png

 

「変更の発行」をクリックして、設定を反映させます。

esg-dhcp-14.png

 

VM の論理スイッチへの接続。

論理スイッチに、VM を接続します。

edge-dhcp-vm-01.png

 

VM を指定します。

edge-dhcp-vm-02.png

 

この VM の vNIC は 1つだけです。

edge-dhcp-vm-03.png

 

論理スイッチに VM が追加されたことが確認できます。

edge-dhcp-vm-05.png

 

この VM が、DHCP で IP アドレスを取得します。

IP プールで指定したレンジの IP アドレスが設定されたことが確認できます。

※この VM では、あらかじめ DHCP を利用するように設定ずみです。

edge-dhcp-vm-06.png

 

ちなみに、PowerNSX では下記のようになります。

NSX ESG / DLR で DHCP Server / Relay を構成してみる。(PowerNSX 編)

 

以上、NSX Edge で DHCP を利用してみる話でした。

NSX の分散ファイアウォール(DFW)には、保護対象から特定の VM を除外する

「除外リスト」があります。

ファイアウォールによる保護からの仮想マシンの除外

 

今回は、vCenter 6.7a / NSX-v 6.4.1 / PowerCLI 10.1 / PowerNSX 3.0 の環境で、

あらかじめ用意した VM リストのテキストファイルをもとに、

PowerNSX で除外リストへのメンバー追加 / 削除をしてみます。

 

DFW 除外リストの様子。

除外リストを見ると、デフォルトでは一般的な VM の「ユーザーが除外した仮想マシン」には

何も登録されていませんが・・・

nsx-dfw-exlist-01.png

 

「システムが除外した仮想マシン」として、

NSX 関連の VM(NSX Controller、NSX Edge など)が自動的に除外されています。

nsx-dfw-exlist-02.png

 

NSX の DFW でデフォルトのルールを「ブロック」や「却下」にした場合、

ルールの考慮 / 設定もれなどで vCenter やインフラの管理機能をもつ VM の通信を

遮断してしまうことがあります。

そこで、そういった VM を 除外リストで DFW の作用から除外しておくという運用ができます。

nsx-dfw-exlist-03.png

 

PowerNSX での DFW 除外リスト管理。

除外対象としたい VM が多い場合には、手作業だとリストへの追加もれなどの心配があります。

そこで、あらかじめ対象 VM のリストを作成しておき、PowerNSX で追加をしてみます。

 

今回は、Connect-NsxServer で vCenter / NSX には接続ずみです。

PowerNSX での NSX への接続方法について。

 

まず下記のような VM 名を記載したテキストファイルを作成しておきます。

あらかじめファイルを用意することで、除外リストの追加対象をしっかり確認して、

それをモレなく実機に反映することが容易になるはずです。

 

vm_list.txt

PowerNSX> cat .\vm_list.txt

ctl-vm-01

ctl-vm-02

ctl-vm-03

ctl-vm-04

ctl-vm-05

ctl-vm-06

 

ファイルの内容をもとに、DFW の除外リストに VM を追加します。

PowerNSX> cat .\vm_list.txt | % {Get-VM -Name $_ | Add-NsxFirewallExclusionListMember}

 

除外リストに VM が追加されました。

PowerNSX> Get-NsxFirewallExclusionListMember

 

Name                 PowerState Num CPUs MemoryGB

----                 ---------- -------- --------

ctl-vm-01            PoweredOff 1        2.000

ctl-vm-02            PoweredOff 1        2.000

ctl-vm-03            PoweredOff 1        2.000

ctl-vm-04            PoweredOff 1        2.000

ctl-vm-05            PoweredOff 1        2.000

ctl-vm-06            PoweredOff 1        2.000

 

 

vSphere Client でも、除外リストで VM の追加が確認できます。

nsx-dfw-exlist-04.png

 

vSphere Web Client でも、除外リストで VM の追加が確認できます。

nsx-dfw-exlist-05.png

 

同様に、除外リストから VM の削除もできます。

Remove-NsxFirewallExclusionListMember で

テキストファイルに記載した VM を除外リストから削除してみます。

PowerNSX> cat .\vm_list.txt | % {Get-VM -Name $_ | Remove-NsxFirewallExclusionListMember}

PowerNSX> Get-NsxFirewallExclusionListMember

PowerNSX>

 

たとえば、vCenter や管理セグメントに配置されたインフラ管理系の VM については

除外リストの対象とすることができます。

 

また、サービスや業務で直接利用されない VM については

DFW によるマイクロセグメンテーションが必ずしも必要ではないので

除外リストに入れることで、DFW ルール処理の件数を削減すると

負荷軽減が見込めそうです。

 

他にも、ESXi を vSAN 以外の HCI(ハイパー コンバージド インフラストラクチャ)として

利用していて、コントローラ VM (従来のストレージ コントローラの役割)が

存在する場合も、それらの除外リスト追加を検討するとよいと思います。

一方、基本的に DFW は VMkernel ポートには作用しないので、

vSAN の場合は特別に除外リストを気にすることはないはずです。

 

以上、PowerNSX で DFW の除外リストを管理してみる話でした。

NSX Edge をデプロイする時に クラスタ / リソースプールを指定しますが、

デプロイ後に VM(仮想アプライアンス)の配置を変更すると、

構成情報と実機での状態がずれて表示されてしまいます。

 

たとえば、デプロイ時には下記の状態であったとします。

infra-nsxesg-01 という NSX Edge が、infra-cluster-01 クラスタにデプロイされています。

nsx-edge-rp-01.png

 

「ホストおよびクラスタ」のインベントリでは下記の配置です。

infra-nsxesg-01 の VM は、infra-cluster-01 クラスタ直下に配置されています。

nsx-edge-rp-02.png

 

ここで vSphere Web Client から、NSX Edge の VM を別のリソースプールに移動してみます。

infra-nsxesg-01 の VM は、rp-01-infra というリソースプールに移動されました。

nsx-edge-rp-03.png

 

そうすと、NSX 側ではズレが生じます。

nsx-edge-rp-04.png

 

これは vSphere Web Client や REST API で修正することができますが、

今回は自宅ラボなので、PowerNSX の Set-NsxEdge コマンドで修正してみます。

たまになぜか GUI からの設定変更ができなくなることがあり、

そういった場合でも PowerNSX や API の直接利用で対処できることがあります。

 

まず、PowerNSX で NSX Manager と vCenter に接続します。

※今回の vCenter は infra-vc-01.go-lab.jp です。

PowerNSX> Connect-NsxServer -vCenterServer infra-vc-01.go-lab.jp

 

リソースプールの ID を確認しておきます。VM を配置しているリソースプールは下記です。

PowerNSX> Get-ResourcePool -Name rp-01-infra | select Name,{$_.ExtensionData.MoRef.Value}

 

Name        $_.ExtensionData.MoRef.Value

----        ----------------------------

rp-01-infra resgroup-61

 

 

NSX Edge の構成を確認しておきます。

PowerNSX> $edge = Get-NsxEdge -Name infra-nsxesg-01

PowerNSX> $edge.appliances.appliance.configuredResourcePool

 

id         name             isValid

--         ----             -------

domain-c36 infra-cluster-01 true

 

 

NSX Edge の構成情報を変更します。

PowerNSX> $edge.appliances.appliance.configuredResourcePool.id = "resgroup-61"

PowerNSX> $edge | Set-NsxEdge -Confirm:$false

 

リソースプールの情報が修正されました。

PowerNSX> $edge = Get-NsxEdge -Name infra-nsxesg-01

PowerNSX> $edge.appliances.appliance.configuredResourcePool

 

id          name        isValid

--          ----        -------

resgroup-61 rp-01-infra true

 

 

vSphere Web Client での表示も修正されました。

nsx-edge-rp-05.png

 

以上、NSX Edge の構成情報を PowerNSX で修正してみる話でした。

今回は、PowerNSX で Edge Service Gateway(ESG)のファイアウォールの無効化 / 有効化と、

デフォルトルールのアクションの変更をしてみます。

 

今回も下記の VMware HoL 環境を利用しています。

HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

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

 

Edge ファイアウォールの無効化 / 有効化。

はじめは、Edge ファイアウォールが有効な状態です。

edge-fw-01.png

 

では、Edge ファイアウォールを無効にしてみます。

まず Get-NsxEdge  で ESG を取得します。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

 

そして、パラメータを変更して Set-NsxEdge で設定します。

$edge.features.firewall.enabled = "false"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-02.png

 

Edge ファイアウォールが無効になりました。

edge-fw-03.png

 

今度は、有効化してみます。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

$edge.features.firewall.enabled = "true"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-04.png

 

ファイアウォールが有効化されました。

edge-fw-05.png

 

デフォルトルール アクションの変更。

Edge ファイアウォールの「Default Rule」は、デフォルトではアクションが Accept になっています。

これを Deny に変更してみます。

edge-fw-06.png

 

PowerNSX でも、accept が設定されていることがわかります。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

$edge.features.firewall.defaultPolicy

edge-fw-07.png

 

それでは、Deny に変更してみます。

$edge.features.firewall.defaultPolicy.action = "deny"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-08.png

 

Default Rule のアクションが Deny に設定変更されました。

edge-fw-09.png

 

ESG の設定内容の確認。

PowerNSX では、 Format-XML  で元の XML を確認することができます。

Get-NsxEdge の結果を Format-XML に渡すことで ESG の詳細な設定を確認することができます。

そして前項で指定した「$edge.features.firewall.defaultPolicy.action」といった設定箇所も

XML の構造をたどることで見つけることができます。

edge-fw-10.png

 

実は ESG の情報取得や設定は PowerNSX では難しいことがあり

今回のように Get-NsxEdge / Set-NsxEdge で設定したり、

REST API と同様に XML を扱うことになるケースもあったりします。

 

以上、PowerNSX による Edge ファイアウォールの設定変更例でした。

ここからは、NSX の分散ファイアウォール(DFW)を PowerNSX で操作してみます。

 

今回は下記のラボを利用します。

HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

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

 

今回は、いわゆる3層構成(Web / App / DB)アプリケーションを意識した

分散ファイアウォール ルールを、PowerNSX で作成してみます。

※HOL-1803-02-NET の、モジュール1のシナリオです。

※一番下のファイアウォール ルール「Default Rule」の Action は、あらかじめ Block にしておきます。

 

はじめに PowerShell を起動して、NSX Manager と vCenter に接続しておきます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

ファイアウォール セクションとセキュリティ グループの作成。

ファイアウォール セクションを作成して、そこにファイアウォール ルールを追加します。

 

ファイアウォール セクション「3-tier App」を作成します。

New-NsxFirewallSection -Name "3-tier App"

hol1803-powernsx-07-01.png

 

VM「web-01a」と「web-02a」が含まれるセキュリティ グループを作成します。

対象の VM は下記の 2台です。

$vms = Get-VM web-0[12]a.*

$vms

hol1803-powernsx-07-02.png

 

セキュリティグループ「Web-tier」を作成します。

あとでファイアウォールルールの指定で利用するため、ここで変数に入れておきます。

$web_sg = New-NsxSecurityGroup -Name Web-tier -IncludeMember $vms

$web_sg

hol1803-powernsx-07-03.png

 

外部 → Web 層のファイアウォール ルール作成。

Web 層の VM では、HTTPS と SSH サービスの通信を許可します。

特定のサービスを含めるとエラーになってしまうので、

今回は下記のような条件で 2つのサービスに絞っています。

$service_web = @()

$service_web += Get-NsxService -Name HTTPS | where {$_.isUniversal -eq "false"}

$service_web += Get-NsxService -Name SSH | where {$_.isUniversal -eq "false"}

$service_web

hol1803-powernsx-07-04.png

 

外部から Web 層へ通信を許可するルールを作成します。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "Ext to Web" -Position Bottom -Destination $web_sg -Service $service_web -Action allow

hol1803-powernsx-07-05.png

 

Web 層 → App 層のファイアウォール ルール作成。

App 層のネットワークは「App_Tier_Logical_Switch」です。

$app_nw = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

$app_nw

hol1803-powernsx-07-06.png

 

App サービスを定義しておきます。

$service_app = New-NsxService -Name MyApp -Protocol TCP -port 8443

$service_app

hol1803-powernsx-07-07.png

 

Web 層から App 層へ通信を許可するルールを作成します。

ファイアウォール セクションはルールを追加するたびにオブジェクトの再取得が必要なので

変数格納せずに、都度 Get-NsxFirewallSection で取得しています。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "Web to App" -Position Bottom -Source $web_sg -Destination $app_nw -Service $service_app -Action allow

hol1803-powernsx-07-08.png

 

App 層 → DB 層のファイアウォール ルール作成。

DB 層のネットワークは「DB_Tier_Logical_Switch」です。

$db_nw = Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch

$db_nw

hol1803-powernsx-07-09.png

 

DB 層の VM では、このラボでは HTTP を許可します。

$service_db = Get-NsxService -Name HTTP | where {$_.isUniversal -eq "false"}

$service_db

hol1803-powernsx-07-10.png

 

App 層から DB 層へ通信を許可するルールを作成します。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "App to Database" -Position Bottom -Source $app_nw -Destination $db_nw -Service $service_db -Action allow

hol1803-powernsx-07-11.png

 

これで「3-tier App」セクションには 3つのルールが作成されました。

Get-NsxFirewallSection -Name "3-tier App" | Get-NsxFirewallRule

hol1803-powernsx-07-12.png

 

vSphere Web Client からもルール追加されたことが確認できます。

hol1803-powernsx-07-13.png

 

さらに一番下のファイアウォール ルール「Default Rule」の Action を Block にすることで、

シナリオどおりデフォルト ルールで ping がブロックされつつ、

「Customer DB App」ページが表示できることが確認できるはずです。

 

ちなみに現行バージョンの NSX は基本機能でマルチテナント対応しているわけではないので、

実環境では、各ルールの「Applied To(適用先)」で環境やアプリケーションごとに

ルールの適用先を制御することになるかなと思います。

 

つづく!

今回は、ここまでのシナリオでの PowerNSX コマンドラインを工夫して

簡易的なスクリプトを作成してみます。

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

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

 

以前のシナリオで、NSX Edge Service Gateway(ESG)から

分散論理ルータ(DLR)への論理スイッチの付け替えをしました。

NSX の HoL シナリオを PowerNSX でためす。Part.2(DLR 接続 / OSPF 設定)

 

このときの論理スイッチの付け替え作業を、スクリプトで簡略化してみます。

 

スクリプトの内容。

スクリプトの内容は、下記のようにしています。

  • ESG のインターフェース名を指定して実行すると、
    論理スイッチとアドレス設定を DLR に移行します。
  • インターフェースは論理スイッチに接続されている必要があります。
    (標準 / 分散ポートグループではなく)
  • IP アドレス、サブネットマスク、ポートグループ(論理スイッチ)の設定は、
    ESG のインターフェースから情報取得することで、入力を省略しています。
  • 設定後の DLR のインターフェースの情報を表示します。

 

このスクリプトでは、例外処理(エラー処理など)は省略しています。

また、このラボの構成に合わせることで、スクリプトの内容を簡略化しています。

例えばトランスポートゾーンや NSX Edge の名前が決め打ちだったりしているので、

汎用的なスクリプトを作成する場合はさらに工夫が必要になります。

 

また、HoL のシナリオにある OSPF のルーティング設定はスクリプトに含まないので、

テストむけの「Customer DB App」ページを表示するには

OSPF を手作業で設定する必要があります。

 

スクリプトの内容は下記のようにしました。

migrate_hol_nw.ps1 · GitHub

# Usage:

#   PowerNSX> .\migrate_hol_nw.ps1 <ESG_IF_NAME>

 

$if_name = $args[0]

 

$tz = Get-NsxTransportZone -Name "RegionA0-Global-TZ"

$src_esg =  Get-NsxEdge -Name "Perimeter-Gateway-01"

$dst_dlr = Get-NsxLogicalRouter -Name "Distributed-Router-01"

 

# Disconnect from ESG

$if = $src_esg | Get-NsxEdgeInterface -Name $if_name

$if_ip = $if.addressGroups.addressGroup.primaryAddress

$if_prefix = $if.addressGroups.addressGroup.subnetPrefixLength

$if_pg_name = $if.portgroupName

$if | Clear-NsxEdgeInterface -Confirm:$false

 

$if_pg = Get-NsxLogicalSwitch -TransportZone $tz -Name $if_pg_name

 

# Disconnect to DLR

$dlr_if = $dst_dlr | New-NsxLogicalRouterInterface -Name $if_name -Type internal -ConnectedTo $if_pg -PrimaryAddress $if_ip -SubnetPrefixLength $if_prefix

$dst_dlr | Get-NsxLogicalRouterInterface -Name $if_name | % {

    $ip = $_.addressGroups.addressGroup

    $_ | select `

        Index,

        type,

        name,

        connectedToName,

        @{N="primaryAddress";E={$ip.primaryAddress}},

        @{N="Prefix";E={$ip.subnetPrefixLength}}

}

 

これは、下記のように HoL の環境に「テキストの送信」して使用します。

スクリプトの内容は、PowerShell のヒアドキュメント(「@'」と、「'@」で囲む)を利用して保存しています。

hol1803-powernsx-06-01.png

 

スクリプトでのインターフェース移行。

それでは、スクリプトを実行してみます。

まず、HoL シナリオでは移行しなかった Web_Tier インターフェースを移行してみます。

このインターフェースを移行すると後続のモジュールのシナリオに影響がありますが、

今回はこのモジュールだけ実行する想定として、移行してしまいます。

 

まず、vSphere Web Client からスクリプト実行前の状態を確認しておきます。

ESG の index 2 インターフェースに「Web_Tier」が設定されています。

hol1803-powernsx-06-02.png

 

インターフェース名「Web_Tier」を指定して、スクリプトを実行します。

インターフェースが移行されて、移行後の DLR インターフェース設定が表示されました。

PS> .\migrate_hol_nw.ps1 Web_Tier

hol1803-powernsx-06-03.png

 

移行元である ESG の index 2 のインターフェース はクリアされました。

hol1803-powernsx-06-04.png

 

そして、DLR には期待通り Web_Tier のインターフェースが作成されました。

hol1803-powernsx-06-05.png

 

さらに、App_Tier、DB‗Tier のインターフェースも移行してみます。

PS> .\migrate_hol_nw.ps1 App_Tier

PS> .\migrate_hol_nw.ps1 DB_Tier

hol1803-powernsx-06-06.png

 

ESG の App_Tier、DB_Tier が接続されていたインターフェースがクリアされました。

hol1803-powernsx-06-07.png

 

そして DLR にインターフェースが作成されました。

hol1803-powernsx-06-08.png

 

NSX の GUI 操作は画面遷移が多く、設定変更箇所が多くなる傾向があります。

手順のステップが多いけれども繰り返し実行されるようなものは、

このようにスクリプト等を利用した自動化により、作業の効率化や作業ミスの防止が見込めます。

 

まだつづく・・・

NSX の HoL シナリオを PowerNSX でためす。Part.7(DFW ルール作成)

今回は、PowerNSX で NSX Edge Service Gateway(ESG)によるロードバランサを構成します。

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

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

 

ESG のデプロイ。

ロードバランサとして利用するため、新しい ESG をデプロイします。

 

まず PowerShell を起動して、NSX Manager と vCenter に接続しておきます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

ロードバランサで利用する場合も、デプロイされる ESG は同じ仮想アプライアンスです。

デプロイされるものは変わりませんが、

ここでは以前の投稿とは少しコマンドラインを変更してデプロイします。

NSX の HoL シナリオを PowerNSX でためす。Part.3(NSX Edge デプロイ)

 

今回も、クラスタでは DRS を有効にしてしまいます。

Get-Cluster RegionA01-MGMT01 | Set-Cluster -DrsEnabled:$true -Confirm:$false

 

ESG の仮想アプライアンスの設定を用意します。

今回はパラメータを変数で事前定義してから NSX Edge の仮想アプライアンスをデプロイします。

$esg_name = "OneArm-LoadBalancer"

$password = "VMware1!VMware1!"

$esg_spec = "compact"

$cluster = Get-Cluster RegionA01-MGMT01

$ds = Get-Datastore RegionA01-ISCSI01-COMP01

$vm_folder = Get-Folder -Type VM -Name "Discovered virtual machine"

$esg_dgw = "172.16.10.1"

 

インターフェースの設定を用意します。

ワンアーム 構成のロードバランサなので、インターフェースは最小限の1つだけ作成します。

$vnic0_name = "WebNetwork"

$vnic0_nw = Get-NsxLogicalSwitch -Name Web_Tier_Logical_Switch

$vnic0_type = "internal"

$vnic0_ip = "172.16.10.10"

$vnic0_prefix = 24

$vnic0 = New-NsxEdgeInterfaceSpec -Index 0 -Name $vnic0_name -Type $vnic0_type -ConnectedTo $vnic0_nw -PrimaryAddress $vnic0_ip -SubnetPrefixLength $vnic0_prefix

 

ESG をデプロイします。

New-NsxEdge -Name $esg_name -Username admin -Password $password -Cluster $cluster -Datastore $ds -FormFactor $esg_spec -VMFolder $vm_folder -Interface $vnic0 -EnableSSH -FwEnabled -FwDefaultPolicyAllow

hol1803-powernsx-05-01.png

 

ESG にデフォルトゲートウェイを設定します。

Get-NsxEdge -Name $esg_name | Get-NsxEdgeRouting | Set-NsxEdgeRouting -DefaultGatewayVnic 0 -DefaultGatewayAddress $esg_dgw -Confirm:$false

hol1803-powernsx-05-02.png

 

ESG にデフォルトゲートウェイが設定されたことが確認できます。

Get-NsxEdge -Name $esg_name | Get-NsxEdgeRouting | select -ExpandProperty staticRouting | select -ExpandProperty defaultRoute

hol1803-powernsx-05-03.png

 

ロードバランサの構成。

 

ESG のロードバランサを有効化します。

Get-NsxEdge -Name $esg_name | Get-NsxLoadBalancer | Set-NsxLoadBalancer -Enabled

hol1803-powernsx-05-04.png

 

アプリケーション プロファイルを作成します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerApplicationProfile -Name OneArmWeb-01 -Type HTTPS -SslPassthrough

hol1803-powernsx-05-05.png

 

デフォルトの HTTPS モニタの設定です。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerMonitor -Name default_https_monitor | fl

hol1803-powernsx-05-06.png

 

PowerNSX ではモニタの設定変更が難しいため、今回は URL の異なる新しいモニタを作成します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerMonitor -Name default_https_monitor-2 -Interval 5 -Timeout 15 -MaxRetries 3 -TypeHttps -Method GET -Url /cgi-bin/app.py

hol1803-powernsx-05-07.png

 

作成したモニタを指定して、ロードバランサ プールを作成します。

$monitor = Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerMonitor -Name default_https_monitor-2

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerPool -Name Web-Tier-Pool-01 -Monitor $monitor -Algorithm round-robin

hol1803-powernsx-05-08.png

 

プールにメンバ サーバ(web-01a、web-02a)を追加します。

 

web-01a を追加します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Add-NsxLoadBalancerPoolMember -Name web-01a -IpAddress 172.16.10.11 -Port 443 -MonitorPort 443

 

web-02a を追加します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Add-NsxLoadBalancerPoolMember -Name web-02a -IpAddress 172.16.10.12 -Port 443 -MonitorPort 443

hol1803-powernsx-05-09.png

 

メンバが追加されたことが分かります。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Get-NsxLoadBalancerPoolMember | ft -AutoSize

hol1803-powernsx-05-10.png

 

仮想サーバを作成します。

PowerNSX では、Add-NsxLoadBalancerVip で仮想サーバを作成できます。

$profile = Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerApplicationProfile -Name OneArmWeb-01

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Add-NsxLoadBalancerVip -ApplicationProfile $profile -Name Web-Tier-VIP-01 -IpAddress 172.16.10.10 -Protocol https -Port 443 -DefaultPool $pool

hol1803-powernsx-05-11.png

 

これでロードバランサが構成されて、ラボの「1-Arm LB Customer DB」ページや、

ESG でのステータス確認ができるはずです。

 

続く・・・

NSX の HoL シナリオを PowerNSX でためす。Part.6(スクリプトでの作業の簡素化)

ひきつづき、VMware NSX for vSphere の HoL シナリオを PowerNSX で進めてみます。

 

前回までの投稿はこちら。

今回の内容をためすためには、Part.2 ~ Part.3 の内容を実施しておく必要があります。

NSX の HoL シナリオを PowerNSX でためす。Part.1(論理スイッチ 作成 / ESG 接続)

NSX の HoL シナリオを PowerNSX でためす。Part.2(DLR 接続 / OSPF 設定)

NSX の HoL シナリオを PowerNSX でためす。Part.3(NSX Edge デプロイ)

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

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

 

これまでのシナリオでデプロイした NSX Edge Service Gateway(ESG)である

Perimeter-Gateway-02 を利用して、ECMP のルーティングを構成します。

 

追加した ESG のダイナミック ルーティングを設定する。

これまでのシナリオで ESG / DLR の OSPF を有効化していますが、

ESG 「Perimeter-Gateway-02」では OSPF が未設定なので、ここで設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -RouterId 192.168.100.4 -EnableOspf -Confirm:$false

hol1803-powernsx-04-01.png

 

OSPF の Area ID を指定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeOspfArea -AreaId 10 -Confirm:$false

hol1803-powernsx-04-02.png

 

OSPF のインターフェース マッピングを追加します。

$if = Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeInterface -Name Transit_Network_01

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

hol1803-powernsx-04-03.png

 

既存の ESG では BGP が有効化されていますが、

Perimeter-Gateway-02 では 未設定なので、ここで有効にします。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableBgp -LocalAS 65001 -Confirm:$false

hol1803-powernsx-04-04.png

 

BGP ネイバーを追加します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeBgpNeighbour -IpAddress 192.168.100.1 -RemoteAS 65002 -Confirm:$false

hol1803-powernsx-04-05.png

 

BGP と OSPF のルート再配布を有効化します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableOspfRouteRedistribution -EnableBgpRouteRedistribution -Confirm:$false

hol1803-powernsx-04-06.png

 

OSPF のルート再配布を設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner ospf -FromBGP -FromConnected -Action permit -Confirm:$false

 

BGP のルート再配布を設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner bgp -FromOspf -FromConnected -Action permit -Confirm:$false

hol1803-powernsx-04-07.png

 

ECMP を有効化する。

 

それでは、ESG と 分散論理ルータ(DLR)で ECMP を有効化します。

 

DLR「Distributed-Router-01」です。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Set-NsxLogicalRouterRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-08.png

 

ESG「Perimeter-Gateway-01」です。

※今回は ファイアウォールの無効化を省略しています。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-09.png

 

ESG「Perimeter-Gateway-01」です。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-10.png

 

これで、ラボの ESG 、DLR で ECMP が構成されました。

シナリオにある、ルーティング情報やパスの切り替えが確認できるはずです。

 

まだ続く・・・

NSX の HoL シナリオを PowerNSX でためす。Part.5(ESG デプロイ / LB 構成)