VMware製品はこう使う。

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

その1:VxRail のログを取得して見てみた。

DELL EMC が満を持して猛烈に力を入れているHCI アプライアンスを先日触ることができたので、プリセールスという立場でありながら、VxRail のログを見てみよう、という記事です。

 

実際の中の人(サポートエンジニア)の人がサポート系の記事を書くと、しがらみや責任問題が発生するので、個人的に私が書く というスタンスです。

 

VxRail とは?

DELL EMC がオススメしているHCI アプライアンスです。

技術のベースはVMware製品で、vSphere(ESXi,vCenter), vSAN, VxRail Managerで構成されています。

 VMware社とDELL EMC が共同開発しているだけあって、かなり作り込まれている製品で、運用のラクさをとにかく意識した製品です。

 

環境情報

VxRail Manager 4.7.300
vCenter 6.7 14368073
VMware ESXi 6.7 Build 14320388
PTAgent 1.9.2-20

ログバンドルを取得

ログを取得して見てみた、という記事なのでログの取得から見てみます。

すべてGUI(vSphere Client) を使って取得します。楽チンです。

 

1.インベントリからクラスタをクリックします
2.[設定]-[トラブルシューティング] をクリックします
3.右端に表示されている [作成...]ボタンをクリックします

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

vSphereClientLog1

 [収集するデータ] は全部選択します。
ここでの注目ポイントは、トラブルシューティングに必要な基本的なログや構成情報はすべてここで収集してくれます。

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

次にどのホストのログバンドルを収集するのか、を選択します。

ホスト名とかではなく、まさかの [サービスタグ]、[アプライアンスID] での選択です 笑
[アプライアンスID]はVxRail のコンソール画面(ESXiのコンソール画面)に表示されていますし、その他の箇所でも確認可能です。[サービスタグ]については筐体を見て確認することもできます。

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

 

iDRAC の横にある「i」マークをマウスオーバーすると説明が表示されます。
説明がイマイチ…!ですが、HPE のサーバーでいうと iLO と同じ役割のものです。リモートごしにサーバーハードそのものを管理することができ、遠隔地に設置しているサーバーのパワーオンができたり、常にサーバーの状態を監視しています。
つまり、DELL EMC特有のものでありながら、vSphere Client からログが取れるというDell Technologies であるがゆえの機能ですね。

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

 

続いて、PTAgent の横にある「i」マークをマウスオーバーしてみます。
PTAgent はESXi上で動作するサービスの1つで、iDRAC などと通信して情報をとったり、VxRail Managerとの連携に必要なサービスです。そのログを収集します。

余談になりますが、PTAgentのサービスのRestartは、以下のコマンドで実施できます。

 # /etc/init.d/DellPTAgent restart

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

 

[生成]ボタンをクリックするとログの収集がはじまり、収集するログの量に応じた時間がかかります。お使いの環境に応じてログの量が違うので、だいたい目安の時間は、
5分~30分前後が多いです。ログ収集の際に影響しがちなのは、稼働日数が長い仮想マシン(1年とか)が居る場合、vmware.log が巨大になっていることがあるので、事前に確認するのはアリかもしれません。

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

収集後はダウンロードボタンからダウンロードします。

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

 

ダウンロードしたログはこちらです。

 ※別の日時で取得したものなのでファイル名は異なっています。

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

 

 

今回はここまで!

 

次回はログの展開して、ログのディレクトリ構造などを見ながら雰囲気を見ていきたいとおもいます。

 

vCSA [6.0, 6.5, 6.7 etc] : WinSCP でvCSAに接続しようとするとエラー(ファイル転送ができない)

みなさまへ

こんにちは。

この記事にたどり着いた方は結構お困りなのではないかと推察します。

 

というのも、vCSA(vCenter Server Appliance)をデプロイしたあとに、vCSAにプラグインをインストールしようとしたりする際にSSH接続はできるけどSCPでファイル転送しようとするとエラーになったり、我々がよく使うWinSCPでvCSAに接続しようとすると、エラーになり、「vCSAにファイルを送れないじゃないか!!!」となっている方がたどり着く記事だからです。

 

そこであまり日本の記事や情報が見当たらなかったので、情報の共有です。

 

まず、結論から申し上げると、VMware KB があります。

 

+Error when uploading files to vCenter Server Appliance using WinSCP (2107727)
https://kb.vmware.com/kb/2107727

 

中身を見ると、理由などが書かれているんですが、我々がやりたことはとにかくファイルを転送させてくれ!というところだと思うんですね。

この問題に直面している人のだいたいが構築中の方だとおもいますので、先に解消することが先決かと思うので、方法だけを記載します。

 

1.vCSAにTeraterm などでSSH接続します。(root)

2.画面上に何をするかの選択肢が出てきます。Shellと入力してEnterです。

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

 

すると一般的なLinuxと同じ画面になります。

 

3. /etc/passwd  を vi エディタで開きます。

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

 

4.一番上の行に /bin/appliancesh  になっているのがわかります。

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

 

5. viエディタの挿入キーである 「i」を押し、一番上の行を/bin/bash に変更します。その後、:wq!  と入力して保存します。

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

 

6.WinSCP で接続できるようになります!

7.必要なファイルをvCSAに転送しちゃいましょう。

 

8.その後 /bin/bash に変更したものを /bin/appliancesh  に戻しておきましょう。

 

以上になります。

 

私も最初ファイル転送できなくて、デプロイ操作でなにか誤りがあったかな?と思っていましたが、そうではなかったという結論です。

 

なぜこのような現象になるか興味ある方は VMware KB 2107727 を見てください。

 

今回はこのへんで。

 

VCF(VMware Cloud Foundation) とはなにかご存知ですか。

みなさま、こんにちは。

 

最近投稿が滞ってしまっていました。

 

2018年12月から製品部に所属するプリセールスにJob Changeし、立場が変わり、いろいろバタバタしております。前職種ではテクニカルサポートエンジニアとして仕事をしていました。

現在はVMware 製品、Microsoft 製品、SimpliVityの製品プリセールスをしています。

特にSimpliVityに関してはサポート側でLeadをしていたので、発信できればと思っています。

職種が守る側から攻める側に変わったので、生活スタイルが激変しました。

※イメージ

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

 

以前までは、技術サポート情報中心の投稿でしたが、これからはプリセールス観点でもいろいろ発信できればと考えていますので、よろしくお願いいたします。

 

さて、今回のネタは VMwareさんが推し推しのVCF(VMware Cloud Foundation)の内容です。

みなさまVCFご存知ですか? 「よくわからない」、「ナニソレ?」という人向けにVMwareさんご協力のもと、VMware公式Blogに説明記事を掲載しました!

よければ見てください。

「VMware Cloud Foundation (VCF) 」 をご存知ですか?
https://blogs.vmware.com/jp-cim/2019/03/vcf1.html

 

 なぜこのタイミングで VCFのお話をするのかというと…

ゴールデンウィーク真っ只中の10連休の前半 2019年4月29日(米国時間)Microsoftから「Azure VMware Solutions」が発表されましたね。

わかりやすい日本語の記事だと@ITさんの記事かなと思います。

 

Microsoft Azure上のVMware vSphereクラウドサービス、「Azure VMware Solutions」が発表

https://www.atmarkit.co.jp/ait/articles/1904/30/news017.html

 

記事の中身を見ると… 書いてますね!VCF!!

VMware Cloud Foundationを自動展開することで、ホステッドプライベートクラウドを提供する。」

 

そうなんです、Azure VMware SolutionsはVCFベースで稼動するのです。

あまり知られていませんが、「VMware Cloud on AWS」もVCFをベースに構築されています。つまり、VCFは知っておく必要があるものというのは容易に判断できるとおもいます。

 

実はわたくし VMware Cloud Foundation の検証なども社内で実施する立場にいまして、現行のVCFバージョンは3.7ですが、3.5のときなどの情報も含みながら、スクリーンショット付きで次回以降ご紹介できればとおもっています。

 

では今回はこのへんで。

vCenter 6.7 Update 1 でログを採取する方法(HTML5 - vSphere Client)

vCenter 6.7 Update 1 でログを採取する方法(HTML5 - vSphere Client)

 

https://vCenter のIP  or FQDN /ui/   でログインします。

 

インベントリツリーの一番上を右クリックし、[システム ログのエクスポート] をクリックします。

 

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

 

ログを取得したいESXiにチェックを入れます。(vm-support)

[vCenter Server およびvSphere UI Client ログを含めます] にチェックを入れます。(vc-support)

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

 

収集するログを選択します。基本はデフォルトのままでよいです。

[ログのエクスポート]をクリックします。

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

 

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

 

ダウンロードしたファイルがこちら。

従来のvSphere Web Client のときとはファイルの命名規則が異なっています。

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

 

しかし、解凍をして中をみると従来どおりでした。

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

 

ファイル名に vcsupport と入っているものが vc-support です。

のこりの2つがvm-support です。

 

おわり

vCenter 6.5(vCSA) からvCenter 6.5 Update 1 へバージョンアップ

 

vCenter 6.7 からvCenter 6.7 Update 1 (Build 10244745)へバージョンアップのメモです。

いつもどおり、パッチのダウンロードページからダウンロードしました。

https://my.vmware.com/group/vmware/patch#search

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

ファイル名:VMware-vCenter-Server-Appliance-6.7.0.20000-10244745-patch-FP.iso

 

vCSA の仮想マシンに 上記のisoをマウントします。

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

 

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

<vCenterのFQDN>:5480/ を開き、

root ユーザーでログインしたあと、[更新] を開き、[更新の確認] - [CD-ROM の確認] をクリックします。

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

[使用可能な更新] の中に今回アップグレードするものが表示されます。

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

 

[ステージングしてインストール] をクリックします。

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

進めていきます。

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

 

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

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

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

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

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

 

その後、アプライアンス管理画面を確認すると Build が上がっていることが確認できます。

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

 

おおよそこれまで通りの操作で問題ありませんでした。

 

■余談

vCSAのroot パスワードの期限が切れている場合は、

更新前のチェックでエラーが表示され、進めることができません。

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

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

 

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

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

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

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

 

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

 

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

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

 

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

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

 

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」ファイルを開きます。

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

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

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. から始まることが多いです。

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

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

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
------------------------------------------------------------

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

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. から始まる事が多いです。

 

以上メモ書きでした。