今回は、vSphere Client でコンソールを開くための話です。

VMにOSをインストールするためには、最初にコンソール接続する必要があります。

vCenterを使用する環境でコンソールが開けないトラブルが多いようなので、
「名前解決の問題」についてポイントを書いてみようと思います。

まず、vSphereのコンソール接続（vCenter環境の場合）の概要図です。

• vSphere Clientは vCenterと通信します。
  
• コンソールは、VMの起動しているESXi と通信します。（tcp902番ポート使用）
  

基本的にvSphere Clientでのインベントリ操作（仮想マシンを作成/ON/OFFしたり、フォルダ移動したり）は
vCenterと通信していますが、コンソールの操作はESXiと直接通信しています。

つまりvCenterに接続した場合も、すべての通信がvCenter経由となるわけではありません。

vCenterを使用している場合、vCenterでESXiの名前解決はできているのに

コンソール端末でESXiの名前解決ができなくてトラブルとなることが多いようです。

たとえば、上記の例で vm1というVM のコンソールを開きたい場合、

Windows端末は ESXi1 の名前解決ができる必要があります。

ためしに、あえて名前解決できない状態でVMにコンソール接続してみます。

このとき、対象にVMが起動しているESXiに接続しますが、
その時のESXiへの接続ではインベントリ登録されているESXi名が使用されています。

たとえば、vma1というVMのコンソールを開く場合、
そのVMが乗っているESXi （例では sc-esxi502） とコンソールを開く端末が
通信できる必要があります。
つまり、その端末で ESXi 「sc-esxi502」の 名前解決ができる必要があります。

このとき、名前解決ができないと
下記のようなメッセージが表示されてコンソールが表示されません。

「MKSに接続できません： Host address lookup for server XXX failed: No such host.」

この場合、DNSサーバなどで名前解決するか、

コンソール端末自身のhostsファイルで名前解決する必要があります。

タイトルバーに表示されているESXi ホスト名と、エラーメッセージにある名前が

vCenterインベントリに登録されている名前と一致しています。

※ちなみに、MKSは Mouse Keyboard Screen の略らしいです。

Windowsのhostsファイルは下記にあります。
編集には管理者権限が必要です。

Widnowsのhostsファイルの場所：

C:\Windows\System32\drivers\etc\hosts

下の例では、sc-esxi502 という名前をIPアドレス 172.16.～ に名前解決するよう記載しています。

※例ではショートネーム（ドメイン部分のない名前）を使用していますが、

VMware社的にはFQDN（ホスト名.ドメイン名 という形式）での名前解決をするようにガイドしているようです。

ちゃんと名前解決ができて、コンソール端末とESXiが接続できるようになると
コンソール画面が表示されるようになります。

実際には、名前解決ができるだけでなく

ESXiと実際に接続できて、tcp902ポートで通信できる必要があります。

以上、ESXi へのコンソール接続の話でした。

ESXiの管理は、基本的に vSphere Client や Web Client を使用します。
また、ESXiへのコマンドをリモート実行する場合は、esxcli （主に vSphereCLI や vMA など）を使用すると思います。

しかし、まれにESXi に対してSSHでアクセスしたいケースもあると思います。

たとえば、

• ESXiの設定ファイルを直接編集した。（下記のような）
  
  • ESXi 5.x SSHログインで少し楽をする方法（ただし非推奨）
    
• ローカルデータストアや Scratch パーティションにどのようなファイルがあるか確認したい。
  

など。

とくにESXiの台数が多い場合は、個々にSSHログインするのは大変です。

そんな時の解決法として、Linux サーバから expect コマンドでリモートアクセスをする方法があります。

expect では、接続先サーバの応答をもとにコマンドを自動実行することができます。

今回は expect コマンドを使用して主に参照系のコマンドを実行してみます。

※esxcli コマンドは、vSphereCLIに含まれリモート実行できるので、今回はあえて実行しません。

Linuxへの expect コマンドインストール

今回は、アクセス元として Oracle Linux 6.2 を使用しています。
Redhat 6.x系(Oracle LinuxやCentOSも) にはデフォルトでは expect が入っていないので
OSインストールDVDにあるRPMファイルで別途インストールします。

[root@guest192 Packages]# cat /etc/oracle-release
Oracle Linux Server release 6.2

[root@guest192 Packages]# rpm -ivh expect-5.44.1.15-2.el6.x86_64.rpm
警告: expect-5.44.1.15-2.el6.x86_64.rpm: ヘッダ V3 RSA/SHA256 Signature, key ID ec551f03: NOKEY
準備中...       ########################################### [100%]
   1:expect        ########################################### [100%]

[root@guest192 Packages]# which expect
/usr/bin/expect   ★expect コマンドが見つかることを確認。

[root@guest192 Packages]# /usr/bin/expect -v
expect version 5.44.1.15  ★ついでに expect のバージョンも確認。

スクリプトの説明とファイル構成について

今回は、こんなスクリプトを作成してみました。
エラー処理などは特に入れていません。

SSHアクセス先ESXiのリスト（sv.list）とシェル（get_esxi_info.sh）の2ファイル構成です。

[root@guest192 work]# ls -l
合計 8
-rw-r--r--. 1 root root 638  3月  8 00:45 2013 get_esxi_info.sh
-rw-r--r--. 1 root root  56  3月  8 00:41 2013 sv.list

まず、アクセス先のESXiを、下記のように sv.list ファイルに書いておきます。

sv.list ファイルの内容

172.16.50.121  ★1列でESXiのアドレスを記載しておく。
172.16.50.122
172.16.50.123

SSHを実行するシェル（get_esxi_info.sh）は下記のような感じで作ってみました。

get_esxi_info.sh ファイルの内容

#!/bin/sh

 

user=root

pass=<ESXiのrootパスワード>

list=sv.list

prompt=\"\~\ \#\"

 

cat $list | while read LINE
do
sv=$LINE

expect -c "
  spawn ssh ${user}@${sv}
  expect \"\(yes\/no\)\?\" {
    send \"yes\\r\"
    expect \"Password:\"
    send \"${pass}\\r\"
  } \"Password:\" {
    send \"${pass}\\r\"
  }

expect ${prompt}
send \"uname -n\\r\"
expect ${prompt}
send \"cat /etc/ssh/sshd_config \| grep ^PasswordAuthentication\\n\"
expect ${prompt}
send \"ls /vmfs/volumes/ds_\*\\r\"
expect ${prompt}
send \"exit\\r\"
" > ${sv}.txt
echo "Get ESXi Info : ${sv}"
done

ヒント1

${prompt} の部分は、スクリプト冒頭の
prompt=\"\~\ \#\"
によりESXiのプロンプト文字列「~ #」を表します。

「~ #」が表示されるたびに、次の send より後部分のコマンドが実行されます。

ヒント2

何かコマンドラインを足したい時は、
expect ${prompt}
send \"コマンドライン\\r\"

の2行をセットで追加します。
ただし、コマンドライン中のスペース文字や記号（「*」や「 | 」など）はエスケープ「\」します。

スクリプトの実行例

実行すると、下記のような感じになります。

ESXiの情報取得が終わるたびに、対象のESXiのアドレスが表示されます。

[root@guest192 work]# sh get_esxi_info.sh
Get ESXi Info : 172.16.50.121
Get ESXi Info : 172.16.50.122
Get ESXi Info : 172.16.50.123

シェルの実行が終わると、ESXi毎に情報を取得したファイルが作成されます。

[root@guest192 work]# ls -1
172.16.50.121.txt  ★「ESXiアドレス.txt」 が出力される。
172.16.50.122.txt
172.16.50.123.txt
get_esxi_info.sh
sv.list

ためしに、172.16.50.121.txt を開いてみると
SSHでコマンド実行した時の情報が取れています。

※最初のcatコマンド以下は、すべて「172.16.50.121.txt 」ファイルの中身です。

[root@guest192 work]# cat 172.16.50.121.txt
spawn ssh root@172.16.50.121
Password:
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # uname -n  ★実行したコマンドラインもファイルに残る。
sc-esxi501
~ # cat /etc/ssh/sshd_config | grep ^PasswordAuthentication
PasswordAuthentication yes
~ # ls /vmfs/volumes/ds_*  ★データストアに変なファイルが残っていないか見たり。
/vmfs/volumes/ds_local_esxi501:
vm01        vm02        vm03

/vmfs/volumes/ds_nfs131:
DB          lost+found          esxtop_001.log

/vmfs/volumes/ds_nfs132:
ESXi500-201209001.zip  lost+found  vma1
work                   iso

ちなみに、接続できないESXiがあったりすると、

ファイルにも下記のようにNGだった様子が出力されます。

[root@guest192 work]# cat 172.16.50.123.txt
spawn ssh root@172.16.50.123
ssh: connect to host 172.16.50.123 port 22: No route to host

おまけ。シェルと作るときに役立ちそうなこと。

1. 初回アクセス対策

Linux からESXi にアクセスするときも、お決まりの RSA key の質問があり

「yes」と入力する必要があります。

[root@guest192 work]# ssh root@172.16.50.121
The authenticity of host '172.16.50.121 (172.16.50.121)' can't be established.
RSA key fingerprint is 5d:27:66:c5:a6:ea:9b:ca:4a:ab:40:29:59:74:e5:5a.
Are you sure you want to continue connecting (yes/no)?

そこで、今回のシェルでは下記のようにexpectの条件分岐で

SSH初回アクセス/2回以降のアクセスを判断して対処しています。

ちなみに、「\r」 はEnterキーと同義です。

～

expect \"\(yes\/no\)\?\" {
    send \"yes\\r\"
    expect \"Password:\"
    send \"${pass}\\r\"
  } \"Password:\" {
    send \"${pass}\\r\"
  }

～

2. エスケープ文字「\」が多い場合の実際のコマンドライン確認

このスクリプトを要約すると
expect -c "xxxxxxx xxxxx" といったexpectの使い方をしています。
この場合、expectのサブコマンド（sendコマンドなど）で指定されるコマンドラインでは、
「"」を表現するためにエスケープ文字を使用し、「\"」と書く必要があります。
そのため文字列が複雑になり、実際に実行されるコマンドラインがわかりにくくなります。

この場合、echoコマンドを使うと、わかりやすくコマンドラインを確認することができます。

たとえば、下記のように確認します。

[root@guest192 work]# echo expect \"\(yes\/no\)\?\"
expect "(yes/no)?"
[root@guest192 work]# echo prompt=\"\~\ \#\"
prompt="~ #"
[root@guest192 work]# echo send \"ls /vmfs/volumes/ds_\*\\r\"
send "ls /vmfs/volumes/ds_*\r"

このような確認をしながらスクリプトを作成すると、間違いを減らすことができます。

以上、ESXi にSSHアクセスするときの工夫でした。

以前にVMのCPUアフィニティをPowerCLIで設定する方法をためしてみました。

• PowerCLIでCPUアフィニティ設定（ESXi 5.x）
  

今回は、その設定を確認する方法についてです。

CPUアフィニティは、
VMのvCPUを、特定の物理CPUに紐づけする機能です。

物理CPUといっても、ハイパースレッデイングを利用していると
論理CPUとして2倍数がみえますが、今回はひとまず気にしません。
（物理CPUとvCPUだけで説明します。）

標準のPowerCLI コマンドレットでの確認

とりあえずPowerCLIでCPUアフィニティを確認するだけであれば下記のようなコマンドラインでOKです。
しかし、CPUアフィニティが特定の物理CPUにかたよっていないか
といったことを確認するためには、ちょっとわかりにくいです。

PowerCLI> Get-VM vm?? | sort | Get-VMResourceConfiguration | select VM,CpuAffinity

VM              CpuAffinity
--              -----------
vm01             Cpu0, Cpu1
vm02             Cpu2, Cpu3
vm03                   Cpu4
vm04                   Cpu5
vm05                   Cpu6
vm06                   Cpu7
vm11 Cpu0, Cpu1, Cpu2, Cpu3
vm12 Cpu0, Cpu1, Cpu2, Cpu3
vm13 Cpu4, Cpu5, Cpu6, Cpu7
vm14 Cpu4, Cpu5, Cpu6, Cpu7

CPUアフィニティ設定をスクリプトで確認

そこで、
ちょっとCPUアフィニティが見やすいスクリプトを作成してみました。

スクリプト例： get_cpu_affinity.ps1

Connect-VIServer -Server <vCenterかESXiのアドレス>

$vms = $args[0]

 

# CPUアフィニティ ON/OFF の表示設定
$on  = "[on]"
$off = "[__]"

 

Get-VM $vms | sort -Property VMHost,Name | % {
    # CPUアフィニティ情報格納テーブルを作成
    $cpuset = "" | select hvname,vmname,cnt,

    cpu00,cpu01,cpu02,cpu03,cpu04,cpu05,cpu06,cpu07

    # ESXi名とVM名を取得
    $cpuset.hvname = $_.VMHost
    $cpuset.vmname = $_.Name
    $cpuset.cnt = $_.NumCpu
  
    # CPUアフィニティ情報を取得
    $vm = $_ | Get-View
    $vcpus = $vm.Config.CpuAffinity.AffinitySet
  
    $cpuset.cpu00 =  if ($vcpus -notcontains 0) {$off} else {$on}
    $cpuset.cpu01 =  if ($vcpus -notcontains 1) {$off} else {$on}
    $cpuset.cpu02 =  if ($vcpus -notcontains 2) {$off} else {$on}
    $cpuset.cpu03 =  if ($vcpus -notcontains 3) {$off} else {$on}
    $cpuset.cpu04 =  if ($vcpus -notcontains 4) {$off} else {$on}
    $cpuset.cpu05 =  if ($vcpus -notcontains 5) {$off} else {$on}
    $cpuset.cpu06 =  if ($vcpus -notcontains 6) {$off} else {$on}
    $cpuset.cpu07 =  if ($vcpus -notcontains 7) {$off} else {$on}
  
    # 結果を表示
    $cpuset
} | ft * -AutoSize

上記のスクリプトの実行例です。
引数には、VM名を指定します。
たとえば「vm01」、「vm*」、「vm??」、「vm01,vm02」といった指定ができます。

PowerCLI> .\get_cpu_affinity.ps1 vm*

hvname     vmname cnt cpu00 cpu01 cpu02 cpu03 cpu04 cpu05 cpu06 cpu07
------     ------ --- ----- ----- ----- ----- ----- ----- ----- -----
sc-esxi501 vm01     2 [on]  [on]  [__]  [__]  [__]  [__]  [__]  [__]
sc-esxi501 vm02     2 [__]  [__]  [on]  [on]  [__]  [__]  [__]  [__]
sc-esxi501 vm03     1 [__]  [__]  [__]  [__]  [on]  [__]  [__]  [__]
sc-esxi501 vm04     1 [__]  [__]  [__]  [__]  [__]  [on]  [__]  [__]
sc-esxi501 vm05     1 [__]  [__]  [__]  [__]  [__]  [__]  [__]  [__]
sc-esxi501 vm06     1 [__]  [__]  [__]  [__]  [__]  [__]  [__]  [__]
sc-esxi502 vm11     2 [on]  [on]  [on]  [on]  [__]  [__]  [__]  [__]
sc-esxi502 vm12     2 [on]  [on]  [on]  [on]  [__]  [__]  [__]  [__]
sc-esxi502 vm13     4 [__]  [__]  [__]  [__]  [on]  [on]  [on]  [on]
sc-esxi502 vm14     4 [__]  [__]  [__]  [__]  [on]  [on]  [on]  [on]

hvname列はESXi名、vmname列はVM名を表示しています。
cnt列 にはVMのvCPU数を表示しています。

CPUアフィニティ設定がないVM（=すべての物理CPUを使用するVM。例ではvm05とvm06）は、
すべての物理CPUが空欄になります。

おまけ

ちなみに、vm11とvm12のvCPU数は2つですが、
4つの（vCPU数より多い物理CPUにアフィニティを設定してあります。

CPUアフィニティを設定する理由はだいたい下記2つだと思います。

1. VM同士を、物理的に隔離したい
   
2. ソフトウェアライセンス費用を削減したい
   

1つ目の「VM同士の物理的な隔離」が目的（提供するサービスを分離するためなど）の場合、
VMの性能面を考慮すると 上記の vm11や vm12 のように
vCPU数より多数の物理CPUにCPUアフィニティ設定したほうがよいのです。
これは、VMのvCPUとは別に、ESXiハイパーバイザがVM管理に物理CPUを使用するためです。

2つ目の「VMに導入する製品ライセンス数（物理CPU数をカウントするような）節約」
のためにCPUアフィニティを設定する場合は、vCPUと同数の物理CPUに
アフィニティを設定することが多いはずです。

以上、PowerCLIでCPUアフィニティ設定を確認する方法でした。

ESXiのファイアウォールの構造をPowerCLIで見てみようと思います。

ためした環境は、下記です。

• ESXi 5.0
  
• vCenter 5.0
  
• PowerCLI 5.1 R2
  

まず、ESXiのファイアウォールの全体図をイメージ化してみました。

ESXiのファイアウォールは、
デフォルトポリシー（DefaultPolicy）と
ルールセット（Ruleset）で構成されています。

PowerCLI> $hv = Get-VMHost sc-esxi501 | Get-View

PowerCLI> $hv.Config.Firewall | gm -MemberType Property

   TypeName: VMware.Vim.HostFirewallInfo

Name            MemberType Definition
----            ---------- ----------
DefaultPolicy   Property   VMware.Vim.HostFirewallDefaultPolicy DefaultPolicy {get;set;}
DynamicProperty Property   VMware.Vim.DynamicProperty[] DynamicProperty {get;set;}
DynamicType     Property   System.String DynamicType {get;set;}
Ruleset         Property   VMware.Vim.HostFirewallRuleset[] Ruleset {get;set;}

インバウンド、アウトバウンドどちらも、
デフォルトではブロックされます。（～Blocked が True）

PowerCLI> $hv.Config.Firewall.DefaultPolicy

IncomingBlockedOutgoingBlocked DynamicType DynamicProperty
--------------- --------------- ----------- ---------------
          True            True

ルールセットには下記があります。

PowerCLI> $hv.Config.Firewall.Ruleset | select Key,Label

Key                Label
---                -----
CIMHttpServer      CIM サーバ
CIMHttpsServer     CIM セキュア サーバ
CIMSLP             CIM SLP
DHCPv6             DHCPv6
DVFilter           DVFilter
DVSSync            DVSSync
HBR                HBR
IKED               IKED
NFC                NFC
WOL                WOL
activeDirectoryAll Active Directory すべて
dhcp               DHCP クライアント
dns                DNS クライアント
faultTolerance     Fault Tolerance
ftpClient          FTP クライアント
gdbserver          gdbserver
httpClient         httpClient
iSCSI              ソフトウェア iSCSI クライアント
netDump            netDump
nfsClient          NFS クライアント
ntpClient          NTP クライアント
remoteSerialPort   VM シリアル ポートはネットワークに接続されます
snmp               SNMP サーバ
sshClient          SSH クライアント
sshServer          SSH サーバ
syslog             syslog
updateManager      vCenter Update Manager
vMotion            vMotion
vSPC               VM シリアル ポートは vSPC に接続されます
vSphereClient      vSphere Client
vpxHeartbeats      VMware vCenter Agent
webAccess          vSphere Web Access

たとえば、SSHサーバを例に見てみると、
ルールセットには、ルールのリスト（Rule）と
許可ホストリスト（AllowedHosts）がひもづくことがわかります。

PowerCLI> $hv.Config.Firewall.Ruleset | where {$_.key -like "sshServer"}

Key             : sshServer
Label           : SSH サーバ
Required        : False
Rule            : {VMware.Vim.HostFirewallRule}
Service         : TSM-SSH
Enabled         : True
AllowedHosts    : VMware.Vim.HostFirewallRulesetIpList
DynamicType     :
DynamicProperty :

SSHサーバのルールは、下記のようになっています。
TCPの22番ポート宛のインバウンド通信についてのルールです。

PowerCLI> $r = $hv.Config.Firewall.Ruleset | where {$_.key -like "sshServer"}
PowerCLI> $r.Rule

Port            : 22
EndPort         :
Direction       : inbound
PortType        : dst
Protocol        : tcp
DynamicType     :
DynamicProperty :

下記のSSHサーバのルールセットでは、
すべてホストからの通信（AllIp）は拒否されています。

PowerCLI> $r.AllowedHosts

IpAddress       :
IpNetwork       : {VMware.Vim.HostFirewallRulesetIpNetwork,
                  VMware.Vim.HostFirewallRulesetIpNetwork,
                  VMware.Vim.HostFirewallRulesetIpNetwork}
AllIp           : False
DynamicType     :
DynamicProperty :

そして、指定したホストからの通信だけ許可しています。ホワイトリスト形式です。

PowerCLI> $r.AllowedHosts | % {$_.IpNetwork}

Network     PrefixLength DynamicType DynamicProperty
-------     ------------ ----------- ---------------
172.16.50.0           24
192.168.4.0           24
192.168.0.0           24

以上、ESXiファイアウォールをPowerCLIで見てみました。

ESXiのファイアウォールの許可設定をPowerCLIで変更してみます。

ためした環境は、下記です。

• ESXi 5.0
  
• vCenter 5.0
  
• PowerCLI 5.1 R2
  

PowerCLIでは、ESXiのファイアウォールの有効化/無効化であれば

Set-VMHostFirewallException で設定できるのですが、

細かい許可NWアドレスやIPアドレスの指定はできません。

そこで、スクリプトを作ってみました。

set_esxi_fw.ps1

# 設定変更するルールセット名を指定
$ruleset_name = $args[0]

 

# リストからESXiの一覧を読み込む
$hvs   = Get-Content $args[1]

 

# CSVから通信許可するネットワーク（IP）を読み込む
$rules = Import-Csv $args[2]

 

# 通信許可するネットワーク（IP）数を指定している。
$rule_num = $rules.Count

 

# FW設定の準備
$spec = New-Object VMware.Vim.HostFirewallRulesetRulesetSpec
$spec.allowedHosts = New-Object VMware.Vim.HostFirewallRulesetIpList
$spec.allowedHosts.ipNetwork = New-Object VMware.Vim.HostFirewallRulesetIpNetwork[]($rule_num)
$cnt = 0
$rules | sort | % {
    $spec.allowedHosts.ipNetwork[$cnt] = New-Object VMware.Vim.HostFirewallRulesetIpNetwork
    $spec.allowedHosts.ipNetwork[$cnt].network = $_.network
    $spec.allowedHosts.ipNetwork[$cnt].prefixLength = $_.prefixLength
    $cnt = $cnt + 1
}
$spec.allowedHosts.allIp = $false

 

# ESXiにFW設定
$hvs | sort | % {
    $fw = Get-View (Get-VMHost $_ | Get-View).ConfigManager.FirewallSystem
    $fw.UpdateRuleset($ruleset_name, $spec)
}

別ファイルとして、設定対象のESXi のリスト（hvs.txt）と、

FWルールセットに対して許可するNWのリスト（rules.txt）を用意しておきます。

ESXiのリスト（hvs.txt）の例。

sc-esxi501
sc-esxi502

許可するNWのリスト（rules.txt）の例。ヘッダとして network,prefixLength を書いておきます。

NWアドレスと、サブネットマスクの長さをCSV（「,」で区切って）で記載します。

network,prefixLength
192.168.0.0,24
192.168.4.0,24
172.16.50.0,24

PowerCLIでvCenterに接続して、この3つのファイルで下記のように実行します。

実行方法：

.\set_esxi_fw.ps1 <FWルールセットのKey> <ESXiのリストファイル> <許可NWのリストファイル>

ここで指定できる「FWルールセットのKey」は、

PowerCLI> .\set_esxi_fw.ps1 "sshServer" "hvs.txt" "rules.txt"

うまくいくと、PowerCLIのプロンプトには特に標準出力ありませんが、

vSphere Clientのタスクには設定変更されたことが表示されます。

ファイアウォールのプロパティでも、

「許可されたIPアドレス」にrules.txtで記載した設定が反映されていることが確認できます。

★補足

この方法でESXiファイアウォールを設定するとき、

ネットワークアドレスではなくIPアドレス指定すると、そのあとのvSphereClientでの設定変更が大変でした。

192.168.0.0/24とかではなく、192.168.0.1/32とすると、

なぜか「許可されたIPアドレス」がvSphere Clientから編集できなくなってしまいました。

この場合、/etc/vmware/esx.conf  にファイアウォール設定を記載したうえで

esxcli （esxcli network firewall ・・・・）でallowedip設定を追加/削除することで修正可能です。

たとえば・・・

「許可されたIPアドレス」追加

~ # esxcli network firewall ruleset allowedip add --ruleset-id=<ルールセット名> --ip-address=＜IPアドレス/32＞

「許可されたIPアドレス」削除

~ # esxcli network firewall ruleset allowedip remove --ruleset-id=<ルールセット名> --ip-address=＜IPアドレス/32＞

実行する場合は、検証環境などで試してみてください。

許可IP設定をコマンド設定する場合は esxcli などで実施したほうが良い気がしました。

以上、ESXiファイアウォールの設定をPowerCLIで変更してみる話でした。

今回は、vCenterの設定をPowerCLIで取得してみます。

vSphere Clientの「管理」→「vCenter Server 設定」のあたりで見られるものをテキスト化できるので、

たとえば、パラメータシート作成や、設定確認などの時にちょっと楽できるのではないかと思います。

さっそくですが、下記のようなコマンドラインで、vCenterの設定が表示できます。

IPアドレスが「192.168.5.52」のvCenterに接続しています。

※「Connect-VIServer」ではユーザ/パスワードを求められるので入力します。

PowerCLI C:\> $vc = Connect-VIServer -Server 192.168.5.52
PowerCLI C:\> $vcseting = get-view (Get-View $vc).Content.Setting
PowerCLI C:\> $vcseting.Setting

結果は下記のように表示されます。

これは、vSphere Clientで見られる情報（下記の画面）と同じはずです。

PowerCLI はPowerShellベースなので
ただ標準出力するだけでなく、CSVやHTMLにも変換できます。

最初のコマンド実行例の、最後のコマンド（3行目）からを、下記のように変更します。

どちらの例も、事前に作成しておいた「c:\work」フォルダにファイル保存して

最初の数行（-First で指定した行数）だけ表示しています。

CSV形式でファイル保存

PowerCLI C:\> $vcseting.Setting | select Key,Value | Export-Csv -NoTypeInformation "c:\work\vc_setting.csv"
PowerCLI C:\> cat c:\work\vc_setting.csv | select -First 10
"Key","Value"
"ads.checkInterval","1440"
"ads.checkIntervalEnabled","True"
"ads.maxFetch","5000"
"ads.maxFetchEnabled","True"
"ads.timeout","60"
"AgentUpgrade.autoUpgradeAgents","True"
"AgentUpgrade.checkPeriodSeconds","30"
"alarms.upgraded","False"
"alarms.version","20"

HTML形式でファイル保存

PowerCLI C:\> $vcseting.Setting | select Key,Value | ConvertTo-Html | Out-File "C:\work\vc_setting.html"
PowerCLI C:\> cat c:\work\vc_setting.html | select -First 20
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>HTML TABLE</title>
</head><body>
<table>
<colgroup>
<col/>
<col/>
</colgroup>
<tr><th>Key</th><th>Value</th></tr>
<tr><td>ads.checkInterval</td><td>1440</td></tr>
<tr><td>ads.checkIntervalEnabled</td><td>True</td></tr>
<tr><td>ads.maxFetch</td><td>5000</td></tr>
<tr><td>ads.maxFetchEnabled</td><td>True</td></tr>
<tr><td>ads.timeout</td><td>60</td></tr>
<tr><td>AgentUpgrade.autoUpgradeAgents</td><td>True</td></tr>
<tr><td>AgentUpgrade.checkPeriodSeconds</td><td>30</td></tr>
<tr><td>alarms.upgraded</td><td>False</td></tr>
<tr><td>alarms.version</td><td>20</td></tr>

ちなみに、今回コマンドを実行したvCenterのバージョンは5.1ですが、5.0でもいけます。

PowerCLI C:\> $vc.Version
5.1

以上、vCenterの設定をPowerCLIで確認してみました。

こんな記事を見つけました。パッチ適用について解説されています。

Understanding ESXi Patches – Size & Patch Bundles
http://blogs.vmware.com/vsphere/2013/04/understanding-esxi-patches-size-patch-bundles.html

簡単にまとめると・・・

ESXiのパッチ適用は「イメージ プロファイル」全体の置き換えになるので、
パッチを適用するたびにハイパーバイザが使用する容量が増えたりしない。
※ESXi全体容量が若干増加することはありますが、
　適用するたびに以前のファイルが残って容量が増えたりはしない、ということです。

これは、アップデート（ESXi510-201212001 のようなパッチ適用）でも、
アップグレード（ESXi 5.0 → ESXi 5.1）でも同じ。

ESXiのパッチ適用は、2つのブートバンクパーティションを使ったロールバックができる。

修正版（VIB単位で提供されている）には、
セキュリティフィックス（SG）とバグフィックス（BG）がある。
BGには、SGも含まれている。

※VIBは、ESXiのモジュールのこと。Red hatでのRPMのようなものです。

パッチのセキュリティ修正も、バク修正も累積的で、
後にリリースされたパッチには、以前の修正が含まれる。

詳しくは原文をどうぞ・・・

ちなみに、
記事の中にあるブートバンク（boot bank partitions）は、ESXiからは、

• Primary Boot Bank → /bootbank
  
• Alternate Boot Bank → /altbootbank
  

として見えます。

Primary Boot Bank が現在のESXiイメージで、
Alternate Boot Bank にはパッチ適用前のイメージが格納されます。
パッチ適用前のESXiイメージにロールバックしたい場合は、ESXiの起動画面（下記）で Shift + Rを押します。

ためしに、違うバージョンのESXi で、ブートバンクのパーティションを見てみました。

実際は130MB程度しか使用していません。

ESXi 5.0

~ # vmware -v
VMware ESXi 5.0.0 build-623860

~ # ls -l /bootbank /altbootbank
lrwxrwxrwx    1 root     root  49 Apr  5 05:22 /altbootbank -> /vmfs/volumes/83e5a376-53913a73-000b-c189f76f34ab
lrwxrwxrwx    1 root     root  49 Apr  5 05:22 /bootbank -> /vmfs/volumes/6ea24f7e-79ac5e6f-8f9a-c984ff2c64ed

~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       3.0G 625.0M      2.4G  20% /vmfs/volumes/ds_local_esxi501
vfat         4.0G  20.4M      4.0G   0% /vmfs/volumes/5133df94-58d56db2-557d-000c29f64fbb
vfat       249.7M 126.4M    123.3M  51% /vmfs/volumes/6ea24f7e-79ac5e6f-8f9a-c984ff2c64ed
vfat       249.7M 139.8M    109.9M  56% /vmfs/volumes/83e5a376-53913a73-000b-c189f76f34ab
vfat       285.8M 179.8M    106.1M  63% /vmfs/volumes/5133df8b-ac86a44a-da7e-000c29f64fbb

 

ESXi 5.1

~ # vmware -v
VMware ESXi 5.1.0 build-838463

~ # ls -l /bootbank /altbootbank
lrwxrwxrwx    1 root     root  49 Apr 24 22:51 /altbootbank -> /vmfs/volumes/2f4c5d7c-b6dcf4de-c73e-929023028db4
lrwxrwxrwx    1 root     root  49 Apr 24 22:51 /bootbank -> /vmfs/volumes/8c5de477-c38a8e6f-d788-e67366ddce88

~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       3.0G 831.0M      2.2G  27% /vmfs/volumes/ds_esxi01
vfat         4.0G  15.1M      4.0G   0% /vmfs/volumes/51166f8f-87bb8f52-a114-000c29013d16
vfat       249.7M 130.2M    119.5M  52% /vmfs/volumes/8c5de477-c38a8e6f-d788-e67366ddce88
vfat       249.7M   8.0K    249.7M   0% /vmfs/volumes/2f4c5d7c-b6dcf4de-c73e-929023028db4
vfat       285.8M 201.9M     83.9M  71% /vmfs/volumes/51166f87-ee697d6a-0a9f-000c29013d16

以上、ESXiのパッチについてでした。

ESXi上のVMをクローニング（複製）したいケースが多いと思いますが、
vCenterがないと、単純に「右クリックで[クローン作成]」といったことができません。

vCenterなし環境でVMを複製する場合、
だいたい、下記のどれかの方法となるのではないかと思います。

A. VMをOVF（OVA）形式でエクスポート→別のVMとしてインポート。
B. ESXiに直接ログイン（SSH等）して、VMの構成ファイルをコピー。
C. VMware vCenter Converter を使用する。

「A」の方法では、VMのイメージや構成ファイル（VMDKファイルやVMXファイルなど）を
一度、ESXiのデータストアの以外の場所に保存する必要があり、
そこには数GB（VMの使用している容量分）の空き容量が必要になります。

「C」の方法は、Converterをどこか（ESXiにアクセスすることができるPCなど）に
インストールしておく必要があります。

そのため、
コマンドライン操作が苦手でないのであれば、
慣れれば「B」の方法が、簡潔＆便利ではないかと思っています。

そこで、「うちではこうしてます」的なやりかたを紹介してみます。

vCenterなし環境でのVM複製例。

1. SSHでESXiにログインして、データストアに移動（cd）します。

~ # cd /vmfs/volumes/ds_local_01
/vmfs/volumes/4e1d568f-c2bf5a1e-8739-d48564c9f062 # pwd
/vmfs/volumes/ds_local_01

2. スクリプトを配置

ここにVM構成ファイルをまとめてコピーするコマンドを記載したスクリプトファイルを置いておきます。

ESXiでは、Linux風にシェルスクリプトを作成して実行することができます。

※例では、スクリプトファイル名を「cpvm.sh」にしています。
※あまり作りこんでいないので、一例としてご覧ください。このままではイレギュラーケースには全く対応できないので...

スクリプト例： cpvm.sh

SRC_VM=$1
DST_VM=$2

 

[ -d $SRC_VM ] || { echo "src_vm not exists."    ; exit 1; }
[ -d $DST_VM ] && { echo "dst_vm already exists."; exit 1; }

 

mkdir $DST_VM

 

ls $SRC_VM/*vmdk | grep -v -e "-flat" -e "delta" | while read L
do
        L2=`echo $L | sed -e s/${SRC_VM}/${DST_VM}/g`
        vmkfstools --diskformat thin --clonevirtualdisk $L $L2
done

 

ls $SRC_VM/* | grep -v -e "vmdk" -e ".log" | while read L
do
        L2=`echo $L | sed -e s/${SRC_VM}/${DST_VM}/g`
        cp -p $L $L2
done

 

sed -i s/$SRC_VM/$DST_VM/g $DST_VM/${DST_VM}.vmx

3. 複製スクリプト実行。

それでは、既に作成してある 「vm01」というVMを複製してみます。

コピー元のvm01

/vmfs/volumes/4e1d568f-c2bf5a1e-8739-d48564c9f062 # ls vm01
vm01-flat.vmdk  vm01.vmdk       vm01.vmx        vmware.log
vm01.nvram      vm01.vmsd       vm01.vmxf

スクリプトを実行して、複製します。

実行方法は、
sh cpvm.sh ＜複製元VM名＞ ＜新規VM名＞

です。

/vmfs/volumes/4e1d568f-c2bf5a1e-8739-d48564c9f062 # sh cpvm.sh vm01 vm02
Destination disk format: VMFS thin-provisioned
Cloning disk 'vm01/vm01.vmdk'...
Clone: 100% done.
/vmfs/volumes/4e1d568f-c2bf5a1e-8739-d48564c9f062 # ls vm02
vm02-flat.vmdk  vm02.nvram      vm02.vmdk       vm02.vmsd       vm02.vmx        vm02.vmxf

※上記のスクリプトでは、実際は下記のようなコマンドを実行しています。

mkdir vm02
vmkfstools --diskformat thin --clonevirtualdisk vm01/vm01.vmdk vm02/vm02.vmdk
cp -p vm01/vm01.nvram vm02/vm02.nvram
cp -p vm01/vm01.vmsd vm02/vm02.vmsd
cp -p vm01/vm01.vmx vm02/vm02.vmx
cp -p vm01/vm01.vmxf vm02/vm02.vmxf
sed -i s/vm01/vm02/g vm02/vm02.vmx

ちなみに、新規VM名が既にVMが存在する場合は、
「dst_vm already exists.」
存在しないVMを複製元として指定した場合は
「src_vm not exists.」
と表示して止まるようにしてみました。

4. インベントリにVMを登録

このあと、データストアブラウザやvim-cmd コマンドなどでインベントリにVMを登録します。

たとえば、vim-cmdコマンドなら下記のように登録します。

/vmfs/volumes/4e1d568f-c2bf5a1e-8739-d48564c9f062 # vim-cmd solo/registervm /vmfs/volumes/ds_local_01/vm02/vm02.vmx
74

5. VMの起動

vSphere ClientなどからVMを起動します。

VMを起動したときに下記のような質問がある場合は、「I copied it」 を選択します。

以上、VMのクローンの話でした。

esxtopのフィールド表示設定は、-c ＜設定ファイル＞ を指定してesxtopを実行することで
起動時点の状態をカスタマイズできます。

まだ設定ファイルがない場合、esxtopの実行中に「W」キーを押すことで
ファイル名を指定して設定ファイルを保存することができます。

デフォルトでは「//.esxtop50rc」というパスが指定されるので、
/.esxtop50rc

に保存されます。（ルートディレクトリ直下です。）

デフォルトの設定ファイルは、下記のようになっています。
※esxtop実行して、そのままWを押して保存した設定ファイルです。

~ # cat /.esxtop50rc
ABcDEFghij
aBcDefgHijKLmnOpq
ABCdEfGhijkl
ABcdeFGhIjklmnop
aBCDEFGH
AbcDEFGHIJKLmno
ABCDeF
ABCDe
5c

このままでは、各行がどのesxtopパネルと対応しているのかがわかりにくいのですが、

esxtopのパネルとの対応は下記のようになっています。（上行から順番で）
ABC～の文字がそれぞれどのフィールドに対応するかは、esxtopで各パネル実行中に「f」キーを押すと確認できます。
大文字=表示ON、小文字=表示OFF です。

ためしに、設定ファイルでいくつか試してみました。

あらかじめアルファベットを並べ替えておくと
フィールドの表示順番を変更することができます。
例： 1行目のABcDEFghij → BAcDEFghij

アルファベットを省略すると、そのフィールドは表示されなくなります。
この場合、esxtop起動中に「f」キーで表示ON/OFFを切り替えることもできなくなります。
例1： 1行目のABcDEFghij → ABcDEF とすると、「ghij」に相当するカウンタは表示できなくなる。
例2： 空行を入れておく →該当するパネルはフィールドを表示できなくなる。

各パネルで、デフォルトのフィールド表示状態を見てみました。

esxtop起動中に「f」キーを押して表示される画面では、

各フィールドの先頭に「*」がついているものが、表示ONになっています。

その場で表示ON/OFFを切り替える場合は、
切り替えたいフィールドに対応するキーを押し、大文字/小文字を変更します。

たとえば、「c:cpu」では、デフォルトでは
「I:  SUMMARY STATS = CPU Summary Stats」は非表示です。
ここで「i」キーを押してカウンタ名の頭に「*」をつけて画面を抜ける（Enterキー）すると
「SUMMARY STATS」のカウンタセットが表示されるようになります。

設定ファイルに記載しておく場合は、あらかじめ1行目の cpu のフィールド設定文字列に

「I」（大文字のi）を記載しておくと表示されます。

c:cpu

Current Field order: ABcDEFghij

 

* A:  ID = Id
* B:  GID = Group Id
  C:  LWID = Leader World Id (World Group Id)
* D:  NAME = Name
* E:  NWLD = Num Members
* F:  %STATE TIMES = CPU State Times
  G:  EVENT COUNTS/s = CPU Event Counts
  H:  CPU ALLOC = CPU Allocations
  I:  SUMMARY STATS = CPU Summary Stats
  J:  POWER STATS = CPU Power Stats

m:memory

Current Field order: aBcDefgHijKLmnOpq

 

  A:  ID = Id
* B:  GID = Group Id
  C:  LWID = Leader World Id (World Group Id)
* D:  NAME = Name
  E:  NWLD = Num Members
  F:  MEM ALLOC = MEM Allocations
  G:  NUMA STATS = Numa Statistics
* H:  SIZE = MEM Size (MB)
  I:  ACTV = MEM Active (MB)
  J:  MCTL = MEM Ctl (MB)
* K:  SWAP STATS = Swap Statistics (MB)
* L:  LLSWAP STATS = Llswap Statistics (MB)
  M:  CPT = MEM Checkpoint (MB)
  N:  COW = MEM Cow (MB)
* O:  OVHD = MEM Overhead (MB)
  P:  CMT = MEM Committed (MB)
  Q:  ZIP = MEM Compression (MB)

d:disk adapter

Current Field order: ABCdEfGhijkl

 

* A:  ADAPTR = Adapter Name
* B:  PATH = Path Name
* C:  NPATHS = Num Paths
  D:  QSTATS = Queue Stats
* E:  IOSTATS = I/O Stats
  F:  RESVSTATS = Reserve Stats
* G:  LATSTATS/cmd = Overall Latency Stats (ms)
  H:  LATSTATS/rd = Read Latency Stats (ms)
  I:  LATSTATS/wr = Write Latency Stats (ms)
  J:  ERRSTATS/s = Error Stats
  K:  PAESTATS/s = PAE Stats
  L:  SPLTSTATS/s = SPLIT Stats

u:disk device

Current Field order: ABcdeFGhIjklmnop

 

* A:  DEVICE = Device Name
* B:  ID = Path/World/Partition Id
  C:  NUM = Num of Objects
  D:  SHARES = Shares
  E:  BLKSZ = Block Size (bytes)
* F:  QSTATS = Queue Stats
* G:  IOSTATS = I/O Stats
  H:  RESVSTATS = Reserve Stats
* I:  LATSTATS/cmd = Overall Latency Stats (ms)
  J:  LATSTATS/rd = Read Latency Stats (ms)
  K:  LATSTATS/wr = Write Latency Stats (ms)
  L:  ERRSTATS/s = Error Stats
  M:  PAESTATS/s = PAE Stats
  N:  SPLTSTATS/s = SPLIT Stats
  O:  VAAISTATS= VAAI Stats
  P:  VAAILATSTATS/cmd = VAAI Latency Stats (ms)

v:disk VM

Current Field order: aBCDEFGH

 

  A:  ID = Vscsi Id
* B:  GID = Grp Id
* C:  VMNAME = VM Name
* D:  VDEVNAME = Virtual Device Name
* E:  NVDISK = Num of Virtual Disks
* F:  IOSTATS = I/O Stats
* G:  LATSTATS/rd = Read Latency Stats (ms)
* H:  LATSTATS/wr = Write Latency Stats (ms)

n:network

Current Field order: AbcDEFGHIJKLmno

 

* A:  PORT-ID = Port Id
  B:  UPLINK = Uplink(Y/N)
  C:  PNIC = Physical Nic Properties
* D:  USED-BY = Used By Name
* E:  TEAM-PNIC = Team Uplink Physcial NIC Name
* F:  DNAME = Device Name
* G:  PKTTX/s = Packets Tx/s
* H:  MbTX/s = MegaBits Tx/s
* I:  PKTRX/s = Packets Rx/s
* J:  MbRX/s = MegaBits Rx/s
* K:  DRPTX/s = %Packets Dropped (Tx)
* L:  DRPRX/s = %Packets Dropped (Rx)
  M:  ACTN/s = Actions/s
  N:  MULTICAST/s = Multicast Packets/s
  O:  BROADCAST/s = Broadcast Packets/s

i:interrupt

Current Field order: ABCDeF

 

* A:  VECTOR = Interrupt Vector Id
* B:  COUNT/sec = Total Number of Interupts Per Second
* C:  TIME/int = Average Interrupt Processing Time (usec)
* D:  COUNT_x/sec = Number of Interupts Per Second On CPU x
  E:  TIME_x/int = Average Interrupt Processing Time (usec) on CPU x
* F:  DEVICES = Devices Using the Interrupt Vector

p:power mgmt

Current Field order: ABCDe

 

* A:  PCPU = PCPU Id
* B:  CPU Usage = CPU Usage time: %USED and %UTIL
* C:  %CState = Percentage of time spent in a C-State
* D:  %PState = Percentage of time spent in a P-State
  E:  %TState = Percentage of time spent in a T-State

今回確認した ESXi のバージョンは下記です。

~ # vmware -v
VMware ESXi 5.1.0 build-799733

以上、設定ファイルでのesxtopのフィールド表示カスタマイズでした。

PowerCLIで作業履歴（TeraTermログ的な）を残すには、
「Start-Transcript」 というコマンドレットが便利です。

これはPowerCLI 特有のコマンドではなく、ベースであるPowerShellの標準的なコマンドレットです。

下記のようにコマンド実行すると、コマンド実行結果がファイルに保存されます。

PowerCLI> Start-Transcript <ログ出力ファイル名>

※出力を停止するときは、「Stop-Transcript」を実行します。

実行例

PowerCLIのコマンド実行結果をファイルに残してみます。

ためしに、「powercli.log」というファイルに出力します。

PowerCLI C:\work> Start-Transcript powercli.log  ★ファイルへの出力開始
トランスクリプトが開始されました。出力ファイル: powercli.log
PowerCLI C:\work> Get-VMHost | select Name,PowerState | ft -AutoSize  ★適当にコマンド実行

Name              PowerState
----              ----------
esxi51n2.vs51.lab  PoweredOn
esxi51n1.vs51.lab  PoweredOn

PowerCLI C:\work> Stop-Transcript  ★ファイルへの出力を終了
トランスクリプトが停止されました。出力ファイル: C:\work\powercli.log
PowerCLI C:\work>

コマンド実行結果の出力を見てみます。

PowerCLI C:\work> type .\powercli.log
**********************
Windows PowerShell トランスクリプト開始
開始時刻: 20130606012555
ユーザー名  : WIN7PC-01\testuser1
コンピューター    : WIN7PC-01 (Microsoft Windows NT 6.1.7601 Service Pack 1)
**********************
トランスクリプトが開始されました。出力ファイル: powercli.log
PowerCLI C:\work> Get-VMHost | select Name,PowerState | ft -AutoSize

Name              PowerState
----              ----------
esxi51n2.vs51.lab  PoweredOn
esxi51n1.vs51.lab  PoweredOn

PowerCLI C:\work> Stop-Transcript
**********************
Windows PowerShell トランスクリプト終了
終了時刻: 20130606012610
**********************
PowerCLI C:\work>

※かならず「Stop-Transcript」で出力を停止してから確認します。

　「Start-Transcript」したままファイルを表示すると、

　ファイル内容表示→ファイルに出力→ファイル内容表示... のループになってしまいます。

なお、「Stop-Transcript」を実行しなくても、

PowerCLIの画面を閉じれば、自動的にファイルへの出力も停止します。

おまけ

PowerCLI（PowerShell）では、ユーザ名やタイムスタンプが取得できます。
こういった情報をファイル名の一部として指定すると便利です。

★PowerCLIを実行しているコンピュータ名

PowerCLI> $Env:COMPUTERNAME
WIN7PC-01

★現在のタイムスタンプ

PowerCLI C:\work> Get-Date -Format "yyyyMMddHHmmss"
20130606013128

★PowerCLIを実行しているWindowsユーザ名

（testuser1というユーザでPowerCLIを実行しているWindowsにログイン中）

PowerCLI C:\work> $Env:USERNAME
testuser1

★PowerCLIからvCenterに接続しているユーザ名

（vcadminというユーザで、vCenterに接続中）

PowerCLI C:\work> (Get-View "SessionManager").CurrentSession.FullName.Trim()
vcadmin

たとえば、下記コマンドラインのようにファイル名を指定すると、
「WIN7PC-01_testuser1_20130606013254_ps.log」といった名前のファイルに
コマンドの結果を残すことができます。

PowerCLI> Start-Transcript ($Env:COMPUTERNAME + "_" + $Env:USERNAME + "_" + (Get-Date -Format "yyyyMMddHHmmss") + "_ps.log")

以上、PowerCLIのコマンド作業履歴を残す方法でした。

esxtop をバッチモード（-b）で実行してCSVファイルで保存しておくことが多いですが、

あとから、その時どんなVMが起動していたか確認したいことがあります。

テキストエディタで開いて確認したりするのは、結構大変なので

下記のように、コマンドラインで確認すると便利だと思います。

まず、esxtopには、Windowsのパフォーマンスカウンタ向けのヘッダがついています。

sedで、カンマ「,」を改行「\n」に置換して、カウンタを縦に並べてみました。

量が膨大なので、headで最初の数行だけ表示しています。

# head -1 esxtop_esx502.csv | sed 's/,/\n/g' | head
"(PDH-CSV 4.0) (UTC)(0)"
"\\esx502\Memory\Memory Overcommit (1 Minute Avg)"
"\\esx502\Memory\Memory Overcommit (5 Minute Avg)"
"\\esx502\Memory\Memory Overcommit (15 Minute Avg)"
"\\esx502\Physical Cpu Load\Cpu Load (1 Minute Avg)"
"\\esx502\Physical Cpu Load\Cpu Load (5 Minute Avg)"
"\\esx502\Physical Cpu Load\Cpu Load (15 Minute Avg)"
"\\esx502\Physical Cpu(0)\% Processor Time"
"\\esx502\Physical Cpu(1)\% Processor Time"
"\\esx502\Physical Cpu(2)\% Processor Time"

しかし、esxtopのカウンタは、量が多いです。

カウンタの数を表示（上記のコマンドラインの結果を wc -l で行数表示）してみると、数万件あります。

# head -1 esxtop_esx502.csv | sed 's/,/\n/g' | wc -l
30535

→30535件もあります。

ただ、esxtopのデータには、VMごとに一意の名前のカウンタがあります。（例: VM名は「hdpjt1」）

# head -1 esxtop_esx502.csv | sed 's/,/\n/g' | grep hdpjt01 | head
"\\esx502\Group Cpu(6686629:hdpjt01)\Members"
"\\esx502\Group Cpu(6686629:hdpjt01)\% Used"
"\\esx502\Group Cpu(6686629:hdpjt01)\% Run"
"\\esx502\Group Cpu(6686629:hdpjt01)\% System"
"\\esx502\Group Cpu(6686629:hdpjt01)\% Wait"
"\\esx502\Group Cpu(6686629:hdpjt01)\% VmWait"
"\\esx502\Group Cpu(6686629:hdpjt01)\% Ready"
"\\esx502\Group Cpu(6686629:hdpjt01)\% Idle"
"\\esx502\Group Cpu(6686629:hdpjt01)\% Overlap"
"\\esx502\Group Cpu(6686629:hdpjt01)\% CoStop"

そこで、カウンタからVM名だけ拾ってみました。

下記のコマンドラインでは、

「\\esx502\Group Cpu(6686629:＜仮想マシン名＞)\% Used」 というようなカウンタ（文字列）を抽出して

awk で仮想マシン名の部分を抽出しています。

# head -1 esxtop_esx502.csv | sed 's/,/\n/g' | grep \:vmx\).*Used | awk -F: '{print $2}' | sort
dc1
vm01
vm02
vm03
vm04
ganglia1
hdpjt01
hdpnn01
hdptt01
hdptt02
hdptt03
infra1
veritas02
veritas03
sql1
sql2
vdca1
vc51u1
sv001

このコマンドラインは、ESXiでも、Linuxでも実行できるはずです。

簡単なスクリプトを用意して置くと便利です。

スクリプト例： esxtop2vm.sh

ESXTOP_CSV=$1

[ "x" == x$ESXTOP_CSV ] && { echo "./esxtop2vm.sh esxtop_csv_file"; exit; }

[ ! -f $ESXTOP_CSV ]    && { echo "$ESXTOP_CSV file not exists."; exit; }

head -2 $ESXTOP_CSV | tail -1 | awk -F, '{print $1}'

head -1 $ESXTOP_CSV | sed 's/,/\n/g' | grep \:vmx\).*Used | awk -F: '{print $2}' | sort

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

esxtopを取得開始した時間

（ESXi は一般的に時間設定がUTCなので、日本時間マイナス9時間のことあり）と、

その時のVMが表示されます。

# sh esxtop2vm.sh esxtop_esx501.csv
"05/27/2013 18:49:05"
dc1
vm01
vm02
vm03
vm04
ganglia1
hdpjt01
hdpnn01
hdptt01
hdptt02
hdptt03
infra1
veritas02
veritas03
sql1
sql2
vdca1
vc51u1
sv001

以上、esxtopのCSVからVM名を抽出してみる話でした。

ためしに、ESXi上のゲストからRDM仮想ディスクを見てみました。

仮想ディスクの割り当て方式について

ESXiのVMには、2種類の方式で仮想ディスクを割り当てることができます。
どちらを使用するかは、VMに仮想ディスクを追加するときに決めることができます。

1. ファイル（通称 VMDKファイル）を作成し、仮想ディスクとして割り当てる方式

デフォルトはこちら。一般的には、この方式が使用されます。

2. 物理ディスク（またはLUN）を、そのまま仮想マシンに使わせる「Rawデバイスマッピング（RDM）」

「ローデバイスマッピング」と読まれることが多いと思います。
Rawデバイス = 生デバイス（ディスクをそのまま）というイメージです。
この方式は、さらに「仮想モードRDM」「物理モードRDM」があります。
上記のファイルを作成して割り当てるよりも、RDMのほうが
一般的に、パフォーマンスが良いといわれています。

今回は、「仮想モードRDM」と「物理モードRDM」をVMにわりあてて、
ゲストOSから見てみました。

環境

ESXiをiSCSIディスク（Windows Server 2008 の iSCSIターゲット）に接続し、
ESXi自身が認識したディスク（LUN）を、RDMで割り当ててみました。
ゲストOSは Oracle Enterprise Linux 5（Redhat Linux 5互換）です。

仮想ディスクとしてVMDKファイルを割り当てた場合

まず、デフォルトの「VMDKファイル」を作成して仮想ディスクを
割り当てた時のSyslogを見てみました。（ここではiSCSIは関係ありません。）
ディスクのベンダはVMware、モデルは「Virtual disk」と認識しています。

Jul 14 00:00:00 oel55gst1 kernel: mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 3, phy 3, sas_addr 0x5000c2992220773c

Jul 14 00:00:00 oel55gst1 kernel:   Vendor: VMware    Model: Virtual disk      Rev: 1.0

Jul 14 00:00:00 oel55gst1 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02

Jul 14 00:00:00 oel55gst1 kernel: SCSI device sdd: 2097152 512-byte hdwr sectors (1074 MB)

Jul 14 00:00:00 oel55gst1 kernel: sdd: Write Protect is off

Jul 14 00:00:00 oel55gst1 kernel: sdd: cache data unavailable

Jul 14 00:00:00 oel55gst1 kernel: sdd: assuming drive cache: write through

Jul 14 00:00:00 oel55gst1 kernel: SCSI device sdd: 2097152 512-byte hdwr sectors (1074 MB)

Jul 14 00:00:00 oel55gst1 kernel: sdd: Write Protect is off

Jul 14 00:00:00 oel55gst1 kernel: sdd: cache data unavailable

Jul 14 00:00:00 oel55gst1 kernel: sdd: assuming drive cache: write through

Jul 14 00:00:01 oel55gst1 kernel:  sdd: unknown partition table

Jul 14 00:00:01 oel55gst1 kernel: sd 0:0:3:0: Attached scsi disk sdd

Jul 14 00:00:01 oel55gst1 kernel: sd 0:0:3:0: Attached scsi generic sg3 type 0

物理モードRDMとして割り当てた場合

LinuxゲストのVMに「物理モードRDM」形式で仮想ディスクを割り当てた時のSyslogです。
ディスクのベンダはMSFT、モデルは「Virtual HD」と認識しています。

※モデル「Virtual HD」は、「Virtual」とついていますがVMwareの仮想化とは関係ありません。

WindowsのiSCSI サーバ（iSCSIターゲット）が、LUNをvhd形式で作成しているためこう見えます。

例としてはちょっとイマイチだったかもしれません。

ディスクベンダを、ちゃんとマイクロソフト（MSFT）だと認識しています。
これは、物理環境のOSがWindows iSCSIを認識したときと同様の状態です。

この方式だと、物理ディスクとほとんど同じように扱えますが、
そのかわり、VMwareのスナップショット機能などが使用できなくなります。

Jul 12 08:41:57 oel55gst1 kernel: mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 1, sas_addr 0x5000c29020dea104

Jul 12 08:41:57 oel55gst1 kernel:   Vendor: MSFT      Model: Virtual HD        Rev: 3.3

Jul 12 08:41:57 oel55gst1 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05

Jul 12 08:41:57 oel55gst1 kernel: SCSI device sdb: 2097152 512-byte hdwr sectors (1074 MB)

Jul 12 08:41:57 oel55gst1 kernel: sdb: Write Protect is off

Jul 12 08:41:58 oel55gst1 kernel: sdb: got wrong page

Jul 12 08:41:58 oel55gst1 kernel: sdb: assuming drive cache: write through

Jul 12 08:41:58 oel55gst1 kernel: SCSI device sdb: 2097152 512-byte hdwr sectors (1074 MB)

Jul 12 08:41:58 oel55gst1 kernel: sdb: Write Protect is off

Jul 12 08:41:58 oel55gst1 kernel: sdb: got wrong page

Jul 12 08:41:58 oel55gst1 kernel: sdb: assuming drive cache: write through

Jul 12 08:41:58 oel55gst1 kernel:  sdb: unknown partition table

Jul 12 08:41:58 oel55gst1 kernel: sd 0:0:1:0: Attached scsi disk sdb

Jul 12 08:41:58 oel55gst1 kernel: sd 0:0:1:0: Attached scsi generic sg1 type 0

仮想モードRDMとして割り当てた場合

LinuxゲストのVMに「仮想モードRDM」形式で仮想ディスクを割り当てた時のSyslogです。
ディスクのベンダはVMware、モデルは「Virtual disk」と認識しています。
これは、VMDKファイルを割り当てた時と同様の見え方です。

この方式であれば、RDMでありながらスナップショット等の機能が使用できます。

Jul 12 08:43:13 oel55gst1 kernel: mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 2, phy 2, sas_addr 0x5000c295ba9503e4

Jul 12 08:43:13 oel55gst1 kernel:   Vendor: VMware    Model: Virtual disk      Rev: 1.0

Jul 12 08:43:13 oel55gst1 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02

Jul 12 08:43:13 oel55gst1 kernel: SCSI device sdc: 2097152 512-byte hdwr sectors (1074 MB)

Jul 12 08:43:13 oel55gst1 kernel: sdc: Write Protect is off

Jul 12 08:43:13 oel55gst1 kernel: sdc: cache data unavailable

Jul 12 08:43:13 oel55gst1 kernel: sdc: assuming drive cache: write through

Jul 12 08:43:13 oel55gst1 kernel: SCSI device sdc: 2097152 512-byte hdwr sectors (1074 MB)

Jul 12 08:43:13 oel55gst1 kernel: sdc: Write Protect is off

Jul 12 08:43:13 oel55gst1 kernel: sdc: cache data unavailable

Jul 12 08:43:13 oel55gst1 kernel: sdc: assuming drive cache: write through

Jul 12 08:43:13 oel55gst1 kernel:  sdc: unknown partition table

Jul 12 08:43:13 oel55gst1 kernel: sd 0:0:2:0: Attached scsi disk sdc

Jul 12 08:43:13 oel55gst1 kernel: sd 0:0:2:0: Attached scsi generic sg2 type 0

上記3つのどの方法でも、ゲストOSからは同様に扱うことができます。
パーティション作成もできますし、ファイルシステムの作成もできます。
また、1つのVMに、VMDKファイルやRDMが混在してもOKです。

下記の例では1つのVMに、3つの方式で仮想ディスクを割り当ててみました。

どれも、ゲストから見ると簡単には見分けがつきません。

（ほとんど意識せず、同じように扱うことができます。）

[root@oel55gst1 ~]# fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14         144     1052257+  82  Linux swap / Solaris
/dev/sda3             145        1305     9325732+  83  Linux

Disk /dev/sdb: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

ディスク /dev/sdb は正常な領域テーブルを含んでいません★これ（sdb）は物理モードRDM

Disk /dev/sdc: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

ディスク /dev/sdc は正常な領域テーブルを含んでいません★これ（sdc）は仮想モードRDM

Disk /dev/sdd: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

ディスク /dev/sdd は正常な領域テーブルを含んでいません★これ（sdd）はVMDKファイル

以上、RDMの見え方についてでした。

ありがたい資料が公開されました。

Network port diagram for vSphere 5.x (2054806)
http://kb.vmware.com/kb/2054806

上記のKBから、
Network Port Diagram - vSphere 5.x - Reference Sheet
（NetworkPortDiagram-vSphere5x-ReferenceTable-v2.pdf）
というPDFがダウンロードできます。

この資料のおすすめなところ

• vCenter 5.1～のコンポーネントについても書いてある。
  （Web Clientサーバ、vCenter Single Sign On、Inventory Services）
• VMware系以外のサーバも書いてある。
  （DNSやSNMP、CIMサーバ、LDAP…）

いままでは、下記のKBを見ながら確認していたのですが、
VMwareがどのTCP/UDPポートを使用しているのか、通信要件確認は結構大変でした。

TCP and UDP Ports required to access vCenter Server, ESXi/ESX hosts, and other network components (1012382)
http://kb.vmware.com/kb/1012382

以上、印刷して壁にはっておきたいと思います。

あ、

vCenter SSO → Database（SQL-1433/TCP or Oracle-1521/TCP） とかもありそうな気が・・・

ESXiで起動中のVMがどれくらいCPUオーバーコミットか「見える化」してみようと思い

簡単なPowerCLI スクリプトを作成してみました。

get_esxi_cpuoc.ps1

Get-VMHost | % {

    $hv = $_

    $hv_pcpu = $hv.NumCpu

    $hv_vcpus = 0

    $hv | Get-VM | where {$_.PowerState -eq "PoweredOn"} | % {

        $vm = $_

        $hv_vcpus += $vm.NumCpu

    }

    "$hv では、 $hv_pcpu 物理コアに $hv_vcpus vCPUあります。"

    "CPU物理コアのオーバーコミット: " + ($hv_vcpus / $hv_pcpu * 100) + "%"

    "vCPU: " + ("■" * $hv_vcpus)

    "pCPU: " + ("□" * $hv_pcpu)

} | ft -AutoSize

PowerCLI で接続中のvCenter/ESXi から、すべてのESXiについて情報取得します。

起動中VM（PowerState = PoweredOn のもの）に設定されている、

すべてのvCPU数を足して、物理CPUコア数と並べて表示しています。

実行例

2台のESXiに接続して実行してみたイメージです。

ESXi（例だと、esxi243 と esxi244）は、それぞれHWスペックが異なります。

vCPUと、pCPU（物理CPUコア）のゲージ的なものが並べて表示されます。
一コマ、1CPU（vCPU/pCPU）です。

基本的には、vCPUごとにpCPUがずっと固定されているわけではありません。

特にCPUアフィニティを設定していない場合は、

上段に表示された vCPU が、空いている下段の pCPUのどれかに割り当てられる感じです。

PowerCLI> Connect-VIServer esxi243,esxi244

PowerCLI> .\get_esxi_cpuoc.ps1
esxi244 では、 4 物理コアに 40 vCPUあります。
CPU物理コアのオーバーコミット: 1000%
vCPU: ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
pCPU: □□□□
esxi243 では、 2 物理コアに 12 vCPUあります。
CPU物理コアのオーバーコミット: 600%
vCPU: ■■■■■■■■■■■■
pCPU: □□

※接続するときの画面表示は省略しています。

ちなみに、ESXi上のVM全体で物理CPUコア数よりも多くvCPU割り当てした状態でも、

すぐにCPUリソースに余裕がなくなるというわけではありません。

上記の例でもオーバーコミットは1000%と600%ですが、

実際のCPUリソースにはまだ余裕があります。CpuTotalMhz のうち、CpuUsageMhz の分しか使用していません。

PowerCLI> Get-VMHost | select Name,NumCpu,CpuUsageMhz,CpuTotalMhz | ft -AutoSize

Name    NumCpu CpuUsageMhz CpuTotalMhz
----    ------ ----------- -----------
esxi244      4       10902       13568
esxi243      2        1087        2594

以上です。

CPUオーバーコミット具合を見てみる話でした。

とうとうvSphere5.5がダウンロードできるようになりました。

VMware vSphere 5.5 リリース ノート
http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/vsphere-esx-vcenter-server-55-release-notes.html

すでに新機能についてのホワイトペーパーは公開されていますが、
まだ英語版だけのようです。

そこで、新機能についてうまくまとめてくれている記事をご紹介・・・

英語ですが、少し前の VMware vSphere Blog に、
新機能を1ページに見やすくまめとめて紹介している記事がありました。

What’s New in vSphere 5.5 Platform–Quick Reference
http://blogs.vmware.com/vsphere/2013/09/whats-new-in-vsphere-5-5-platformquick-reference.html

新機能まとめのPDFはこちら。

表でまとめてあるので、英語苦手でも結構いけると思います。
※バージョンが 0.5 になっているのでそのうち更新されるのかもしれません。
http://blogs.vmware.com/vsphere/files/2013/09/vSphere-5.5-Quick-Reference-0.5.pdf

日本語だと、こちらがおすすめです。

Japan Cloud Infrastructure Blog
VMware vSphere 5.5 新機能の概要について
http://blogs.vmware.com/jp-cim/2013/09/vsphere55-orverview.html

以上です。
vSphere自体は、5.5になっても5.1のときほどの大きな変更などはないようですが

個人的にWebClientやvCenterSSOが安定してきているのではと期待しています。

さっそく、ESXi 5.5 をインストールしてみました。

インストール手順や画面は5.1とほぼ同じですが、HW要件の注意が必要です。
5.1 まではメモリ2GBあればインストールできましたが、
ESXi 5.5 からは 最低でも4GBないとインストールできません。

CPUは、従来通り2コアあればイストールできました。

vSphere Client も、5.5用のものが用意されていて
ESXi 5.5 に接続するときはアップグレードが必要です。
ログイン画面には、5.0までの機能が使える

（5.1からの新機能はWebClientからしか使えない）という案内が表示されます。

仮想マシンをvSphere Client で作成してみたところ、
デフォルトだと 仮想マシンバージョンは8（ESXi 5.0 相当）でした。

仮想マシンを右クリックして「仮想ハードウェアのアップグレード」すると

一気にバージョン10になります。

ESXi 5.5 + vSphere Clientでは バージョン9（vmx-09）にはできないようです。

仮想マシンバージョンを上げることで、

仮想マシンに設定できるHWリソースの最大値が上がったり、対応OSが増えたりします。

「仮想ハードウェアのアップグレード」を選択すると、

確認画面には「バージョン 10 以上にアップグレードされます」と表示されます。

「はい」をクリックすると バージョン10 になります。

バージョン10は、vmx-10 と表示されます。

vSphere Clientでは、仮想マシンをvmx-10にすることは可能ですが

一度バージョンを上げてしまうと、「設定の編集」ができなくなってしまうので要注意です。

Web Clientからは、vmx-09 （選択画面では「ESXi 5.1 以降」）を選択することができます。

当然ですが、vmx-10（ESXi 5.5 以降）にもできます。

※Web Client を使用するには、vCenter 5.5が必要です。

以上、ESXi5.5の仮想マシンバージョンの話でした。

ためしに、PowerCLIでESXiをバックアップ＆リストアしてみました。

これまでESXi バックアップとリストアは

vSphereCLI の esxcfg-cfgbackup.pl スクリプトを使ったりするのが一般的だったと思いますが、

PowerCLIメインでvSphere管理している場合は、

Get-VMHostFirmwareと Set-VMHostFirmwareコマンドレットを使用すると便利です。

ESXiのバックアップ＆リストアはvCenterに接続して実施することもできますが、
今回はESXiに直接接続して実施してみます。

バックアップ

1. まず、ESXi に接続します。

今回の対象ESXiのIPアドレスは「192.168.0.244」です。
※名前解決できない環境なので、ホスト名ではなくIPアドレスを直接指定しています。

※ユーザ/パスワードを聞かれるので、ESXi のものを入力します。

PowerCLI> Connect-VIServer 192.168.0.244

Name                           Port  User
----                           ----  ----
192.168.0.244                  443   root

2. Get-VMHostFirmwareでバックアップを取得します。
「-DestinationPath」には、バックアップファイル出力先フォルダを指定します。
バックアップファイルは、「configBundle-＜ESXi名＞.tgz」という名前で、
tar + gzip 形式の圧縮ファイルとして保存されます。

PowerCLI> Get-VMHostFirmware -DestinationPath C:\work

Host            Data
----            ----
192.168.0.244   C:\work\configBundle-192.168.0.244.tgz

試した環境では、25KBくらいのバックアップファイルが取得されました。
バックアップは、これで終わりです。

リストア

バックアップしたファイルを使用して、ESXiをリストアしてみます。

1. まず、ESXiを再インストールします。

・物理サーバに、CD-ROMからESXiを再インストール
・物理サーバに直接コンソール接続してNW設定

2. PowerCLI で ESXi に接続して、メンテナンスモード にします。

※コマンドの結果表示は省略しています。

PowerCLI> Connect-VIServer 192.168.0.244
PowerCLI> Set-VMHost -State Maintenance

3. Set-VMHostFirmware でリストアを実施します。
リストアなので「-Restore」をつけています。
「-SourcePath」には、バックアップファイル名を指定します。
★このコマンド実行後、自動的にESXiが再起動されます。

PowerCLI> Set-VMHostFirmware -Restore -SourcePath C:\work\configBundle-192.168.0.244.tgz

VMHost               UploadUrl
------               ---------
192.168.0.244        http://192.168.0.244/tmp/configBundle.tgz

起動完了したら、メンテナンスモードは解除された状態でした。

これで、リストア完了です。

ためした環境

ESXi のバージョンは 5.1 Update 1 で、
PowerCLIのバージョンは 5.1 R2 です。

PowerCLI> Get-VMHost | select Version,Build | ft -AutoSize

Version Build
------- -----
5.1.0   1065491

PowerCLI> Get-PowerCLIVersion

PowerCLI Version
----------------
   VMware vSphere PowerCLI 5.1 Release 2 build 1012425
---------------
Snapin Versions
---------------
   VMWare AutoDeploy PowerCLI Component 5.1 build 768137
   VMWare ImageBuilder PowerCLI Component 5.1 build 768137
   VMware License PowerCLI Component 5.1 build 669840
   VMware VDS PowerCLI Component 5.1 build 1012428
   VMware vSphere PowerCLI Component 5.1 build 1012428

以上、PowerCLIでのESXiバックアップ/リストアでした。

最近、VMware 入門向けの資格
VMware Certified Associate（VCA）がリリースされました。

キャンペーンサイトらしきところ
http://certified-assoc-ja.vmwareevents.com/

試験は、下記の4つです。

Data Center Virtualization (VCA-DCV)
→ 一般的なvSphereについてです。
（ESXiやvCenterなど）

Cloud (VCA-Cloud)
→ クラウドソリューションと製品についてです。
（vCloud Hybrid Serviceとか、vCloud Directorとか）

Workforce Mobility (VCA-WM)
→ 主にHorizon Suite（仮想デスクトップやアプリ仮想化など）についてです。
（View、Mirage、Horizon Workspaceあたり）

Network Virtualization (VCA-NV)
※NVはまだリリースされていません。

そして、試験ごとにそれぞれ
無料のEラーニングが用意されています。

VCA-DCV →「VMware データ センター仮想化の基礎知識」

VCA-Cloud →「VMware クラウドの基礎知識」

VCA-WM →「VMware Workforce Mobility の基礎知識」

※上記のURL先に、Eラーニングへのリンクもあります。

このEラーニング、VCA-DCVの「VMware データ センター仮想化の基礎知識」については結構おすすめです。

ほかのVCA-DCVについてはほかのVCAの前提知識にもなるので、

迷ったらDCVから勉強＆取得するとよいと思います。

ふつうに視聴していくと、記載されているとおり時間がかかります。
（2.5h～3hくらい）

Eラーニング3つを受講してみて、ちょっと残念なところは

・なんとなく、製品や機能のイントネーションが変なところが気になりました。

　　例： ディレクトリ が ダイレクトリー
・WM、Cloud はちょっと翻訳が微妙な気がしました。
・製品画面があまり無いので、イメージつかめない人はGoogleとかでスクリーンショットを探して見るとよいと思います。

試験をためしに受けてみましたが、結構、難易度高い気がします。
ちゃんとEラーニングで勉強してから受験したほうが良いです。
私は一応 VCAP5-DCA 取得者ですが、
・DCV → 普通に合格
・Cloud → ギリギリ合格
・WM → 不合格（そして結構 悪い点）
でした。一応勉強したのですが・・・WMも・・・

いままで、パートナーではない一般の人向けのVMware資格の入口はVCPでしたが
ハードル高すぎたので（とくに金銭的に）
VMware的な基礎知識を客観的に証明できるようになったのは良いことだと思います。

そして今なら受験費用50%OFFです。（2013年12月末まで？）

以上です。VCAの話でした・・・

ESXiで問題が起きた時に、システムログ（ログバンドルや、vm-supportと呼ばれるファイル）

を取得することが多いと思います。

vSphere Client であれば、

「ファイル」 → 「エクスポート」 → 「システムログのエクスポート」

のあたりで取得できるログファイルです。

今回は、これを PowerCLI の、Get-Log コマンドレットで取得してみました。

ちなみに、バージョンはPowerCLI 5.1 Release 2です。

PowerCLI> Get-PowerCLIVersion | select UserFriendlyVersion

UserFriendlyVersion
-------------------
VMware vSphere PowerCLI 5.1 Release 2 build 1012425

ESXi のシステムログ取得（PowerCLI編）

あらかじめ、Connect-VIServerでvCener か ESXi に接続したうえで、

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

Get-VMHost ＜取得対象のESXi＞ | Get-Log -Bundle -DestinationPath ＜ファイルの出力先フォルダ＞

コマンドラインを実行すると、下記のようにゲージが進み、

tgz（tar + gzip）で圧縮されたログファイルがダウンロードされます。

vCenter や ESXi にSSHログインして取得する場合とは異なり、UUIDが含まれるファイル名になります。

ちなみに、同じESXi からGet-Logするたびに、ファイル名のUUID部分は変わります。

※ほかの方法で取得する場合は、ファイル名にESXiのホスト名やvCenterのインベントリ登録名が含まれます。

PowerCLI 慣れしている人には、vSphere Client などを使用するよりも便利だと思いますが、

ちょっとファイル名がイケていない気がします。

→ ファイル名にESXiのホスト名＆タイムスタンプがつく PowerCLI スクリプト作ってみました。

• PowerCLI で ESXi ログバンドル取得するときの工夫。

以上、PowerCLI で ログバンドルを取得してみた話でした。

PowerCLI で ESXi ログバンドル ファイル（通称 vm-support）を取得してみたところ、
ログファイル名が微妙になってしまいました。

• PowerCLI で ESXi システムログ（ログバンドル）取得。

そこで、わかりやすいファイル名でログバンドル取得できるスクリプトを作ってみました。

たとえば ESXi が4台あるとして、

PowerCLI> Get-VMHost | select Name

Name
----
hv501
hv502
hv503
hv504

ログバンドルを複数台で取得してみると下記のようになります。
どの ESXi のログバンドルファイルか判別できません。

PowerCLI> Get-VMHost | Get-Log -Bundle -DestinationPath C:\work

Data
----
C:\work\vmsupport-521833d1-fe73-6314-5455-ac763a63e43e.tgz
C:\work\vmsupport-52cecb2a-45df-e436-1a1e-1d7463a5078c.tgz
C:\work\vmsupport-52faaacb-1afa-cb59-8926-6c76980ea13a.tgz
C:\work\vmsupport-5267d049-ce93-4ba8-af59-5c2d30fd2320.tgz

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

• 引数に ESXi （Get-VMHostで見える名前）を指定して実行すると、
• ログバンドルを取得して、
• そのままESXiホスト名つきのファイル名にリネーム。
• ファイル名は、「vmsupport_＜ESXi名＞_＜タイムスタンプ＞.tgz」
• 保存先フォルダは、とりあえず C:\work\logs です。

スクリプト名は、 get_vmsupport.ps1 としています。

$hv_list = $args[0]
$log_dir = "C:\work\logs" #★保存先フォルダはここ

$hvs = Get-VMHost $hv_list
$hvs | % {
    $hv = $_
    $hv_name = $hv.Name
    $timestamp = Get-Date -Format "yyyyMMddHHmmss"

    # ESXiのログバンドルファイル（vm-support）取得
    $info = $hv | Get-Log -Bundle -DestinationPath $log_dir

    # ESXiのログバンドルファイルの（vm-support）取得
    $info | select @{N="ESXi";E={$_.Host}},
      @{N="VmSupportFile";E={$_.Data.Name}},
      @{N="FileSize";E={$_.Data.Length}} |
      ft -AutoSize | Out-String

    # vm-supportのファイル名を変更
    $org_name = $log_dir + "\" + $info.Data.Name
    $new_name = $log_dir + "\" + "vmsupport_" + $hv_name + "_" + $timestamp + ".tgz"
    $info = $null
    "ログバンドル名： " + $new_name
    mv $org_name $new_name
}

実行方法

1. まずvCenterに接続します。
PowerCLI> Connect-VIServer ＜vCenterアドレス＞

2. ESXi を指定して上記のスクリプトを実行します。
PowerCLI> .\get_vmsupport.ps1 ＜ESXiを指定＞

実行例

下記のように、ESXi のホスト名を指定して実行します。

PowerCLI> .\get_vmsupport.ps1 hv501,hv502
→ ESXi 2台からログバンドル取得（例では hv501とhv502）

PowerCLI> .\get_vmsupport.ps1 hv50*
→ hv50 から始まる名前の ESXi からログバンドル取得。

vCenterが管理している全てのESXi からログバンドル取得
PowerCLI> .\get_vmsupport.ps1 *

実行すると、下記のような感じになります。

※ちなみに試したバージョンは PowerCLI 5.1 R2です。

以上です。簡単なスクリプトですが、ご参考まで・・・