ESXiがインストールされているデバイス （bootbank） をログから特定する。

最近では、ESXiをSD Card にインストールしている環境や、

HyperConverged 製品などではSD Card にリカバリメディアが収められていたりなど、

構築後しばらく経っていたりすると、どのデバイスにESXiがインストールしてあるか

わからないことが稀にあります。

ログから見ていく方法についてのメモです。

まず先に以下の記事をご覧頂き、ログを収集します。

vSphere Web Clientからログ収集を行う。 - VMware製品はこう使うのよ。

ログ収集後に tgz ファイルが出来上がるので、tgz ファイルを解凍します。

commands フォルダの中を開きます。

場所：

VMware-vCenter-support-2018-10-10@14-30-58\192.168.2.71-vm2018-10-10@05-45-32\esx-aoshima.17f.local-2018-10-10--05.27\commands

「vmkfstools_-P--v-10-bootbank.txt」ファイルを開きます。

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

Could not retrieve max file size: Inappropriate ioctl for device
vfat-0.04 file system spanning 1 partitions.
File system label (if any):
Mode: private
Capacity 261853184 (63929 file blocks * 4096), 55214080 (13480 blocks) avail, max supported file size 0
UUID: f6f857ec-1070d4c8-5b91-401cf12b749c
Logical device: mpx.vmhba32:C0:T0:L0:5
Partitions spanned (on "disks"):Partitions spanned (on "disks"):
px.vmhba32:C0:T0:L0:5
Is Native Snapshot Capable: NO
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0

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

"Logical device" の太字の箇所をメモします。

太字のものがESXiのBootしているデバイスです。

では次に commands フォルダの中にある「localcli_storage-core-device-list.txt」ファイルを開き、先程メモした　mpx.vmhba32:C0:T0:L0

でテキスト内を検索します。

今回のこの環境は SD Card にインストールされたESXiで、SD Card をマザーボード上のUSBコントローラーがハンドリングしているため、USB Direct-Access と表示されています。また、SD Cardにインストールされている場合は mpx. から始まることが多いです。

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

mpx.vmhba32:C0:T0:L0:
Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
Has Settable Display Name: false
Size: 3781
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/mpx.vmhba32:C0:T0:L0
Vendor: Single
Model: Flash Reader
Revision: 1.00
SCSI Level: 2
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: true
Is SSD: false
Is VVOL PE: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unsupported
Other UIDs: vml.0000000000766d68626133323a303a30
Is Shared Clusterwide: false
Is Local SAS Device: false
Is SAS: false
Is USB: true
Is Boot USB Device: true
Is Boot Device: true
Device Max Queue Depth: 1
No of outstanding IOs with competing worlds: 32
Drive Type: unknown
RAID Level: unknown
Number of Physical Drives: unknown
Protection Enabled: false
PI Activated: false
PI Type: 0
PI Protection Mask: NO PROTECTION
Supported Guard Types: NO GUARD SUPPORT
DIX Enabled: false
DIX Guard Type: NO GUARD SUPPORT
Emulated DIX/DIF Enabled: false

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

たとえば、一般的なSATA やSASのHDDにインストールされたESXiのコマンド例を記載します。
naa. から始まる名称となっています。

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

Could not retrieve max file size: Inappropriate ioctl for device
vfat-0.04 (Raw Major Version: 0) file system spanning 1 partitions.
File system label (if any):
Mode: private
Capacity 261853184 (63929 file blocks * 4096), 67665920 (16520 blocks) avail, max supported file size 0
Disk Block Size: 512/0/0
UUID: 7de9a576-7d3403be-34ee-ceebcadfbc43
Logical device: naa.600508b1001c04a7141003d2be00dffc:6
Partitions spanned (on "disks"):
naa.600508b1001c04a7141003d2be00dffc:6
Is Native Snapshot Capable: NO
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0
------------------------------------------------------------

naa.600508b1001c04a7141003d2be00dffc:
Display Name: Local HP Disk (naa.600508b1001c04a7141003d2be00dffc)
Has Settable Display Name: true
Size: 1907697
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.600508b1001c04a7141003d2be00dffc
Vendor: HP
Model: LOGICAL VOLUME
Revision: 4.50
SCSI Level: 5
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: false
Is SSD: false
Is VVOL PE: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
------------------------------------------------------------

HDDやRaid Card 配下のデバイスの場合、naa. から始まる事が多いです。

一方でSD Card などはmpx. から始まる事が多いです。

以上メモ書きでした。

PowerCLI 10.0/Connect-VIServer で証明書のエラーになる。

メモ。

手元の環境で、PowerCLI 10.0　でConnect-VIServerしようとしたら証明書のエラーになり、えー(´・ω・`)　と思っていたのですが、-force オプション付けるだけでよかったです。

【環境】

PowerCLI 10.0

vCenter 6.7(vCSA）

ESXi6.0/6.5 混在環境

【内容】

PowerCLI 10.0 を起動して、ログインしようしたら証明書のエラーになる。

■エラー内容

Connect-VIServer : 2018/09/27 20:39:08 Connect-VIServer Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for
the InvalidCertificateAction option to Prompt if you'd like to connect once or to add a permanent exception for this server.
Additional Information: 機関 'vcsa65-main.17f.local' との SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした
。
発生場所 行:1 文字:1
+ Connect-VIServer -server vcsa65-main.17f.local -User Administrator@vS ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : セキュリティ エラー: (: ) [Connect-VIServer]、ViSecurityNegotiationException
+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.Cmdlets.Commands.Connec
tVIServer

【解決策】

-force オプションを付ける。

■メッセージ全文記載

Welcome to VMware PowerCLI!

Log in to a vCenter Server or ESX host: Connect-VIServer
To find out what commands are available, type: Get-VICommand
To show searchable help for all PowerCLI commands: Get-PowerCLIHelp
Once you've connected, display all virtual machines: Get-VM
If you need more help, visit the PowerCLI community: Get-PowerCLICommunity

Copyright (C) VMware, Inc. All rights reserved.

PS C:\> Connect-VIServer -server vcsa65-main.17f.local -User Administrator@vSphere.local -Password "　　　　"
Connect-VIServer : 2018/09/27 20:39:08 Connect-VIServer Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for
the InvalidCertificateAction option to Prompt if you'd like to connect once or to add a permanent exception for this server.
Additional Information: 機関 'vcsa65-main.17f.local' との SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした
。
発生場所 行:1 文字:1
+ Connect-VIServer -server vcsa65-main.17f.local -User Administrator@vS ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : セキュリティ エラー: (: ) [Connect-VIServer]、ViSecurityNegotiationException
+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.Cmdlets.Commands.Connec
tVIServer

PS C:\> Connect-VIServer -server vcsa65-main.17f.local -User Administrator@vSphere.local -Password "　　　　　" -force

Name Port User
---- ---- ----
vcsa65-main.17f.local 443 VSPHERE.LOCAL\Administrator

==================

PowerCLI 10.0 でデフォルト値が変わっている。常に無視したいなら設定変更もあり。

https://blogs.vmware.com/PowerCLI/2018/02/powercli-10.html

Default Certificate Handling

This version changes the way certificates are handled when connecting to a vCenter server or ESXi host with the Connect-VIServer cmdlet. If your connection endpoint is using an invalid certificate (self-signed or otherwise), PowerCLI would previously return back a warning. The handling has been updated to be more secure and now return back an error.

If you are using an invalid certificate, you can correct the error with the ‘Set-PowerCLIConfiguration’ cmdlet. The parameter needing to be configured is ‘InvalidCertificateAction’ and the available settings are Fail, Warn, Ignore, Prompt, and Unset.

The following code will configure the ‘InvalidCertificateAction’ parameter to be Ignore:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

vCenter配下の仮想マシンのVMwareToolsバージョン一覧を見るPoweshell

ただのメモです。

（あとでコピペして使いたいだけ）

vCenter配下の仮想マシンのVMwareToolsバージョン一覧を見るPS Script です。

Get-VM | select-object -Property Name,@{Name='ToolsVersion'; Expression={$_.Guest.ToolsVersion}}

おわり

ESXi5.5 のジェネラルサポートが 2018/09/19 終了となります。

こんにちは。

ESXi5.5 のジェネラルサポート　が　2018/09/19　終了となります。

ジェネラルサポートとは　Microsoft製品などでいうところのメインストリームサポートに近いものです。

+VMware Lifecycle Product Matrix
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

+ What does End of General Support mean?
https://blogs.vmware.com/vsphere/2018/09/end-of-general-support.html?src=so_5a314d05e49f5&cid=70134000001SkJn

ESXi5.0 / 5.1 が完全にサポート終了し、一息ついていたところですが、
ESXi5.5はジェネラルサポートが終了になります。

事例などはVMware社やOEMサポートでも受けることは可能ですが、基本は事例ベースでの調査となりますので、早期のバージョンアップ計画をオススメします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/vmfs/volumes/<datastorename>/vmName

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

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

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

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

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

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

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

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

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

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

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

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

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

おわり

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が出てきます。

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

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

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

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

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

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

（一般的なvSphere の操作です）

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

パワーオンします。

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

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

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

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

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

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

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

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

　-VMware PowerCLI のインストール

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概要をみます。

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

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

コスト詳細　をみます。

Azure 対応性を見ます。

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

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

　-Windows 7 64 bit

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

　-Windows Server 2012 R2

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

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

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

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

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

[Assessment_Summary]

 [All_Assessed_Machines]

 [Assessment_Properties]

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

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

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

オワリ