All Posts

10/27 以降現在まで安定して使用出来ています。 更新もまだないようなので現時点では、vmnat.exe の置き換えが対策として正しそうです。  
vSphere Clientのインベントリから対象の仮想マシンを選択して、権限タブから割り当てたいユーザとRoleを選択する形で十分かと思いましたがいかがでしょうか?
ログイン・停止・起動・再起動、はこちらの「Virtual Machine Power User 」で要件満たせそうです。 追加で、管理者Aが作成した仮想マシンAだけvSphereClientから確認でき、仮想マシンAだけ操作可能になるロール、 もしくは手法等がもしあれば、ご教示いただければ幸いです。  
返信ありがとうございます!試してみます!
事前定義済みのRoleであるVM User もしくは VM PowerUserでは不足でしょうか? Required Privileges for Common Tasks (vmware.com) Managing VMware VirtualCenter Roles and Permissions
vSphereClient(VCSA_ver8.0)でクラスタ管理している環境にて、 カスタムロール等を使用して、 担当者Aアカウントでログインし、仮想マシンの再起動・停止・起動のみの権限を与えることは可能でしょうか。 ※アカウント作成時のユーザは管理者権限を持つ、「administrator@vsphere.local」で操作できます。  
先程、PCのセキュリティソフトを停止して、再インストールを行った所、正常にインストールする事が出来ました。 ご回答ありがとうございました。
以下のコミュニティ投稿が役に立つかもしれません。 Vmnetbridge.dll fails to copy to c:\Windows\system... - VMware Technology Network VMTN   とりあえずは上記にもあるとおり、vminst.logを確認してみるのはいかがでしょうか? 私もちょうどつい先日にVMware Workstation Proをイン... See more...
以下のコミュニティ投稿が役に立つかもしれません。 Vmnetbridge.dll fails to copy to c:\Windows\system... - VMware Technology Network VMTN   とりあえずは上記にもあるとおり、vminst.logを確認してみるのはいかがでしょうか? 私もちょうどつい先日にVMware Workstation Proをインストールしましたが、該当のログファイルは存在していました。 また、権限の問題の可能性の切り分けとして管理者権限でインストーラを実行するのも有効かとおもいます。 業務PCの場合は何らかのセキュリティソリューションが入っていて、それが原因となっている場合もありますので、可能であればセキュリティサービスを一時的に無効化するか、社内ITに問い合わせたほうが良い場合も考えられます。
先日、VMware Workstation Pro を購入し、インストールを行った所、「vmnetbridge.dllをコピーできません。」とエラーが発生しました。 VMware Workstationフォルダ直下を確認すると、「vmnetBridge.dll」はありましたが、「vmnetbridge.dll」は見当たりませんでした。 解決策のご教授お願い致します。
返信ありがとうございます。 問題のありそうな vmnat.exe(ファイルバージョン 17.5.0.49595)を、VMware-player-17.0.2-21581411.exe 内の 17.0.2.41032に置き換えて、しばらく様子を見てみます。ちょっと試した範囲では、正常そうでした。
海外のコミュニティで同様の報告が挙げられていました。 今のところ VMware 公式からの既知問題の情報は無さそうで、 vmnat.exe を 17.0.2 のもので置き換えるコミュニティの回避策しか無いようです。 https://communities.vmware.com/t5/-/-/td-p/2992063
バージョン 17.5.0 build-22583795 になってからだと思うのですが、VMware NAT Service (32 ビット) の CPU 利用率が異常に高いように思います。Core i7-9700 で、4.5GHz 程度の 20% 程度を、ゲスト OS を起動していない状態でも常時使用しています。これで正常なのでしょうか? ホスト OS は、Windows10 Pro 22H2 ... See more...
バージョン 17.5.0 build-22583795 になってからだと思うのですが、VMware NAT Service (32 ビット) の CPU 利用率が異常に高いように思います。Core i7-9700 で、4.5GHz 程度の 20% 程度を、ゲスト OS を起動していない状態でも常時使用しています。これで正常なのでしょうか? ホスト OS は、Windows10 Pro 22H2 OS ビルド 19045.3570 です。
こんにちは。   状況を想像する上で、下記のあたりの情報もあるとよさそうかなと思いました。 データストアの情報(種類、接続プロトコル、ストレージのモデルなど) クラスタVMDKの設定で参照したKB、Docs、ブログのリンクなど(設定/確認済みの前提情報として) Windows のバージョン、クラスタリングしているDBについての情報など(とくに共有ディスク構成のあたり) ... See more...
こんにちは。   状況を想像する上で、下記のあたりの情報もあるとよさそうかなと思いました。 データストアの情報(種類、接続プロトコル、ストレージのモデルなど) クラスタVMDKの設定で参照したKB、Docs、ブログのリンクなど(設定/確認済みの前提情報として) Windows のバージョン、クラスタリングしているDBについての情報など(とくに共有ディスク構成のあたり)  
ESXi:8.0.0b (Build: 21203435) vCenter Server:8.0c (Build : 21457384) 上記の機器、ソフトウェアで仮想基盤を構成していますが、そのうち2台のWindows仮想マシンにてクラスタVMDKによるゲストクラスタ(WSFC)を構成しています。 フェイルオーバークラスタを構成したところ、フェールオーバー時、以下のように挙動がおかしい(... See more...
ESXi:8.0.0b (Build: 21203435) vCenter Server:8.0c (Build : 21457384) 上記の機器、ソフトウェアで仮想基盤を構成していますが、そのうち2台のWindows仮想マシンにてクラスタVMDKによるゲストクラスタ(WSFC)を構成しています。 フェイルオーバークラスタを構成したところ、フェールオーバー時、以下のように挙動がおかしい(異常に時間がかる)状況です。 ・再起動後にスタンバイ状態になるまでに8分ほどかかる <---これは想定しない挙動で、かなり時間がかかっています  ※再起動するサーバがアクティブでもスタンバイでも、DB#1でもDB#2でも同じような挙動になります。 クラスター構築時の検証操作(構築時のチェック的な処理)で、以下のような警告メッセージが各ディスクに対して出ていました。 ------------------------------ テストディスク0は、記憶域サブシステムを使用するクラスター化された記憶域プールに必要なSCSI-3永続的な予約コマンドをサポートしません。 記憶装置によっては、フェールオーバークラスターで適切に動作するように、特定のバージョンのファームウェアや特定の設定が必要です。 記憶装置の管理者または販売元に問い合わせて、記憶域サブシステムを使用するフェールオーバークラスターで記憶装置が適切に動作するように構成する方法を確認してください。 ------------------------------   フェイルオーバーに時間がかかっているのは、このエラー・警告が出ていることが関係していますでしょうか。 クラスタVMDKに関して経験があまり無く、注意すべき設定情報や構成について何かありましたらご教授いただきますと幸いです。 よろしくお願いいたします。
通信要件まで記載いただきありがとうございました。 セキュリティ的に気になっていたので助かりました。 ありがとうございます。
http / 80番ポートへのアクセスは全て https / 443番にリダイレクトされ暗号化された通信のみでやりとりされます。 VMware 製品で必要な各ポートやプロトコルの条件は以下の Ports and Protocols にて確認可能ですのでその他ポート要件の確認に併せてご利用下さい。 https://ports.esp.vmware.com/home/vSphere
追加で事例があれば教えていただきたいのですが、証明書による保護された通信がなされているということですが、、、 ①意図的にhttpでつなげた場合通信平文通信になる可能性は、ありますでしょうか。 ②その他証明書が入っていて暗号化されている通信が行われているとはいえ、http通信で行われる場合は通信によってあったりしないでしょうか。   どのような通信においても必ず暗号化されている通信になって... See more...
追加で事例があれば教えていただきたいのですが、証明書による保護された通信がなされているということですが、、、 ①意図的にhttpでつなげた場合通信平文通信になる可能性は、ありますでしょうか。 ②その他証明書が入っていて暗号化されている通信が行われているとはいえ、http通信で行われる場合は通信によってあったりしないでしょうか。   どのような通信においても必ず暗号化されている通信になっているかきになります。
>手順ですが、以下の2つでどちらも vCenter A に入ってから vCenter B、次に vCenter C と接続していますか? はい、そのように実施しておりました。 >切り分けとして試すとしたらターゲットを vCenter B として、 >一回目は vCenter A からターゲットを vCenter B に、 >二回目は vCenter C からターゲットを vCenter ... See more...
>手順ですが、以下の2つでどちらも vCenter A に入ってから vCenter B、次に vCenter C と接続していますか? はい、そのように実施しておりました。 >切り分けとして試すとしたらターゲットを vCenter B として、 >一回目は vCenter A からターゲットを vCenter B に、 >二回目は vCenter C からターゲットを vCenter B を指定して実施してみては如何でしょうか? ありがとうございます。上記の手順で実施したところ、3台のvCenterで拡張リンクモードをつなげることができました。 なお、私が最初に実施した手順ですとvCenterAにvCenterBのPSCをみにいくように指示した後に、vCenterCのPSCをみにいくように指示していたそうです。。 ご回答ありがとうございました。
ありがとうございます。とても助かります。
> 要件としては3台のvCenterを拡張リンクモードでつなげることはできる認識です。 ご認識の通り可能です。 >vCenterBの拡張リンクモードが外れ、vCenterAとvCenterCのみ拡張リンクモードで構成された おそらくSrcとDestの指定の仕方、実行するVCSAが間違っているのだと思います。ラボで簡易的に試した限り、kawamanさんのおっしゃる通りの以下の方法で実現できま... See more...
> 要件としては3台のvCenterを拡張リンクモードでつなげることはできる認識です。 ご認識の通り可能です。 >vCenterBの拡張リンクモードが外れ、vCenterAとvCenterCのみ拡張リンクモードで構成された おそらくSrcとDestの指定の仕方、実行するVCSAが間違っているのだと思います。ラボで簡易的に試した限り、kawamanさんのおっしゃる通りの以下の方法で実現できました。 一回目は vCenter A からターゲットを vCenter B に、 二回目は vCenter C からターゲットを vCenter B を指定して実施してみては如何でしょうか?   なお、いずれの順序やSrc/Targeで実施したとしても、Replicationトポロジーをみるとループになっていないと思いますので、vdcrepadmin -f createagreement のコマンドを利用してReplication Partnerを追加するのが良いと思います。詳細については以下の記事が参考になります。 Determining replication agreements and status with the Platform Services Controller (PSC) (2127057) (vmware.com) vSphere SSO domain replication topology – make IT work (make-it-work.net)