従来からの存在するvSphere Client (C#)との決別

こんにちは。

vSphere 6.5 がリリースされましたね。
いろんな機能が追加されています。

私としてはすごく悲しくなったのは、従来から存在していたvSphere Clientが
なくなったということです。（C#版というみたいですが）

VMwareの公式Blogにかかれていることや私でも試してみましたので、
ご参考に頂ければと思います。

まず、VMware公式Blogの内容を抜粋します。

+ Goodbye vSphere Client for Windows (C#) – Hello HTML5
https://blogs.vmware.com/vsphere/2016/05/goodbye-vsphere-client-for-windows-c-hello-html5.html

Today we have two important announcements.  First, the C# client (AKA Desktop Client/thick client/vSphere Client for Windows) will not be available for the next version of vSphere.  

実際にWindows 版 vCenter Server 6.0から vCenter Server 6.5 にバージョンアップしました。

まず、vCenter Server6.5 のIP Addressをブラウザで指定して開きました。
何か増えています。
・Flash版vSphere Web Client ←今まで通りのWeb Client（vCenter）
・HTML5版 vSphere Client (vSphere Clientという名前ですが
　ブラウザベースのWeb Client です(vCenter))

＋vCenter Server 6.5の画面

＋vCenter Server 6.0の画面

■Flash版 vSphere Web Client

これは今まで通りのvSphere Web Clientになります。

ログインしても、vCenter 6.0のときと変わりません。

では気になる、HTML5版 vSphere Client を見てみましょう。
VMwareのドキュメントセンターみたいな画面になっています。
まだHTML5 版は未完成品のようなので、従来のvSphere Web Client を使うといいです。

この辺で。

ESXi - 仮想マシンのインプレースアップグレードはサポートされていない。

みなさま、こんにちは。

今回はVMware製品上の仮想マシンのOSのバージョンアップについてです。

私は仕事柄、ESXiを触り倒すので、ESXi視点で記載します。

最近よく、ESXi上で動作している仮想マシンのOSバージョンアップをする際、
インプレースアップグレードするお話をよく聞きます。
そして、サービスパックレベルではなくメジャーバージョンアップをする話も多いです。

例えば、Windows Server 2008 R2 -->Windows Server 2012 R2 といった具合に。

実はこのバージョンアップですが、VMware製品（今回はESXi）では、
サポートされていないオペレーションになります。

+ VMware support for guest operating system upgrade

https://kb.vmware.com/kb/2018695

つまり、ESXi上で稼働するWindows Server 2008 R2は2012R2に
インプレースアップグレードするなということです。

VMware KB 2018695の一部を抜粋します。
VMware does not support the installation of major update releases on an operating system as an upgrade in a virtual machine, 

例を挙げると、Windows Server 2008 R2として仮想マシンを作成したとき、
ESXiは2008R2に最適な仮想ハードウェア構成で仮想ハードウェアが作成されます。
（SCSIコントローラーの種類などです）
そこに2008R2をインストールします。

そして次に、ゲストOSを2008R2から2012 R2 にアップグレードした場合、
仮想ハードウェアは2008R2 のときに構成されたもののままでありながら、
2012R2となってしまうため、最適な仮想ハードウェア構成に
なっていない可能性が出てきたりするわけです。

Windowsだけであれば組み合わせのテストをしてロジックを付け加えるのも
いいかもしれませんが、Linuxやその他OSなども含めると膨大な量になり、
それをVMware社がすべての組み合わせのテストを行うのは現実的ではありません。

安全性も考慮した答えが、Not Support という結論なのだと思います。

マイナーバージョンアップはサポートされているので、安心してください。
VMware supports the installation of minor update releases on an operating system as an upgrade in a virtual machine,

今後、2008R2 -> 2012R2 や2012R2 -> 2016などもあり得ますし、
RHEL5.x-> 6.x などもあるでしょうから、注意したいところですね。

以上！

【Windows Server 2016 でVMwareToolsのインストール後、マウントが外れる】

みなさん、こんにちは。

今回はESXi6.0上にWindows Server 2016 をインストールして、

VMwareToolsをインストール完了間際に、VMwareToolsメディアのマウントが外れるという内容です。

インストール中の画面です。

インストールが完了しました。

[完了]ボタンを押すと、再起動を促されます。

[はい]をクリックし、再起動を実施します。

すると、高確率でマウントが外れます。

インストール後にマウントが外れているため、
実害はありませんが、私の手元の環境ではほとんとの確率でマウントが外れます。

[キャンセル]もしくは[続行]をクリックすればいいだけです。

今回はこのへんで。

【ESXi上で動作するWindows Server 2016 にHyper-Vの役割を入れて仮想マシンを稼働させる】

みなさんこんにちは。

今回は、検証をするときに役に立つ情報を書きます。

内容は、ESXi上でゲストOSとしてWindows Server 2016 を稼働させ、
Windows Server 2016 にHyper-Vの役割をインストールし、
Hyper-V上で仮想マシンを稼働させる方法をご紹介します。

最近では仮想化されたゲストOS上で検証や開発を行うことが多いと思います。
そして、ゲストOSを多く動作させるにはそれだけ物理ホストが必要になってきます。

しかし、勉強や検証目的だけのために、超高額な物理ホストを何台も購入することは
お財布事情から考えてほぼ不可能だと思います。

当然ながら運用上VMware社としてサポートされない環境ではありますが、
動作検証などを行う上では十分使えるので、興味がある方はお試し頂ければと思います。

環境情報と実施したことを順に書いていきます。

【環境】
Serer : HP ProLinat DL360 G6 
OS : ESXi 6.0 Update 2
Guest OS : Windows Server 2016 Datacenter（製品版）
　　（※HPE はDL360 G6にESXi6.0 を入れて使うことを正式サポートしていません）
+ (HWサポート状況の確認)HPE Servers Support & Certification Matrices

http://h17007.www1.hpe.com/us/en/enterprise/servers/supportmatrix/vmware.aspx#.WAI8YY-LQ6R

※仮想マシンハードウェアバージョンは11でなければいけません。

　仮想マシンハードウェアバージョンが10だとHyper-Vの役割はインストールできるのですが、
Hyper-V上の仮想マシンを起動させるときにエラーとなります。
（CPUが仮想化に対応していないといったエラーが発生します）

【作業1】
まずは普通に仮想マシンを作成します。

設定は全部デフォルトのまま作成しました。

 ※仮想マシンはパワーオフにしておきます。

【作業2】

ESXiホストにSSH接続します。私はTeratermを使います。

仮想マシンを保存したディレクトリまで移動します。

cd /vmfs/volumes/＜データストア名＞

 仮想マシン名のディレクトリに移動します。

 ls コマンドで中をみると、.vmx ファイル（構成ファイル）があることがわかります。

 vi コマンドで .vmx ファイルを開き、一番下に以下の２つを追記して保存します。

vhv.enable = "TRUE"
hypervisor.cpuid.v0 = "FALSE"

【作業3】

仮想マシンをパワーオンし、Windows Server 2016 を普通にインストールします。

Windows Server 2016 のインストールが終わったので、Hyper-Vの役割をインストールします。

ハードウェア要件がここで行われます。
何も設定を変更しなければ、ここでエラーが表示されHyper-Vの役割にチェックをつけることができません。

Hyper-Vの役割のインストール開始。

再起動します。

Hyper-V Manager を起動し、仮想マシンを作成していきます。

Hyper-V上の仮想マシンを起動させることができました。

仮想マシンのコンソールを開いてみましょう。

きちんと起動できていることが確認できました。

OSまでインストールはしていませんが、起動できているので問題ないとおもいます。

今回はこのへんで。

ESXi の APD(All-path-Down)はご存知でしょうか。

こんにちは。

今回はESXiの運用をしたことがある人であればだいたいの人が
遭遇したことがありそうなAPD(All-path-Down)内容になります。

中規模・大規模環境になってくると共有ディスクを利用し、
それぞれのESXiから参照することが一般的な構成かと思います。
図で表すと以下のような接続図です。

そして、共有ディスクへの接続パスは冗長性の観点から、
複数あることが望ましいことは言うまでもありません。
しかし、ストレージ側の障害よってストレージがパワーオフしてしまった場合は、
どうでしょうか？いくらESXiからストレージへ複数のパスを使って接続できるように
なっていても、ストレージがパワーオフになってしまえば、完全に無意味です。
このような状態に陥った状態のことをAPDやPDL状態といいます。

もう少し定義について詳細がVMwareのストレージガイドに記載されています。
vSphere 6.0 ストレージガイド　124ページ
◇抜粋◇
全パス ダウン (APD）
ストレージ デバイスがホストに対してアクセス不能となり、
デバイスへのパスが使用できなくなった場合に発生する状態です。
通常デバイスのこの問題は一時的なものであり、デバイスが再び
使用できるようになることが期待できるため、ESXi は、
これを一時的な状態として扱います。

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

上記の例で示したストレージ側の障害では、障害復旧後は再度障害前に
提供していたボリュームをESXiに提供することが想定されます。
つまり、APDということです。

APDについてもうすこし理解を深める場合は、
VMware KB 2081089 が大変参考になります。
+ vSphere 5.x および 6.x での永続的なデバイスの損失 (PDL) と全パス ダウン (APD)
https://kb.vmware.com/kb/2081089

全パス ダウン (APD)

PDL SCSI 認識コードがデバイスから戻されない場合（ストレージ アレイに接続できない場合、
またはサポートされる PDL SCSI コードを戻さないストレージ アレイの場合）、
そのデバイスは全パス ダウン (APD) 状態にあり、ESXi ホストは応答を受信するまで I/O 要求を送信し続けます。

 

このように記載もされています。

 

つまり、APD状態に陥ったESXiホストは I/O要求を送信し続けます。

これは何を意味するのかというと、ESXiは軽量なOSです。

多くのリソースを仮想マシン側に提供したいので、
限られたリソースの範囲で稼働しています。

しかし、ESXiからストレージに対してI/O要求を送信し続けるということは、
それだけDriverからSCSIコマンドが発行され続け、ESXiが利用可能なリソースの
限り延々と要求し続けます。

その結果、時間が経つとESXiはその他のESXiの稼働に必要なリソースまで使ってしまい、最後にはESXiはvCenter Server から見ると "応答なし" なホストになってしまいます。

ここまでくると、もはやSSH接続もできなくなることが多いです。
当然稼働していた仮想マシンたちも移行（vMotion/Storage vMotion）もできないことが

多いです。

ではどうしたらいいのか。
対処方法はまずESXiホストの再起動です。

（VMware KB 2081089）

• APD 状況は、ストレージ アレイ/ファブリック レイヤーで解決して、ホストへの接続を復元する必要があります。
• 影響を受けるすべての ESXi ホストでは、再起動して、影響を受ける APD 状態のデバイスに対する残存参照すべてを取り除く必要があります。

APDにならないようにするには、きちんと事前に、利用しないボリュームを
vSphere Client からアンマウントしたあと、デバイスを分離します。
これは大変重要な作業です。この作業をしないままストレージ側でLUNを削除したり
すると、APD状態に陥ります。

Windows Server などの感覚で、適当な操作をしていると痛い目に遭うので、
ストレージを操作するときは十分に注意し、操作を行うことをお勧めします。

今回はこのへんで。

SSDのStorageを使うときには。(VMware KB 2013188)

近年、SSDの需要が高まっていることは周知のとおりかと思います。
特に、ディスクI/O が高速であることもさながら、価格も下がってきており、
採用される企業も増加傾向にあります。

私が知る限りでも、増加傾向にあります。

ESXi でSSD ベースのディスク/LUN Arrayを利用する場合は、オプションを有効にする必要があります。

そのため、きちんとVMware KB が公開されています。

Enabling the SSD option on SSD based disks/LUNs that are not detected as SSD by default (2013188)

https://kb.vmware.com/kb/2013188

確認方法は簡単で、esxcli コマンドを実行して確認します。
---------------------------------------------------------------------------------

esxcli storage core device list
naa.60002ac000000000000000100xxxxxx
Display Name: 3PARdata Fibre Channel Disk (naa.60002ac00000000000000xxxxxx)

Has Settable Display Name: true
Size: 409600
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.60002ac000000000000000xxxxxxxx
Vendor: 3PARdata
Model: VV
Revision: 3222
SCSI Level: 6
Is Pseudo: false
Status: on
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: false
Is VVOL PE: false
Is Offline: false

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

赤字の箇所です。

日本語版のVMware KB 2092902　も公開されていますが、端折られている内容も多く、

英語版を見るほうがより確実です。

デフォルトでは SSD として検出されない SSD ベースのディスク/LUN に対して SSD オプションを有効にする (2092902)

https://kb.vmware.com/kb/2092902

このような部分は、ほとんどの場合は導入および構築したベンダーや企業で行われていることがほとんどです。

しかし、サイジング時の想定よりI/Oパフォーマンスが出ていない場合などは、念のために確認してみるのもよいかと思います。

今回はこのへんで。