仮想化の花道

How to configure EVC in an environment with vCSA connected to vDS on VMware vSAN HCI

2019-08-30T21:55:00.001+09:00

●Overview
You need to configure EVC to add servers with different CPU generation to VMware vSAN HCI.
If your VMware vSAN HCI network is configured with vDS, you need some tips.😀

●Oparation
１．Create "Ephemeral binding" DVportGroup to vDS.
２．Disconnect esxi running vcsa using vsphere client.
３．Turn on EVC.
４．Log in to ESXi running vCenter Server using Host Client.
５．Shutdown vCSA.
６．Unregister vCSA from ESXi using Host Client.
７．Register vCSA with another ESXi of vSAN cluster using Host Client.
８．Change the vCSA Network Label to "Ephemeral binding" using Host Client.
９．Start vCSA using Host Client.
１０．Log in to vCSA started using vsphere client.
１１．Change vCSA Network Label to the original "Dynamic binding" DVportGroup.

Change of state of virtual machine storage policy

2015-07-06T23:42:00.000+09:00

今回は vsanDatastoreに配置している仮想マシンを vDP でバックアップ/リストアすると、その仮想マシンに設定している仮想マシンストレージポリシーはどの時点（バックアップ取得時？リストア直前？）を基準にしたポリシーが設定されるのかをご紹介します。

3択問題ですね。
----------------------
A.バックアップ取得時のポリシーが設定される。
B.リストア直前のポリシーが設定される。
C.デフォルトのポリシーが設定される。
----------------------

前提としては、バックアップ取得時の仮想マシンストレージポリシーは、『VSAN-Failer1』という、仮想マシンストレージポリシーを設定していました。（画像がなくてスミマセン。。。）
このポリシーは、"FTT(Failures to Tolerate) = 1" を設定しているものです。
ですので、コンポーネント（VMホーム、vmdk）のミラー数は FTT+1 なので、それぞれ "2" と言うことになります。

では早速リストアをやってみます。
仮想マシンをリストアする前に、『VSAN-Failer0』という仮想マシンストレージポリシーに変更しました。
このポリシーは、"FTT(Failures to Tolerate) = 0" を設定しているものです。
ですので、コンポーネント（VMホーム、vmdk）はミラーされていない状態であることが確認できます。

リストア直前の仮想マシンストレージポリシーの確認①

リストア直前の仮想マシンストレージポリシーの確認②

まず上書きする形でリストアしてみます。

上書きするようにリストア

仮想マシンストレージポリシーを見てみると、リストアする直前の仮想マシンストレージポリシーが保持されていることが確認できます。

上書きリストア後の仮想マシンストレージポリシーの確認①

上書きリストア後の仮想マシンストレージポリシーの確認②

次に新規仮想マシンとしてリストアしてみます。

新規仮想マシンとしてリストア

仮想マシンストレージポリシーを見てみると、デフォルトの仮想マシンストレージポリシーが設定されていることが確認できます。

新規仮想マシンとしてリストアした後の仮想マシンストレージポリシーの確認①

新規仮想マシンとしてリストアした後の仮想マシンストレージポリシーの確認②

まとめると、

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

上書きリストア→リストア直前の仮想マシンストレージポリシーが設定される。

新規仮想マシンとしてリストア→デフォルトの仮想マシンストレージポリシーが設定される。

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

というわけで、正解は B と C でした！！

----------------------
~~A.バックアップ取得時のポリシーが設定される。~~
B.リストア直前のポリシーが設定される。
C.デフォルトのポリシーが設定される。
----------------------

vDP でリストアするときに、仮想マシンストレージポリシーを選択する項目はありませんでした。

Compress Thin provisioning disk (Linux OS)

2015-07-05T22:47:00.000+09:00

今回は Thin provisioning フォーマットの vmdk を vmkfstools を使って圧縮する方法をご紹介します。
Thin provisioning ディスクは容量可変ディスクですが、一旦アロケートされたブロックは開放しないので、ファイルの増減が多いシステムでは結構無駄な領域として残ってしまいがちです。
なお、今回は Guest OS が Linux OS の場合の手順です。

Thin provisioning vmdk を圧縮するにあたってのポイントは 2 つです。

　・圧縮前に Guest OS 内で空き容量をゼロクリアする
　・ゼロクリアするので、一時的に VMFS の容量は逼迫する

手順概要は以下の通りです。
簡単ですね。
-------------------------------
１．Guest OS にログインして、対象のディスクをゼロクリアする。
２．圧縮前に Guest OS をシャットダウンする。
３．vmdk を vmkfstools コマンドを使って圧縮する。
-------------------------------

では、実際の手順をご紹介します。
なお、今回の Linux OS の構成はこのようになっています。
-------------------------------
OS:CentOS 6.2
vCPU：1
vRAM：2GB
vmdk：20GB(Thin provisioning)
-------------------------------

０．まず、現状のストレージ使用量を確認しておきます。
VMFS としてはこのような使用量になります。
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # du -hs test001/test001-flat.vmdk
3.1G    ./test001/test001-flat.vmdk
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #
-------------------------------

１．Guest OS にログインして、対象の vmdk に対してゼロクリアを行います。
-------------------------------
[root@test001 home]# dd if=/dev/zero of=ZEROFILE.txt bs=1000000 ; rm -f ZEROFILE.txt
dd: writing `ZEROFILE.txt': デバイスに空き領域がありません
13680+0 records in
13679+0 records out
13679198208 bytes (14 GB) copied, 951.158 s, 14.4 MB/s
[root@test001 home]#
-------------------------------

このとき、VMFS はこのような使用量になります。（青字）
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # du -hs test001/test001-flat.vmdk
15.6G   test001/test001-flat.vmdk
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #
-------------------------------

２．圧縮前に Guest OS をシャットダウンします。
-------------------------------
[root@test001 home]# shutdown -h now
Broadcast message from root@test001
        (/dev/pts/0) at 13:51 ...
The system is going down for halt NOW!
[root@test001 home]#
-------------------------------

３．vmdk を vmkfstools コマンドを使って圧縮します。（青字）
これは ESXi から作業します。
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # vmkfstools --punchzero test001/test001.vmdk
vmfsDisk: 1, rdmDisk: 0, blockSize: 1048576
Hole Punching: 100% done.
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #
-------------------------------

vmkfstools 実行後に VMFS の使用量を確認します。
すると、割り当て容量が減少したことが確認できました。（青字）
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # du -hs test001/test001-flat.vmdk
2.7G    test001/test001-flat.vmdk
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #
-------------------------------

これらの作業を vSphere Web Client から状態を確認すると、このようになりました。

vSphere Web Client からみたストレージ使用量の変化

ちなみに、Guest OS 内でゼロクリアしたあと、Storage vMotion を行っても、圧縮はできませんでした。
Storage vMotion だと、一旦 Eager Zeroed Thick disk に変更したあと、改めて Thin provisioning disk に変更するとできそうですね。（試していませんが。）

Dividing vCenter SSO and vCenter Server before upgrading to vCenter 6.0

2015-07-04T02:02:00.001+09:00

vSphere 6 で vCenter Server 間の vMotion を実行する場合、Enhanced Linked Mode にする必要があります。
トポロジで表すと、このような構成です。

ところで、vCenter 5.1/5.5 を Simple Install で構成した場合は、このような構成になります。

当然、この状態で vCenter 6.0 にアップグレードして Enhanced Linked Mode の構成にすると、こうなります。

しかし、このトポロジ構成は KB2108548 に書かれている通り、推奨しない&将来未サポートになるかもしれない構成なのです。

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

Topologies that are deprecated and will be unsupported in the future.
These topologies are not recommended.

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

さらに、vSphere 6 アップグレードガイドには、
「アップグレードした後は PSC と vCenter Server のデプロイモデルを変更することはできない。」
と書かれています。

vSphere 6 アップグレードガイド抜粋

Simple Install で構成したら、Enhanced Linked Mode を使用したくても躊躇しちゃいますね。
ではどうすれば良いかというと、アップグレード前に分けちゃえば良いんです。
分割方法は KB2033620 に書かれています。
vCSA の場合は KB2094888 になります。vCSA の場合は vCSA 5.5 のみ情報がありました。

今回は、この KB2033620 の方法で vCenter SSO 5.5 と vCenter Server 5.5 を分けて、かつそれぞれを PSC とvCenter Server 6.0 へアップグレードする方法をご紹介します。

作業概要は以下の通りです。
------------------------------------
1. 旧 vCenter SSO の情報をバックアップ
2. 新 vCenter SSO を新しいサーバにカスタムインストール
3. vCenter Inventory Service を新 vCenter SSO に登録
4. vCenter Server を新 vCenter SSO に登録
5. vCenter Server と vCenter Inventory Service を再登録
6. vSphere Web Client を新 vCenter SSO に登録
7. 旧 vCenter SSO の情報を新 vCenter SSO へリカバリ
8. 旧 vCenter SSO をアンインストール
9. 新 vCenter SSO を PSC にアップグレード
10. vCenter Server をアップグレード
------------------------------------
この作業の 3~6 が、KB2033620 に該当します。

早速やってみましょう。

1. 旧 vCenter SSO の情報をバックアップ

vCenter SSO の情報をバックアップする場合、以下の3つの方法が考えられますが、私が試した中では、1つしかできませんでした。

　　・vSphere Web Client でログインし、vCenter SSOの情報をメモする
　
　　　-ユーザ、グループ
　　　-パスワードポリシー、ロックアウトポリシー、トークンポリシー
　　　-アイデンティティソース
　　　-STS　証明書（メモと言うよりどの証明書を使っていたかの確認）

　
　　・バックアップせず、新 vCenter SSO を同じドメインの新規サイトとして追加し、旧 vCenter SSO の情報を複製する

　　・旧 vCenter SSO の構成ファイルをバックアップする（KB2057353）

正解は「vCenter SSOの情報をメモする」です。
2番目の旧 vCenter SSO と新 vCenter SSO を同じドメインにして、情報を複製するやり方だと、アップグレードした後も旧 vCenter SSO と同期使用としてエラーメッセージがログに出力され続けます。
3番目の構成情報のバックアップは、新 vCenter SSO のサーバ名が変わる為、使えないのです。

2. 新 vCenter SSO を新しいサーバにカスタムインストール

新しいサーバに vCenter SSO をカスタムインストールします。そのとき、vCenter SSO のデプロイモードは、「最初の vCenter Server 用の vCenter Single Sign-On 」でインストールします。
このとき、サイト名、vCenter SSO ユーザ(Administrator@vSphere.local)のパスワードは旧 vCenter SSO と同じである必要はありません。

一番上を選択する

3. vCenter Inventory Service を新 vCenter SSO に登録
4. vCenter Server を新 vCenter SSO に登録
5. vCenter Server と vCenter Inventory Service を再登録
6. vSphere Web Client を新 vCenter SSO に登録

ここはKBそのままなので省略します。注意点としては、バッチ実行後、エラーが表示される場合がありますが、net start コマンドのタイムアウトなので気にしないでください。

vCenter Inventory Service を新 vCenter SSO に登録する時に表示される

vCenter Server を新 vCenter SSO に登録する時に表示される

7. 旧 vCenter SSO の情報を新 vCenter SSO へリカバリ

vSphere Web Client でログインし、作業 1 でメモした情報を入力します。

8. 旧 vCenter SSO をアンインストール

vCenter SSO のアンインストールはインストール媒体を使うか、コントロールパネルの「プログラムと機能」からアンインストールすることができます。
アンインストールしないと、次の作業で行う vCenter Server のアップグレード時に、もう使っていない vCenter SSO までアップグレードされてしまいます。

9. 新 vCenter SSO を PSC にアップグレード
10. vCenter Server をアップグレード

あとは、vCenter Server 6.0 のインストール媒体を使ってアップグレードするだけです。

Roll back of ESXi, further roll back

2015-07-03T05:50:00.002+09:00

今回は ESXi のロールバックについてご紹介します。

ESXi のロールバックは『Shift + R』で実行します。
で、どのタイミングで実行するのかというと、この起動画面の時です。

ESXiの起動画面

最初に、ESXiのインストールパーティションはどのようになっているかというと、こんなイメージになっています。
これからESXiをロールバックすることで、/bootbankと/altbootbankの状態の変化を見ていきます。

ESXiのパーティションイメージ

現在のESXiのインストールパーティションの情報を確認します。
青字の箇所が現在のBoot Partiton内の情報です。
----------------------------------
~ # vmware -v
VMware ESXi 5.5.0 build-1892794
~ #
~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       5.0G   2.1G      2.9G 41% /vmfs/volumes/datastore1
vfat         4.0G   8.8M      4.0G   0% /vmfs/volumes/53b4a926-32f4ebef-dd5d-0050569152b4
vfat       249.7M 130.2M    119.6M 52% /vmfs/volumes/17c62275-beda452f-73cf-0b3203cc9f9f
vfat       249.7M 157.0M     92.7M 63% /vmfs/volumes/184ee772-92c4e69d-a69d-4d71ce05557c
vfat       285.8M 192.7M     93.1M 67% /vmfs/volumes/53b4a415-b3d2eb67-9e9b-0050569152b4
~ #
~ # diff /bootbank/boot.cfg /altbootbank/boot.cfg
(中略)
-build=5.5.0-1.28.1892794
(中略)
+build=5.1.0-799733
~ #
----------------------------------
文字だけでは分かりにくいので絵にしてみました。

現在のパーティション情報

では実際ESXiのロールバックをやってみます。
先程の起動画面で『Shift + R』を押すと、このような画面が出てきます。
ここで<Y:Roll back>を実行します。簡単ですね。

ロールバック実行画面

ロールバックした後のBoot Partiton内の情報を確認します。
----------------------------------
~ # vmware -v
VMware ESXi 5.1.0 build-799733
~ #
~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       5.0G   2.1G      2.9G 41% /vmfs/volumes/datastore1
vfat         4.0G   9.4M      4.0G   0% /vmfs/volumes/53b4a926-32f4ebef-dd5d-0050569152b4
vfat       249.7M 130.2M    119.6M 52% /vmfs/volumes/17c62275-beda452f-73cf-0b3203cc9f9f
vfat       249.7M 157.1M     92.7M 63% /vmfs/volumes/184ee772-92c4e69d-a69d-4d71ce05557c
vfat       285.8M 192.7M     93.1M 67% /vmfs/volumes/53b4a415-b3d2eb67-9e9b-0050569152b4
~ #
~ # diff /bootbank/boot.cfg /altbootbank/boot.cfg(中略)
-build=5.1.0-799733
(中略)
+build=5.5.0-1.28.1892794
~ #
----------------------------------
文字だけでは分かりにくいので絵にしてみました。

ロールバック後のパーティション情報

/bootbankと/altbootbank内の情報が入れ替わっています。
・・・入れ替わるんですね。

入れ替わったので、もう一回ロールバックできるのか？なんて疑問が出てきたので、この状態からもう一度ロールバックを実行してみます。

再度ロールバックを実行

"No alternate hypervisor to rool back to."
ロールバックできませんでした。そんなに甘くはないですね。

まとめると、ロールバックは一回のみ実行できる！！
という事でした。

Performance of vSphere FT

2015-07-01T05:40:00.000+09:00

vSphere 6 の機能の中から、vSphere FT の性能を個人的に調べましたので、ご紹介します。
あくまで個人的な検証結果ですので、参考程度で見てください。
今回は Nested ESXi 上で検証しました。

■測定概要
　・1vCPU 構成で、SMP-FT、LegacyFT、vSphere 5.5 FT のそれぞれのDiks I/O 性能を測定
　・1vCPU / 2vCPU / 4vCPU 構成で、FT有効/無効でのDiks I/O 性能を測定

■測定ツール
　iometer

■環境
　・ESXi　：　Nested ESXi 6.0/5.5
　・Storage 　：　物理, iSCSI(1Gbps), RAID5(5D+1P), 3.5" 600GB 15krpm SAS
　・VM　： CentOS 6.2(32bit), 1vCPU, 1024MB-vRAM, 10GB-vmdk(Eaga　Zeroed)
Windows Server 2012, 1vCPU, 1024MB-vRAM, 10GB-vmdk(Eaga　Zeroed)

環境構成図

１．SMP-FT、LegacyFT、vSphere 5.5 FT の比較(CentOS 6.2(32bit))
※Nested ESXi では、Windows Server 2012 のLegacyFT、vSphere 5.5 FT が構成できなかったので、比較対象外としました。
・vSphere 5.5 FT の測定結果を『1』とした時の比率で表示

IOPSと平均レスポンスタイム(Sequential/Random)

２．1vCPU / 2vCPU / 4vCPU 構成で、FT 有効/無効での比較
　
　２－１．Sequential Access(CentOS 6.2(32bit))
　　　・FT 無効の測定結果を『1』とした時の比率で表示

IOPS と平均レスポンスタイム(Sequential)

　２－２．Random Access(CentOS 6.2(32bit))
　　　・FT 無効の測定結果を『1』とした時の比率で表示

IOPS と平均レスポンスタイム(Random)

　２－３．Sequential Access(Windows Server 2012)
　　　・FT 無効の測定結果を『1』とした時の比率で表示

IOPS と平均レスポンスタイム(Sequential)

　２－４．Random Access(Windows Server 2012)
　　　・FT 無効の測定結果を『1』とした時の比率で表示

IOPS と平均レスポンスタイム(Random)

FT VM on Nested ESXi 6.0

2015-04-11T01:39:00.000+09:00

vSphere 6 の Fault Tolerance から、SMP に対応しました。
最大 4 vCPU の仮想マシンで vSphere FT を構成することが可能です。

簡単に動作確認する方法として、Nested ESXi 6.0 上で vSphere FT を構築する方法をご紹介します。

ちなみに今回は、
Xeon 5600番台(Westmere)のサーバ(ESXi 5.5)上に Nested ESXi 6.0 を構築しました。

構築するにあたってのポイントは 2 つです。
・ Nested ESXi 6.0 の仮想マシンで Hardware virtualization を有効にする
・ Nested ESXi 6.0 の仮想マシンに VMXNET3 の NIC を追加する(FT logging 用)

手順の概要は以下の通りです。
操作は vSphere Web Client を利用します。

------------------------------------------------------
1. 仮想マシンを ESXi 5.1 以降の互換性で作成する。(Nested ESXi 6.0用)
2. 作成した仮想マシンで Hardware virtualization を有効にする。
3. VMXNET3 の仮想 NIC を追加する。
4. Guest OS Virsion を VMware ESXi 5.x に変更する。
5. 作成した仮想マシンに ESXi 6.0 をインストールする。
6. Nested ESXi 上で FT Network を設定する。
7. Nested ESXi 上の仮想マシンで Fault Tolerance をオンにする。
------------------------------------------------------

1. 仮想マシンを ESXi 5.1 以降の互換性で作成する。(Nested ESXi 6.0用)
　　この時、Guest OS は Other(64-bit)のままにしておきます。
　　これは VMXNET3 の NIC を追加する為です。VMware ESXi 5.x を指定してしまうと
　　VMXNET3 が追加できません。

全ての設定が終わるまで Other(64-bit) のまま変更しない

2. 作成した仮想マシンで Hardware virtualization を有効にする。

Hardware virtualization をチェックする

3. VMXNET3 の仮想 NIC を追加する。
　　経験上、Nested ESXi 6.0 と VMXNET3 の相性が悪く、通信が途切れることが
　　多々ありますので、FT Logging 用だけにしておいたほうが良いです。

VMXNET3 の vNIC を追加する

実は Nested ESXi ではサポートされていない

Nested ESXi 上ではこのように表示されます

4. Guest OS Virsion を VMware ESXi 5.x に変更する。

VMXNET3 の vNIC を追加している為、
アラートが表示されるが気にしない

5. 作成した仮想マシンに ESXi 6.0 をインストールする。

(絵は省略)

6. Nested ESXi 上で FT Network を設定する。

FT 用の vmkernel を VMXNET3 の NICに接続する

7. Nested ESXi 上の仮想マシンで Fault Tolerance をオンにする。

FT をオンにする

Install Error of vCenter Server 6.0

2015-04-07T01:20:00.001+09:00

vCenter Server 6.0 をインストールしたときに発生したエラーについてご紹介します。

vCenter Server 6.0 のインストールは、PSC（Platfom Services Controller）と vCenter Server の 2 つに分けられています。

PSC と vCenter Server を同居して構築したり、別サーバで構築することが可能です。

今回は PSC と vCenter Server を別サーバで構築し、下図のような環境を作りました。

2つのサイトを構築

図の左サイトを構築し、vCenter SSO のパスワードポリシーを 0(無期限)に変更した後、

右サイトで、vCenter Server をインストールしている時にエラーが発生しました。

vCenter SSO のパスワードの最長有効期間を 0(無期限)に設定

これがエラーメッセージ①です。(vminst.log)

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

ProcdessMsiMsg: ACTIONDATA reporting "VMware vSphere Auto Deploy Waiter を開始しています..."

(省略)

ParseStatusFile: curr error msg: "内部エラーが発生しました。

see C:\ProgramData\VMware\vCenterServer\logs\firstboot\autodeploy-firstboot.py_3316_stderr.log"

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

エラーメッセージ②です。(autodeploy-firstboot.py_3316_stderr.log)

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

RC = 9999

Stduot =

Stderr = error: Failed to find AD user details: 50(dir-cli failed. Error 50: Possible error:

LDAP error: Insufficient access

Win Error: この要求はサポートされていません。

)

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

ひとまずエラーメッセージを調べると、以下の KB に同じエラーメッセージが載っていました。

http://kb.vmware.com/kb/2110025

合致する内容ではありませんが、vCenter SSO のパスワードポリシーで、”最長有効期間”を

0(無期限)に設定している場合に発生するエラーのようです。

今回の環境では、PSC 間でデータが複製されるので、右サイトの PSC も同じパスワードポリシーになってエラーが発生しました。

KB のようにパスワードポリシーを 0(無期限) 以外に設定することで、無事右サイトの vCenter Server をインストールすることができました。

How to recover vCenter in vSanDatastore

2015-04-03T01:43:00.002+09:00

VSAN（Virtual SAN）は、サーバの内蔵ディスク( SSD や HDD )を共有ストレージとして利用できる機能です。
共有ストレージと言えば、 vSphere HA や vSphere DRS など利用するうえで、なくてはならないものですよね。

VSAN で形成される共有ストレージのことを VSAN データストアと呼びます。
VSAN クラスタ配下に 1 つの VSAN データストアを形成し、各サーバの内蔵ディスクに仮想マシンのファイル群を自動で分散配置します。
その際、仮想マシンファイル群はミラーリング( RAID 1 相当)されます。仮想ディスクについては、さらにストライピング( RAID 0+1 相当)することも可能です。これら RAID 相当の管理により、コンポーネントとしての可用性を担保している訳です。
補足ですが、ESXi をインストールした内蔵ディスクは VSAN データストアとして利用できないので注意して下さい。

VSAN クラスタは vSphere HA や vSphere DRS を構成するのと同じくらい簡単にできます。
HA クラスタや DRS クラスタを有効にするのと同様に、チェックボックスにチェックを入れることで、VSAN クラスタを構成することができます。

VSAN クラスタを有効化する

勘の良い方は HA/DRS クラスタと同様に、VSAN クラスタを構成するには vCenter Server が必要なのでは？と思われたのではないでしょうか。
正解です。
VSAN クラスタを構成するには、vCenter Server が必須です。（厳密に言うと、簡単に構成するには。）

さて、うだうだ VSAN について書きましたが、ここからが本題です。
VSAN クラスタは簡単に構成できることは説明しましたが、同じように簡単に無効にすることもできます。注意する点としては、VSAN クラスタを無効化すると、VSAN データストアに配置している仮想マシンにアクセスすることができなくなります。（ VSAN データストアが消える為）

もし、vCenter Server を仮想マシンとして構成し、VSAN データストア上に配置している環境でVSAN クラスタを無効化してしまうと、vCenter Server にアクセスできなくなり、VSAN クラスタを再構成することができなくなってしまいます。考えただけでも恐ろしいですね。

VSAN クラスタを無効化するときの警告

VSAN クラスタを無効化すると、

仮想マシンはアクセス不可になる

でも VSAN クラスタを復旧する手段があります。
今回はその手順をご紹介します。
※ VSAN 1.0 で実施したものです。まだ VSAN 6.0 では試せていません。

実施する手順は以下の通りです。

1. ESXi ホストにダイレクトコンソールや ssh でログインする

2. VSAN クラスタの UUID(Sub-Cluster UUID) を確認する

　　cat /var/log/vsanvpd.log | grep “:Cluster uuid" | head -n 1

3. VSAN クラスタ情報を取得する

　　esxcli vsan cluster get

4. VSAN クラスタから ESXi ホストを外す
　　(ただし、手順3で VSAN クラスタ情報が取得できなければこの手順は行わない)

　　esxcli vsan cluster leave

5. VSAN クラスタへ ESXi ホストを追加する

　　esxcli vsan cluster join –u　UUID

6. VSAN クラスタ情報が表示されることを確認する

　　esxcli vsan cluster get

7. 手順1～6 までを VSAN クラスタ配下の全ての ESXi ホストで実行する

8. vCenter Server が登録されている ESXi ホストへ vSphere Client でログインし、
　　vCenter Server の仮想マシンを起動する

9. vSphere Web Client で vCenter Server にログインし、VSAN クラスタを有効化する

コマンド部分はこんな感じで実行します。

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

~ # ls /var/log/vsan*.log

/var/log/vsanvpd.log

~ #

~ # cat /var/log/vsanvpd.log | grep ":Cluster uuid" | head -n 1

2014-MM-DDT03:57:27Z vsanSoapServer: ExtractClusterUuid:199:Cluster uuid: 521e8255-4e80-a785-26f7-dd407352e7f2

~ #

~ # esxcli vsan cluster get

VSAN Clustering is not enabled on this host

~ #

~ # esxcli vsan cluster join -u 521e8255-4e80-a785-26f7-dd407352e7f2

~ #

~ # esxcli vsan cluster get

Cluster Information

Enabled: true

Current Local Time: 2014-MM-DDT07:15:34Z

Local Node UUID: 53a7d492-9256-3534-f431-005056913994

Local Node State: BACKUP

Local Node Health State: HEALTHY

Sub-Cluster Master UUID: 53a7d68b-8859-f918-0657-005056915059

Sub-Cluster Backup UUID: 53a7d492-9256-3534-f431-005056913994

Sub-Cluster UUID: 521e8255-4e80-a785-26f7-dd407352e7f2

Sub-Cluster Membership Entry Revision: 2

Sub-Cluster Member UUIDs: 53a7d68b-8859-f918-0657-005056915059, 53a7d492-9256-3534-f431-005056913994

Sub-Cluster Membership UUID: 07abab53-c607-cf78-3cc6-005056915059

~ #

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