Skip navigation
2018

PowerCLI を利用して、vSAN 6.7 の Witness Appliance をデプロイしてみます。

 

今回の環境。

vSAN Witness Appliance をデプロイする vCenter と、

登録する(vSAN クラスタを構成する)vCenter は別にしています。

 

vSAN Witness Appliance のデプロイ。

まず vCenter に接続します。

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp

 

今回は、vSAN 6.7 の Witness Appliance の ova ファイル

(VMware-VirtualSAN-Witness-6.7.0-8169922.ova)をデプロイします。

PowerCLI> $ovf_config = Get-OvfConfiguration -Ovf E:\VMware\VMware-VirtualSAN-Witness-6.7.0-8169922.ova

 

入力するパラメータは、下記のような感じです。

PowerCLI> $ovf_config

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

OvfConfiguration: VMware-VirtualSAN-Witness-6.7.0-8169922.ova

 

   Properties:

   -----------

   DeploymentOption

   NetworkMapping

   vsan

 

 

PowerCLI> $ovf_config.DeploymentOption

 

 

Key                : DeploymentOption

Value              :

DefaultValue       : normal

OvfTypeDescription : string["tiny", "normal", "large"]

Description        : Tiny (10 VMs or fewer)

                     Configuration for Tiny vSAN Deployments with 10 VMs or fewer

 

                     * 2 vCPUs

                     * 8GB vRAM

                     * 1x 12GB ESXi Boot Disk

                     * 1x 15GB Magnetic Disk

                     * 1x 10GB Solid-State Disk

                     * Maximum of 750 Witness Components

 

                     Medium (up to 500 VMs)

                     Configuration for Medium vSAN Deployments of up to 500 VMs

 

                     * 2 vCPUs

                     * 16GB vRAM

                     * 1x 12GB ESXi Boot Disk

                     * 1x 350GB Magnetic Disk

                     * 1x 10GB Solid-State Disk

                     * Maximum of 22K Witness Components

 

                     Large (more than 500 VMs)

                     Configuration for Large vSAN Deployments of more than 500 VMs

 

                     * 2 vCPUs

                     * 32GB vRAM

                     * 1x 12GB ESXi Boot Disk

                     * 3x 350GB Magnetic Disks

                     * 1x 10GB Solid-State Disk

                     * Maximum of 45K Witness Components

 

 

PowerCLI> $ovf_config.NetworkMapping | fl

 

 

Management_Network :

Witness_Network    :

 

 

PowerCLI> $ovf_config.vsan.witness.root.passwd

 

 

Key                : vsan.witness.root.passwd

Value              :

DefaultValue       :

OvfTypeDescription : password(7..)

Description        : Set password for root account.

 

                        A valid password must be at least 7 characters long and must contain a mix

                        of upper and lower case letters, digits, and other characters.  You can use

                        a 7 character long password with characters from at least 3 of these 4

                        classes.  An upper case letter that begins the password and a digit that

                        ends it do not count towards the number of character classes used.

 

 

パラメータを設定します。デプロイします。

今回は、直接接続の 2 ノード vSAN にする想定として、

vSAN Witness Appliance の Management / vSAN トラフィックは vmk0 ポートを併用します。

ここでは Management_Network / Witness_Network 両方に同じポートグループを指定していますが、

vmk1 を接続する vNIC は、後で切断状態にしてしまいます。

PowerCLI> $ovf_config.vsan.witness.root.passwd.Value = "パスワード"

PowerCLI> $ovf_config.NetworkMapping.Management_Network.Value = "dvpg-vds01-vlan-0000"

PowerCLI> $ovf_config.NetworkMapping.Witness_Network.Value = "dvpg-vds01-vlan-0000"

PowerCLI> $ovf_config.DeploymentOption.Value = "tiny"

 

Import-VApp でデプロイします。オプションは下記のようにしています。

  • VM 名: hv-n23w ※Nested ESX の VM。
  • デプロイ先の ESXi: hv-i21.go-lab.jp
  • デプロイ先データストアも vSAN ※ただし今回の vSAN とは別。
  • デプロイ先のフォルダ: test

PowerCLI> Import-VApp -Name hv-n23w -OvfConfiguration $ovf_config -Source $ovf_config.Source -VMHost hv-i21.go-lab.jp -Datastore vsanDatastore-01 -StorageFormat Thin -InventoryLocation (Get-Folder -Type VM test)

 

今回は2つ目の vNIC を使用しないので、切断状態にしておきます。

PowerCLI> Get-VM hv-n23w | Get-NetworkAdapter -Name "Network adapter 2" | Set-NetworkAdapter -StartConnected:$false -Confirm:$false

 

VM を起動します。

PowerCLI> Get-VM hv-n23w | Start-VM

 

ゲスト OS の ESXi が起動するまで待ちます。

PowerCLI> Get-VM hv-n23w | Get-VMGuest | ft -AutoSize State,OSFullName,IPAddress

 

  State OSFullName      IPAddress

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

Running VMware ESXi 6.5 {192.168.1.42, fe80::250:56ff:fe8a:1896, 2400:4030:8c62:5400:250:56ff:fe8a:1896, fe80::250:5...

 

 

vSAN Witness Appliance のネットワーク設定。

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

通常は vSAN Witness Appliance の VM コンソールを開いて DCUI から設定しますが、

ここでは、前回の投稿でのスクリプトを利用して設定してみます。

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

 

vCenter に接続していない場合は、あらかじめ接続した状態でスクリプトを実行します。

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp -Force

PowerCLI> .\invoke_nested-esxcli.ps1 system hostname set --host hv-n23w --domain go-lab.jp -ESXiVM:hv-n23w -ESXiUser:root -ESXiPass:パスワード

PowerCLI> .\invoke_nested-esxcli.ps1 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.217 --netmask=255.255.255.0 --gateway=192.168.1.1 -ESXiVM:hv-n23w -ESXiUser:root -ESXiPass:パスワード

 

少し待つと、VMware Tools から取得した情報でも設定が反映されたことが分かります。

PowerCLI> Get-VM hv-n23w | Get-VMGuest | fl HostName,IPAddress

 

HostName  : hv-n23w.go-lab.jp

IPAddress : {192.168.1.217, fe80::250:56ff:fe8a:1896, 2400:4030:8c62:5400:250:56ff:fe8a:1896, 169.254.80.14...}

 

 

疎通確認をしておきます。

PowerCLI> Test-Connection -Quiet 192.168.1.217

True

PowerCLI> ping 192.168.1.217

 

192.168.1.217 に ping を送信しています 32 バイトのデータ:

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

 

192.168.1.217 の ping 統計:

    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、

ラウンド トリップの概算時間 (ミリ秒):

    最小 = 0ms、最大 = 0ms、平均 = 0ms

PowerCLI>

 

いったん、PowerCLI をデプロイ先の vCenter から切断します。

PowerCLI> Disconnect-VIServer -Confirm:$false

 

vSAN Witness Appliance の vCenter 登録。

vSAN Witness Appliance を登録します。

 

vSAN クラスタをセットアップする予定の vCenter に接続します。

PowerCLI> Connect-VIServer vc-sv02.go-lab.jp -Force

 

vSAN Witness Appliance は、通常の ESXi と同様に vCenter に登録します。

vCenter インベントリのデータセンタ(dc02)は既に作成してあります。

ESXi の root ユーザ / デプロイ時に指定したパスワード でログインします。

PowerCLI> Get-Datacenter -Name dc02 | Add-VMHost -Name hv-n23w.go-lab.jp -Force

 

検証しやすいように、SSH を有効化 / サービス起動してしまいます。

PowerCLI> $hv = Get-VMHost hv-n23w.go-lab.jp

PowerCLI> $hv | Get-VMHostService | where {$_.key -eq "TSM-SSH"} | Set-VMHostService -Policy On -Confirm:$false

PowerCLI> $hv | Get-VMHostService | where {$_.key -eq "TSM-SSH"} | Start-VMHostService

 

DNS Server のアドレスを設定しておきます。

ここでは 192.168.1.254, 192.168.1.253 の 2台を参照するように設定しています。

PowerCLI> $hv | Get-VMHostNetwork | Set-VMHostNetwork -DnsAddress 192.168.1.254,192.168.1.253

 

vmk0 の vSAN タグを有効にしておきます。

PowerCLI> Get-VMHost hv-n23w.go-lab.jp | Get-VMHostNetworkAdapter -Name vmk0 | Set-VMHostNetworkAdapter -VsanTrafficEnabled:$true -Confirm:$false

 

vmk1 の IP アドレス、vSAN タグを無効化しておきます。

PowerCLI> Get-VMHost hv-n23w.go-lab.jp | Get-VMHostNetworkAdapter -Name vmk1 | Set-VMHostNetworkAdapter -IP 0.0.0.0 -SubnetMask 255.255.255.255 -VsanTrafficEnabled:$false -Confirm:$false

 

VMkernel ポートが設定変更されました。

PowerCLI> Get-VMHost hv-n23w.go-lab.jp | Get-VMHostNetworkAdapter -VMKernel | ft -AutoSize Name,PortGroupName,VsanTrafficEnabled,IP,SubnetMask

 

Name PortGroupName      VsanTrafficEnabled IP            SubnetMask

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

vmk0 Management Network               True 192.168.1.217 255.255.255.0

vmk1 witnessPg                       False

 

 

このあと vSAN クラスタをセットアップする際に、ここまでセットアップしてきた

vSAN Witness Appliance を vSAN 監視ホストとして指定します。

vSAN クラスタの設定でも PowerCLI を利用することができます。

PowerCLI で vSAN セットアップをためしてみる。(2 Node 版)

 

そして工夫次第で vSAN Witness Appliance ~ vSAN セットアップまで

PowerCLI スクリプトで自動化できたりします。

 

以上、PowerCLI で vSAN Witness Appliance をセットアップしてみる話でした。

ESXi 上の VM に ESXi をインストールする「Nested ESXi」と呼ばれる使用方法があり、

検証環境や、vSAN Witness Appliance などで利用されています。

Running Nested VMs

 

Nested ESXi は物理マシンへのインストールと同様に DCUI からの設定作業ができるため

通常は、VM コンソールから設定をすることになります。

nested-esxi-vm.png

 

しかし VM であり、しかも最近の ESXi 6.x ではデフォルトで VMware Tools がインストールされます。

そのため Nested ESXi では、ネットワーク設定前であっても

vSphere のレイヤから直接での設定投入ができます。

 

通常、PowerCLI からゲスト OS の設定を変更する場合は Invoke-VMScript を使用しますが、

ScriptType で指定できるインタープリタは PowerShell、Bat、Bash だけなので

ESXi ではスクリプト(コマンド)が実行できません。

 

Invoke-VMScript

https://code.vmware.com/doc/preview?id=6330#/doc/Invoke-VMScript.html

 

そこで、ためしに vSphere Web Services API の GuestOperationsManager にある

GuestProcessManager を利用して esxcli コマンドを実行してみました。

 

GuestProcessManager

https://code.vmware.com/apis/358/vsphere?h=GuestOperationsManager#/doc/vim.vm.guest.ProcessManager.html

 

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

エラー制御などは、あえて一切いれていないので、

実行してみる場合はお好みで改造していただければと・・・

invoke_nested-esxcli.ps1 · GitHub

 

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

param($ESXiVM, $ESXiUser, $ESXiPass)

 

# 最初に変数設定。

$vm_name = $ESXiVM

$esxi_user = $ESXiUser

$esxi_pass = $ESXiPass

$esxcli_args = $args

 

$vm = Get-VM $vm_name | select -First 1

$vm_id = $vm.Id

$vc_name = $vm.Uid  -replace "^.*@|:.*$",""

$vc = $global:DefaultVIServers | where {$_.Name -eq $vc_name}

 

"ESXi VM Name:" + $vm.Name

"esxcli args: " + $esxcli_args

 

# ESXi の認証情報をセット。

$cred = New-Object VMware.Vim.NamePasswordAuthentication

$cred.Username = $esxi_user

$cred.Password = $esxi_pass

 

# esxcli コマンドをフルパスで指定。

$gps = New-Object VMware.Vim.GuestProgramSpec

$gps.WorkingDirectory = "/tmp"

$gps.ProgramPath = "/bin/esxcli"

$gps.Arguments = $esxcli_args

 

# ここでコマンド実行。

$gom = Get-View $vc.ExtensionData.Content.GuestOperationsManager

$pm = Get-View $gom.ProcessManager

$gos_pid = $pm.StartProgramInGuest($vm_Id, $cred, $gps)

$pm.ListProcessesInGuest($vm_Id, $cred, $gos_pid)

 

実行するときには、まず Nested VM を管理している vCenter に接続しておきます。

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

 

このスクリプトでは、esxcli のオプションを通常どおり指定しやすいように工夫しています。

実行方法は、下記のような感じです。

PowerCLI> .\invoke_nested-esxcli.ps1 <esxcli option> -ESXiVM:<Nested ESXi VM Name> -ESXiUser:<Nested ESXi User Name> -ESXiPass:<Nested ESXi User password>

 

もしくは・・・

PowerCLI> .\invoke_nested-esxcli.ps1 -ESXiVM:<Nested ESXi VM Name> -ESXiUser:<Nested ESXi User Name> -ESXiPass:<Nested ESXi User password> <esxcli option>

 

たとえば「esxcli system hostname set --host ~ --domain ~」の実行は

下記のようになります。

PowerCLI> .\invoke_nested-esxcli.ps1 system hostname set --host hv-n23w --domain go-lab.jp -ESXiVM:hv-n23w -ESXiUser:root -ESXiPass:VMware1!

ESXi VM Name:hv-n23w

esxcli args: system hostname set --host hv-n23w --domain go-lab.jp

 

Name      : esxcli

Pid       : 2278253

Owner     : root

CmdLine   : "/bin/esxcli" system hostname set --host hv-n23w --domain go-lab.jp

StartTime : 2018/04/22 2:52:18

EndTime   :

ExitCode  :

 

 

これだとコマンドの出力結果は取得できないのですが、

Nested ESXi をネットワーク設定して vCenter に登録してしまえば

vCenter 経由で ESXi の設定確認ができるので、うちでは設定投入するだけの利用をしています。

 

ちなみに、今回の環境では下記でした。

  • 物理環境: vCenter 6.5 U1 / ESXi 6.5 U1
  • Nested ESXi: ESXi 6.7
  • PowerCLI 10.0.0 / PowerShell 5.1 / Windows 10

 

以上、PowerCLI から Nested ESXi の esxcli を実行してみる話でした。

vSAN 6.7 がリリースされ、とうとう vSAN も vSphere Client(通称 HTML5 Client)で操作可能になりました。

What’s New with VMware vSAN 6.7 - Virtual Blocks

 

そこで、さっそく HTML5 Client で 2 ノード の vSAN を構成してみました。

 

事前に下記の準備をしてあります。

 

vCenter 6.7 の HTML5 Client です。

vsan67-h5-2node-01.png

 

VMkernel ポートの vSAN Witness トラフィックのタグ(vSAN 監視)が設定されているか、

確認できるようになっています。(設定はまだ esxcli などになるようです)

vsan67-h5-2node-16.png

 

HTML5 Client での 2ノード vSAN の構成。

クラスタの「設定」→「vSAN」→「サービス」の

「構成」ボタンから vSAN を有効化できるようになっています。

vsan67-h5-2node-02.png

 

「2 台のホストの vSAN クラスタ」を選択します。

vsan67-h5-2node-03.png

 

デデュープ(重複排除)および圧縮、暗号化などは有効化せず、そのまま次へ。

vsan67-h5-2node-04.png

 

キャッシュ層、キャパシティ層のディスクを選択します。

vsan67-h5-2node-05.png

 

すでに vCenter に登録してある vSAN Witness Appliance を

監視ホストとして選択します。

vsan67-h5-2node-06.png

 

監視ホストでも、キャッシュ層、キャパシティ層のディスクを選択します。

vsan67-h5-2node-07.png

 

確認画面で「完了」して、タスクが完了するのを待ちます。

vsan67-h5-2node-08.png

 

構成した 2ノード vSAN の様子。

サポートされていないハードウェア(Nested ESXi)で構成しているのでエラーや警告が出ていますが・・・

「サマリー」タブに「vSAN の概要」が表示されています。

vsan67-h5-2node-09.png

 

「健全性」の確認も HTML5 Client でできるようになっています。

ためしに「ストレッチ クラスタ」の様子を見てみました。

vsan67-h5-2node-14.png

 

「設定」タブのメニューをいくつか見てみます。

vsan67-h5-2node-10.png

 

ディスクグループの様子です。

vsan67-h5-2node-11.png

 

フォルト ドメイン が 2つ構成されて、監視ホストが指定されている様子もわかります。

vsan67-h5-2node-12.png

 

ちゃんと 2 ノード vSAN でも HTML5 Client が利用できそうです。

 

以上、HTML5 Client から vSAN の  2 ノードクラスタを構成してみる話でした。

今回は vSphere Docker Volume Service(vDVS)を利用して、

vSAN データストアから Docker Volume を作成してみます。

 

Docker では基本的にコンテナを削除すると一緒にデータも削除されてしまいます。

しかし、Docker  Volume とよばれる仕組みを利用することで

コンテナの削除にかかわらずデータを永続化することができます。

 

そして vSphere 環境での Docker にその永続的なストレージ(Volume)を提供する

Project Hatchway というプロジェクトがあります。

Hatchway では Docker / Kubernetes などに、vSphere のデータストアの仮想ディスクを Volume として提供します。

Project Hatchway by VMware®

 

VMware の Storage Hub にもドキュメントがあります。

 

Introduction to Project Hatchway

https://storagehub.vmware.com/t/vsphere-storage/project-hatchway/

 

それでは vDVS をセットアップしてみます。

vDVS では、Docker ホストになる VM と ESXi との両方での対応が必要です。

  1. ESXi への VIB のインストール。
  2. Docker ホスト(ゲスト OS)への Docker Plugin のインストール。

 

今回の環境。

すでに vCenter 6.5 U1 / ESXi 6.5 U1 の環境を構築ずみです。

 

このクラスタの ESXi は、vSAN / NFS データストアを接続しています。

  • vSAN データストア: vsanDatastore-04
  • NFS データストア: ds-nfs-vmdk-01

vdvs-vsan-01.png

 

ESXi は 2台(hv-n41 / hv-n42)あり、それぞれ VM が1台ずつ(vm41 / vm42)起動しています

vdvs-vsan-02.png

 

今回の ESXi は、6.5 U1 です。

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

VMware ESXi 6.5.0 build-7388607

VMware ESXi 6.5.0 Update 1

 

Docker ホスト(ゲスト OS)は、Photon OS 2.0 にしました。

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

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@vm41 [ ~ ]# uname -r

4.9.90-1.ph2-esx

 

今回の Docker バージョンは 17.06 です。

root@vm41 [ ~ ]# docker version

Client:

Version:      17.06.0-ce

API version:  1.30

Go version:   go1.8.1

Git commit:   02c1d87

Built:        Thu Oct 26 06:33:23 2017

OS/Arch:      linux/amd64

 

Server:

Version:      17.06.0-ce

API version:  1.30 (minimum version 1.12)

Go version:   go1.8.1

Git commit:   02c1d87

Built:        Thu Oct 26 06:34:46 2017

OS/Arch:      linux/amd64

Experimental: false

 

ESXi への VIB のインストール。

ESXi ホストそれぞれ(今回は 2台)で、VIB をインストールします。

 

vDVS の VIB は、Bintray からダウンロードできます。

最新版は下記の URL から入手できます。

https://bintray.com/vmware/vDVS/VIB/_latestVersion

 

今回は、Version 0.21.1 を利用します。

https://bintray.com/vmware/vDVS/VIB/0.21.1

https://bintray.com/vmware/vDVS/download_file?file_path=VDVS_driver-0.21.1-offline_bundle-7812185.zip

 

VIB のオフラインバンドルは、vSAN データストアに配置しました。

vSAN データストアに osfs-mkdir コマンドでディレクトリを作成して・・・

[root@hv-n41:~] /usr/lib/vmware/osfs/bin/osfs-mkdir /vmfs/volumes/vsanDatastore-04/vib

 

VIB のオフラインバンドル「VDVS_driver-0.21.1-offline_bundle-7812185.zip」を配置してあります。

VIB の名前は「esx-vmdkops-service」になっています。

[root@hv-n41:~] ls /vmfs/volumes/vsanDatastore-04/vib

VDVS_driver-0.21.1-offline_bundle-7812185.zip

[root@hv-n41:~] esxcli software sources vib list -d /vmfs/volumes/vsanDatastore-04/vib/VDVS_driver-0.21.1-offline_bundle-7812185.zip

Name                 Version             Vendor  Creation Date  Acceptance Level  Status

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

esx-vmdkops-service  0.21.c420818-0.0.1  VMWare  2018-02-13     VMwareAccepted    New

 

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

[root@hv-n41:~] esxcli software vib install -d /vmfs/volumes/vsanDatastore-04/vib/VDVS_driver-0.21.1-offline_bundle-7812185.zip

Installation Result

   Message: Operation finished successfully.

   Reboot Required: false

   VIBs Installed: VMWare_bootbank_esx-vmdkops-service_0.21.c420818-0.0.1

   VIBs Removed:

   VIBs Skipped:

 

インストールした VIB の情報です。

[root@hv-n41:~] esxcli software vib get -n esx-vmdkops-service

VMWare_bootbank_esx-vmdkops-service_0.21.c420818-0.0.1

   Name: esx-vmdkops-service

   Version: 0.21.c420818-0.0.1

   Type: bootbank

   Vendor: VMWare

   Acceptance Level: VMwareAccepted

   Summary: [Fling] ESX-side daemon supporting basic VMDK operations requested by a guest

   Description: Executes VMDK operations requested by an in-the-guest application.

   ReferenceURLs:

   Creation Date: 2018-02-13

   Depends: esx-version >= 6.0.0

   Conflicts:

   Replaces:

   Provides:

   Maintenance Mode Required: False

   Hardware Platforms Required:

   Live Install Allowed: True

   Live Remove Allowed: True

   Stateless Ready: False

   Overlay: False

   Tags:

   Payloads: vmdkops

 

hostd を再起動しておきます。

[root@hv-n41:~] /etc/init.d/hostd restart

watchdog-hostd: Terminating watchdog process with PID 67445

hostd stopped.

hostd started.

 

Docker ホスト(ゲスト OS)への Docker Plugin のインストール。

Dcoker ホストそれぞれ(今回は 2台)に、Docker Plugin をインストールします。

 

はじめは、Docker Plugin が登録されていない状態です。

root@vm41 [ ~ ]# docker plugin ls

ID                  NAME                DESCRIPTION         ENABLED

root@vm41 [ ~ ]#

 

Docker Plugin は、Docker Store からインストールします。

root@vm41 [ ~ ]# docker plugin install --grant-all-permissions --alias vsphere vmware/vsphere-storage-for-docker:latest

latest: Pulling from vmware/vsphere-storage-for-docker

05da47b7b6ce: Download complete

Digest: sha256:a20bcdfef99ebf017bf3cabd815f256430bf56d8cb7881048150e7c918e0c4c6

Status: Downloaded newer image for vmware/vsphere-storage-for-docker:latest

Installed plugin vmware/vsphere-storage-for-docker:latest

 

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

root@vm41 [ ~ ]# docker plugin ls

ID                  NAME                DESCRIPTION                           ENABLED

5bb66ae50bbd        vsphere:latest      VMWare vSphere Docker Volume plugin   true

 

設定ファイルを作成しておきます。

内容は主にログ出力設定ですが、このファイルがなくてもとりあえず vDVS はログ出力します。

cat << EOF > /etc/vsphere-storage-for-docker.conf

{

    "Driver": "vsphere",

    "MaxLogAgeDays": 28,

    "MaxLogFiles": 10,

    "MaxLogSizeMb": 10,

    "LogPath": "/var/log/vsphere-storage-for-docker.log",

    "LogLevel": "info",

    "GroupID": "root"

}

EOF

 

Volume を利用してみる。

1台目の Docker ホスト「vm41」で、Docker Volume を作成してみます。

 

docker volume create コマンドで vsphere ドライバを指定して、ボリュームを作成します。

今回の環境では vSAN と NFS のデータストアがありますが、特にデータストアを作成しない場合は

vSAN データストアにボリュームが作成されました。

root@vm41 [ ~ ]# docker volume create --driver=vsphere --name=vol01 -o size=1gb

vol01

root@vm41 [ ~ ]# docker volume ls

DRIVER              VOLUME NAME

vsphere:latest      vol01@vsanDatastore-04

 

NFS データストアを指定して、ボリュームを作成してみます。

root@vm41 [ ~ ]# docker volume create --driver=vsphere --name=vol02@ds-nfs-vmdk-01 -o size=1gb

vol02@ds-nfs-vmdk-01

root@vm41 [ ~ ]# docker volume ls

DRIVER              VOLUME NAME

vsphere:latest      vol01@vsanDatastore-04

vsphere:latest      vol02@ds-nfs-vmdk-01

 

それぞれのデータストアにファイルが作成されています。

[root@hv-n41:~] ls -l /vmfs/volumes/vsanDatastore-04/dockvols/_DEFAULT/

total 8

-rw-------    1 root     root          4096 Apr 16 16:52 vol01-1d8b22d5cfe8e28a.vmfd

-rw-------    1 root     root           586 Apr 16 16:52 vol01.vmdk

[root@hv-n41:~] ls -l /vmfs/volumes/ds-nfs-vmdk-01/dockvols/_DEFAULT/

total 33436

-rw-------    1 root     root          4096 Apr 16 17:06 vol02-256a299ab1ad11b3.vmfd

-rw-------    1 root     root     1073741824 Apr 16 17:06 vol02-flat.vmdk

-rw-------    1 root     root           558 Apr 16 17:06 vol02.vmdk

 

vSAN データストアに作成された Volume を接続して、コンテナを起動してみます。

コンテナ イメージは Docker Hub オフィシャルの Photon OS のイメージです。

ボリューム「vol01」は、/dir01 ディレクトリにマウントします。

root@vm41 [ ~ ]# docker container run -it -v vol01@vsanDatastore-04:/dir01 photon

root [ / ]# uname -n

e58556770d1b

root [ / ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

コンテナの中での df コマンドで、ボリュームが接続されていことがわかります。

root [ / ]# df -h

Filesystem                                      Size  Used Avail Use% Mounted on

overlay                                          16G  420M   15G   3% /

tmpfs                                           122M     0  122M   0% /dev

tmpfs                                           122M     0  122M   0% /sys/fs/cgroup

/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0 976M  2.5M  973M   1% /dir01

/dev/root                                        16G  420M   15G   3% /etc/resolv.conf

shm                                              64M     0   64M   0% /dev/shm

tmpfs                                           122M     0  122M   0% /sys/firmware

 

ためしに、Volume をマウントしたディレクトリ /dir01 に適当なデータを書き込んでおきます。

root [ / ]# echo "yo-soro-!" > /dir01/test.f

root [ / ]# cat /dir01/test.f

yo-soro-!

 

コンテナを抜けて、Docker ホストに戻ります。

Volume は、Docker ホストに /dev/sdb として接続されています。

root@vm41 [ ~ ]# LANG=C lsblk

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda      8:0    0   16G  0 disk

|-sda1   8:1    0    3M  0 part

`-sda2   8:2    0   16G  0 part /

sdb      8:16   0    1G  0 disk /var/lib/docker/plugins/5bb66ae50bbdd237a3205a6051e6f51c88042f1a71c44e49170fef601d9ab9ab/propagated-mount/vol01@vsanDatastore-04

sr0     11:0    1 1024M  0 rom

 

VM から見ても、Docker Volume にあたる「ハード ディスク 2」が

vSAN データストアにあることがわかります。

「仮想マシン ストレージ ポリシー」は Volume 作成時に

指定していないので空欄になっています。

vdvs-vsan-03.png

 

別の Docker ホストでの Volume 利用。

コンテナを削除しても、Volume が消えない様子を確認してみます。

 

まず、これまで Volume を利用していた Docker コンテナを削除します。

root@vm41 [ ~ ]# docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

e58556770d1b        photon              "/bin/bash"         11 minutes ago      Up 11 minutes                           determined_khorana

root@vm41 [ ~ ]# docker container rm -f e58556770d1b

e58556770d1b

root@vm41 [ ~ ]# docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

root@vm41 [ ~ ]#

 

Docker ホストの VM から、Volume にあたる「ハード ディスク 2」が切断されました。

vm41 には、「ハード ディスク 1」だけが残っています。

vdvs-vsan-04.png

 

そして、別の ESXi で起動している Docker ホストで

先ほどの Volume「vol01」を接続したコンテナを起動してみます。

Docker ホスト「vm42」でも、vDVS の Docker Plugin はインストールずみです。

root@vm42 [ ~ ]# docker plugin ls

ID                  NAME                DESCRIPTION                           ENABLED

3e561e744610        vsphere:latest      VMWare vSphere Docker Volume plugin   true

 

この Docker ホストでも、vm41 で作成した Volume が見えます。

root@vm42 [ ~ ]# docker volume ls

DRIVER              VOLUME NAME

vsphere:latest      vol01@vsanDatastore-04

vsphere:latest      vol02@ds-nfs-vmdk-01

 

Volume「vol01」を接続して、コンテナを起動します。

Volume はコンテナとは独立してデータが永続化されているので、

先ほど Volume に作成したファイルが残っています。

root@vm42 [ ~ ]# docker container run -it -v vol01@vsanDatastore-04:/dir01 photon

Unable to find image 'photon:latest' locally

latest: Pulling from library/photon

d3603a6287f0: Pull complete

Digest: sha256:9cdad7d78710eed3dd4fc5e565bf783aec99ece689d8ab9771b629fd4e5d0ed1

Status: Downloaded newer image for photon:latest

root [ / ]# uname -n

cd2ba7d55444

root [ / ]# cat /dir01/test.f

yo-soro-!

 

このように vDVS では、コンテナで利用するデータを永続化して、

別の ESXi で起動する Docker ホスト(の VM)でもデータを利用することができます。

そして VMFS / NFS / vSAN といった、どのデータストアでも同様に Docker Volume を作成できます。

 

以上、vDVS を使用してみる話でした。

ひきつづき、PowerCLI 10.0 で vRealize Operations Manager(vROps)6.6.1 から情報を取得してみます。

今回は、PowerCLI でどのような vSAN の情報を取得できるのか

(どのようなメトリックが取得できるのか)を確認してみます。

 

PowerCLI での vROps への接続については、これまでの投稿をどうぞ。

PowerCLI で vROps に接続してみる。

 

まず vROps のリソースから情報収集で利用されるアダプタの種類を抽出してみると、

いかにも vSAN にかかわるもの「VirtualAndPhysicalSANAdapter」があります。

PowerCLI> Get-OMResource | select AdapterKind -Unique | Sort-Object AdapterKind

 

AdapterKind

-----------

Container

EP Ops Adapter

OPENAPI

PythonRemediationVcenterAdapter

VCACAdapter

vCenter Operations Adapter

VirtualAndPhysicalSANAdapter

VMWARE

vRealizeOpsMgrAPI

 

 

そしてすべてのリソースから、そのアダプタをもとに vSAN 特有のものと思われるリソースの種類を抽出してみます。

※通常の仮想マシンや仮想ディスクの情報については、今回は省略します。

PowerCLI> Get-OMResource -AdapterKind VirtualAndPhysicalSANAdapter | select ResourceKind -Unique | Sort-Object ResourceKind

 

ResourceKind

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

CacheDisk

CapacityDisk

VirtualAndPhysicalSANAdapter Instance

VirtualSANDCCluster

VirtualSANDiskGroup

VirtualSANFaultDomain

VirtualSANWitnessHost

vSAN World

 

 

このアダプタに関する性能情報のキーを取得してみます。

982 のメトリックがあるようです。

PowerCLI> $stat_keys = Get-OMResource -AdapterKind VirtualAndPhysicalSANAdapter | Get-OMStatKey | Sort-Object ResourceKind,Name

PowerCLI> $stat_keys.Count

982

 

最初の 10件だけ select して、様子を見てみます。

PowerCLI> $stat_keys | select -First 10 | ft -AutoSize

 

Name                           Unit ResourceKind Description

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

badge|alert_count_critical          CacheDisk    Alert Count Critical

badge|alert_count_immediate         CacheDisk    Alert Count Immediate

badge|alert_count_info              CacheDisk    Alert Count Info

badge|alert_count_warning           CacheDisk    Alert Count Warning

badge|anomaly                       CacheDisk    Anomaly

badge|capacityRemaining        %    CacheDisk    Capacity Remaining

badge|capacityRemaining_whatif %    CacheDisk    Capacity Remaining with committed projects

badge|compliance                    CacheDisk    Compliance

badge|density                       CacheDisk    Density

badge|density_whatif                CacheDisk    Density with committed projects

 

 

ちなみに上記のうちの1件に含まれるプロパティをすべて表示して様子をみると、下記のようになっています。

PowerCLI> $stat_keys | select -First 1 *

 

ExtensionData : VMware.VimAutomation.VROps.Views.ResourceTypeAttribute

Name          : badge|alert_count_critical

Unit          :

Description   : Alert Count Critical

ResourceKind  : CacheDisk

AdapterKind   : VirtualAndPhysicalSANAdapter

Client        : VMware.VimAutomation.vROps.Impl.V1.OMClientImpl

Uid           : /OMServer=admin@vrops01.go-lab.jp:443/AdapterKind=VirtualAndPhysicalSANAdapter/ResourceKind=CacheDisk/O

                MStatKey=badge|alert_count_critical/

 

 

あまりに多いので、CSV でエクスポートしてみました。

リソースの種類(ResourceKind)ごとに、取得できる性能情報(Name)が異なることがわかります。

PowerCLI> $stat_keys | select ResourceKind,Name,Unit,Description | Export-Csv -Encoding UTF8 -NoTypeInformation -Path .\vrops_vsan_stat-keys.csv

vrops_vsan_stat-keys.csv · GitHub

 

前のコマンドラインでは、流れの都合で変数「$stat_keys」から CSV エクスポートしていますが、

実行した内容は下記のような内容です。

PowerCLI> Get-OMResource -AdapterKind VirtualAndPhysicalSANAdapter | Get-OMStatKey | Sort-Object ResourceKind,Name | select ResourceKind,Name,Unit,Description | Export-Csv -Encoding UTF8 -NoTypeInformation -Path .\vrops_vsan_stat-keys.csv

 

ここで取得した ResourceKind や Name をもとにして、

下記の投稿のように個々のリソースについての性能情報を取得できます。

PowerCLI で vROps から vSAN ディスクグループの情報を取得してみる。

 

vROps で取得できる性能情報は多いので、PowerCLI を利用することで

効率よく確認対象の精査をする工夫ができるのではないかと思います。

 

以上、PowerCLI で vROps からどのような情報が取得できるか確認してみる話でした。

PowerCLI 10.0 で、vRealize Operations Manager(vROps)から

vSAN ディスクグループのメトリック情報を取得してみます。

 

vROps は、vSAN にかかわる情報も収集していて、

たとえば下記のように vSAN ディスクグループの性能情報を確認することができます。

vrops-vsan-01.png

 

PowerCLI で vROps に接続することで、同様の情報をコマンド実行で取得することができます。

 

まず、vROps に接続しておきます。(前回の投稿より)

PowerCLI で vROps に接続してみる。

 

あわせて、vCenter Server (うちの vCenter アドレスは vc-sv01.go-lab.jp)にも接続しておきます。

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp -Force

 

今回は、vSAN ディスクグループの情報を取得してみます。

vSAN クラスタのホストから・・・

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | Sort-Object Name | select Name

 

Name

----

hv-i21.go-lab.jp

hv-i22.go-lab.jp

hv-i23.go-lab.jp

hv-i24.go-lab.jp

hv-i25.go-lab.jp

hv-i26.go-lab.jp

 

 

1台の vSAN ディスクグループを選んで見ます。

PowerCLI> Get-VMHost hv-i21.go-lab.jp | Get-VsanDiskGroup | fl Name,DiskGroupType

 

Name          : Disk group (0100000000424631335f303036315f434233385f323530300053414d53554e)

DiskGroupType : AllFlash

 

 

ディスクグループのリソース情報が収集できています。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name

 

 

Name                         Health  ResourceKind    Description

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

Disk group (0100000000424... Green   VirtualSANDi...

 

 

 

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | select Name,AdapterKind,ResourceKind,Status,Health,HealthValue

 

Name         : Disk group (0100000000424631335F303036315F434233385F323530300053414D53554E)

AdapterKind  : VirtualAndPhysicalSANAdapter

ResourceKind : VirtualSANDiskGroup

Status       : DataReceiving

Health       : Green

HealthValue  : 100

 

 

vSAN ディスクグループでは、下記のような情報を取得されていることがわかります。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | Get-OMStat | select key -Unique | Sort-Object key

 

Key

---

badge|anomaly

badge|capacityRemaining

badge|compliance

badge|efficiency

badge|efficiency_classic

badge|efficiency_state

badge|fault

badge|health

badge|health_classic

badge|health_state

badge|risk

badge|risk_classic

badge|risk_state

badge|timeRemaining

badge|timeRemaining_whatif

badge|workload

Congestion|compCongestion

Congestion|iopsCongestion

Congestion|logCongestion

Congestion|memCongestion

Congestion|slabCongestion

Congestion|ssdCongestion

DiskI/O|busResets

DiskI/O|commandsAborted

DiskI/O|deviceLatency

DiskI/O|deviceReadLatency

DiskI/O|deviceWriteLatency

DiskI/O|errors

DiskI/O|iopsRead

DiskI/O|iopsWrite

DiskI/O|latencyAvgRead

DiskI/O|latencyAvgWrite

DiskI/O|maxIopsRead

DiskI/O|maxIopsWrite

DiskI/O|readCount

DiskI/O|throughputRead

DiskI/O|throughputWrite

DiskI/O|writeCount

DiskSpace|actual.capacity

DiskSpace|actual.capacity.normalized

DiskSpace|base.demand

diskspace|capacity

diskspace|capacityRemaining

diskspace|capacityRemaining_min

DiskSpace|capacityRemainingValue

DiskSpace|capacityUsage

DiskSpace|capacityUsed

DiskSpace|idletimepercent

DiskSpace|object.capacity

DiskSpace|object.capacity.not.normalized

DiskSpace|object.capacity.with.ha

DiskSpace|object.demand

DiskSpace|object.demand.percent

DiskSpace|object.demand.with.size.recommendation

DiskSpace|object.demand.without.size.recommendation

DiskSpace|oversized

DiskSpace|size.recommendation

diskspace|timeRemaining

diskspace|timeRemaining_whatif

DiskSpace|underusedpercent

diskspace|workload

ReadCache|rateCapacity

ReadCacheRate|actual.capacity

ReadCacheRate|actual.capacity.normalized

ReadCacheRate|object.capacity

ReadCacheRate|object.capacity.not.normalized

ReadCacheRate|object.capacity.with.ha

summary|capacityRemaining_min

summary|idle

summary|poweredOff

summary|poweredOffTimePercent

summary|timeRemaining

summary|timeRemaining_whatif

summary|utilization.range

System Attributes|active_alarms

System Attributes|active_ki_alarms

System Attributes|alert_count_critical

System Attributes|alert_count_immediate

System Attributes|alert_count_info

System Attributes|alert_count_warning

System Attributes|all_metrics

System Attributes|availability

System Attributes|change_index

System Attributes|child_active_alarms

System Attributes|child_active_ki_alarms

System Attributes|child_all_metrics

System Attributes|child_ki_metrics

System Attributes|child_new_alarms

System Attributes|health

System Attributes|ki_metrics

System Attributes|new_alarms

System Attributes|self_alert_count

System Attributes|total_alarms

System Attributes|total_alert_count

WriteBuffer|actual.capacity

WriteBuffer|actual.capacity.normalized

WriteBuffer|base.demand

WriteBuffer|capacityRemaining

WriteBuffer|capacityRemaining_min

WriteBuffer|capacityRemainingValue

WriteBuffer|idletimepercent

WriteBuffer|ioCountWbRead

WriteBuffer|ioCountWbWrite

WriteBuffer|iopsWbRead

WriteBuffer|iopsWbWrite

WriteBuffer|latencyWbRead

WriteBuffer|latencyWbWrite

WriteBuffer|object.capacity

WriteBuffer|object.capacity.not.normalized

WriteBuffer|object.capacity.with.ha

WriteBuffer|object.demand

WriteBuffer|object.demand.percent

WriteBuffer|object.demand.with.size.recommendation

WriteBuffer|object.demand.without.size.recommendation

WriteBuffer|oversized

WriteBuffer|size.recommendation

WriteBuffer|timeRemaining

WriteBuffer|timeRemaining_whatif

WriteBuffer|underusedpercent

WriteBuffer|Usage

WriteBuffer|Used

WriteBuffer|wbFreePct

WriteBuffer|wbSize

WriteBuffer|workload

 

 

たとえば、下記のように 書き込みバッファ容量の推奨値を取得したりできます。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | Get-OMStat -Key "WriteBuffer|size.recommendation" | Sort-Object Time -Descending | select Key,Time,Value -First 10

 

Key                             Time                      Value

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

WriteBuffer|size.recommendation 2018/04/04 21:02:05 17542670336

WriteBuffer|size.recommendation 2018/04/03 21:04:27 18549729280

WriteBuffer|size.recommendation 2018/04/02 21:02:11 18654631936

WriteBuffer|size.recommendation 2018/04/01 21:04:56 19039205376

WriteBuffer|size.recommendation 2018/03/31 21:01:43 18871312384

WriteBuffer|size.recommendation 2018/03/30 21:04:43 17880637440

WriteBuffer|size.recommendation 2018/03/29 21:02:42 17377789952

WriteBuffer|size.recommendation 2018/03/28 21:05:27 17070935040

WriteBuffer|size.recommendation 2018/03/27 21:02:16 17010818048

WriteBuffer|size.recommendation 2018/03/26 21:00:16 16274199552

 

 

この情報は、取得期間を絞ったりすることもできます。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | Get-OMStat -Key "WriteBuffer|size.recommendation" -Start "2018/03/01" -To "2018/03/31" | select Time,Value

 

Time                      Value

----                      -----

2018/03/01 21:02:09 19482898432

2018/03/02 21:03:40 18346463232

2018/03/03 21:05:10 16553049088

2018/03/04 21:02:39 15175520256

2018/03/05 21:04:25 16046277632

2018/03/06 21:01:25 16615967744

2018/03/07 21:03:26 16375300096

2018/03/08 21:00:15 15958652928

2018/03/09 21:04:59 15831619584

2018/03/10 21:01:44 16785255424

2018/03/11 21:03:59 17555458048

2018/03/12 21:00:44 17643444224

2018/03/13 21:03:15 17892603904

2018/03/14 21:00:30 17919207424

2018/03/15 21:02:00 18216976384

2018/03/16 21:03:30 18676643840

2018/03/17 21:05:01 18532560896

2018/03/18 21:01:47 17640730624

2018/03/19 21:03:32 15869313024

2018/03/20 21:00:48 16326699008

2018/03/21 21:00:45 16425305088

2018/03/22 21:02:45 16436318208

2018/03/23 21:04:45 15822150656

2018/03/24 21:01:46 15301784576

2018/03/25 21:03:31 15560028160

2018/03/26 21:00:16 16274199552

2018/03/27 21:02:16 17010818048

2018/03/28 21:05:27 17070935040

2018/03/29 21:02:42 17377789952

2018/03/30 21:04:43 17880637440

 

 

このように情報取得することで、vROps で確認できる性能情報を

PowerShell で集計できるようになります。

定期的な性能レポート作成などでも活用できそうな気がします。

 

以上、vROps から PowerCLI で情報取得してみる話でした。

つづくかもしれない。

PowerCLI 10.0 で、vRealize Operations Manager(vROps)に接続してみます。

 

今回の vROps のホスト名は、vrops01.go-lab.jp で、バージョンは 6.6.1 です。

vrops661-01.png

 

情報収集対象の vCenter Server は vROps に登録ずみです。

vrops661-02.png

 

今回の PowerCLI モジュールのバージョンです。

PowerCLI 10.0 では、下記の vROps むけモジュールがあります。

ちなみに Linux での PowerCLI にもコマンドは含まれていますが、まだ対応はしていないようです。

(今回は Windows 10 で実行しています)

PowerCLI> Get-Command -Module VMware.VimAutomation.vROps | Sort-Object Name | select Source,Version,Name

 

Source                     Version        Name

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

VMware.VimAutomation.vROps 10.0.0.7893921 Connect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Disconnect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlert

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertDefinition

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertSubType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMRecommendation

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMResource

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStat

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStatKey

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMUser

VMware.VimAutomation.vROps 10.0.0.7893921 Get-vROpsCommand

VMware.VimAutomation.vROps 10.0.0.7893921 Set-OMAlert

 

 

これは Get-vROpsCommand でも確認できます。

PowerCLI> Get-vROpsCommand | Sort-Object Name | select Source,Version,Name

 

Source                     Version        Name

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

VMware.VimAutomation.vROps 10.0.0.7893921 Connect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Disconnect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlert

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertDefinition

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertSubType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMRecommendation

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMResource

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStat

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStatKey

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMUser

VMware.VimAutomation.vROps 10.0.0.7893921 Get-vROpsCommand

VMware.VimAutomation.vROps 10.0.0.7893921 Set-OMAlert

 

 

では vROps に接続してみます。

ここで対話的にユーザ / パスワードを入力します。

PowerCLI> Connect-OMServer -Server vrops01.go-lab.jp

 

接続されたことが確認できます。

今回は vROps のローカルユーザで接続したので AuthSource が空欄ですが、

vCenter のユーザで接続すると、ここに vROps に登録した vCenter の名前が入ります。

PowerCLI> $global:DefaultOMServers | fl Name,IsConnected,User,AuthSource

 

Name        : vrops01.go-lab.jp

IsConnected : True

User        : admin

AuthSource  :

 

 

これで vROps のリソース情報が見られるようになります。

PowerCLI> (Get-OMResource).Count

260

PowerCLI> Get-OMResource | group ResourceKind | select Count,Name | Sort-Object Name

 

Count Name

----- ----

    3 AIM Plugin

    1 BusinessService

    7 CacheDisk

   11 CapacityDisk

    7 ClusterComputeResource

    1 ContainerAdapterInstance

    1 Datacenter

   11 Datastore

    2 DatastoreFolder

   23 DistributedVirtualPortgroup

    1 Enterprise

    1 ENTITYSTATUS

    2 Environment

    1 EP Ops Adapter Instance

    4 EP Ops Adapter Resources Group

   18 HostSystem

    2 Licensing

    1 OPENAPI Adapter Instance

    1 Operating Systems World

    1 PythonRemediationVcenterAdapter Instance

    1 Remote Checks World

    4 ResourcePool

    1 Tier

    1 Universe

    1 vCenter Operations Adapter Instance

    1 vC-Ops-Admin-UI

    1 vC-Ops-Analytics

    1 vC-Ops-CaSA

    1 vC-Ops-Cluster

    1 vC-Ops-Collector

    1 vC-Ops-Controller

    1 vC-Ops-Fsdb

    1 vC-Ops-Node

    1 vC-Ops-Persistence

    1 vC-Ops-Product-UI

    1 vC-Ops-Self-Monitoring

    1 vC-Ops-Suite-API

    1 vC-Ops-Watchdog

    1 VirtualAndPhysicalSANAdapter Instance

   90 VirtualMachine

    4 VirtualSANDCCluster

   11 VirtualSANDiskGroup

    4 VirtualSANFaultDomain

    2 VirtualSANWitnessHost

    4 VM Entity Status

   18 VMFolder

    1 VMwareAdapter Instance

    2 VmwareDistributedVirtualSwitch

    1 vRealizeOpsMgrAPI Adapter Instance

    1 vSAN World

    1 vSphere World

 

 

PowerCLI> Get-OMResource -ResourceKind VirtualMachine | select -Last 5

 

Name                         Health  ResourceKind    Description

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

vm01                         Green   VirtualMachine

vrops01                      Green   VirtualMachine

esxi65-template              Green   VirtualMachine

nsx-mgr01                    Green   VirtualMachine

vc-sv01                      Green   VirtualMachine

 

 

個人的には、コマンドラインからメトリック情報を収集する場合などには

REST API よりも PowerCLI の方がデータを扱いやすいかなと思います・・・

 

つづく。