Skip navigation
2018

PowerCLI では、ESXi の「システムの詳細設定」パラメータを確認・変更することができます。

そこで、VSAN Swap オブジェクトの Thick Provision無効化の設定を、

PowerCLI でまとめて確認・設定してみます。

 

今回のパラメータは、下記で説明されているものです。

VSAN Cormac Blog 〜VSAN 6.2 VM スワップ オブジェクトに関する新機能〜 - Japan Cloud Infrastructure Blog - VMware Blogs

VSAN 6.2 Part 5 - New Sparse VM Swap Object - CormacHogan.com

 

自宅のラボでは Swap オブジェクトの容量を確保しなくてもよいので、
vSAN クラスタに含まれるすべての ESXi で「有効」に揃えてみます。

 

PowerCLI スクリプトでの設定変更も紹介されていますが、

あえて今回はシンプルなコマンドラインを使用してみます。

Virtual SAN 6.2 & PowerCLI - Sparse Virtual Swap files - Virtual Blocks

 

今回、設定変更の対象とする ESXi です。

「vsan-cluster-01」という名前の vSAN クラスタに含まれる ESXi を対象とします。

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | sort Name | select Name,Version,Build

 

Name             Version Build

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

hv-i21.go-lab.jp 6.5.0   7388607

hv-i22.go-lab.jp 6.5.0   7388607

hv-i23.go-lab.jp 6.5.0   7388607

hv-i24.go-lab.jp 6.5.0   7388607

hv-i25.go-lab.jp 6.5.0   7388607

hv-i26.go-lab.jp 6.5.0   7388607

 

 

現時点での設定状態を確認します。

デフォルトでは VSAN.SwapThickProvisionDisabled = 0

(「Thick プロビジョニング無効」を無効にされている状態)です。

ESXi「hv-i24.go-lab.jp」以外は、すでに設定変更していました。

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | sort Name | Get-AdvancedSetting VSAN.SwapThickProvisionDisabled | select Entity,Name,Value

 

Entity           Name                            Value

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

hv-i21.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i22.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i23.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i24.go-lab.jp VSAN.SwapThickProvisionDisabled     0

hv-i25.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i26.go-lab.jp VSAN.SwapThickProvisionDisabled     1

 

 

下記のように、設定変更をしていなかった ESXi だけに絞って、設定変更してみます。

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | sort Name | Get-AdvancedSetting -Name VSAN.SwapThickProvisionDisabled | where {$_.Value -ne 1} | select Entity,Name,Value

 

Entity           Name                            Value

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

hv-i24.go-lab.jp VSAN.SwapThickProvisionDisabled     0

 

 

設定変更します。

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | sort Name | Get-AdvancedSetting -Name VSAN.SwapThickProvisionDisabled | where {$_.Value -ne 1} | Set-AdvancedSetting -Value 1 -Confirm:$false

 

Name                 Value                Type                 Description

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

VSAN.SwapThickPro... 1                    VMHost

 

 

ESXi「hv-i24.go-lab.jp」の設定が変更され、パラメータが揃いました。

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | sort Name | Get-AdvancedSetting -Name VSAN.SwapThickProvisionDisabled | select Entity,Name,Value

 

Entity           Name                            Value

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

hv-i21.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i22.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i23.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i24.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i25.go-lab.jp VSAN.SwapThickProvisionDisabled     1

hv-i26.go-lab.jp VSAN.SwapThickProvisionDisabled     1

 

 

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

そこで、ESXi の実機で設定変更されていることを

「esxcli system settings advanced list」でも確認してみます。

/VSAN/SwapThickProvisionDisabled の IntValue が「1」に変更されていることがわかります。

PowerCLI> (Get-VMHost -Name hv-i24.go-lab.jp | Get-EsxCli -V2).system.settings.advanced.list.Invoke() | where {$_.Path -eq "/VSAN/SwapThickProvisionDisabled"}

 

 

DefaultIntValue    : 0

DefaultStringValue :

Description        : Turn off default thick provisioning type for VM swap object and allow user to control the provisioning type using policy.

IntValue           : 1

MaxValue           : 1

MinValue           : 0

Path               : /VSAN/SwapThickProvisionDisabled

StringValue        :

Type               : integer

ValidCharacters    :

 

 

以上、PowerCLI で ESXi のパラメータを変更してみる話でした。

PowerCLI で、ESXi のバージョンを取得することができます。

Connect-VIServer で vCenter に接続すると、下記のように

vCenter 管理下の ESXi のバージョンをまとめて表示することができます。

PowerCLI> Get-VMHost | select Name,Version,Build | sort Name

 

Name             Version Build

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

hv-d02.go-lab.jp 6.0.0   4192238

hv-i11.go-lab.jp 6.5.0   5310538

hv-i21.go-lab.jp 6.5.0   5310538

hv-i22.go-lab.jp 6.5.0   5310538

hv-i23.go-lab.jp 6.5.0   7388607

hv-i24.go-lab.jp 6.5.0   5969303

hv-i25.go-lab.jp 6.5.0   5310538

hv-i26.go-lab.jp 6.5.0   5310538

hv-n11.go-lab.jp 6.5.0   5969303

hv-n12.go-lab.jp 6.5.0   5969303

hv-n13.go-lab.jp 6.5.0   5969303

hv-n14.go-lab.jp 6.5.0   5969303

 

PowerShell の Group-Object(エイリアスの「Group」でもよい)で工夫すると、

下記のように ESXi のバージョンがどれくらい揃っているか確認することができます。

ESXi の Version + Build ごとに、ESXi 台数(Count 列)がわかります。

ただし、これだけだとグループ化された情報(Group 列)が省略されてしまったりします。

PowerCLI> Get-VMHost | Group Version,Build

 

Count Name                      Group

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

    5 6.5.0, 5310538            {hv-i26.go-lab.jp, hv-i11.go-lab.jp, hv-i21.go-lab.jp, hv-i22.go-lab.jp...}

    1 6.5.0, 7388607            {hv-i23.go-lab.jp}

    5 6.5.0, 5969303            {hv-i24.go-lab.jp, hv-n12.go-lab.jp, hv-n11.go-lab.jp, hv-n14.go-lab.jp...}

    1 6.0.0, 4192238            {hv-d02.go-lab.jp}

 

たとえば下記のように工夫することで、見やすくすることができます。

  • グループ化された ESXi を、名前順にソートして「,」で Join。(これで表示が省略されることを防止)
  • グループ化された ESXi の列名を「ESXi」にする。
  • 古いものから表示されるように、ESXi の Version + Build (グループ化された後の Name 列)でソート。

PowerCLI> Get-VMHost | Group Version,Build | select Count,Name,@{N="ESXi";E={($_.Group.Name | sort) -join ","}} | sort Name

 

Count Name           ESXi

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

    1 6.0.0, 4192238 hv-d02.go-lab.jp

    5 6.5.0, 5310538 hv-i11.go-lab.jp,hv-i21.go-lab.jp,hv-i22.go-lab.jp,hv-i25.go-lab.jp,hv-i26.go-lab.jp

    5 6.5.0, 5969303 hv-i24.go-lab.jp,hv-n11.go-lab.jp,hv-n12.go-lab.jp,hv-n13.go-lab.jp,hv-n14.go-lab.jp

    1 6.5.0, 7388607 hv-i23.go-lab.jp

 

私の環境では ESXi を FQDN で vCenter 登録していて名前が長いので、

さらに ESXi 名のドメイン部分も省略(.go-lab.jp なので「\..*」でマッチする部分を省略)してしまいます。

PowerCLI> Get-VMHost | Group Version,Build | select Count,Name,@{N="ESXi";E={($_.Group.Name -replace "\..*","" | sort) -join ","}} | sort Name

 

Count Name           ESXi

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

    1 6.0.0, 4192238 hv-d02

    5 6.5.0, 5310538 hv-i11,hv-i21,hv-i22,hv-i25,hv-i26

    5 6.5.0, 5969303 hv-i24,hv-n11,hv-n12,hv-n13,hv-n14

    1 6.5.0, 7388607 hv-i23

 

以上、PowerCLI で ESXi バージョン確認するときの工夫についてでした。

vSAN 環境では、VM の容量確保や冗長性の設定のために

仮想マシン ストレージ ポリシーを利用します。

たとえば仮想マシン ストレージ ポリシーを 仮想ディスク(VMDK)に適用するだけで

RAID1 から RAID5 に変更することができます。

しかし、対象 VM が多いと GUI である vSphere Web Client で適用するのが大変なことがあるので、

PowerCLI で仮想マシン ストレージ ポリシー を変更してみました。

 

vCenter には、Connect-VIServer で接続ずみです。

今回の vCenter のバージョンです。

PowerCLI> $global:DefaultVIServer | select Version,Build

 

Version Build

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

6.5.0   5973321

 

PowerCLI のバージョンは 6.5.1 を使用しています。

仮想マシン ストレージ ポリシーにかかわるコマンドレットは、

SPBM(Storage Policy Based Management)といった名前がついています。

PowerCLI> Get-Module VMware.VimAutomation.Storage | select Name,Version

 

Name                         Version

----                         -------

VMware.VimAutomation.Storage 6.5.1.5374001

 

 

PowerCLI> gcm *spbm* | sort Noun,Varb | select Module,Name

 

Module                       Name

------                       ----

VMware.VimAutomation.Storage Get-SpbmCapability

VMware.VimAutomation.Storage Get-SpbmCompatibleStorage

VMware.VimAutomation.Storage Set-SpbmEntityConfiguration

VMware.VimAutomation.Storage Get-SpbmEntityConfiguration

VMware.VimAutomation.Storage Get-SpbmFaultDomain

VMware.VimAutomation.Storage Get-SpbmPointInTimeReplica

VMware.VimAutomation.Storage Start-SpbmReplicationFailover

VMware.VimAutomation.Storage Sync-SpbmReplicationGroup

VMware.VimAutomation.Storage Get-SpbmReplicationGroup

VMware.VimAutomation.Storage Get-SpbmReplicationPair

VMware.VimAutomation.Storage Start-SpbmReplicationPrepareFailover

VMware.VimAutomation.Storage Start-SpbmReplicationPromote

VMware.VimAutomation.Storage Start-SpbmReplicationReverse

VMware.VimAutomation.Storage Start-SpbmReplicationTestFailover

VMware.VimAutomation.Storage Stop-SpbmReplicationTestFailover

VMware.VimAutomation.Storage New-SpbmRule

VMware.VimAutomation.Storage New-SpbmRuleSet

VMware.VimAutomation.Storage Import-SpbmStoragePolicy

VMware.VimAutomation.Storage Get-SpbmStoragePolicy

VMware.VimAutomation.Storage Export-SpbmStoragePolicy

VMware.VimAutomation.Storage Remove-SpbmStoragePolicy

VMware.VimAutomation.Storage New-SpbmStoragePolicy

VMware.VimAutomation.Storage Set-SpbmStoragePolicy

 

この環境では、下記の仮想マシンストレージポリシーを利用しています。

PowerCLI> Get-SpbmStoragePolicy | select Name,@{N="VMs";E={($_|Get-VM).Count}} | where {$_.VMs -gt 0}

 

Name                        VMs

----                        ---

vSAN Default Storage Policy  15

vsan-policy-raid5            94

 

vSAN Default Storage Policy というポリシーは、下記のようなルールが設定されています。

(このポリシーはデフォルトで作成されるものですが、いくつか設定変更しているかもしれません)

PowerCLI> Get-SpbmStoragePolicy -Name "vSAN Default Storage Policy" | select -ExpandProperty AnyOfRuleSets | select -ExpandProperty AllOfRules | ft -AutoSize Capability,Value

 

Capability                  Value

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

VSAN.hostFailuresToTolerate     1

VSAN.stripeWidth                1

VSAN.forceProvisioning      False

VSAN.proportionalCapacity       0

VSAN.cacheReservation           0

 

vsan-policy-raid5 ポリシーは、とりあえず RAID5 にしようと下記のようなルールで作成しました。

PowerCLI> Get-SpbmStoragePolicy -Name "vsan-policy-raid5" | select -ExpandProperty AnyOfRuleSets | select -ExpandProperty AllOfRules | ft -AutoSize Capability,Value

 

Capability                Value

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

VSAN.replicaPreference    RAID-5/6 (Erasure Coding) - Capacity

VSAN.proportionalCapacity 0

 

今回は、まだ vSAN Default Storage Policy ポリシーが適用されている VM に、

vsan-policy-raid5 ポリシーを適用したいと思います。

 

vSAN Default Storage Policy を利用している VM は、下記のように確認できます。

VM は 15 台ありますが、とりあえず 5台だけ表示しています。

ついでに、利用しているストレージ容量も表示してみました。

(今回の例では、容量の少ない VM は 0 になっています。)

PowerCLI> (Get-SpbmStoragePolicy "vSAN Default Storage Policy" | Get-VM).Count

15

PowerCLI> Get-SpbmStoragePolicy "vSAN Default Storage Policy" | Get-VM | select Name,{[int]$_.UsedSpaceGB} | sort Name | select -First 5

 

Name               [int]$_.UsedSpaceGB

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

ansible01                           11

ha-vm01                              0

hv-n00                               0

hv-n06-w                             2

infra-dns01-master                  20

 

infra-dns01-master という VM のポリシーを vsan-policy-raid5 に変更してみます。

PowerCLI> Get-VM infra-dns01-master | Set-SpbmEntityConfiguration -StoragePolicy "vsan-policy-raid5"

 

Entity                         Storage Policy                 Status          Time Of Check

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

infra-dns01-master             vsan-policy-raid5              compliant       2018/01/20 14:59:44

 

上記だと、仮想マシン ホームのポリシーだけが変更されます。

(手軽に確認しやすいため、対象 VM の「仮想マシン ストレージ ポリシーの編集」を開いています)

vm-st-policy-01.png

 

下記のように、仮想ディスクもポリシーを変更します。

PowerCLI> Get-VM infra-dns01-master | Get-HardDisk | Set-SpbmEntityConfiguration -StoragePolicy "vsan-policy-raid5"

 

Entity                         Storage Policy                 Status          Time Of Check

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

Hard disk 1                    vsan-policy-raid5              compliant       2018/01/20 15:10:50

 

仮想マシン ストレージ ポリシーは、下記のように確認することができます。

PowerCLI> Get-VM infra-dns01-master | Get-SpbmEntityConfiguration | ft -AutoSize

 

Entity             Storage Policy    Status    Time Of Check

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

infra-dns01-master vsan-policy-raid5 compliant 2018/01/20 14:59:44

 

PowerCLI> Get-VM infra-dns01-master | Get-HardDisk | Get-SpbmEntityConfiguration | ft -AutoSize

 

 

Entity      Storage Policy    Status    Time Of Check

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

Hard disk 1 vsan-policy-raid5 compliant 2018/01/20 15:10:50

 

 

vSphere Web Client でも、仮想マシンホームだけでなく仮想ディスクのポリシーが変更されています。

vm-st-policy-02.png

 

ただし、データ配置もポリシーに合わせて変更されるため(今回は RAID0 → RAID5)

まとめてポリシー変更する場合は容量やパフォーマンスについて要注意かもしれません。

 

以上、PowerCLI で仮想マシン ストレージ ポリシーを変更してみる話でした。

ためしに、VMware Photon OS 2.0 で NFS 環境を構築してみようと思います。

今回は、NFS Server / NFS Clent の両方を Photon OS にしてみます。

 

NFS Server

  • ホスト名は ph20-nfs-sv-01
  • IP アドレス/サブネットマスクは 192.168.12.240/24

NFS Client

  • ホスト名は ph20-nfs-client-01
  • IP アドレス/サブネットマスクは 192.168.12.241/24

 

OS の準備。

Photon OS 2.0 は、OVA 版(photon-custom-hw13-2.0-304b817.ova)をデプロイしてあります。

NFS Server / NFS Client はどちらも、ホスト名、ネットワークの設定をすませて、

RPM をこの時点の最新のものにしてあります。

root@photon-machine [ ~ ]# hostnamectl set-hostname ph20-nfs-sv-01

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

root@photon-machine [ ~ ]# reboot

 

NFS Server の構築。

今回は、NFS で共有するために VM に仮想ディスク 2(/dev/sdb)を追加しています。

仮想ディスク 2 は VM に追加ずみです。

(NFS で共有するディレクトリは、仮想ディスクをわけずにディレクトリを指定してもよいです)

 

NFS 共有のためのディスク準備。

ディスク(/dev/sdb)をフォーマットします。

sdb が認識されています。

root@ph20-nfs-sv-01 [ ~ ]# lsblk -l /dev/sd?

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  40G  0 disk

 

パーティションを作成します。これで /dev/sdb1 が作成されます。

root@ph20-nfs-sv-01 [ ~ ]# echo '2048,,L' | sfdisk -uS /dev/sdb

 

ext4 ファイルシステムでフォーマットします。

root@ph20-nfs-sv-01 [ ~ ]# mkfs -t ext4 /dev/sdb1

 

今回は、/opt/share ディレクトリを作成してマウントします。

root@ph20-nfs-sv-01 [ ~ ]# mkdir -p /opt/share

root@ph20-nfs-sv-01 [ ~ ]# chmod -R 755 /opt

root@ph20-nfs-sv-01 [ ~ ]# echo '/dev/sdb1 /opt/share ext4 defaults 0 0' >> /etc/fstab

root@ph20-nfs-sv-01 [ ~ ]# cat /etc/fstab

UUID=c1e929b0-5a75-4783-b99f-f79b4007da4e    /    ext4    defaults 1 1

/dev/sdb1 /opt/share ext4 defaults 0 0

root@ph20-nfs-sv-01 [ ~ ]# mount -a

root@ph20-nfs-sv-01 [ ~ ]# df -h /opt/share

Filesystem      Size  Used Avail Use% Mounted on

/dev/sdb1        40G   49M   38G   1% /opt/share

 

lsblk コマンドでも、/dev/sdb1 がマウントされたことが確認できます。

root@ph20-nfs-sv-01 [ ~ ]# lsblk -l /dev/sd?

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  40G  0 disk

sdb1   8:17   0  40G  0 part /opt/share

 

NFS Server のセットアップ。

nfs-utils をインストールします。

root@ph20-nfs-sv-01 [ ~ ]# tdnf install -y nfs-utils

 

NFS 関連のサービスを有効化 / 起動します。

 

rpcbind

root@ph20-nfs-sv-01 [ ~ ]# systemctl enable rpcbind

Created symlink /etc/systemd/system/multi-user.target.wants/rpcbind.service → /lib/systemd/system/rpcbind.service.

Created symlink /etc/systemd/system/sockets.target.wants/rpcbind.socket → /lib/systemd/system/rpcbind.socket.

root@ph20-nfs-sv-01 [ ~ ]# systemctl start rpcbind

root@ph20-nfs-sv-01 [ ~ ]# systemctl is-active rpcbind

active

 

nfs-server

root@ph20-nfs-sv-01 [ ~ ]# systemctl enable nfs-server

Created symlink /etc/systemd/system/multi-user.target.wants/nfs-server.service → /lib/systemd/system/nfs-server.service.

root@ph20-nfs-sv-01 [ ~ ]# systemctl start nfs-server

root@ph20-nfs-sv-01 [ ~ ]# systemctl is-active nfs-server

active

 

NFS で共有するディレクトリをエクスポートします。

今回は、マウントするアドレスを制限していない(「*」を指定している)ため
exportfs では /opt/share は「<world>」となっています。

ちなみに no_subtree_check は、exportfs 実行時のメッセージ抑止のためにデフォルト値をそのまま記載しています。

root@ph20-nfs-sv-01 [ ~ ]# echo '/opt/share *(rw,no_root_squash,no_subtree_check)' >> /etc/exports

root@ph20-nfs-sv-01 [ ~ ]# cat /etc/exports

/opt/share *(rw,no_root_squash,no_subtree_check)

root@ph20-nfs-sv-01 [ ~ ]# exportfs -r

root@ph20-nfs-sv-01 [ ~ ]# exportfs

/opt/share      <world>

 

iptables の設定。

2049 番ポートあての通信を許可しておきます。

今回の NFS Server / NFS Client は、どちらも 192.168.12.0/24 のネットワーク セグメントにあります。

※環境によっては、systemctl disable iptables でもよいかもしれません。

※今回は、NFS v4 を利用しています。(Photon OS 2.0 のデフォルト)

root@ph20-nfs-sv-01 [ ~ ]# iptables -A INPUT -s 192.168.12.0/24 -p tcp --dport 2049 -j ACCEPT

root@ph20-nfs-sv-01 [ ~ ]# iptables -A INPUT -s 192.168.12.0/24 -p udp --dport 2049 -j ACCEPT

root@ph20-nfs-sv-01 [ ~ ]# iptables-save > /etc/systemd/scripts/ip4save

 

NFS Client でのマウント。

Client 側でも、nfs-utils をインストールします。

root@ph20-nfs-client-01 [ ~ ]# tdnf install -y nfs-utils

 

/opt/share ディレクトリ を作成して、NFS をマウントします。

root@ph20-nfs-client-01 [ ~ ]# mkdir -p /opt/share

root@ph20-nfs-client-01 [ ~ ]# chmod -R 755 /opt

root@ph20-nfs-client-01 [ ~ ]# echo '192.168.12.240:/opt/share /opt/share nfs _netdev 0 0' >> /etc/fstab

root@ph20-nfs-client-01 [ ~ ]# mount -a

root@ph20-nfs-client-01 [ ~ ]# df -h /opt/share

Filesystem                 Size  Used Avail Use% Mounted on

192.168.12.240:/opt/share   40G   48M   38G   1% /opt/share

 

Photon OS 2.0 では、デフォルトは NFS v4 になります。

root@ph20-nfs-client-01 [ ~ ]# nfsstat -m

/opt/share from 192.168.12.240:/opt/share

Flags: rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.12.241,local_lock=none,addr=192.168.12.240

 

root@ph20-nfs-client-01 [ ~ ]# nfsstat -l

nfs v4 client        total:      300

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

nfs v4 client        write:        3

nfs v4 client         open:        9

nfs v4 client    open_noat:        4

nfs v4 client        close:        4

nfs v4 client      setattr:       10

nfs v4 client       fsinfo:       20

nfs v4 client       access:       24

nfs v4 client      getattr:       81

nfs v4 client       lookup:       24

nfs v4 client  lookup_root:        5

nfs v4 client       create:        2

nfs v4 client     pathconf:       15

nfs v4 client       statfs:        5

nfs v4 client      readdir:        8

nfs v4 client  server_caps:       35

nfs v4 client  delegreturn:        1

nfs v4 client  exchange_id:        5

nfs v4 client create_session:        5

nfs v4 client destroy_session:        4

nfs v4 client     sequence:       22

nfs v4 client reclaim_comp:        5

nfs v4 client   secinfo_no:        5

nfs v4 client destroy_clientid:        4

 

 

ちなみに photon の GitHub にも、少しだけ NFS についての説明があります。

photon/nfs-utils.md at master · vmware/photon · GitHub

 

以上、Photon OS 2.0 の NFS の様子でした。

ESXi は、Kickstart でインストールとその後の設定を一部自動化することができます。

Kickstart は PXE ブートと合わせて利用することが多いですが、

今回は Kickstart スクリプトを自動的に読み込む ESXi のカスタム ISO インストーラを作成してみます。

 

ESXi 6.5 のドキュメントでは下記のあたりです。

カスタムのインストールまたはアップグレードスクリプトを含む、インストーラ ISO イメージの作成

 

ISO イメージ ファイル作成のための環境準備。

ESXi のインストーラは、ESXi 6.5 U1 のもの

(VMware-VMvisor-Installer-6.5.0.update01-5969303.x86_64.iso)を利用しています。

これは、あらかじめ MyVMware からダウンロードしておきます。

 

ISO を作成する OS は、Oracle Linux 7 を利用しています。

(ただ、RHEL や CentOS でも同様のはずです。)

[root@ol74 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.4

 

ISO イメージを作成するために、genisoimage をインストールします。

[root@ol74 ~]# yum install -y genisoimage

 

ちなみに、mkisofs コマンドも alternatives で管理されていて 、genisoimage へのリンクになっているようです。

[root@ol74 ~]# alternatives --display mkisofs

mkisofs -ステータスは自動です。

リンクは現在 /usr/bin/genisoimage を指しています。

/usr/bin/genisoimage - 優先度 50

スレーブ mkisofs-mkisofsman: /usr/share/man/man1/genisoimage.1.gz

スレーブ mkisofs-mkhybrid: /usr/bin/genisoimage

スレーブ mkisofs-mkhybridman: /usr/share/man/man1/genisoimage.1.gz

現在の「最適」バージョンは /usr/bin/genisoimage です。

[root@ol74 ~]# which mkisofs

/usr/bin/mkisofs

[root@ol74 ~]# ls -l /usr/bin/mkisofs

lrwxrwxrwx. 1 root root 25  1月  4 21:02 /usr/bin/mkisofs -> /etc/alternatives/mkisofs

[root@ol74 ~]# ls -l /etc/alternatives/mkisofs

lrwxrwxrwx. 1 root root 20  1月  4 21:02 /etc/alternatives/mkisofs -> /usr/bin/genisoimage

 

オリジナルのインストーラのファイルを配置。

あらかじめ この Linux に転送しておいた、

ESXi のインストーラの ISO イメージ ファイルをマウントします。

[root@ol74 ~]# ls -l VMware-VMvisor-Installer-6.5.0.update01-5969303.x86_64.iso

-rw-r--r--. 1 root root 348788736  1月  4 14:55 VMware-VMvisor-Installer-6.5.0.update01-5969303.x86_64.iso

[root@ol74 ~]# mount -o loop VMware-VMvisor-Installer-6.5.0.update01-5969303.x86_64.iso /mnt/

mount: /dev/loop0 is write-protected, mounting read-only

 

インストーラのファイルを、一時的に利用するディレクトリ(今回は /tmp/ESXi65u1-custom-iso)にコピーします。

[root@ol74 ~]# mkdir /tmp/ESXi65u1-custom-iso

[root@ol74 ~]# cp -pr /mnt/* /tmp/ESXi65u1-custom-iso/

 

コピーが終わったら、ISO イメージ ファイルはアンマウントしておきます。

[root@ol74 ~]# umount /mnt/

 

Kickstart ファイルの配置。

Kickstart で利用するスクリプト(今回は KS.CFG)を作成します。

事情によりネットワーク設定は VLAN ID 指定 + DHCP 設定にしていますが、

静的に IP アドレスを設定することもできます。

ESXi Kickstart サンプル。 · GitHub

 

今回の Kickstart ファイルは、/tmp/ESXi65u1-custom-iso/KS.CFG として作成します。

ファイル名は 8.3形式で大文字にしておきます。

[root@ol74 ~]# vi /tmp/ESXi65u1-custom-iso/KS.CFG

 

boot.cfg の編集(もしくは新規作成)。

Kickstart スクリプトを読み出すように、boot.cfg を編集します。

今回は カスタム ISO で対話式インストールもできるように、

boot.cfg の編集ではなく、boot-ks.cfg というファイルを新規作成します。

[root@ol74 ~]# sed 's|^kernelopt=.*$|kernelopt=runweasel ks=cdrom:/KS.CFG|' /tmp/ESXi65u1-custom-iso/boot.cfg > /tmp/ESXi65u1-custom-iso/boot-ks.cfg

[root@ol74 ~]# grep kernelopt /tmp/ESXi65u1-custom-iso/boot-ks.cfg

kernelopt=runweasel ks=cdrom:/KS.CFG

 

ちなみに新規作成されたファイルの全体は下記のようになっています。

[root@ol74 ~]# cat /tmp/ESXi65u1-custom-iso/boot-ks.cfg

bootstate=0

title=Loading ESXi installer

timeout=5

kernel=/tboot.b00

kernelopt=runweasel ks=cdrom:/KS.CFG

modules=/b.b00 --- /jumpstrt.gz --- /useropts.gz --- /features.gz --- /k.b00 --- /chardevs.b00 --- /a.b00 --- /user.b00 --- /uc_intel.b00 --- /uc_amd.b00 --- /sb.v00 --- /s.v00 --- /ata_liba.v00 --- /ata_pata.v00 --- /ata_pata.v01 --- /ata_pata.v02 --- /ata_pata.v03 --- /ata_pata.v04 --- /ata_pata.v05 --- /ata_pata.v06 --- /ata_pata.v07 --- /block_cc.v00 --- /char_ran.v00 --- /ehci_ehc.v00 --- /elxnet.v00 --- /hid_hid.v00 --- /i40en.v00 --- /igbn.v00 --- /ima_qla4.v00 --- /ipmi_ipm.v00 --- /ipmi_ipm.v01 --- /ipmi_ipm.v02 --- /ixgben.v00 --- /lpfc.v00 --- /lsi_mr3.v00 --- /lsi_msgp.v00 --- /lsi_msgp.v01 --- /misc_cni.v00 --- /misc_dri.v00 --- /mtip32xx.v00 --- /ne1000.v00 --- /nenic.v00 --- /net_bnx2.v00 --- /net_bnx2.v01 --- /net_cdc_.v00 --- /net_cnic.v00 --- /net_e100.v00 --- /net_e100.v01 --- /net_enic.v00 --- /net_fcoe.v00 --- /net_forc.v00 --- /net_igb.v00 --- /net_ixgb.v00 --- /net_libf.v00 --- /net_mlx4.v00 --- /net_mlx4.v01 --- /net_nx_n.v00 --- /net_tg3.v00 --- /net_usbn.v00 --- /net_vmxn.v00 --- /nhpsa.v00 --- /nmlx4_co.v00 --- /nmlx4_en.v00 --- /nmlx4_rd.v00 --- /nmlx5_co.v00 --- /ntg3.v00 --- /nvme.v00 --- /nvmxnet3.v00 --- /ohci_usb.v00 --- /pvscsi.v00 --- /qedentv.v00 --- /qfle3.v00 --- /qflge.v00 --- /qlnative.v00 --- /sata_ahc.v00 --- /sata_ata.v00 --- /sata_sat.v00 --- /sata_sat.v01 --- /sata_sat.v02 --- /sata_sat.v03 --- /sata_sat.v04 --- /scsi_aac.v00 --- /scsi_adp.v00 --- /scsi_aic.v00 --- /scsi_bnx.v00 --- /scsi_bnx.v01 --- /scsi_fni.v00 --- /scsi_hps.v00 --- /scsi_ips.v00 --- /scsi_isc.v00 --- /scsi_lib.v00 --- /scsi_meg.v00 --- /scsi_meg.v01 --- /scsi_meg.v02 --- /scsi_mpt.v00 --- /scsi_mpt.v01 --- /scsi_mpt.v02 --- /scsi_qla.v00 --- /shim_isc.v00 --- /shim_isc.v01 --- /shim_lib.v00 --- /shim_lib.v01 --- /shim_lib.v02 --- /shim_lib.v03 --- /shim_lib.v04 --- /shim_lib.v05 --- /shim_vmk.v00 --- /shim_vmk.v01 --- /shim_vmk.v02 --- /uhci_usb.v00 --- /usb_stor.v00 --- /usbcore_.v00 --- /vmkata.v00 --- /vmkplexe.v00 --- /vmkusb.v00 --- /vmw_ahci.v00 --- /xhci_xhc.v00 --- /emulex_e.v00 --- /btldr.t00 --- /weaselin.t00 --- /esx_dvfi.v00 --- /esx_ui.v00 --- /lsu_hp_h.v00 --- /lsu_lsi_.v00 --- /lsu_lsi_.v01 --- /lsu_lsi_.v02 --- /lsu_lsi_.v03 --- /native_m.v00 --- /rste.v00 --- /vmware_e.v00 --- /vsan.v00 --- /vsanheal.v00 --- /vsanmgmt.v00 --- /tools.t00 --- /xorg.v00 --- /imgdb.tgz --- /imgpayld.tgz

build=

updated=0

 

Boot メニューの編集。

Boot メニューのファイル(isolinux.cfg)を下記のように編集します。

  1. Kickstart むけのエントリ追記。
  2. Kickstart むけのエントリでの自動起動設定を追記。

 

下記のように、Kickstart むけのエントリを追記します。

vi などでの編集でもよいですが、今回はコピーペーストしやすいので

今回は LABEL ks として、boot-ks.cfg を読み込むエントリを追加しています。

MENU LABEL は、もともとの末尾に「Kickstart」を追記しています。

isolinux.cfg-LABEL_ks · GitHub

 

追記の様子です。

[root@ol74 ~]# cat << EOF >> /tmp/ESXi65u1-custom-iso/isolinux.cfg

> LABEL ks

>   KERNEL mboot.c32

>   APPEND -c boot-ks.cfg

>   MENU LABEL ESXi-6.5.0-20170702001-standard ^Installer Kickstart

> EOF

[root@ol74 ~]#

 

Boot メニューのタイムアウト時に、追記した Kickstart むけのエントリ(LABEL ks)が

自動選択されるように isolinux.cfg を編集します。

[root@ol74 ~]# sed -i '/^TIMEOUT.*$/a ONTIMEOUT ks' /tmp/ESXi65u1-custom-iso/isolinux.cfg

 

isolinux.cfg は、結果的に下記のようになりました。

[root@ol74 ~]# cat /tmp/ESXi65u1-custom-iso/isolinux.cfg

DEFAULT menu.c32

MENU TITLE ESXi-6.5.0-20170702001-standard Boot Menu

NOHALT 1

PROMPT 0

TIMEOUT 80

ONTIMEOUT ks

LABEL install

  KERNEL mboot.c32

  APPEND -c boot.cfg

  MENU LABEL ESXi-6.5.0-20170702001-standard ^Installer

LABEL hddboot

  LOCALBOOT 0x80

  MENU LABEL ^Boot from local disk

LABEL ks

  KERNEL mboot.c32

  APPEND -c boot-ks.cfg

  MENU LABEL ESXi-6.5.0-20170702001-standard ^Installer Kickstart

 

ISO イメージ ファイルの作成。

/tmp/ESXi65u1-custom-iso 配下のファイルから、genisoimage コマンドで

Kickstart ファイルを含む ISO イメージファイル(/tmp/ESXi65u1-custom.iso)を作成します。

コマンドラインで指定している isolinux.bin、boot.cat、efiboot.img はオリジナルのインストーラに含まれています。

[root@ol74 ~]# genisoimage -relaxed-filenames -J -R -o /tmp/ESXi65u1-custom.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e efiboot.img -no-emul-boot /tmp/ESXi65u1-custom-iso

Warning: creating filesystem that does not conform to ISO-9660.

I: -input-charset not specified, using utf-8 (detected in locale settings)

Size of boot image is 4 sectors -> No emulation

Size of boot image is 2048 sectors -> No emulation

  2.94% done, estimate finish Thu Jan  4 23:09:45 2018

  5.87% done, estimate finish Thu Jan  4 23:09:45 2018

  8.81% done, estimate finish Thu Jan  4 23:09:45 2018

11.73% done, estimate finish Thu Jan  4 23:09:53 2018

14.67% done, estimate finish Thu Jan  4 23:09:51 2018

17.60% done, estimate finish Thu Jan  4 23:09:50 2018

20.54% done, estimate finish Thu Jan  4 23:09:49 2018

23.47% done, estimate finish Thu Jan  4 23:09:49 2018

26.40% done, estimate finish Thu Jan  4 23:09:48 2018

29.33% done, estimate finish Thu Jan  4 23:09:48 2018

32.27% done, estimate finish Thu Jan  4 23:09:48 2018

35.20% done, estimate finish Thu Jan  4 23:09:47 2018

38.13% done, estimate finish Thu Jan  4 23:09:47 2018

41.07% done, estimate finish Thu Jan  4 23:09:47 2018

43.99% done, estimate finish Thu Jan  4 23:09:47 2018

46.93% done, estimate finish Thu Jan  4 23:09:47 2018

49.86% done, estimate finish Thu Jan  4 23:09:47 2018

52.80% done, estimate finish Thu Jan  4 23:09:46 2018

55.73% done, estimate finish Thu Jan  4 23:09:46 2018

58.66% done, estimate finish Thu Jan  4 23:09:46 2018

61.59% done, estimate finish Thu Jan  4 23:09:46 2018

64.53% done, estimate finish Thu Jan  4 23:09:46 2018

67.46% done, estimate finish Thu Jan  4 23:09:46 2018

70.39% done, estimate finish Thu Jan  4 23:09:46 2018

73.32% done, estimate finish Thu Jan  4 23:09:46 2018

76.26% done, estimate finish Thu Jan  4 23:09:46 2018

79.19% done, estimate finish Thu Jan  4 23:09:46 2018

82.13% done, estimate finish Thu Jan  4 23:09:46 2018

85.05% done, estimate finish Thu Jan  4 23:09:47 2018

87.99% done, estimate finish Thu Jan  4 23:09:47 2018

90.92% done, estimate finish Thu Jan  4 23:09:47 2018

93.85% done, estimate finish Thu Jan  4 23:09:47 2018

96.79% done, estimate finish Thu Jan  4 23:09:47 2018

99.72% done, estimate finish Thu Jan  4 23:09:47 2018

Total translation table size: 2048

Total rockridge attributes bytes: 14341

Total directory bytes: 6144

Path table size(bytes): 50

Max brk space used 25000

170483 extents written (332 MB)

[root@ol74 ~]#

 

ISO イメージ ファイルが作成されました。

[root@ol74 ~]# ls -l /tmp/ESXi65u1-custom.iso

-rw-r--r--. 1 root root 349149184  1月  4 23:09 /tmp/ESXi65u1-custom.iso

 

作成した ISO イメージの動作確認。

ESXi65u1-custom.iso を利用して ESXi のインストールを開始すると、自動的に Kickstart の処理が進みます。

 

今回は、VMware Workstation で ISO ブートしてみました。

作成した ISO イメージファイルでブートしてみると、

Boot メニューの 3行目に「~ Kickstart」メニューが追加されています。

このままカウントダウンが終わると、自動的に追加したメニューでインストール処理が進みます。

 

esxi-custom-iso-01.png

 

インストール完了時に下記のようなメッセージが表示されますが、

Kickstart スクリプトに「reboot」があるので、少し待つと自動的に再起動されます。

 

esxi-custom-iso-02.png

 

PXE + Kickstart の環境を用意するほどではないけれどもインストールを自動化したい場合や、

ホストプロファイルが利用できなかったり、ホストプロファイルでカバーできないカスタマイズを

したい場合などに便利かもしれません。

 

以上、ESXi のカスタム インストーラを作成してみる話でした。