VM_Yamato's Accepted Solutions

頂いた御症状と同じものが、2件海外のVMTNになったので掲示します。 https://communities.vmware.com/t5/vCenter-Server-Discussions/vCenter-Server-7-failed-install/td-p/2895161 https://communities.vmware.com/t5/vSphere-Upgrade-Install/When-I-first-installed-vsphere-I-was-stuck-at-Starting-VMware/td-p/2879714   私自身この症状は当たったことはないのですが、どちらのスレッドでも"SSOドメインをvsphere.localにしてみましょう"というソリューションで回答がされています。 もし上記のドメイン名でのセットアップが可能な場合はそちらを試してみるのは1つの方法かと思います。 もし既にvsphere.localで進めたにも関わらず問題が継続的に発生する場合は、次の点の確認当たりは有効化と思います。 ご使用いただいているvCenter Serverのインストールイメージが最新版でない場合はそちらをお試しいただく DNSサーバが起動しているか、またそれの中にvCenter ServerのAレコードとPTRレコードが用意されているか 上記2つは、vCenter Serverの展開時の典型的な確認箇所なので、今回の事象との関係性は少なそうな気もするのですが、念のため掲示させて頂きました。少しでもお役に立てば幸いです。

質問への回答を致します。 ・vSAN構成での運用について、vSANのリバランスを起こさないことがベストプラクティスとだという 認識ですが、これが発生するとおおよそどれぐらいのパフォーマンス影響が発生するものでしょうか？ これぐらい業務用のIOPSが下がるとか、CPU使用率が上がるとか、もしなにか指標などあれば情報を いただけますでしょうか。 上記については、正直データの移行量と発生タイミングとの他のワークロードにもよるため、環境次第だと言えます。 ・vSANのリバランスはvSANクラスタへの新しいノードを追加する時や、ノードを撤去するときにも発生する可能性はあるものでしょうか？ はい、仰るとおりです。そのため、ノード追加時の注意点としてはデータ移行がピークタイムに発生するとパフォーマンスに影響を及ぼす可能性があるため、ピークタイム以外にノードを追加するのが理想的です。良く行われる手法としては、追加ノードについてはメンテナンスモードで追加をしておき、ピークタイムを過ぎてからメンテナンスモードを解除するという方法です。メンテナンスモード中は増設ノードのキャパシティはvSANには使用されないためです。 ・vSAN環境でESXiノードをクラスタから切り離す場合、残すノードへ全データの移行を行うと思いますが、 この時もvSANリバランス時と同じレベルのパフォーマンス影響が出ると思ってよいでしょうか？ その通りです。これもやはりデータが既存ノードに移動されるため、仮想マシンのサイズが大きい場合、数が多い場合は比例的に上がると言えます。

移行後の仮想マシンでは、仮想NICが1つ必要なのだと思うのですが前環境でご使用だったMACアドレスを引き続き使う必要があるのでしょうか？ その場合は、下記の手順であれば以前のMACアドレスを手動で移行後の仮想マシンにアサインは可能だと言えます。 仮想マシンに対する固定 MAC アドレスの設定 特に以前のMACアドレスに拘らない場合は、次の手順で対応が出来るのではないかと思われます。 1. 旧NICの固定IP並びにサブネットマスクなどの手動設定情報をメモしておく 2. 旧NICをCentOS上でIOを停止する(ifdown) 3. 新NICに1.でメモした手動設定を入力し、InterfaceをUpする 4. 以下のディレクトリ内の旧NICの設定ファイル削除 /etc/sysconfig/networking/devices/ifcfg-eth*

ハードウェアの情報を教えて頂き有難うございます。 まず大前提としては、やはりノートパソコンでのESXi利用は通常非サポート構成ですので、それが原因(かも)しれませんね。 勿論、サポート外とは言えESXiが運良く動く製品もあったりしますので、この点ははっきり言って運的な所も少々あります。 ご提示の環境で、後出来る事があるとすれば次のアイデアがあります。 1. 当該ノートパソコンのBIOSなどのハードウェア周りを最新版に更新してみる。当方が富士通製品には詳しくないので、多分以下がリンクなのだと思います。 ダウンロード（BIOS） - FMVサポート : 富士通パソコン 初期にご紹介したKB自体の内容からも、エラーの内容はESXiがもつブートローダーとハードウェアの非互換によるものです。 ハードウェア側に更新余地がある場合は、少しでも新しくしておくことで内的なバグや最新OSへの対応を促そうということを期待してのご提案です。 2. 特別な理由でESXi 7でないといけない！ということでないのならば、vSphere ESXi 6.7 Update 2以前に再インストールをしてみる。 https://my.vmware.com/en/web/vmware/downloads/details?downloadGroup=ESXI67U2&productId=742&rPId=52124 初期にご紹介したKB自体の内容からも、エラーの内容はESXiがもつブートローダーとハードウェアの非互換によるものです。 6.7 Update3から起きるようなので、それを避けるためにUpdate 2をご提案しています。 3. ESXiに拘ならい場合は、Windows 10などの元々のOEM OSに戻して頂いて、その上でVMware Workstationを入れて仮想環境を構築する。 VMware Workstation Player | VMware | JP (無償で利用可能な、Windows環境上で実行出来る仮想化ソフトウェアです) 今回のESXi導入の目的次第だとは思いますが、それ次第で上記でご提案したアイデアでハマるものがあればと思います。 なお、海外フォーラムでも同様の事象に対して、上記のようなアプローチがなされていたのでそれを参考にしております。 esxi cannot boot after updating to 6.7 u3! how to fix it?

お返事有難うございます。 当方の方で、簡単な検証をVMware HOL上で試してみました。 1. VMware HOL上で、実在し正常なユーザー名でログインを試す。(結果：問題無くログインが出来る) 2. 実在しないユーザー名を入力して見る(結果：当然ですが認証は失敗します。そしてエラーは”不明なユーザーまたはパスワードとなります） この検証から想定すると、現在 taka1204​ さんがあたっている問題は、エラーのメッセージが”ドメインまたはユーザー名が無効です”なので、VMware Horizon Clientそのものが、入力している文字列を無効な形式だと判断しているように思います。(つまり、ADに対しての認証すら行っていないものだと推察されます） 私の予想ではあるのですが、お使いのVMware Horizon Clientでは、ドメイン名\ユーザー名(数字のみ)はそもそもユーザー名として相応しくないものと判断しているようにも思います。 現在はワークアラウンドをお持ち(ユーザー名@ドメイン名)のようなので、運用面で回避出来ているようなので、そちらで運用を継続していただくのは一つかと思います。 もう1点気になりましたのが、私が利用した環境では、VMware Horizon Clientは5.1.0 build-14045148でしたが、ドメイン名はユーザー名欄とは別で入れる様になっています。 現在ご使用のVMware Horizon Clientのバージョンはいくつでしょうか？ 以下のリンクからは、HorizonとHorizon Clientのバージョン互換性の確認が可能です。もしHorizon Clientが古いようでしたら新しいものに上げてみるというのは1つのソリューションになりうるかもしれません。 VMware Product Interoperability Matrices 今回の問題の原因については、現状はわかりかねますが、エラーメッセージからの想定では上記にまとめている次第です。 余談にはなりますが、Windowsの側面としてはユーザー名に使って良い文字列やルールは次の箇所にまとめがあります。 数字のみのユーザー名を禁ずるような記載はありません。またWindowsとしてのログインが出来ていたり@を使ってのログインは出来ている点からも、Horizonとしてのマイナーなイシューに合致しているのではないだろうかと考えている所です。 Creating User and Group Accounts | Microsoft Docs 以上、参考になれば幸いです。よろしくお願い致します。

vSphereなどのVMware製品の各種最大値については、以下のページから確認が可能です。 VMDKのサイズについては、次のように検索をいただけると確認が出来ます。(下図ですと62TBです) 参考になると幸いです。 https://configmax.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%207.0&categories=1-0

頂いたご質問に回答をするために、当方から何点か確認をさせてください。 1. 以下で書かれているクラスタとは具体的にvSphereが持つどのクラスタ機能を利用になる予定でしょうか？ >ESXi 2台でクラスタを組みます。(AとBとします) VSANなどは使用しません。 vSphereには次のようなクラスタがありますので、念の為確認です。 vSphere HA vSphere FT EVC vSAN(こちらはご使用にならないということで承知致しました) なお共有ストレージのご使用が無いという事ですと、HA/FT/EVCもご利用が出来ないはずなので、"共有ストレージが無いクラスタ"というのが具体的に指している環境が解りかねましたので確認させていただきました。当方の理解が不適切な場合は誠にお手数ですがもう少し環境詳細をいただけると幸いです。 2. 以下の内容は、障害をトリガーとしてホストA上の仮想マシンをコピーして、ホストBに切り替える事がvSphereの機能で可能か？という質問でしょうか？ >ESXi上に仮想のファイルサーバを立てるのですが、いろいろ理由がありまして、共有ストレージではなくESXi-Aの中にファイルサーバのデータを置きたいです。 >このとき仮にESXi-Aに障害が発生したとき、仮想ファイルサーバとともになかのデータもESXi-Bにコピーされて、継続してアクセス可能なようにする方法は >何かありますでしょうか？ これについて言えば上述をしております、vSphere HAやFTが近いものだと言えます。(どちらかと言えばFTです。RAID1のように1台の仮想マシンを、2つの異なるESXiホスト上にミラー化し、常に2つのホスト間で同期を取っています。) しかし、FTを使う場合は、前提としてvSphere HAが構成出来ることが条件であり、HAを使うには共有ストレージが必須です。 ということも有り、機能はあるものの、共有ストレージが存在しないと構成は難しいと言えます。 3. 以下は恐らくレプリケーション相当の機能があるかどうか？ということでしょうか？ >また、ESXi-Aの中に置いたファイルサーバのデータとバックアップ用にESXi-Bの中に置いたデータを常に同期をとるような仕組みがあったりしますでしょうか？ VMwareのソリューションとして、親しいものは"vSphere Replication"があります。これはvSphere Essentials Plus以上のライセンスがあれば利用可能なレプリケーション機能です。 一般的なレプリケーションと違い、同一サイト内であっても仮想マシンの同期は可能です。(クラスタからクラスタへ同期となります） 現状頂いている構成は、2ノードで1クラスタとおっしゃられているので、これを1ホストで1クラスタを組めば可能ではないかと推察されます。 vSphere Replication の仕組み 下図はシングルサイトでのレプリカ構成のイメージ図です。図では1クラスタに2ホストとなっていますが、これを1クラスタに1ホストで組めばいけそうな気がします（やったことがないので恐らく、なのですが） 常に同期を取りたいという点では、このソリューションではRPO(Recovery Point Object)ベースで常時レプリカが実行されますので、その点での要件は満たしていると言えます。 ご質問への回答というよりは、その前段階としてのヒアリングのような形で恐れ入りますが、ご確認の上お返事を頂けますと幸いです。 以上、よろしくお願いします。

仰る通り、仮想マシンを停止後に対象のNICを外して頂き、再追加で作業は完了出来ます。以下は追加時の作業です。 仮想マシンへのネットワーク アダプタの追加 クローンに関する上記記述は、作業対象仮想マシンへの変更が容易ではない(例えば大変重要度が高いサーバであり、あまり気軽に構成変更が許容出来ない）場合に向けた言及です。 もしそうした環境のものではない場合は、上記作業だけでOKです。 構成変更後から、別の症状などが出る場合ということも、可能性としては0では有りませんので、上記以外の方法としてバックアップの取得などをお持ちであればそれでも代用可能といえます。 この点についてはサーバの重要度/復帰プランを考慮する必要がある際にのみご検討されるとよいです。 少々冗長な説明となりましたが、問題が解消されることをお祈りしております。

バージョンは5.1という事で理解致しました。 1つ再確認をしたいのですが、以下で上げていただいている値は、各領域に対する”使用率"の値でしょうか。 (残り空き領域ではない） 【作業前】 ・System : 47% ・Database : 2% ・Logs : 45% ・Coredumps : 4% 【作業後】 ・System : 47% ・Database : 2% ・Logs : 34% (11%削減) ・Coredumps : 4% 上記のLogs領域の変動から、上記の再確認に当たります。 使用率である場合は、いずれの領域も十分に空き領域があるように見えます。 よってこの場合はvpxdが停止してしまっている要因は、ディスクスペース枯渇では無いと思われます。この事は作業後に同事象が出ていることからもその裏付けが出来ます。 ここまで、ストレージスペース枯渇の想定でスレッドが進行しましたが、 上記の数値が使用率を示す場合は、問題を追求するためには、vpxd.logの調査がやはり有効な手立てとなると言えます。 問題発生時間から遡り、関連するイベントからKBを検索頂く事になると思います。 また、こちらは本件との直接的には関係ないものの、商用環境としてのご利用の場合には、既に5.x世代はGeneral Supportを2018年に終えておりますので、 現時点ではWeb上の公開情報やフォーラムでの既知ユーザーとのやり取りレベルでの調査で問題を解決していくフェーズです。 また本年9月19日には技術的なWeb情報の更新提供も終了する予定ですので、もし今後も同様の環境を運用されていく場合は、サポート期間が有効な6.5以降のvSphereバージョンを用意されたほうが良いかもしれません。 https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf