Skip navigation

本番環境に vSAN を導入するときには厳密にハードウェア互換性などを確認する必要があります。

しかしその反面、動作確認、機能検証、デモンストレーションといった用途のためであれば

手軽なネステッド環境で vSAN を構築することができます。

 

そこで今月は1日1回くらい、

ネステッド環境で、さまざまな vSAN を構成してみようと思います。

ソフトウェア バージョンは、2018年12月時点で最新の vSAN 6.7 u1 を利用しています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

ネステッド vSAN と、その構築方法については下記もどうぞ。

図解 ネステッド vSAN ラボ。

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

ネステッド vSAN ラボを構築するための工夫 Part.2。(物理マシン ESXi と ESXi VM の準備)

ネステッド vSAN ラボを構築するための工夫 Part.3。(vSAN クラスタ構築)

ネステッド vSAN ラボを構築するための工夫 Part.4。(スクリプトでの簡素化)

 

1日目は、vSAN の基本操作・動作を確認しやすい、

運用観点での最小構成である 4ノード構成のネステッド vSAN を構築してみました。

  • ESXi は 4ノード
  • ハイブリッド(SSD + HDD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • 重複排除・圧縮 は無効のまま
  • フォールト ドメインはデフォルト構成のまま
  • vCenter は vSAN 外部に配置

 

それでは、構成したネステッド vSAN 環境を vSphere Cilent (旧 HTML5 Client)でひととおり見てみます。

 

ネストの外側と、ネストの内側。

ネステッド vSAN を構成する ESXi は、VM です。

「ネストの外側」から実体の VM を見ると、ゲスト OS が VMware ESXi になっています。

vsan-adv-01-02.png

 

一方「ネストの内側」となるハイパーバイザから見ると、

サーバのモデルが「VMware Virtual Platform」です。

vsan-adv-01-03.png

 

ネステッド vSAN で主な画面を眺める。

vSAN 6.7 U1 では、基本的に HTML5 版の vSphere Client  から操作できるようになっています。

(Flash 版の vSphere Web Client ではなく)

 

HTML5 版の vSphere Client でサポートされるようになった機能は、下記のドキュメントで確認できます。

Functionality Updates for the vSphere Client

 

それでは、vSAN の UI を表示してみます。

 

設定 → vSAN → サービス

今回はデフォルトで無効なものは、そのままです。

vsan-adv-01-04.png

 

設定 → vSAN → ディスク管理

各ノードには、1つのディスクグループが作成されています。

ディスクグループあたり、キャッシュ層 SSD が 1つ、キャパシティ層 HDD が 1つあります。

vsan-adv-01-05.png

 

設定 → vSAN → フォールト ドメイン

フォールト ドメインはデフォルトのままで特に構成していないので

各ノードそれぞれがフォールト ドメインとなっています。

vsan-adv-01-06.png

 

設定 → vSAN → iSCSI ターゲット サービス

vSAN iSCSI ターゲットも無効のままです。

vsan-adv-01-07.png

 

監視 → vSAN → 健全性

ネステッド環境はそもそも本番環境ではサポートされておらず、ハードウェア互換性などを無視しているので

そのぶんエラーや警告などは表示されます。

そのため、検証目的やデモ内容に直接関係ないものは、わりきって無視します。

vsan-adv-01-08.png

 

監視 → vSAN → 仮想オブジェクト

この vSAN にはまだ VM を配置していないので、仮想オブジェクトもまだありません。

vsan-adv-01-09.png

 

監視 → vSAN → 物理ディスク

vsan-adv-01-10.png

 

監視 → vSAN → オブジェクトの再同期

この vSAN にはまだ VM を配置していないので、この画面にも特に表示されません。

vsan-adv-01-11.png

 

監視 → vSAN → プロアクティブ テスト

ネステッド vSAN でも、プロアクティブ テストは利用できます。

(利用例は、後の投稿にて)

vsan-adv-01-12.png

 

監視 → vSAN → 容量

vSAN データストアでは、ESXi VM に割り当てた VMDK ファイルの容量が認識されます。

そのため ネステッド ESXi に接続する VMDK をシン プロビジョニングにしておけば、

外側の物理マシンのストレージ容量を超えた、大容量 vSAN のデモ環境も作成できます。

vsan-adv-01-14.png

 

監視 → vSAN → パフォーマンス

今回は vSAN パフォーマンス サービスを有効化していないので、なにも表示されていません。

vsan-adv-01-15.png

 

監視 → vSAN → パフォーマンス診断

vsan-adv-01-16.png

 

監視 → vSAN → サポート

vsan-adv-01-17.png

 

このように、基本操作や画面確認であれば、ネステッド vSAN でも、通常の vSAN 同等に利用可能です。

VMware の提供するオンラインのハンズオン ラボでもネステッド vSAN が利用されています。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-02

日本の vExperts Advent Calendar 2018 の 1日目の投稿です。

 

vExperts Advent Calendar 2018

https://adventar.org/calendars/3101

 

1日目なのでクリスマス色のつよい Tips をお伝えしたいと思います。

そこで、lamw さんの Tips を参考に vSphere Client の色を変更してみます。

Add custom color to vSphere HTML5 UI Header/Footer in vSphere 6.7 Update 1 · GitHub

 

当然ながら HTML5 のハックは非サポートですので、

自宅ラボなどで気分を出すためにご利用いただければと思います。

この投稿でも、既存環境への適用を避けて新規の VCSA 6.7 u1 をデプロイします。

 

vCenter Server Appliance (VCSA) のデプロイ。

今回は、デプロイ手順を簡略化するため CLI を利用します。

vcsa-deploy.exe での CLI デプロイは、ちゃんとサポートされる方法です。

VCSA 6.7 を CLI デプロイしてみる。(embedded-PSC x2 の Enhanced Linked Mode)

 

デプロイ環境について。

 

VCSA は、この投稿時点で最新のバージョンを利用します。

  • バージョン: VMware vCenter Server 6.7 Update 1 ビルド 10244745
  • インストーラ: VMware-VCSA-all-6.7.0-10244745.iso

 

デプロイ先として、ESXi 6.7 u1 環境はセットアップずみです。

  • ESXi インストールずみ。
  • VCSA の Tiny デプロイのスペック以上のマシンが必要。
    • CPU 2コア(スレッド)以上
    • メモリは最小 16GB程度(ESXi と VCSA の 10GB を搭載できる程度)
    • ディスク
  • データストア名、ポートグループ名はそのまま。
  • ネットワーク / DNS アドレスはデプロイ環境にあわせる。
  • ユーザ / パスワードは、いつものデモ用のもの。

 

CLI で指定するデプロイ設定のファイル(JSON のテキストファイル)は下記のようにしました。

 

lab-vcsa-67u1.json · GitHub

  • 今回のハックのために、SSH アクセスを有効化しています。
  • 正式には system_name で VCSA のアドレスで FQDN のホスト名を指定しますが、
    ラボでの DNS レコード省略のため IP アドレスににします。

{

    "__version": "2.13.0",

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

    "new_vcsa": {

        "esxi": {

            "hostname": "192.168.1.20",

            "username": "root",

            "password": "VMware1!",

            "deployment_network": "VM Network",

            "datastore": "datastore1"

        },

        "appliance": {

            "thin_disk_mode": true,

            "deployment_option": "tiny",

            "name": "lab-vcsa-67u1"

        },

        "network": {

            "ip_family": "ipv4",

            "mode": "static",

            "ip": "192.168.1.55",

            "dns_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "prefix": "24",

            "gateway": "192.168.1.1",

            "system_name": "192.168.1.55"

        },

        "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

        }

    }

}

 

VCSA デプロイの実施。

それでは、Windows クライアントからデプロイします。

VCSA のインストーラは F: ドライブにマウントしています。

 

事前チェック

※ lab-vcsa-67u1.json はファイルを配置したパスを指定します。

PS> cd F:/vcsa-cli-installer/win32/

PS> ./vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula --precheck-only ~/lab-vcsa-67u1.json

 

デプロイ実行

PS> ./vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula ~/lab-vcsa-67u1.json

 

デプロイ処理が完了すると、HTML5 の

vSphere Client にアクセスできるようになります。

vcsa-html5-hack-01.png

 

HTML5 Client(vSphere Client)の色を変更してみる。

※ここからは非サポートの方法です。

 

今回は、スクリプトを用意してみました。

Add custom color to vSphere HTML5 UI Header/Footer in vSphere 6.7 Update 1 · GitHub

 

NotSupported_H5ClientHacks-Xmas.sh ファイルの内容

  • 元ファイルを、いちおうバックアップ。
  • ファイルの置き換えからサービス再起動まで実行。
  • 色がクリスマス風。

NEW_HEADER_HEX_COLOR=006400

NEW_BOTTOM_HEX_COLOR=8b0000

BACKUP_FILE=/usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war.bak

if [ ! -e ${BACKUP_FILE} ]; then

  cp /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war ${BACKUP_FILE}

fi

mkdir -p /root/work

cd /root/work

cp /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war .

unzip h5ngc.war

rm -f h5ngc.war

cat << EOF >> resources/css/NotSupported_H5ClientHacks.css

.main-nav HEADER{

  background-color:#${NEW_HEADER_HEX_COLOR} !important; }

bottom-panel toggle-splitter {

  background: #${NEW_BOTTOM_HEX_COLOR} !important; }

EOF

sed -i '/--%>/a \

\n   <link href="resources/css/NotSupported_H5ClientHacks.css" rel="stylesheet"/>' WEB-INF/views/index.jsp

zip -r /root/h5ngc.war config  error.jsp  locales  META-INF  notfound.jsp  plugin.xml  resources  webconsole.html  WEB-INF

cd /root

rm -rf /root/work

cp /root/h5ngc.war /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/

service-control --stop vsphere-ui; service-control --start vsphere-ui

 

VCSA に SSH でログインして、shell を起動します。

[gowatana@infra-jbox-01 ~]$ ssh root@192.168.1.55

 

VMware vCenter Server Appliance 6.7.0.20000

 

Type: vCenter Server with an embedded Platform Services Controller

 

root@192.168.1.55's password:

Last login: Sat Dec  1 03:46:41 2018 from 192.168.1.103

Connected to service

 

    * List APIs: "help api list"

    * List Plugins: "help pi list"

    * Launch BASH: "shell"

 

Command> shell

Shell access is granted to root

root@photon-machine [ ~ ]#

 

スクリプトをダウンロードして、実行します。

root@photon-machine [ ~ ]# curl -O https://gist.githubusercontent.com/gowatana/a82d8038c7994e317484d747e8edf461/raw/NotSupported_H5ClientHacks-Xmas.sh

root@photon-machine [ ~ ]# bash ./NotSupported_H5ClientHacks-Xmas.sh

 

もしくは、ダウンロード~実行をまとめることもできます。

root@photon-machine [ ~ ]# curl https://gist.githubusercontent.com/gowatana/a82d8038c7994e317484d747e8edf461/raw/NotSupported_H5ClientHacks-Xmas.sh | bash

 

サービスの再起動をまって HTML5 の vSphere Client にアクセスすると、

クリスマス風になります。

vcsa-html5-hack-02.png

 

元に戻す場合は、下記のようにバックアップ ファイルをリストアして、

サービスを再起動します。

root@photon-machine [ ~ ]# cp /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war.bak /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war

root@photon-machine [ ~ ]# service-control --stop vsphere-ui; service-control --start vsphere-ui

 

以上、vSphere Client をクリスマスカラーにしてみる話でした。

vE アドベントカレンダー 2日目は kmassue さんの予定です。よろしくお願いします。

ここまで、PowerCLI を利用したネステッド vSAN 環境セットアップの工夫を紹介してきました。

今回は、ここまでのコマンドラインを利用したスクリプトによるデプロイ簡素化についてです。

 

これまでの話については下記をどうぞ。

図解 ネステッド vSAN ラボ。

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

ネステッド vSAN ラボを構築するための工夫 Part.2。(物理マシン ESXi と ESXi VM の準備)

ネステッド vSAN ラボを構築するための工夫 Part.3。(vSAN クラスタ構築)

 

今回のサンプルスクリプトは、下記に配置しました。

GitHub - gowatana/deploy-1box-vsan

 

vSAN 環境の初期化。

まず、ここまでで下記のような vSAN 環境をセットアップしてあります。

vsan-1box-5-1.png

 

はじめに、再度デプロイをためすために、一度環境を初期化します。

前回に引き続き、PowerCLI は Connect-VIServer で vCenter に接続したままの状態です。

 

今回の vSAN クラスタ名と、ESXi VM の名前は下記です。

$cluster_name = "vSAN-Cluster"

$vm_name = "vm-esxi-??"

 

vSAN クラスタにある ESXi をすべて削除して、クラスタも削除します。

今回はラボを初期化してしまうので、ESXi はメンテナンスモードなどにはせず

切断 → インベントリから削除 としています。

$cluster = Get-Cluster $cluster_name

$cluster | Get-VMHost | Set-VMHost -State Disconnected -Confirm:$false

$cluster | Get-VMHost | Remove-VMHost -Confirm:$false

$cluster | Remove-Cluster -Confirm:$false

 

ESXi VM も削除します。

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

Get-VM $vm_name | Remove-VM -DeletePermanently -Confirm:$false

 

これで、vCenter のインベントリから、ネステッド vSAN 環境が削除されます。

vsan-1box-5-2.png

 

vSAN 環境のデプロイ。(スクリプト簡素化版)

それでは、スクリプトでデプロイしてみます。

 

設定情報については、できるだけスクリプトから分離したいので

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

 

config_vSAN-Cluster-01.ps1

# Lab Global Setting.

$base_vc_address = "192.168.1.30"

$base_vc_user = "administrator@vsphere.local"

$base_vc_pass = "VMware1!"

 

 

 

$nest_vc_address = "192.168.1.30"

$nest_vc_user = "administrator@vsphere.local"

$nest_vc_pass = "VMware1!"

 

$domain = "go.lab.jp"

$hv_ip_prefix_vmk0 = "192.168.1."

$hv_subnetmask = "255.255.255.0" # /24

$hv_gw = "192.168.1.1"

$dns_1 = "192.168.1.101"

$dns_2 = "192.168.1.102"

$hv_user = "root"

$hv_pass = "VMware1!"

 

# Base ESXi Setting

$template_vm_name = "vm-esxi-template-01"

$hv_name = "192.168.1.20"

$base_hv_name = "192.168.1.20"

 

# Cluster setting

$vm_num_start = 1

$vm_num_end = 3

$cluster_name = "vSAN-Cluster-01"

 

# vSAN Disk setting

$vsan_cache_dev = "mpx.vmhba0:C0:T1:L0"

$vsan_capacity_dev = "mpx.vmhba0:C0:T2:L0", "mpx.vmhba0:C0:T3:L0"

 

# VM / ESXi List

$nest_hv_hostname_prefix = "esxi-"

$vm_name_prefix = "vm-esxi-"

 

$vm_name_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $vm_name_prefix + $i.toString("00")

}

 

$nest_hv_hostname_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $nest_hv_hostname_prefix + $i.toString("00")

}

 

$hv_ip_vmk0_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $hv_ip_prefix_vmk0 + (30 + $i).ToString()

}

 

$vc_hv_name_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $hv_ip_prefix_vmk0 + (30 + $i).ToString()

}

 

下記のようにコマンドライン1行でデプロイできます。

(ただし、今回の対象は ESXi VM 作成以降の部分です)

PowerCLI> ./setup_vSAN-Cluster_AllFlash.ps1 ./config_vSAN-Cluster-01.ps1

 

スクリプトからの出力表示は粗いままですが・・・

vsan-1box-5-3.png

 

下記のように、前回までにデプロイした vSAN と同様の環境がセットアップできます。

vsan-1box-5-4.png

 

今回は SSD 上でのネステッド環境ですが、

ハイブリッド構成にみせかけてネステッド vSAN をセットアップすることもできます。

PowerCLI> ./setup_vSAN-Cluster_Hybrid.ps1 ./config_vSAN-Cluster-02.ps1

vsan-1box-5-5.png

 

vSAN 環境の初期化。(スクリプト簡素化版)

冒頭に実施した vSAN 環境の初期化もスクリプト化しておくと、

下記のように再構築も簡素化できます。

PowerCLI> ./destroy_vSAN-Cluster.ps1 ./config_vSAN-Cluster-01.ps1

PowerCLI> ./destroy_vSAN-Cluster.ps1 ./config_vSAN-Cluster-02.ps1

 

以上、ネステッド vSAN 環境構築の簡素化についてでした。

ひきつづき、ネステッド vSAN 環境セットアップの工夫を紹介します。

今回は、vSAN クラスタのセットアップです。PowerCLI も利用していきます。

 

これまでの話は下記をどうぞ。

図解 ネステッド vSAN ラボ。

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

ネステッド vSAN ラボを構築するための工夫 Part.2。(物理マシン ESXi と ESXi VM の準備)

 

前回までの投稿にて、起動されたネステッド ESXi が用意されているので、

ここからは、クラスタの作成、ESXi の登録、クラスタでの vSAN 有効化

といったことを進めていきます。

1box-vsan-13.png

3-1. クラスタの作成。

vCenter のインベントリに、クラスタ「vSAN-Cluster」を作成します。

PowerCLI は、以前の投稿にて vCenter に接続したままの状態です。

この時点では、まだ vSAN は有効化していません。

PowerCLI> Get-Datacenter LAB-DC | New-Cluster -Name vSAN-Cluster

 

3台のネステッド ESXi (Nest-ESXi)を登録します。

  • PowerCLI の Add-VMHost コマンドを利用。
  • ESXi は、IP アドレスのまま(192.168.1.31 ~ 192.168.1.33)でインベントリ登録。
  • ESXi VM は 1つのテンプレート VM からクローンしているため、
    ID 重複によるエラーをさけたいのでローカルデータストア(datastore1)は ESXi から除去。
  • データストア削除(Remove-Datastore)でエラーになってしまいますが、
    データストアは外せるので、今回はエラーを無視しています。

 

PowerCLI のプロンプトに投入するコマンドラインは、下記のようにします。

"192.168.1.31","192.168.1.32","192.168.1.33" | %{

    $hv_name = $_

    Add-VMHost -Name $hv_name -Location (Get-Cluster vSAN-Cluster) -User root -Password VMware1! -Force

    Get-VMHost $hv_name | Remove-Datastore -Datastore "datastore*" -Confirm:$false -ErrorAction:Ignore

}

 

Nest-ESXi の VMkernel ポートで vSAN トラフィックを有効にします。

設定対象はクラスタ「vSAN-Cluster」配下の、全ホストの vmk0 です。

本番環境では、vSAN トラフィックは( vmk1 などに)分離することが多いはずですが、

ラボ用途なので今回はシンプルに vmk0 に相乗りさせています。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VMHost | Get-VMHostNetworkAdapter -Name vmk0 | Set-VMHostNetworkAdapter -VsanTrafficEnabled:$true -Confirm:$false

 

3-2. vSAN クラスタのセットアップ。

クラスタで、vSAN を有効にします。

PowerCLI> Get-Cluster vSAN-Cluster | Set-Cluster -VsanEnabled:$true -Confirm:$false

 

vSAN ディスクグループを作成します。

「ScsiLun」などから、Nest-ESXi の認識しているデバイス名を確認しておきます。

容量や VMDK の接続順などから、デバイス名を特定できます。

このデバイス名は、Nest-ESXi の vSCSI / VMDK 構成が同じであれば、必ず同じものになります。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VMHost | Get-VMHostDisk | select VMHost,ScsiLun,TotalSectors | Sort-Object VMHost,ScsiLun

 

VMHost       ScsiLun             TotalSectors

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

192.168.1.31 mpx.vmhba0:C0:T0:L0     33554432

192.168.1.31 mpx.vmhba0:C0:T1:L0     41943040

192.168.1.31 mpx.vmhba0:C0:T2:L0    104857600

192.168.1.31 mpx.vmhba0:C0:T3:L0    104857600

192.168.1.32 mpx.vmhba0:C0:T0:L0     33554432

192.168.1.32 mpx.vmhba0:C0:T1:L0     41943040

192.168.1.32 mpx.vmhba0:C0:T2:L0    104857600

192.168.1.32 mpx.vmhba0:C0:T3:L0    104857600

192.168.1.33 mpx.vmhba0:C0:T0:L0     33554432

192.168.1.33 mpx.vmhba0:C0:T1:L0     41943040

192.168.1.33 mpx.vmhba0:C0:T2:L0    104857600

192.168.1.33 mpx.vmhba0:C0:T3:L0    104857600

 

 

各ホストでディスクグループを作成します。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VMHost | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba0:C0:T1:L0 -DataDiskCanonicalName mpx.vmhba0:C0:T2:L0,mpx.vmhba0:C0:T3:L0

 

ディスクグループ作成が完了すると、その分の

vSAN データストアの容量(CapacityGB)も増加します。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VsanSpaceUsage

 

Cluster              FreeSpaceGB     CapacityGB

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

vSAN-Cluster         295.945         299.953

 

 

これで、vSAN データストアが構成されて、

そこに VM を作成したりできるようになりました。

ネステッド環境上でのポートグループの作成やVM の作成などは、

基本的にネストであることを意識せずに実施します。

 

ちなみに、vSAN クラスタの PowerCLI でのセットアップについては、以前にも投稿しましたが、

こちらは少し前のものなので、現行のハンズオンラボ環境には未対応です・・・

PowerCLI で vSAN セットアップをためしてみる。

 

以上、ネステッド vSAN の環境セットアップについての話でした。

 

まだ続きあり。

ネステッド vSAN ラボを構築するための工夫 Part.4。(スクリプトでの簡素化)

前回に続いて、ネステッド vSAN 環境セットアップの工夫を紹介します。

今回は、特にネスト特有の、物理マシンの ESXi と、ESXi VM の部分についてです。

ひきつづき PowerCLI も利用していきます。

 

これまでの話は下記をどうぞ。

図解 ネステッド vSAN ラボ。

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

 

ネステッド ハイパーバイザとなる ESXi VM は、下図のように

vCenter(VCSA)と横並びの VM として作成して、ネスト環境特有の設定をします。

今回は最初に、テンプレートにする ESXi VM を作成し、

それをクローンして 3台の ネステッド ESXi にします。

1box-vsan-12.png

2-1. ESXi VM を接続するポートグループの作成。

ESXi にデフォルトで作成される「VM Network」ポートグループは、

今回の構成ではネストではない VM で利用するものとします。

そこで、デフォルトで作成される仮想スイッチ「vSwitch0」に、

ESXi VM を接続する、ネスト環境むけのポートグループ

「Nested-Trunk-Network」を新規作成します。

 

このポートグループには、下記の設定をしています。

  • 無差別モード(プロミスキャスモード)の許可。
  • 「偽装転送」と「MAC アドレス変更」はデフォルト同様に「許可」。
  • VLAN ID 4095。

※ PowerCLI は前回の投稿で vCenter に接続したままの状態です。

PowerCLI> $pg_name = "Nested-Trunk-Network"

PowerCLI> $pg = Get-VMHost | Get-VirtualSwitch -Name vSwitch0 | New-VirtualPortGroup -Name $pg_name -VLanId 4095

PowerCLI> $pg | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous:$true -ForgedTransmits:$true -MacChanges:$true

 

2-2. ESXi VM の作成。

ESXi をインストールする VM を作成します。

これは、あとで複数台の ESXi をクローンするための、VM テンプレートとして利用する想定です。

 

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

末尾の 4行では「ハードウェア アシストによる仮想化をゲスト OS に公開」にあたる

NestedHVEnabled を有効にしています。

また、vNIC は 最低限である 1つだけ作成しています。

 

create-esxi-vm.ps1

$vm_name = "vm-esxi-template-01"

$hv_name = "192.168.1.20"

 

$guest_id = "vmkernel65Guest"

$num_cpu = 2

$memory_gb = 6

$ds_name = "datastore1"

$vmdk_gb = 16

$pg_name = "Nested-Trunk-Network"

 

$vm = New-VM -Name $vm_name -VMHost $hv_name `

    -GuestId $guest_id `

    -NumCpu $num_cpu -CoresPerSocket $num_cpu `

    -MemoryGB $memory_gb `

    -DiskGB $vmdk_gb -Datastore $ds_name -StorageFormat Thin `

    -NetworkName $pg_name

 

$vm = Get-VM -Name $vm_name

$vm_config_spec = New-Object VMware.Vim.VirtualMachineConfigSpec

$vm_config_spec.NestedHVEnabled = $true

$vm.ExtensionData.ReconfigVM($vm_config_spec)

 

スクリプトは、vCenter に接続した状態で、下記のように実行します。

PowerCLI> .\create-esxi-vm.ps1

 

さまざまな vSAN を作成しやすいように、

VMDK の追加や ISO ファイルの接続はクローン後に実施します。

 

2-3. ESXi VM への ESXi インストールとクローン準備。

まず ESXi VM に、ESXi インストーラの ISO イメージファイルを接続してから起動し、

通常どおり ESXi をインストールします。

 

ESXi インストーラの ISO イメージファイルも、PowerCLIで VM に接続します。

ISO イメージファイルは、あらかじめ 物理マシン ESXi のデータストアに配置してあります。

※ESXi を Kickstart でインストールする場合は、この ISO イメージファイル接続は不要です。

PowerCLI> $iso_path = "[datastore1] iso/VMware-VMvisor-Installer-6.7.0.update01-10302608.x86_64.iso"

PowerCLI> Get-VM vm-esxi-?? | New-CDDrive -IsoPath $iso_path -StartConnected:$true

 

ESXi Shell を有効化して、vSphere Client の VM のコンソールからログインします。

この時点では、まだネットワーク設定は不要です。

 

下記の 2つの設定をします。

 

1) クローンによる MAC アドレス変更の対策として、

/Net/FollowHardwareMac を有効化します。

[root@localhost:~] esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

 

2) クローン後の ESXi VM 初回起動で UUID を再生成するために、

/etc/vmware/esx.conf ファイルから「/system/uuid」をいったん記載削除します。

※ これは vi などの編集でもよいです。

[root@localhost:~] sed -i "/uuid/d" /etc/vmware/esx.conf

 

設定後、ESXi VM をシャットダウンします。

クローン前に ESXi VM を起動した場合は、また /system/uuid を記載削除する必要があります。

 

また、VM テンプレートには、変換しても、しなくても大丈夫です。

 

2-4. ESXi VM のクローン。

ここまでに作成した VM「vm-esxi-template-01」から、3台の VM をクローンします。

  • PowerCLI は、vCenter に接続した状態で 物理マシン ESXi「192.168.1.20」上の VM をクローン。
  • 仮想マシン名は「vm-esxi-XX」とする。

PowerCLI> 1..3 | % {New-VM -VMHost 192.168.1.20 -StorageFormat Thin -VM "vm-esxi-template-01" -Name ("vm-esxi-" + $_.toString("00"))}

 

vSAN Disk として利用する VMDK を追加します。

今回は Cache 用に 20GB x 1、Capacity 用に 50GB x 2 を 各 ESXi に用意します。

PowerCLI> Get-VM vm-esxi-?? | New-HardDisk -SizeGB 20 -StorageFormat Thin

PowerCLI> Get-VM vm-esxi-?? | New-HardDisk -SizeGB 50 -StorageFormat Thin

PowerCLI> Get-VM vm-esxi-?? | New-HardDisk -SizeGB 50 -StorageFormat Thin

 

VMDK は下記のように作成されます。

PowerCLI> Get-VM vm-esxi-?? | Get-HardDisk | select CapacityGB,Parent,Name | Sort-Object Parent,Name

 

CapacityGB Parent     Name

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

        16 vm-esxi-01 Hard disk 1

        20 vm-esxi-01 Hard disk 2

        50 vm-esxi-01 Hard disk 3

        50 vm-esxi-01 Hard disk 4

        16 vm-esxi-02 Hard disk 1

        20 vm-esxi-02 Hard disk 2

        50 vm-esxi-02 Hard disk 3

        50 vm-esxi-02 Hard disk 4

        16 vm-esxi-03 Hard disk 1

        20 vm-esxi-03 Hard disk 2

        50 vm-esxi-03 Hard disk 3

        50 vm-esxi-03 Hard disk 4

 

 

ESXi VM をまとめてパワーオンします。

PowerCLI> Get-VM vm-esxi-?? | Start-VM

 

このあとの工程に備えて、ネステッド ESXi の VMware Tools が起動したことを確認しておきます。

PowerCLI> Get-VM vm-esxi-?? | select Name,PowerState,@{N="ToolsStatus";E={$_.Guest.ExtensionData.ToolsStatus}}

 

Name       PowerState ToolsStatus

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

vm-esxi-03  PoweredOn     toolsOk

vm-esxi-02  PoweredOn     toolsOk

vm-esxi-01  PoweredOn     toolsOk

 

 

2-5. ネステッド ESXi の設定。

ネステッド ESXi が起動したら、普通の ESXi と同様に

vCenter から登録する準備としてネットワーク設定をします。

これは VM コンソール経由で DCUI や esxcli などで設定できます。

 

しかし、ESXi には標準で VMware Tools がインストールされており、

VM にインストールした場合は、vCenter 経由で(ゲスト OS としての)ESXiのコマンドが実行できます。

そして、それを PowerCLI 経由で実行することもできます。

 

そこで、下記の投稿にある PowerCLI のサンプルスクリプトを利用して、

3台の ESXi VM それぞれにむけて esxcli によるネットワーク設定をします。

PowerCLI から Nested ESXi の esxcli を実行してみる。(GuestProcessManager)

 

1台目。

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 system hostname set --host esxi-01 --domain go-lab.jp

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.31 --netmask=255.255.255.0 --gateway=192.168.1.1

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 network ip dns server add --server=192.168.1.101

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 network ip dns server add --server=192.168.1.102

 

2台目。

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 system hostname set --host esxi-02 --domain go-lab.jp

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.32 --netmask=255.255.255.0 --gateway=192.168.1.1

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 network ip dns server add --server=192.168.1.101

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 network ip dns server add --server=192.168.1.102

 

3台目。

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 system hostname set --host esxi-03 --domain go-lab.jp

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.33 --netmask=255.255.255.0 --gateway=192.168.1.1

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 network ip dns server add --server=192.168.1.101

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 network ip dns server add --server=192.168.1.102

 

 

これで、ネステッド ESXi が 3台作成された状態になります。

あとは、vSAN クラスタのセットアップです。

 

つづく・・・

ネステッド vSAN ラボを構築するための工夫 Part.3。(vSAN クラスタ構築)

前回はネステッド vSAN のイメージ(下記)を紹介したので、

今回はセットアップ手順での工夫についての紹介です。

図解 ネステッド vSAN ラボ。

 

一般的には、ESXi の Host Client や vSphere Client / vSphere Web Client といった

GUI のツールを利用することが多いと思います。

しかし、検証環境は様々なバージョン / 構成でセットアップすることが多いはずなので、

ここでは、パラメータ記録や自動化をしやすいように PowerCLI などを積極的に利用します。

 

最初にネステッド vSAN 環境のベースとなる 物理マシンの ESXi と、vCenter Server を用意します。

1box-vsan-11a.png

 

1-1. 物理マシンへの ESXi のインストール。

物理マシンへの ESXi のインストールは、通常どおり ISO イメージから作成した CD ブートです。

マシンの管理ボードなどから ISO ファイルをマウントできる場合は、ISO イメージそのものから、

PXE サーバを用意している場合は、Kickstart でインストールすることができます。

 

一般的には、インストール方法にかかわらず ISO イメージでインストールしたうえで

オフラインバンドル(zip ファイル)のパッチを適用することになります。

今回は ESXi 6.7 U1 の ISO を利用していて、その後のパッチは(まだないので)適用していませんが、

あらかじめ下記のようにオフラインバンドルファイルから

ISO イメージファイルを作成しておくと、インストール直後にパッチ適用された状態になるので便利です。

ESXi のオフライン バンドルから ISO イメージ ファイルを作成してみる。

 

1-2. 物理マシンの設定。

今回、ESXi インストール直後に、下記の ESXi 設定変更のみ実施しておきます。

  • ネットワーク設定。(IP アドレス、サブネットマスク、デフォルトゲートウェイ)
  • 時刻あわせ。NTP を設定して確実に時刻同期をするか、Host Client や esxcli などで手動で設定変更します。
    • ESXi の都合上、UTC(JST マイナス9時間)で設定します。
      これは、VCSA のデプロイ時に時間がずれていると失敗してしまうためです。

 

データストア名や仮想スイッチ / ポートグループの構成は、

この時点ではデフォルトのままです。

これらの設定変更は、この ESXi を vCenter 管理下にしたあとで実施します。

 

1-3. VCSA のデプロイ。

vCenter Server Appliance(VCSA)をデプロイします。

VCSA は、何度もデプロイするような場合は vcsa-deploy による CLI インストール(下記のような)がおすすめです。

VCSA 6.7 を CLI デプロイしてみる。(embedded-PSC x2 の Enhanced Linked Mode)

 

vcsa-deploy コマンドのオプションと、インストールで利用する JSON ファイルは、

VCSA 6.7 以前 / 以降 のバージョンでパラメータが異なります。

ちなみに VCSA 6.5 形式の JSON ファイルは、VCSA 6.7 でも利用できました。

 

本番環境での VCSA のデプロイは、FQDN でのホスト名指定が事実上必須ですが、

ラボのとりまわしをよくするためにホスト名のかわりに IP アドレスを指定して

デプロイすることもあります。(DNS サーバへの vCenter アドレス登録を省略できるので)

 

ちなみに複数、同名の VCSA をデプロイすると、証明書のエラーにより

Chrome などのブラウザで vSphere Web Client / vSphere Client が

表示できなくなることがあります。

その場合は、以前の投稿にも記載しましたが・・・

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

下記の要領で解消できることもあります。

ちなみに、何度も同じ名前で vCenter をデプロイしていると Chrome / Microsoft Edge で

証明書のエラーになり HTML5 Client / vSphere Web Client にアクセスできなくなることがありますが、

その場合はデプロイした VCSA の CA 証明書を(Firefox などアクセスできるブラウザで何とかダウンロードして)

インストールするとアクセス可能になります。

※その場合、証明書は「https://vCenterのアドレス/certs/download.zip」からダウンロードできます。

 

1-4. VCSA への物理マシン ESXi の登録。

デプロイした vCenter のインベントリにクラスタを作成して、物理マシンの ESXi を登録します。

せっかくなので PowerCLI 11 を利用します。

 

まず、PowerCLI で ESXi に接続します。

今回の vCenter のアドレスは「192.168.1.30」です。

管理ユーザなどのパスワードは、あえてデモ用としてよく知られているものを利用しています。

vCenter の SSL 証明書を入れ替えていないので、エラー回避のため「-Force」が必要です。

PowerCLI> Connect-VIServer 192.168.1.30 -User administrator@vsphere.local -Password VMware1! -Force

 

vCenter インベントリに、データセンター「LAB-DC」を作成します。

PowerCLI> Get-Folder -Type Datacenter | New-Datacenter LAB-DC

 

物理マシン ESXi を登録するクラスタ「MGMT-Cluster」を作成します。

ここではクラスタは必須ではないですが、せっかくなのでそれっぽく作成しています。

PowerCLI> Get-Datacenter LAB-DC | New-Cluster MGMT-Cluster

 

クラスタ「MGMT-Cluster」に、物理マシン ESXi「192.168.1.20」を登録します。

ここでも SSL エラー回避のため「-Force」が必要です。

PowerCLI> Get-Cluster MGMT-Cluster | Add-VMHost -Name 192.168.1.20 -User root -Password VMware1! -Force

 

次は vCenter からの操作で、物理マシン ESXi のうえに

ネステッド ハイパーバイザむけの ESXi と VM の準備をします。

 

つづく。

ネステッド vSAN ラボを構築するための工夫 Part.2。(物理マシン ESXi と ESXi VM の準備)

vSAN の機能検証などで、ネステッド ハイパーバイザ環境を利用することがあります。

そこで、1台の物理マシンに vSAN 環境をセットアップした様子を紹介します。

 

今回の環境構築の方針。

今回は、下記のような vSAN 環境をセットアップします。

  • 物理マシンは 1台のみ利用する。
  • スペックは下記。
    • CPU: 4コア / 8スレッド(ただし 8スレッド必須というわけではない)
    • メモリ: 32GB
    • ディスク: 500GB SSD x 1つだけ
    • NIC: 1Gbps を 1ポートだけ
  • ネステッド ハイパーバイザ環境のベースになる物理サーバの ESXi も、vCenter に登録する。
    • これは、vCenter に登録したほうが ESXi / VM の管理をしやすいため。
  • vCenter は vSAN クラスタ(vSAN データストア)の外に配置する。
    • vCenter を vSAN データストア上に配置することもできるが、
      まず vSAN そのものを勉強するためには vSAN 外にある方がよいと思うので。
  • vCenter Server 6.7 U1 / ESXi 6.7 U1
    • せっかくなので最新版を利用する。

nest-vsan-01.png

 

物理マシン ESXi / ネステッド ESXi の関係。

この環境では、物理マシンの ESXi 上の VM に ESXi をインストールしています。

前スクリーンショットの vCenter インベントリでのネステッド ESXi(Nest-ESXi)と

VM の関係を図示すると、下記のようになります。

  • 物理マシン ESXi には、下記を配置します。
    • vCenter(仮想アプライアンスである VCSA を利用)
    • ESXi をインストールする VM(ESXi VM)3台
    • ESXi VM のテンプレート
  • 物理マシン ESXi に配置している VM へのリソース割り当ては下記にしました。
    • vCenter: VCSA の「極小」(Tiny)スペック。vCPU: 2、メモリ: 10GB
    • ESXi VM: vCPU: 2、メモリ: 6GB、VMDK: 16GB。(これを 3VM作成)
  • 物理マシン ESXi 1台は MGMT-Cluster に登録します。
    • Nest-ESXi の実体となる ESXi VM は、こちらのクラスタで見えます。
  • Nest-ESXi のインストールは、だいたい下記のいずれかになるはずです。
    • 物理 ESXi のデータストアに格納した ISO ファイルを、
      ESXi VM の仮想 CD/DVD ドライブに接続してインストール。
    • PXE Boot によるネットワーク経由での Kickstart インストール。
  • 物理マシン ESXi 側でインストールした Nest-ESXi 3台は、vSAN-Cluster に登録します。

1box-vsan-01.png

ESXi VM はそれぞれ ESXi をインストールするか、

あらかじめ ESXi をインストールした VM をテンプレート(クローン元 VM)を利用します。

今回の ESXi VM では、下記のような設定をします。

  • ゲスト OS の種類は「ESXi 6.5 以降」を選択。
  • CPU で「ハードウェア アシストによる仮想化をゲスト OS に公開」のチェックを入れる。
  • 起動オプション → ファームウェアは BIOS にする。

nest-vsan-04.png

 

ストレージ(データストア / VMDK)の関係。

Nest-ESXi のローカルディスクで vSAN データストアを構成しますが、

その実体は、ESXi VM に接続された VMDK ファイルです。

(下図では Nest-ESXi が1台ですが、実際は 3台で vSAN データストアを構成します)

 

Nest-ESXi で vSAN 構成後にそのうえで VM (図の Nest-VM)を作成すると、

当然ながら、その VMDK もネストされることになります。

1box-vsan-03.png

ネットワーク(vSwitch / ポートグループ / vNIC)の関係。

Nest-ESXi 上で VM(Nest-VM)を作成した場合、Nest-VM の vNIC では、

自身のものとは異なる MAC アドレス / VLAN の通信が発生します。

 

デフォルトの状態ではそのような通信ができないため、
物理マシン ESXi 側で、下記の設定をします。

  • Nest-ESXi を接続するポートグループを追加します。
    • 今回は Nested-Trunk-Network という名前で作成。
    • シンプルに、標準仮想スイッチ(vSS)の、標準ポートグループで作成。
  • 作成したポートグループで、無差別モードを許可する。
    • これで 自身の MAC アドレス以外の通信も受け取るようになる。
    • MAC アドレス変更 / 偽装転送 は、標準ポートグループでは許可されているので、そのまま。
  • 作成したポートグループで、VLAN ID 4095 を設定する。
    • これで 物理 ESXi のポートグループで VLAN ID を付与したまま通すようになり、
      Nest-ESXi 側のポートグループで VLAN ID を付与できるようになります。

 

Nest-ESXi 側では、とくにネストしていることを意識することなく

ネットワークを構成します。

vSAN では VMkernel(vmk)ポートで vSAN トラフィックを有効にする必要がありますが、
これは Nest-ESXi 側だけで設定します。

1box-vsan-04.png

物理 ESXi で作成したポートグループに、すべての ESXi VM の vNIC を接続します。

nest-vsan-03.png

 

作成したポートグループでは、下記のように

無差別モードを有効化、VLAN ID 4095 を設定しています。

nest-vsan-02.png

 

環境構築自体は、ネストであるかどうかにかかわらず、

一般的な vSphere Client(旧 HTML5 Client)や vSphere Web Client での操作となります。

また、ラボを頻繁に構築するようであれば PowerCLI などによる自動化もできます。

 

構築 Tips につづく・・・

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

VMSA-2018-0025 にて、 VM の 3D サポート機能にかかわる

セキュリティ脆弱性が公表されました。

 

よい機会なので、PowerCLI で VM の設定状況を確認してみます。

ただし、この「3D サポートを有効化」はデフォルトでは無効になっています。

そこで今回の環境では意図的に有効にしています。

 

まず、今回は 10台の VM を用意しました。

PowerCLI> Get-VM | Sort-Object Name

 

 

Name                 PowerState Num CPUs MemoryGB

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

test-vm-001          PoweredOn  1        4.000

test-vm-002          PoweredOn  1        4.000

test-vm-003          PoweredOn  1        4.000

test-vm-004          PoweredOn  1        4.000

test-vm-005          PoweredOn  1        4.000

test-vm-006          PoweredOn  1        4.000

test-vm-007          PoweredOn  1        4.000

test-vm-008          PoweredOn  1        4.000

test-vm-009          PoweredOn  1        4.000

test-vm-010          PoweredOn  1        4.000

 

 

このうち1台の VM の設定を確認してみます。

対象の仮想デバイスの設定を確認する専用コマンドが見つけられなかったので、

とりあえず VM「test-vm-010」の ExtensionData からデバイスの情報を探ると

Key = 500 が Video Card だとわかるので、その情報を見てみます。

PowerCLI> $vm = Get-VM test-vm-010

PowerCLI> $vm.ExtensionData.Config.Hardware.Device | select Key,{$_.DeviceInfo.Label}

 

  Key $_.DeviceInfo.Label

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

  200 IDE 0

  201 IDE 1

  300 PS2 controller 0

  100 PCI controller 0

  400 SIO controller 0

  600 Keyboard

  700 Pointing device

  500 Video card

12000 VMCI device

1000 SCSI controller 0

15000 SATA controller 0

16000 CD/DVD drive 1

2000 Hard disk 1

4000 Network adapter 1

 

 

この VM の Video Card は、Enable3DSupport が True になっていることがわかりました。

PowerCLI> $vm.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}

 

VideoRamSizeInKB       : 16384

NumDisplays            : 1

UseAutoDetect          : False

Enable3DSupport        : True

Use3dRenderer          : automatic

GraphicsMemorySizeInKB : 262144

Key                    : 500

DeviceInfo             : VMware.Vim.Description

Backing                :

Connectable            :

SlotInfo               :

ControllerKey          : 100

UnitNumber             : 0

 

 

Enable3DSupport は、下記のように確認することもできます。

PowerCLI> ($vm.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport

True

PowerCLI> Get-VM test-vm-010 | %{($_.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport}

True

 

まとめて複数の仮想マシンの情報を確認することもできます。

PowerCLI> Get-VM | select Name,@{N="Enable3DSupport";E={($_.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport}} | Sort-Object Name

 

 

Name        Enable3DSupport

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

test-vm-001           False

test-vm-002           False

test-vm-003           False

test-vm-004            True

test-vm-005            True

test-vm-006           False

test-vm-007            True

test-vm-008            True

test-vm-009            True

test-vm-010            True

 

 

下記のように、Enable3DSupport  = True の VM だけ抽出することもできます。

PowerCLI> Get-VM | select Name,@{N="Enable3DSupport";E={($_.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport}} | where {$_.Enable3DSupport -eq "True"} | Sort-Object Name

 

 

Name        Enable3DSupport

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

test-vm-004            True

test-vm-005            True

test-vm-007            True

test-vm-008            True

test-vm-009            True

test-vm-010            True

 

 

また、今回の設定のように .vmx パラメータの設定によるものであれば、

シンプルに Get-AdvancedSetting で確認できるケースもあります。

PowerCLI> Get-VM | Get-AdvancedSetting -Name mks.enable3d | select Entity,Value | Sort-Object Entity

 

Entity      Value

------      -----

test-vm-004 TRUE

test-vm-005 TRUE

test-vm-007 TRUE

test-vm-008 TRUE

test-vm-009 TRUE

test-vm-010 TRUE

 

 

このように、PowerCLI を利用することで、簡単に、大量 VM の設定確認ができます。

 

ちなみに、今回の実行環境は Windows PowerShell + PowerCLI 11.0.0 です。

PowerCLI> Get-Host | select Version

 

Version

-------

5.1.17134.228

 

PowerCLI> Get-Module VMware.PowerCLI | select Version

 

Version

-------

11.0.0.10380590

 

 

以上、PowerCLI による VM 情報取得例でした。

VMware Photon OS 2.0 に PowerShell Core と PowerCLI Core をインストールしてみます。

Photon OS PowerCLI を利用したい場合は Docker コンテナを利用すると簡単ですが、

今回はあえて、Install-Module で PowerShell Gallery からインストールしています。

 

PowerCLI Core を Docker コンテナで利用するときは、

下記のような感じになります。

※vmware/powerclicore イメージには PowerCLI だけでなく PowerNSX も含まれています。

Docker コンテナの PowerNSX を実行してみる。

 

Photon OS 2.0 むけ RPM の PowerShell には PowerShellGet がインストールされていないので、

PowerCLI の前に PowerShellGet とその関連モジュールをインストールします。

 

手順は、vmware/powerclicore Docker イメージのもとになる

Dockerfile を参考にしました。

powerclicore/Dockerfile at master · vmware/powerclicore · GitHub

 

インストール対象の Photon OS は、VMware GitHub からダウンロードできる

OVA ファイルのものをデプロイしています。

 

Photon OS 2.0 GA Binaries

OVA with virtual hardware v13 (ESX 6.5 and above)

Downloading Photon OS · vmware/photon Wiki · GitHub

 

今回の Photon OS です。

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

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

PowerShell Core のインストール。

Photon OS の パブリックな Yum リポジトリから、

PowerShell Core と unzip をインストールします。

root@photon-machine [ ~ ]# tdnf install -y powershell unzip

root@photon-machine [ ~ ]# rpm -q powershell

powershell-6.0.1-1.ph2.x86_64

 

PowerShellGet のインストール。

PowerShellGet 関連のモジュールを、ファイル配置することでインストールします。

 

PackageManagement

root@photon-machine [ ~ ]# curl -LO https://www.powershellgallery.com/api/v2/package/PackageManagement

root@photon-machine [ ~ ]# unzip PackageManagement -d /usr/lib/powershell/Modules/PackageManagement

root@photon-machine [ ~ ]# rm PackageManagement

 

PowerShellGet

root@photon-machine [ ~ ]# curl -LO https://www.powershellgallery.com/api/v2/package/PowerShellGet

root@photon-machine [ ~ ]# unzip PowerShellGet -d /usr/lib/powershell/Modules/PowerShellGet

root@photon-machine [ ~ ]# rm PowerShellGet

 

問題対策。

Add-Type の問題対策を設定しておきます。

PowerShell on Photon: Cannot add PowerShell Type · Issue #752 · vmware/photon · GitHub

root@photon-machine [ ~ ]#  mkdir -p /usr/lib/powershell/ref/

root@photon-machine [ ~ ]#  ln -s /usr/lib/powershell/*.dll /usr/lib/powershell/ref/

 

PowerCLI Core のインストール。

PowerShell Core(pwsh)を対話モードで起動します。

root@photon-machine [ ~ ]# pwsh -v

PowerShell v6.0.1

root@photon-machine [ ~ ]# pwsh -NoLogo

PS /root>

 

PowerShell Gallery から PowerCLI Core をインストールします。

PS /root> Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

PS /root> Install-Module VMware.PowerCLI

 

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

PS /root> Get-Module VMware.PowerCLI -ListAvailable | select Version,Name

 

Version        Name

-------        ----

10.2.0.9372002 VMware.PowerCLI

 

 

vCenter にも接続できます。

※証明書エラー回避のため「-Force」をつけています。

PS /root> Connect-VIServer infra-vc-01.go-lab.jp -Force

 

Specify Credential

Please specify server credential

User: gowatana

Password for user gowatana: ***********

 

Name                           Port  User

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

infra-vc-01.go-lab.jp          443   GO-LAB\gowatana

 

 

PS /root> Get-VMHost | select Name,Version,Build,ConnectionState | Sort-Object Name

 

Name                    Version Build   ConnectionState

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

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

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

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

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

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

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

 

 

PowerCLI にかぎらず、ほかの PowerShell モジュールも同様にインストールできるはずです。

 

以上、Photon OS 2.0 に PowerCLI Core をインストールしてみる話でした。

前回、Kubernetes Anywhere で Photon OS による Kubernetes クラスタを構築してみました。

vSphere に Kubernetes クラスタを構築してみる。(Kubernetes Anywhere)

 

今回は、Photon OS から Kubernetes のクライアントである kubectl を実行してみます。

kubectl のインストール先は、前回デプロイした OVA 版の Photon OS 2.0 です。

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

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

ファイルのダウンロードによるインストール。

まず、わりと一般的かと思われる curl コマンドでのダウンロードによるインストール方法です。

前回に構築した Kubernetes クラスタにあわせて v1.9.7 のものをダウンロードしています。

root@photon-machine [ ~ ]# curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.9.7/bin/linux/amd64/kubectl

root@photon-machine [ ~ ]# chmod +x kubectl

root@photon-machine [ ~ ]# mv kubectl /usr/local/bin/kubectl

 

kubectl のバージョンは v1.9.7 です。

※下記の例では、すでに Kubernetes クラスタのコンフィグを読み込んでいます。

root@photon-machine [ ~ ]# which kubectl

/usr/local/bin/kubectl

root@photon-machine [ ~ ]# kubectl version

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

 

Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-18T23:58:35Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

 

RPM でのインストール。

Photon OS の YUM リポジトリには kubectl の RPM が用意されています。

root@photon-machine [ ~ ]# tdnf list kubernetes-kubectl-extras

kubernetes-kubectl-extras.x86_64            1.11.1-2.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-10.ph2       photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-11.ph2       photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-3.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-4.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-5.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-6.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-7.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-8.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-9.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.11.1-1.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.11.1-2.ph2        photon-updates

 

tdnf でインストールします。

root@photon-machine [ ~ ]# tdnf install -y kubernetes-kubectl-extras

root@photon-machine [ ~ ]# rpm -q kubernetes-kubectl-extras

kubernetes-kubectl-extras-1.11.1-2.ph2.x86_64

 

kubernetes-kubectl-extras には、kubectl のみが含まれています。

Linux OS なので、/opt/vmware/kubernetes/linux/amd64/kubectl だけを使用します。

root@photon-machine [ ~ ]# rpm -ql kubernetes-kubectl-extras

/opt/vmware/kubernetes/darwin/amd64/kubectl

/opt/vmware/kubernetes/linux/amd64/kubectl

/opt/vmware/kubernetes/windows/amd64/kubectl.exe

 

ファイルが配置されているディレクトリに Linux コマンドのサーチパスが設定されていないので、

フルパスで実行するか、下記のように PATH 環境変数を設定することになります。

root@photon-machine [ ~ ]# export PATH=/opt/vmware/kubernetes/linux/amd64:$PATH

root@photon-machine [ ~ ]# which kubectl

/opt/vmware/kubernetes/linux/amd64/kubectl

root@photon-machine [ ~ ]# kubectl version

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"archive", BuildDate:"2018-08-14T19:36:17Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

 

Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-18T23:58:35Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

 

kubectl での Kubernetes へのアクセス。

Kubernetes に接続するためのコンフィグファイルは、

前回の投稿で  Docker ホスト(今回 kubectl を実行する Linux)に退避したものを使用します。

下記のように退避したので、kubectl を実行する Linux には $HOME/tmp/kubeconfig.json ファイルとして保存されています。

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

 

kubectl が読み込むディレクトリ(ホームディレクトリの .kube/ 直下)にファイルをコピーします。

root@photon-machine [ ~ ]# mkdir ~/.kube

root@photon-machine [ ~ ]# cp ./tmp/kubeconfig.json ~/.kube/config

 

kubectl でクラスタにアクセスできるようになります。

root@photon-machine [ ~ ]# kubectl get nodes

NAME                STATUS                     ROLES     AGE       VERSION

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

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

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

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

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

root@photon-machine [ ~ ]# 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'.

 

RPM は用意されていますが、1ファイルのパッケージでファイルの配置ディレクトリも微妙なので、

Photon OS の RPM 使用するか、ダウンロードしたものを使用するかは

使用したい kubectl のバージョンによって選択すればよいかなと思います。

 

以上、Photon OS で kubectl を実行してみる話でした。

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 クラスタのデプロイは、下記のようなイメージです。

K8s-Anywhere-on-vSphere_deploy-image.png

 

1. 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 はデプロイ後にパワーオンしないようにしておきます。

 

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

 

3. 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 をデプロイしてみる話でした。

 

続きはこちら。

VMware Photon OS 2.0 から Kubernetes の kubectl を実行してみる。

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 利用例でした。