VMware製品はこう使う。

好きなことを好きに描く、ん~のびしろですね!

仮想マシンのサマリに「仮想マシンのディスク統合が必要です。」と表示される。

今回の内容は未だによく質問をいただく内容です。

 

vSphere Client およびvSphere Web Clientで仮想マシンの情報をみたときに、

「仮想マシンのディスク統合が必要です。」と表示されるという内容です。

vSphere Clientの画面だと以下のような表示です。

f:id:japan-vmware:20180918134433p:plain

 

このメッセージの意味ですが、対象の仮想マシンに過去のスナップショットファイル

つまり delta ファイルが残存していることを示しています。

deltaファイルがあるため、統合してください、とESXiがお知らせしてくれています。

 

対処方法としては、仮想ディスクの統合処理を行うか、仮想マシンをクローンしてクローン後の仮想マシンをこれからは使っていくことです。

 

そこで出てくる質問としては、「なぜスナップショットファイルが残存してしまったのか?」ですが、これは多くの場合、仮想マシンのバックアップが失敗した際に発生する事象です。

 

事象が発生する環境ではバックアップソフトで仮想マシンのバックアップを取得していないでしょうか。ESXiのスナップショットを使用したバックアップソフト(Acronis, Netbackup, BackupExec etc...) を使用していないか確認してみてください。

 

vSphere 4.xまでは、統合機能が実装されていなかったため、残存しているスナップショットファイルに気づかず、ひたすらファイルサイズが膨れ上がり、データストアをひっ迫させるなど、仮想環境に深刻な影響を与えていました。

深刻なもう1つの理由としては、GUI(vSphere Web Clientなど)からは存在を確認しずらいという点もあります。スナップショットファイルなので、スナップショットの管理から見れるでしょ、と思いがちですが、実際にはみることはできません。

キレイさっぱりありません。

f:id:japan-vmware:20180919014651p:plain

 

 

しかし、vSphere 5.xより統合機能が実装されたことで、意図せず残存したスナップショットに気付けるようになり、かつ、vSphere Client の統合メニューでスナップショットファイルを統合することができるようになりました。(ありがたい話です)

 

delta.vmdkファイルの存在確認方法としては ESXiにSSH接続して、以下のディレクトリを見ることでわかります。 

/vmfs/volumes/<datastorename>/vmName

f:id:japan-vmware:20180919011507p:plain

参考程度に事象が発生している 仮想マシンを見てみると、-delta.vmdk ファイルが多くあることがわかるかと思います。

 

事象発生時は vSphere Web Client であれば、仮想マシンを右クリックして、[スナップショット] - [統合] をクリックします。

※参考画像なのでグレーアウトしていますが、症状が出ているときは押せます。

f:id:japan-vmware:20180919012942p:plain

 

よく統合処理にかかる時間について知りたいといった意見がありますが、一概に言えないというのが実情です。

影響するのは delta.vmdkファイルの数、ファイルサイズ、ストレージ性能 などが一般的ですが、いずれにしても計測するのは困難です。

 

また、「統合処理が長い!どうしたらいいのか!」というご意見もいただきますが、基本は待つしかありません。下手に手動で操作をすると仮想ディスクが破損するなどの危険性があり、仮想マシンが帰らぬ人になってしまいます。

 

ひたすら待ち、タイムアウトになったときはその他の方法を検討します。

 

その他の方法とは、仮想マシンのクローンです。

 

仮想マシンのクローンは、統合の処理と似た処理(ファイルを結合)を行いますが、1つ大きな差があります。統合の処理は、現在存在するdelta.vmdkの統合処理を行うのにたいして、仮想マシンのクローンは、統合しながら、新しい仮想ディスクを生成する点です。

クローンで出来上がった仮想マシンでは、delta.vmdkファイルはすべて統合された形で出来上がります。これからはクローンで出来上がった仮想マシンを使っていきます。

 

ただ、1つ懸念事項としては、クローンを行うということは、インベントリ名を一時的にでも元の仮想マシンとは異なる名前にしなければならず、運用上許容されない環境も存在しますので、予め確認しておいたほうがいいでしょう。

 

その他の方法で、稀に試すことがあるのは、delta.vmdkファイルが多くあり、サマリにもにもかかわらず、「仮想マシンのディスク統合が必要です。」と表示されているにもかかわらず、統合のボタンがグレーアウトして押せないということも稀にあるようです。そのときは一時的にvSphere Web Client から1つスナップショットを作成し、

[すべてのスナップショットの削除]をクリックすることで、統合 とほぼ同じ処理が行われます。遭遇した際にはお試しいただければとおもいます。

f:id:japan-vmware:20180919015129p:plain

 

おわり

 

About Azure Migrate - Azure Migrate でオンプレミスのESXi上で動作する仮想マシンをAzureへ移行したときの事前評価をする。

こんにちは。

 

今回は少し趣向を変えて、vCenter/ESXi と Microsoft Azure の Azure Migrateについて ポストしたいと思います。

 

Azure Migrate は、オンプレミスのvCenter配下のESXi上で動作する仮想マシンをAzureへ移行したときに、どの程度の金額になるのか、などの事前評価ができるものになっています。

同じことがMicrosoft のAbout Azure Migrateのページに記載されています。

+ About Azure Migrate

https://docs.microsoft.com/en-us/azure/migrate/migrate-overview 

記事にも記載がされていますが、Azure migrate は移行を行うサービスではないので、ご注意ください。

 

抜粋)

The Azure Migrate service assesses on-premises workloads for migration to Azure. The service assesses the migration suitability of on-premises machines, performs performance-based sizing, and provides cost estimations for running on-premises machines in Azure. If you're contemplating lift-and-shift migrations, or are in the early assessment stages of migration, this service is for you. After the assessment, you can use services such as Azure Site Recovery and Azure Database Migration Service, to migrate the machines to Azure.

assesses on-premises workloads と書いていますね。

 

では、どのようなものなのか見ていきたいと思います。

 

Microsoft Azure Portal で ”migrate” などで検索すると Azure Migrateが出てきます。

画面右下の[作成]ボタンをクリックします。

f:id:japan-vmware:20180911010421p:plain

 

任意の名前を入れ、リソースグループ、場所、を選択して、[作成]ボタンをクリックします。

f:id:japan-vmware:20180911015014p:plain

 

まずすることは、コレクターアプライアンスと呼ばれる仮想マシンのテンプレートファイルをダウンロードするところからです。.OVA ファイルで約10GBあります。

[ダウンロード]ボタンをクリックします。

コレクターアプライアンスの中身は、Windows Server 2012 R2 Datacenter 英語版でライセンス切れしているものです。既にVMwareToolsはインストール済でした。

f:id:japan-vmware:20180911222956p:plain

 

ダウンロードが完了したら、.OVAファイルを使ってESXiにデプロイします。

(一般的なvSphere の操作です)

デプロイ後は「AzureMigrate_1_0_9_12」という仮想マシンがデプロイされます。

パワーオンします。

f:id:japan-vmware:20180911224938p:plain

 

パワーオン後は、Administratorユーザーのパスワード設定を行い、ログインします。

デスクトップに Run Collecor というアイコンがあるので、クリックしたいところですが、先にIP Address の割り振りや、インターネット接続できるようネットワーク設定をします。

その後、Run Collecor アイコンをクリックします。

f:id:japan-vmware:20180911230451p:plain

 

IE が起動し、Azure Migrate Collector が表示されます。

ここでは4つの項目のチェックが入ります。

 -インターネット接続確認

 -時間のズレがないか確認

 -Azure Migrate Service が実行できるか確認

 -VMware PowerCLI のインストール

 

インターネット接続には画面上からWEBプロキシの指定ができるので、ご安心ください。

時間はきちんとNTPを指定しなければいけないです。また、タイムゾーンを変更したらずっとエラーで怒られ続けたので、デフォルトのままがよいかもしれません。

f:id:japan-vmware:20180911230721p:plain

f:id:japan-vmware:20180911231527p:plain

f:id:japan-vmware:20180911231546p:plain

 

事前準備が終わったらやっと、vCenter Serverの情報をいれていきます。

なぜvCenter の情報を入れないといけないかというと、vCenter からインベントリ情報や、パフォーマンス情報などを収集するためです。

必要な情報を入れて [Connect]ボタンをクリックします。

 ※対応するvCenter Serverバージョンは、 5.5, 6.0, or 6.5 です。

f:id:japan-vmware:20180911231931p:plain

 

警告が出ていますが、情報が少ないということで ! が出ているだけなので、

今回はそのまま進めています。

f:id:japan-vmware:20180911232315p:plain

[Hosts and Clusters] から情報収集する対象を選択します。

選択後3分程度で、仮想マシンの数が表示されます。ここでは83台でした。

f:id:japan-vmware:20180911232603p:plain

Project ID と Project Key を入力します。

f:id:japan-vmware:20180911232846p:plain

これはどこから入手するかというと、Azure Portal に表示されています。

コピペして入力し、[Comtinue]ボタンをクリックします。

f:id:japan-vmware:20180911233008p:plain

 

プロジェクトに接続されました。

f:id:japan-vmware:20180911233126p:plain

 

ここからは待つだけです。

f:id:japan-vmware:20180911233224p:plain

注意が必要なのは、✔Collection Complete と表示されても、しばらくは、

Azure Poralに反映されません、1時間以上待つ必要があります。

 ※私は放置していたので実際のところはわからなかったです。

f:id:japan-vmware:20180911233318p:plain

 

長時間経過後、以前までグレーアウトしてクリックできなかった [評価の作成] ボタンがクリックできるようになっています。早速クリックします。

f:id:japan-vmware:20180911233543p:plain

 

評価をする仮想マシンをグループ化して評価するので、私はここでは3台だけ選択し、評価の作成を行いました。

f:id:japan-vmware:20180911233853p:plain

 

すぐに通知が表示されます。

f:id:japan-vmware:20180911234049p:plain

 

評価が作成されました。さっそくクリックします。

f:id:japan-vmware:20180911234319p:plain

 

概要をみます。

Azureの対応性・月間コスト・ストレージ月間コスト が表示されます。

ここでなるほどー と思うわけです。

f:id:japan-vmware:20180911234755p:plain

 

コスト詳細 をみます。

f:id:japan-vmware:20180911235049p:plain

 

Azure 対応性を見ます。

私としては一番重要なのは このAzure 対応性の画面だと思っています。

 

私が評価に選んだ仮想マシン3台の内訳です。

 -Windows 7 64 bit

 -ESXi6.0(HypervisorをNested したものです。

 -Windows Server 2012 R2

私が驚いたのは、Nested ESXiをきちんと認識しているところでした。

そして、推奨されるツールとしてAzure Site Recorery と表示されているので、ユーザーとしてわかりやすいです。

また、プランも表示してくれているので、良心的です。

f:id:japan-vmware:20180911235542p:plain

 

 この評価の内容は、Excel形式でエクスポートできます。

f:id:japan-vmware:20180912000129p:plain

 

3つのシートに分かれており、それぞれ画面を貼ります。

f:id:japan-vmware:20180912000503p:plain

 

[Assessment_Summary]f:id:japan-vmware:20180912000309p:plain

 [All_Assessed_Machines]

f:id:japan-vmware:20180912000428p:plain

 [Assessment_Properties]

f:id:japan-vmware:20180912000611p:plain

 

 

今回はAzure Migrate を少し使ってみた の回でした。

 

評価が終わったらAzure Site Recoreryで移行を試したいところです。

 

(´・ω・`)AzureMapを使う時間は取れなかった…

 

オワリ

ESXi 5.0 , 5.1 のサポートが 2018/08/24 VMware社で終了しました。

 

あまり公になっていませんが、

2018/8/24 に ESXi5.0 , ESXi5.1 の TECHNICAL GUIDANCE フェーズが

終了になりました。

 

これが何を意味するかというと、VMware社に問い合わせをすることができません。

問い合わせをしても断られます。

VMware社のサポートポリシーに従ってサポート提供しているOEMベンダにおいてもほぼ同様です。

 

少しでも何かサポートに問い合わせをしたければ、

バージョンアップは  必須 です。ゴネてもダメです。

 

よくあるのが、こんな重大障害が起こっているのに!と言いながら、

ESX4.1 を使っていることもアルアルです。きちんとしたトラブルシューティングを

したいのであれば日頃からきちんとサポート期間には気をつけるべきです。

 

Support Lifecycle が記述されている公開ドキュメントがありますので、

ぜひブックマークをお願いします。個々数年URLは変わっていません。

 

+ VMware Lifecycle Product Matrix 

http://www.vmware.com/files/pdf/support/Product-Lifecycle-Matrix.pdf

f:id:japan-vmware:20180901005617p:plain

 

END OF GENERAL SUPPORT と END OF TECHNICAL GUIDANCE の

説明については、VMwareのサイトに明確に記載があります。

 

+ VMwareサポートポリシー ライフサイクルサポートフェーズ

https://www.vmware.com/jp/support/policies/lifecycle.html

 

ジェネラル サポート フェーズ
ジェネラル サポート フェーズは、メジャー リリースの一般発売日 (GA) から
始まり、指定された期日で終了します。
ジェネラル サポート フェーズの期間中、VMware サポートを購入されたお客様には、メンテナンス アップデートとアップグレード、
不具合とセキュリティの修正、および技術的な支援が提供されます。

詳細は、 VMware のサポートおよびサブスクリプション サービスの利用条件に定義されています。

 

テクニカル ガイダンス フェーズ
テクニカル ガイダンス フェーズを適用される製品では、ジェネラル サポート フェーズの終了時から指定された期間、
テクニカル ガイダンス フェーズが提供されます。 テクニカル ガイダンスは、主にセルフ ヘルプ ポータルを通じてご利用いただけます。
電話によるサポートは提供されません。 サポート対象の構成上のビジネス クリティカルではない問題については、
オンラインでサポート リクエストを発行し、サポートを受けることができます。
テクニカル ガイダンス フェーズの期間中は、特に指定されているものを除き、新規ハードウェアのサポート、
サーバ / クライアント / ゲスト OS のアップデート、新規のセキュリティ パッチやバグ修正は提供されません。
このフェーズは、システムが適度に安定した負荷の下で運用されている、安定した環境での用途を想定しています。

 

今回はサポート的観点の投稿でした。

 

vm-support -w コマンドで構成情報やログをデータストアに出力する。

ESXiはログバンドルをvm-support コマンドでデータストアに出力することができます。

 

-TeratermなどでESXiにSSH 接続します。

-以下コマンドを実行します。

  vm-support -w /vmfs/volumes/<任意のdatastorename>

-ログバンドルの生成がはじまります。

f:id:japan-vmware:20180830122444p:plain

(text)

[root@aoshima:/vmfs/volumes] vm-support -w /vmfs/volumes/LocalDisk_Raid0
03:06:24: Creating /vmfs/volumes/LocalDisk_Raid0/esx-aoshima.17f.local-2018-08-30--03.06.tgz

*ログバンドルの生成は結構時間がかかります。環境依存ですが長い環境だと20分超えることも

 

完了するとこのような画面がでます。tgz形式でファイルが生成されます。

f:id:japan-vmware:20180830123057p:plain

(text)

Please attach this file when submitting an incident report.
To file a support incident, go to http://www.vmware.com/support/sr/sr_login.jsp
This host has been configured via syslog to send logs to udp://vR-LogInsight:514.
The relevant logs from udp://vR-LogInsight:514 should also be manually added to the incident report.

To see the files collected, check '/vmfs/volumes/LocalDisk_Raid0/esx-aoshima.17f.local-2018-08-30--03.06.tgz'

 

もし、「-w」オプションなしで実行した場合は、tmp配下に生成されます。

f:id:japan-vmware:20180830123225p:plain

(text)

[root@aoshima:/vmfs/volumes] vm-support
03:14:54: Creating /var/tmp/esx-aoshima.17f.local-2018-08-30--03.14.tgz

 

サポート部隊では、取得したtgz ファイルはLinux環境で確認していることが多いです。

 

*私のESXiホストのホスト名は aoshima(青島)です。

同じクラスタ環境には wakusan(ワクさん)がいます。

 

オワリ

vCenter Server のプラグインをMOBからUnregisterする。

こんにちは。

 

vCenter Server にはMOB(Managed Object Browser)という機能があります。

「MOB vCenter」で検索するといっぱい情報が出てくるとおもいますが、

あまり知られていない機能なので、ご紹介したいと思います。

 

MOB はブラウザから操作するものになっています。

アクセス方法は ↓ のURLです。

https://[vCenter IP or FQDN]/mob

*vCenter SSO(Administrator@vSphere.local) でログインします。

 

アクセスしたら "content" のリンクをクリックします。

f:id:japan-vmware:20180820162111p:plain

今回はvCenter Server のプラグイン、すなわちExtensionの操作をしたいので、

"ExtensionManager" のリンクをクリックします。

f:id:japan-vmware:20180820163721p:plain

 

extensionList 行のVALUE列にある more... をクリックします。

表示されるものが増えます。

 

f:id:japan-vmware:20180823153821p:plain

例えば、赤枠のExtension をUnregisterしたい場合、

”” で括られた部分をコピーしたあと、青枠のUnregisterExtension リンクをクリックします。

f:id:japan-vmware:20180823154137p:plain

 

別ウィンドウが表示されます。

UnregisterExtensionでは、指定したExtensionKeyを指定して、Method を実行することで、Unregister 処理を実行することができます。

事前にコピーした内容を VALUE 値に貼り付け、[Invoke Method]リンクをクリック。

f:id:japan-vmware:20180823154414p:plain

 

以上でvCenter からUnregisterされます。

 

しかし、vCenterのプラグインはリリースしている各ベンダーでアンインストール手順が用意されていることが大半ですので、きちんと手順に従うようにしてください。

 

私はExtensionをアンインストールしても何か残骸が残ってしまっている際に、

MOBからExtensionをUnregisterすることがたまにあります。

 

ご紹介は以上です。

 

ESXi で ASR が動作しない

こんにちは。

 

すごく久々の投稿です。こどもが生まれたり、注文住宅を建てたりと、
プライベートがてんやわんやしております、はい。

 

先日同僚から質問を受けたので、メモです。

 

聞かれた内容:
========

ESXiがPSOD(パープルスクリーン)になったのに、ASRで再起動されないのですが。

========

 

HPEさんのProLiant Serverのお話になりますが、DL360 などの機種では、

自動サーバー復旧 (ASR) 機能が搭載されています。

UEFI or BIOS(RBSU)の画面で有効・無効の設定変更が可能です。

ASR は温度異常やハードウェア障害、ハングアップ (フリーズ)、ブルースクリーン、

修正不可能なエラー、またはシステムパニックなどの致命的な OS のエラーが

発生した場合にシステムを自動的に再起動させて復旧を試みる機能です。

 

※自動サーバー復旧:Automatic Server Recovery (ASR) 

ASR は、ヘルス ドライバーが Timer をリセットできなかった場合に

ロックアップと判断して ASR シグナル (NMI Exeption) を発行します。

ヘルスドライバーが動作できない、もしくは命令を実行できない状況は、

ソフトウェアが原因でも起こりえるため、ソフトウェア側の問題が ASR の原因になることもあります。

 

+公開資料から抜粋
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03166025#f5

 

前置きはこれぐらいにして、ESXiがPSOD(パープルスクリーン)になったのに、ASRで再起動されない理由ですが、

ESXiでは ASR を有効化するためのヘルス ドライバーが用意されていないため、

本来ASR が発生するはずのタイミングでも、ASRによるリブートは行われません。

 

 ASR の機能は BIOS(RBSU)の設定項目に存在していますが、

BIOS設定だけではなく、OS 側でヘルスドライバが読み込まれた後に

有効化(正常動作)するようになります。

 

そのため、PSoD 時にもASRは発生しません。

 

 以上になります。

ではまた。