vSAN データストアには、osfs-mkdir コマンドでディレクトリ（namespace オブジェクト）を作成すると

一般的なファイル（ISO イメージなど）を配置できるようになります。

Unable to upload, copy or create files in a VMware vSAN-backed datastore (2119776)

https://kb.vmware.com/s/article/2119776

ふと、ISO のような一般的なファイルを配置した場合に

仮想マシン ストレージ ポリシー がどう適用されるのか気になったので確認してみました。

今回の環境は、vCenter 6.5 U1 です。

vSAN データストアには、下記のように

デフォルトのストレージポリシーとして「vsan-policy-raid5」を設定しています。

このとき、とくに仮想マシン ストレージ ポリシーを指定せずに

VM を作成すると、データストアのデフォルトの仮想マシン ストレージ ポリシーが設定されます。

VM 作成時の 仮想マシン ストレージ ポリシーの様子。

まず、VM を作成した場合のポリシーの様子です。

たとえば PowerCLI で下記のように VM を作成すると・・・

PowerCLI> New-VM -Name vsan-test-vm -Datastore vsanDatastore-01 -ResourcePool vsan-cluster-01

 

 

Name                 PowerState Num CPUs MemoryGB

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

vsan-test-vm         PoweredOff 1        0.250

 

vsanDatastore-01 のデフォルトの仮想マシン ストレージ ポリシーが設定されます。

PowerCLI> Get-VM vsan-test-vm | Get-SpbmEntityConfiguration | Format-List Entity,StoragePolicy,ComplianceStatus

 

 

Entity           : vsan-test-vm

StoragePolicy    : vsan-policy-raid5

ComplianceStatus : compliant

 

 

PowerCLI> Get-VM vsan-test-vm | Get-HardDisk | Get-SpbmEntityConfiguration | Format-List Entity,StoragePolicy,ComplianceStatus

 

 

Entity           : Hard disk 1

StoragePolicy    : vsan-policy-raid5

ComplianceStatus : compliant

 

vSphere Web Client から見ても、ポリシーが設定されています。

仮想ディスクと・・・

仮想マシン ホームのオブジェクトには、どちらもデフォルトのポリシーが設定されました。

vSAN データストアにファイル配置した時のポリシー。

ESXi に SSH でログインして、ディレクトリ（namespace object）を作成します。

ESXi 6.5 U1 です。

[root@hv-i21:~] vmware -vl

VMware ESXi 6.5.0 build-7388607

VMware ESXi 6.5.0 Update 1

osfs-mkdir でディレクトリを作成します。

[root@hv-i21:~] /usr/lib/vmware/osfs/bin/osfs-mkdir /vmfs/volumes/vsanDatastore-01/work

7259115b-7e8f-8fb0-8e97-b8aeedea7a23

今回は、cp コマンドで、ISO イメージ ファイル（photon-2.0-304b817.iso）を配置します。

ISO イメージ ファイルは、あらかじめ NFS データストアを用意して、そこに配置してあります。

[root@hv-i21:~] cp /vmfs/volumes/ds-nfs-work-01/iso/VMware/photon-2.0-304b817.iso /vmfs/volumes/vsanDatastore-01/work/

ファイルが配置されました。

[root@hv-i21:~] ls -l /vmfs/volumes/vsanDatastore-01/work

lrwxr-xr-x    1 root     root            36 Jun  1 14:43 /vmfs/volumes/vsanDatastore-01/work -> 7259115b-7e8f-8fb0-8e97-b8aeedea7a23

[root@hv-i21:~] ls -l /vmfs/volumes/vsanDatastore-01/work/

total 2317312

-rw-r--r--    1 root     root     2372728832 Jun  1 14:41 photon-2.0-304b817.iso

UUID をもとに Other の vSAN オブジェクトを確認すると、

ポリシー設定されていない状態に見えます。

ちなみに、esxcli では下記のように見えます。

Type は、namespace になっています。そして vSphere Web Client でみたとおり、

vSAN オブジェクトのコンポーネントは RAID5 にならず 1つだけです。

実行したコマンド：

esxcli vsan debug object list -u ＜UUID。今回は namespace オブジェクトの UUID＞

vSAN データストアには、できるだけ VM / VMDK にかかわるファイルだけ配置して、

ISO イメージのようなものは NFS データストアなどを用意して配置する方が

よいかもしれません。

以上、vSAN データストアにファイルを配置してみる話でした。

VMware NSX for vSphere は REST API で操作することができます。

しかし運用手順の自動化をするときには、API を直接利用するよりも、

PowerShell などを介して利用する方が便利なことがあります。

そこで、PowerShell ベースのツールである PowerNSX で HoL のシナリオを進めてみます。

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

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

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

PowerNSX での NSX Manager / vCenter への接続。

このラボには PowerNSX の PowerShell モジュールがインストールされています。

そのため PowerShell を起動すれば、そのまま PowerNSX が利用可能です。

PowerShell を起動して NSX Manager / vCenter へ接続し、NSX のバージョンを確認しておきます。

※コマンドラインは「テキストの送信」でコピー＆ペーストできます。

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

NSX 6.3.1 であることがわかります。

論理スイッチを作成する。

それでは、ラボのモジュール 2 のシナリオに沿って論理スイッチを作成します。

PowerNSX でのオブジェクト作成ではトランスポート ゾーンを指定することが多いので

あらかじめ Get-NsxTransportZone で取得しておきます。

$tz = Get-NsxTransportZone

$tz

論理スイッチを作成します。

New-NsxLogicalSwitch -TransportZone $tz -Name Prod_Logical_Switch

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

vSphere Web Client でも、論理スイッチが作成されたことが確認できます。

ラボマニュアルでの指定どおりの設定になっています。

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

作成した論理スイッチを、NSX Edge Service Gateway（ESG）のインターフェースに接続します。

対象の ESG は下記です。

Get-NsxEdge -Name Perimeter-Gateway-01

ESG のインターフェースの構成は、下記のように確認できます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface | select index,name,isConnected,portgroupName

VM を接続する論理スイッチ（先ほど作成したもの）を取得します。

$ls = Get-NsxLogicalSwitch -TransportZone $tz -Name Prod_Logical_Switch

$ls

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

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Index 7 | Set-NsxEdgeInterface -Name Prod_Interface -type internal -Connected:$true -PrimaryAddress 172.16.40.1 -SubnetPrefixLength 24 -ConnectedTo $ls

vSphere Web Client でもインターフェースの設定変更が確認できます。

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

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

本来であれば、論理スイッチには vNIC を指定して接続しますが、

今回の VM は、それぞれ vNIC を １つだけもっているので VM を指定して接続します。

今回の対象 VM は下記（web-03a、web-04a）です。各 VM の vNIC は１つだけです。

Get-VM web-0[34]a.corp.local

Get-VM web-0[34]a.corp.local | Get-NetworkAdapter | ft -AutoSize

vNIC が１つだけなので、VM を指定して接続します。

$vms = Get-VM web-0[34]a.corp.local

Connect-NsxLogicalSwitch -VirtualMachine $vms -LogicalSwitch $ls

接続されました。論理スイッチのバッキング ポートグループが接続されています。

vSphere Web Client でも、論理スイッチに VM が接続されたことが確認できます。

そして HoL のシナリオにあるように、web-03a と web-04a とで ping による疎通確認ができるはずです。

つづく・・・

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

前回の投稿はこちら。

NSX の HoL シナリオを PowerNSX でためす。Part.1

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

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

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

今回は、モジュール3 の分散論理ルーティングを実施します。

このシナリオでは、Edge Security Gateway（ESG）でのルーティングを

分散論理ルータ（DLR）によるルーティングに変更して、

さらに ESG / DLR で OSPF によるダイナミック ルーティングを有効化します。

ESG から DLR へのインターフェース付け替え。

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

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

このラボのサンプル Web ページ「Customer DB App」は、

はじめは NSX Edge Service Gateway（ESG）でルーティングをしています。

まず、ESG のインターフェースの構成を確認しておきます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface | select index,name,type,isConnected,portgroupName | ft -AutoSize

構成変更のため、ESG からインターフェース App_Tier と DB_Tier を削除します。

vnic3、vnic4 がクリアされます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name  App_Tier | Clear-NsxEdgeInterface -Confirm:$false

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name  DB_Tier | Clear-NsxEdgeInterface -Confirm:$false

新たにネットワークを接続する、DLR のインターフェース構成を確認しておきます。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterInterface | %{$ip = $_.addressGroups.addressGroup; $_ | select Index,type,name,connectedToName,{$ip.primaryAddress},{$ip.subnetPrefixLength}} | ft -AutoSize

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

$ls = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

Get-NsxLogicalRouter -Name Distributed-Router-01 | New-NsxLogicalRouterInterface -Name App_Tier -Type internal -ConnectedTo $ls -PrimaryAddress 172.16.20.1 -SubnetPrefixLength 24

接続する論理スイッチは、下記のように指定することもできます。

Get-NsxLogicalRouter -Name Distributed-Router-01 | New-NsxLogicalRouterInterface -Name DB_Tier -Type internal -ConnectedTo (Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch) -PrimaryAddress 172.16.30.1 -SubnetPrefixLength 24

DLR に、論理スイッチに接続したインターフェース App_Tier、DB_Tier が作成されました。

DLR で OSPF を有効化する。

DLR は、OSPF がまだ無効な状態です。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Get-NsxLogicalRouterOspf

DLR で OSPF を有効化します。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Set-NsxLogicalRouterRouting -EnableOspf -EnableOspfRouteRedistribution -RouterId 192.168.5.2 -ProtocolAddress 192.168.5.3 -ForwardingAddress 192.168.5.2 -Confirm:$false

OSPF Area を作成します。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterOspfArea -AreaId 10 -Confirm:$false

DLR のアップリンク インターフェースに OSPF Area を追加します。

$if = Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterInterface -Name Transit_Network_01

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

分散ルータで OSPF が有効になりました。

OSPF のルート再配布テーブルに BGP の許可ルールを追加しておきます。

（本来ならルール編集がいいとは思いますが・・・）

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterRedistributionRule -Learner ospf -FromBGP -Action permit -Confirm:$false

NSX ESG に OSPF ルーティングを追加する。

NSX ESG も、まだ OSPF が無効です。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Get-NsxEdgeOspf

ESG で OSPF を有効化します。

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

OSPF Area を作成します。

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

ESG のインターフェースに OSPF Area を追加します。

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

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

今回はルート再配布テーブルに許可ルールを追加してしまいます。

（こちらも本来はルール編集がいいとは思いますが・・・）

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

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

これで、ネットワーク構成を変更したあとも

HoL のサンプル Web ページ「Customer DB App」が表示できるようになるはずです。

つづく。

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

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

NSX の HoL シナリオを PowerNSX でためす。Part.1

NSX の HoL シナリオを PowerNSX でためす。Part.2

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

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

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

今回は、モジュール3 の続きです。

ここでは、この先に ECMP ルーティングの構成する準備として、

ラボに 2台目の NSX Edge Service Gateway（ESG）をデプロイします。

New-NsxEdge の都合上、クラスタでは DRS を有効にしてしまいます。

管理クラスタには NSX Controller も配置されているので、アンチアフィニティ ルールの都合上

可能なら DRS は有効にしておいた方がよい気がします。

ただし、ESG は基本的に常にトラフィックが発生するので

DRS を有効にしても、DRS のポリシーは必ずしも完全自動にはしなくてもよいかなと考えられます。

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

ESG をデプロイする前に、New-NsxEdgeInterfaceSpec で

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

アップリンク側です。vNIC は vDS の分散ポートグループに接続します。

$vnic0 = New-NsxEdgeInterfaceSpec -Index 0 -Name Uplink -Type uplink -ConnectedTo (Get-VDPortgroup Uplink-RegionA01-vDS-MGMT) -PrimaryAddress 192.168.100.4 -SubnetPrefixLength 24

インターナル側です。vNIC は NSX の論理スイッチに接続します。

$vnic1 = New-NsxEdgeInterfaceSpec -Index 1 -Name Transit_Network_01 -Type internal -ConnectedTo (Get-NsxLogicalSwitch -Name Transit_Network_01) -PrimaryAddress 192.168.5.4 -SubnetPrefixLength 29

そして、NSX Edge をデプロイします。

New-NsxEdge -Name Perimeter-Gateway-02 -Username admin -Password "VMware1!VMware1!" -EnableSSH -Cluster (Get-Cluster RegionA01-MGMT01) -Datastore (Get-Datastore RegionA01-ISCSI01-COMP01) -FormFactor compact -Interface $vnic0,$vnic1 -FwEnabled -FwDefaultPolicyAllow

NSX Edge のデプロイは NSX のコンポーネントの中でも入力項目が多く失敗した時の悲しみが大きいので、

コマンドラインを用意しておくことで、成功率を上げたり、リトライしやすくすると便利かなと思います。

また経験上、Nsx Edge のデプロイが成功しない場合はまず下記のあたりを確認するとよさそうです。

• デプロイ先のクラスタで DRS が有効になっているか。
• インターフェースに指定した IP アドレスが正しいか。（ネットワーク アドレス的にも）
• New-NsxEdgeInterfaceSpec や New-NsxEdge で指定しているオブジェクトが本当に存在しているか。
• 指定したオブジェクトの名前が重複していないか。（同一 Edge での New-NsxEdgeInterfaceSpec の Name も）

まだまだ続く。

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

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

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

NSX の HoL シナリオを PowerNSX でためす。Part.1

NSX の HoL シナリオを PowerNSX でためす。Part.2

NSX の HoL シナリオを PowerNSX でためす。Part.3

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

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

OSPF の Area ID を指定します。

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

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

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

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

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

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

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

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

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

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

ECMP を有効化する。

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

DLR「Distributed-Router-01」です。

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

ESG「Perimeter-Gateway-01」です。

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

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

ESG「Perimeter-Gateway-01」です。

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

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

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

まだ続く・・・

今回は、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

今回も、クラスタでは 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"

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

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

$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

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

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

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

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

ロードバランサの構成。

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

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

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

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

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

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

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

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

$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

プールにメンバ サーバ（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

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

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

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

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

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

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

続く・・・

今回は、ここまでのシナリオでの 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

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

スクリプトの内容。

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

• 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 のヒアドキュメント（「@'」と、「'@」で囲む）を利用して保存しています。

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

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

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

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

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

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

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

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

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

PS> .\migrate_hol_nw.ps1 Web_Tier

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

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

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

PS> .\migrate_hol_nw.ps1 App_Tier

PS> .\migrate_hol_nw.ps1 DB_Tier

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

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

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

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

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

まだつづく・・・

ここからは、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"

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

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

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

$vms

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

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

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

$web_sg

外部 → 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

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

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

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

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

$app_nw = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

$app_nw

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

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

$service_app

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

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

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

$db_nw = Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch

$db_nw

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

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

$service_db

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

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

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

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

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

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

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

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

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

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

つづく！

今回は、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 ファイアウォールを無効にしてみます。

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

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

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

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

$edge | Set-NsxEdge -Confirm:$false

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

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

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

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

$edge | Set-NsxEdge -Confirm:$false

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

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

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

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

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

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

$edge.features.firewall.defaultPolicy

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

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

$edge | Set-NsxEdge -Confirm:$false

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

ESG の設定内容の確認。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これは 再デプロイや REST API で修正することができますが、

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

まず、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

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

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

PowerCLI> $edge.appliances.appliance.configuredResourcePool

 

 

id          name        isValid

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

resgroup-61 rp-01-infra true

 

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

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

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

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

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

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

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

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

DFW 除外リストの様子。

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

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

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

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

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

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

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

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

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 の追加が確認できます。

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

同様に、除外リストから 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 では、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 はルーティングを設定済み

下記のような構成です。

ESG（NSX Edge）と DLR はデプロイ済みです。

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

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

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

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

ESG での DHCP サーバ設定。

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

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

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

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

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

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

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

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

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

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

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

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

ESG 側のインターフェースは「Uplink」ではなく「Internal」にしておきます。

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

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

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

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

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

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

VM を指定します。

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

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

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

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

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

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

前回の投稿で、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 の作成 ～ 論理スイッチへの接続

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

あらかじめ、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 で設定してみる話でした。

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>

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

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

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

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

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

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

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

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

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

この状態を回避するには、下記の 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 ドライブからメディア切断してみる話でした。

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 を一括削除するための工夫についてです。

あらかじめ 削除禁止 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 削除の工夫についての話でした。

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 ファイルの情報を取得して利用する話でした。

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つ見えるようになります。

VCSA 6.7 では embedded-PSC（PSC と vCenter を １つの VM に含む）での

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

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

vSphere 6.7 に Kubernetes クラスタを構築してみます。

今回のクラスタは、うちでの勉強のために作成するので

「Kubernetes Anywhere」を利用しています。

GitHub - kubernetes/kubernetes-anywhere: {concise,reliable,cross-platform} turnup of Kubernetes clusters

今回の環境。

Kubernetes クラスタを展開する環境のソフトウェア構成は下記です。

• vSphere 6.7（vCenter 6.7 / ESXi 6.7。vSphere の DRS クラスタ構成ずみ）
• Kubernetes v1.9.7（Kubernetes Anywhere でデプロイ）
• vSAN 6.7（Kubernetes VM のデータストアとして利用）
• NSX for vSphere 6.4.1（NSX Edge の DHCP サービスと論理スイッチを利用）

Kubernetes Anywhere で、Docker コンテナを利用した Kubernetes クラスタのデプロイをします。

実行する Docker ホストのソフトウェア構成は下記です。

• VMware Photon OS 2.0
• Docker 17.06.0-ce

Kubernetes Anywhere 用の OVA のデプロイ。

Kubernetes Anywhere on vSphere むけの Photon OS の OVA ファイル

「KubernetesAnywhereTemplatePhotonOS.ova」が、下記で提供されています。

kubernetes-anywhere/README.md at master · kubernetes/kubernetes-anywhere · GitHub

ファイルへの直接リンクは下記です。

https://storage.googleapis.com/kubernetes-anywhere-for-vsphere-cna-storage/KubernetesAnywhereTemplatePhotonOS.ova

デプロイ時のデフォルトの VM 名は長いので、今回は

03-Template という VM フォルダを作成し、その直下に

k8s-anywhere-ova という名前でデプロイしています。

DHCP によるアドレス取得の都合により、

この OVA はデプロイ後にパワーオンしないようにしておきます。

Kubernetes Anywhere の Docker ホストの準備。

Docker Host の Photon OS は、OVA 版を利用しています。

まず、下記から Photon OS 2.0 GA の OVA をダウンロードして、ESXi にデプロイします。

Photon OS 2.0 GA Binaries

OVA with virtual hardware v13 (ESX 6.5 and above)

Downloading Photon OS · vmware/photon Wiki · GitHub

root / changeme でログインして初期パスワードを変更します。

tdnf コマンドで RPM パッケージをアップデートしたうえで、OS を再起動しておきます。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@photon-machine [ ~ ]# tdnf update -y

root@photon-machine [ ~ ]# reboot

Docker はあらかじめインストールされているので、

サービスを有効化 / 起動します。

root@photon-machine [ ~ ]# systemctl enable docker

root@photon-machine [ ~ ]# systemctl start docker

Kubernetes Anywhere コンテナのダウンロード～起動。

kubernetes-anywhere のコンテナイメージをダウンロードします。

root@photon-machine [ ~ ]# docker pull cnastorage/kubernetes-anywhere:v2

コンテナを起動します。

今回は、Docker ホストのカレントディレクトリ直下の tmp ディレクトリを、

コンテナの /tmp に割り当てています。

起動してそのままコンテナの中に入っているため

プロンプトが「[container]:/opt/kubernetes-anywhere>」になります。

root@photon-machine [ ~ ]# mkdir tmp

root@photon-machine [ ~ ]# docker run -it -v `pwd`/tmp:/tmp --rm --env="PS1=[container]:\w> " --net=host cnastorage/kubernetes-anywhere:v2 /bin/bash

[container]:/opt/kubernetes-anywhere>

Kubernetes をデプロイするためのコンフィグを作成します。

[container]:/opt/kubernetes-anywhere> make config

今回は、下記のように実行しました。

赤字部分が入力部分です。

パラメータを入力した直後には Enter キーも押していますが、

ただ Enter キーを押した個所はわかりにくいため「 Enterキー」と記載しています。

できるだけデフォルト値を採用していますが、

じつは今回は Blockchain on Kubernetes（BoK）検証むけの

Kubernetes クラスタを作成しようとしているため一部の設定値は BoK むけに調整しています。

• CPU、メモリを増加。
• Kubernetes のバージョンは BoK のガイドにある v1.9.7 に決め打ち。
• 同様に phase2.installer_container もガイドにあるイメージを指定。

このラボ環境むけのパラメータ指定もあります。

• phase1.vSphere.username はラボにあるユーザを指定。
  （administrator@vsphere.local などでもよい）
• データストアでは vSAN データストア（vsanDatastore）を指定。
• vSphere のクラスタで DRS を有効化し、リソースプール（kube-pool-01）を事前作成してある。
• VM フォルダ（02-Lab/lab-k8s-01）を指定しているが、これらは事前作成してある。
  02-Lab/lab-k8s-01 は、VM フォルダを2階層にしている。
• ポートグループ（vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003）は、NSX 論理スイッチのバッキングとなっている分散ポートグループを指定。
  この論理スイッチでは、NSX Edge の DHCP サービスを利用して、インターネット接続できるようネットワーク設定をしている。
  （DHCP は Kubernetes Anywhere のデプロイで必要）
• Kubernetes ノードのテンプレートになる VM は配置している VM フォルダも併せて指定（03-Template/k8s-anywhere-ova）。

[container]:/opt/kubernetes-anywhere> make config

CONFIG_="." kconfig-conf Kconfig

*

* Kubernetes Minimal Turnup Configuration

*

*

* Phase 1: Cluster Resource Provisioning

*

number of nodes (phase1.num_nodes) [4] (NEW) Enterキー

kubernetes cluster name (phase1.cluster_name) [kubernetes] (NEW) Enterキー

SSH user to login to OS for provisioning (phase1.ssh_user) [] (NEW) Enterキー

*

* cloud provider: gce, azure or vsphere

*

cloud provider: gce, azure or vsphere (phase1.cloud_provider) [vsphere] (NEW) Enterキー

  *

  * vSphere configuration

  *

  vCenter URL Ex: 10.192.10.30 or myvcenter.io (without https://) (phase1.vSphere.url) [] (NEW) infra-vc-01.go-lab.jp

  vCenter port (phase1.vSphere.port) [443] (NEW) Enterキー

  vCenter username (phase1.vSphere.username) [] (NEW) gowatana

  vCenter password (phase1.vSphere.password) [] (NEW) パスワード

  Does host use self-signed cert (phase1.vSphere.insecure) [Y/n/?] (NEW) Enterキー

  Datacenter (phase1.vSphere.datacenter) [datacenter] (NEW) infra-dc-01

  Datastore (phase1.vSphere.datastore) [datastore] (NEW) vsanDatastore

  Deploy Kubernetes Cluster on 'host' or 'cluster' (phase1.vSphere.placement) [cluster] (NEW) Enterキー

    vsphere cluster name. Please make sure that all the hosts in the cluster are time-synchronized otherwise some of the nodes can remain in pending state for ever due to expired certificate (phase1.vSphere.cluster) [] (NEW) infra-cluster-01

  Do you want to use the existing resource pool on the host or cluster? [yes, no] (phase1.vSphere.useresourcepool) [no] (NEW) yes

    Name of the existing Resource Pool. If Resource pool is enclosed within another Resource pool, specify pool hierarchy as ParentResourcePool/ChildResourcePool (phase1.vSphere.resourcepool) [] (NEW) kube-pool-01

  VM Folder name or Path (e.g kubernetes, VMFolder1/dev-cluster, VMFolder1/Test Group1/test-cluster). Folder path will be created if not present (phase1.vSphere.vmfolderpath) [kubernetes] (NEW) 02-Lab/lab-k8s-01

  Number of vCPUs for each VM (phase1.vSphere.vcpu) [1] (NEW) 2

  Memory for VM (phase1.vSphere.memory) [2048] (NEW) 4096

  Network for VM (phase1.vSphere.network) [VM Network] (NEW) vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003

  Name of the template VM imported from OVA. If Template file is not available at the destination location specify vm path (phase1.vSphere.template) [KubernetesAnywhereTemplatePhotonOS.ova] (NEW) 03-Template/k8s-anywhere-ova

  Flannel Network (phase1.vSphere.flannel_net) [172.1.0.0/16] (NEW) Enterキー

*

* Phase 2: Node Bootstrapping

*

kubernetes version (phase2.kubernetes_version) [v1.6.5] (NEW) v1.9.7

bootstrap provider (phase2.provider) [ignition] (NEW) Enterキー

  installer container (phase2.installer_container) [docker.io/cnastorage/k8s-ignition:v2] (NEW) docker.io/cnastorage/k8s-ignition:v1.8-dev-release

  docker registry (phase2.docker_registry) [gcr.io/google-containers] (NEW) Enterキー

*

* Phase 3: Deploying Addons

*

Run the addon manager? (phase3.run_addons) [Y/n/?] (NEW) Enterキー

  Run kube-proxy? (phase3.kube_proxy) [Y/n/?] (NEW) Enterキー

  Run the dashboard? (phase3.dashboard) [Y/n/?] (NEW) Enterキー

  Run heapster? (phase3.heapster) [Y/n/?] (NEW) Enterキー

  Run kube-dns? (phase3.kube_dns) [Y/n/?] (NEW) Enterキー

  Run weave-net? (phase3.weave_net) [N/y/?] (NEW) Enterキー

#

# configuration written to .config

#

[container]:/opt/kubernetes-anywhere>

上記の入力により、コンフィグファイル「.config」は下記のように作成されます。

make config を実行せず、下記のファイルを直接作成してもデプロイ可能です。

#

# Automatically generated file; DO NOT EDIT.

# Kubernetes Minimal Turnup Configuration

#

 

#

# Phase 1: Cluster Resource Provisioning

#

.phase1.num_nodes=4

.phase1.cluster_name="kubernetes"

.phase1.ssh_user=""

.phase1.cloud_provider="vsphere"

 

#

# vSphere configuration

#

.phase1.vSphere.url="infra-vc-01.go-lab.jp"

.phase1.vSphere.port=443

.phase1.vSphere.username="gowatana"

.phase1.vSphere.password="パスワード"

.phase1.vSphere.insecure=y

.phase1.vSphere.datacenter="infra-dc-01"

.phase1.vSphere.datastore="vsanDatastore"

.phase1.vSphere.placement="cluster"

.phase1.vSphere.cluster="infra-cluster-01"

.phase1.vSphere.useresourcepool="yes"

.phase1.vSphere.resourcepool="kube-pool-01"

.phase1.vSphere.vmfolderpath="02-Lab/lab-k8s-01"

.phase1.vSphere.vcpu=2

.phase1.vSphere.memory=4096

.phase1.vSphere.network="vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003"

.phase1.vSphere.template="03-Template/k8s-anywhere-ova"

.phase1.vSphere.flannel_net="172.1.0.0/16"

 

#

# Phase 2: Node Bootstrapping

#

.phase2.kubernetes_version="v1.9.7"

.phase2.provider="ignition"

.phase2.installer_container="docker.io/cnastorage/k8s-ignition:v1.8-dev-release"

.phase2.docker_registry="gcr.io/google-containers"

 

#

# Phase 3: Deploying Addons

#

.phase3.run_addons=y

.phase3.kube_proxy=y

.phase3.dashboard=y

.phase3.heapster=y

.phase3.kube_dns=y

# .phase3.weave_net is not set

設定が完了したら、デプロイします。

[container]:/opt/kubernetes-anywhere> make deploy

デプロイが完了したら、kubectl で Kubernetes クラスタの状態を確認します。

環境変数 KUBECONFIG を設定して、クラスタの情報を確認します。

Kubernetes master が起動（running）していることや、Kubernetes ノードの状態が確認できます。

今回は、Worker が 4ノードです。

[container]:/opt/kubernetes-anywhere> export KUBECONFIG=phase1/vsphere/kubernetes/kubeconfig.json

[container]:/opt/kubernetes-anywhere> kubectl cluster-info

Kubernetes master is running at https://10.0.3.121

Heapster is running at https://10.0.3.121/api/v1/namespaces/kube-system/services/heapster/proxy

KubeDNS is running at https://10.0.3.121/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

[container]:/opt/kubernetes-anywhere> kubectl get nodes

NAME                STATUS                     ROLES     AGE       VERSION

kubernetes-master   Ready,SchedulingDisabled   <none>    1m        v1.9.7

kubernetes-node1    Ready                      <none>    1m        v1.9.7

kubernetes-node2    Ready                      <none>    1m        v1.9.7

kubernetes-node3    Ready                      <none>    1m        v1.9.7

kubernetes-node4    Ready                      <none>    1m        v1.9.7

[container]:/opt/kubernetes-anywhere>

kubeconfig.json ファイルはコンテナを停止すると削除されてしまうので、

Docker ホストのディレクトリを割り当てている /tmp にコピーしておきます。

[container]:/opt/kubernetes-anywhere> cp phase1/vsphere/kubernetes/kubeconfig.json /tmp/

これで勉強用 Kubernetes が手ごろに作成できるかなと思います。

以上、vSphere に Kubernetes をデプロイしてみる話でした。