Skip navigation
2013

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 のタスクには設定変更されたことが表示されます。

esx-fw1.png

 

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

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

esx-fw2.png

 

★補足

この方法で 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 で変更してみる話でした。

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

 

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

  • ESXi 5.0
  • vCenter 5.0
  • PowerCLI 5.1 R2


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

esxifw.png

 

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

IncomingBlocked OutgoingBlocked 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 で見てみました。

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

 

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

 

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 の管理は、基本的に vSphere Client や Web Client を使用します。
また、ESXi へのコマンドをリモート実行する場合は、esxcli (主に vSphereCLI や vMA など)を使用すると思います。

 

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

 

たとえば、

など。

 

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

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

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


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

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

 

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

 

今回は、アクセス元として Oracle Linux 6.2 を使用しています。
Red Hat 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 アクセスするときの工夫でした。

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

 

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

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

 

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

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

vi-cons0.png

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

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

 

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

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

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

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

 

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

vi-cons2.png

 

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

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

vi-cons1.png

 

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

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

 

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

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

 

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

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

vi-cons3.png

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

 

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

 

Widnows の hosts ファイルの場所:

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

 

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

vi-cons4.png

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

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

 

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

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

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

 

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