- vmdkだけから仮想マシンをVMware Playerで復活 [2020/04/03]
- お決まりの方法では解決しない「VMware Authorization Service」 [2018/05/28]
- SMBus Host Controller not enabled! [2018/04/06]
- VMware Workstation PlayerでLinuxから音を出す [2017/11/23]
- ゲストマシンのメモリトラブルがホストマシンまで影響(Page Fault) [2017/10/09]
- ゲストOS起動のためのバッチファイルとWshShellのRunメソッド [2017/07/30]
- VMware Workstation Player - ゲストOSの名前変更 [2017/06/23]
vmdkだけから仮想マシンをVMware Playerで復活
VMware Workstation Player上で仮想マシンを使っています。試したいと考えていた仮想マシンのvmdkだけが手に入りました。
これを起動させるためには、vmxなどが不足しています。ESXiなどの本格的なハイパーバイザーではない「VMware Workstation Player 15」で、このvmdkを利用してvmxなどを作成し起動できるか試してみました。 これが汎用性のある手順かどうかはわかりませんが、メモとして残します。
蛇足ですが、仮想マシンが起動できてもアカウント情報(IDとパスワード)が不明では使えませんので事前に情報を得ておいてください。
図を使って操作の流れを説明します。操作の流れのイメージが把握できれば、テキストだけの説明でも理解し易いと思います。(スクリーンショットを入れるととても長くなってしまいます)。操作のほとんどは「VMware Workstation Player」(以下VMware Playerと記述します)上で行います。
以下の3段階(Ⅰ、Ⅱ、Ⅲ)に分けて記述します。
Ⅰ.仮のvmdkを作成
- フォルダーと各種ファイルの位置関係を把握してください。図中の右フォルダーには、これから以下の操作で新規仮想マシンの各種ファイルを作成します。
- Explorerを使うなどして入手した(復元したい)vmdkファイルを任意の場所に保存します。図中の右のフォルダー作成は「VMware Player」での操作として以下で説明します(Explorerで作成しても可です)。
- 「VMware Player」を起動したら、右にある「新規仮想マシンの作成(N)」から「新しい仮想マシンウィザード」 に進み、下にある「後でOSをインストール(S)」を選択して、[次へ(N)]。
- 「新しい仮想マシンウィザード」では、仮のvmdkやvmxなどを作成するプロセスになります(復元したい元の仮想マシンの正体がわかっていれば、その情報を使いますが、不明であれば試行錯誤が必要になることもあります。Linuxであれば、Linux distributionなどをリストから選択してください。Linuxのカーネル情報でもよいはずです)。 具体的には、「新しい仮想マシンウィザード」から「ゲスト OS」項目で、入手した(復元したい)仮想マシンに合わせて、OSの種類やバージョンを選択します。[次へ(N)]。
- 「仮想マシン名(V)」「場所(L)」を入力します。このとき、仮想マシン名は、入手したvmdkのファイル名を使います(拡張子を除いた部分)。場所は、上図を意識して決めてください。
- 「ディスク容量の指定」では、サイズ等の指定はそのままで構いません。あとで削除(置き換え)するからです。[次へ(N)]。
- 「新しい仮想マシンウィザード」に戻って、[ハードウェアをカスタマイズ(C)]を選ぶと「ハードウェア」項目になります。ここで「メモリ」や「プロセッサ」などを調整してください。[閉じる」。
- 「新しい仮想マシンウィザード」に戻ったら、[完了]。
Ⅱ.仮のvmdkを削除(VMware Player上での削除操作)
- VMware Playerのトップに戻ったら、右下にある「仮想マシン設定の編集(D)」を選択します。
- 「仮想マシン設定」でリストにある「ハードディスク(SCSI)」を選び、下部にある[削除]で削除します。右下部の[OK]。(注:Explorer上では、まだ仮のvmdkが残っています)
- 一旦、「VMware Player」の操作から離れます。
Ⅲ.入手した(復旧したい)vmdkを適用
- Explorerなどで、入手したvmdkを作成中の仮想マシンのフォルダーにコピーまたは移動し、上記で作成した仮のvmdkファイルを置き換えます。この操作によって、作成中の仮想マシンフォルダーにあるのは入手したvmdkになります。
- 「VMware Player」に戻り、右下部の「仮想マシン設定の編集」でディスクの追加作業を行います。
- 「仮想マシン設定」で「ハードウェア」タブにあるデバイスリストの下部にある[追加]をクリックします。
- 「ハードウェア追加ウィザード」で、「ハードディスク」を選んで[次へ]。
- 今回の場合、「SCSI」が推奨となっていましたが、「SCSI」を選択しても起動できませんでした。「IDE」または「SATA」を選んで[次へ]。
- 「ディスクの選択」では、「既存の仮想ディスクを使用(E)」を選び[次へ]。
- 「既存のディスクファイル」には、コピーまたは移動で置き換えたvmdkを指定(作成中の仮想マシンのフォルダーに存在しています)。[完了]。
- 「既存の仮想ディスクを新しい形式に変換しますか」が表示されたら、[変換]を選択。「仮想マシン設定」ウインドウでデバイスのリストに「新規ハードディスク(IDE)」または「新規ハードディスク(SATA)」がリストにあることを確認して、[OK]。
「VMware Player」のトップページに戻ったら、復元した仮想マシンを起動してください。起動しない場合は、Ⅰ-4またはⅢ-5を変えてみてください。
慣れている方なら、作成されたvmxファイルを編集してご希望の環境に合わせることが可能かと思います。
また、仮想マシンの名称を変更したいときは、「VMware Workstation Player - ゲストOSの名前変更」に方法を記述していますので、ご参照ください。
以上となります。
なお、vmdkから仮想マシン復元には以下の3情報を参考にさせていただきました。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
お決まりの方法では解決しない「VMware Authorization Service」
VMware Authorization Serviceが通常の解決法(サービスを直接開始)で起動しませんでした。
VMware Workstation 14.1.2 Playerがリリースされたので、14.1.1からアップデートしました。その後、クライアントOSを起動しようとしたら、エラーで起動できません。
↑ エラーが発生。以下のメッセージ
パワーオン中にエラーが発生しました:VMware Player は、VMware Authorization Service の起動に失敗しました。VMware Authorization Service を手動で起動してみてください。この問題が続く場合は、VMware サポートに連絡してください。
「コンピュータ管理ツール」から「サービス」とたどり、VMware Authorization Service サービスを開始させる、という通常の方法を行ってみました。
↑ ①VMware Authorization Serviceを選び、②「サービスの開始」をクリック
↑ しかしエラーが発生。以下のメッセージ
ローカル コンピューター で VMware Authorization Service を開始できませんでした。詳細情報はシステム イベント ログ を参照してください。これがMicrosoft 以外のサービスである場合は、サービスの製造元に問い合わせてください。その際、サービス固有のエラーコードが 6000009 であることを伝えてください。
通常のサービスを直接開始させるというおきまりの方法では解決できないのです。
では、イベントビューアでエラーログを調べてみます。
↑ システムログ。固有エラーコードの6000009が確かにあります。VMware Authorization Serviceが止まっています。
↑ アプリケーションログ。VMware Workstationの再インストールが勧められています。
↑ アプリケーションログ。vmmon driverとバージョンが合っていないのです。
解決方法は、「vBrain.info」というブログサイトにありました。 「Workstation 14 Upgrade – Authorization Service error 6000009」というトピックです。
VMware Workstation Playerをアップデートしたときに、vmx86.sysドライバーがアップデートされないことが原因だということです。早速、C:\Windows\System32\drivers\にあるvmx86.sysをプロパティの「詳細」で調べてみます。
↑ バージョンをみると確かにアップデートされていません。
それでは上記の「vBrain.info」サイトにある解決方法をもとにして日本語の説明にします。解決方法は、以下の5ステップになります。
- 必要なインスト用ファイルとツールをダウンロードする
- Windowsの起動時に、vmx86.sysをロードさせない(SysInternals Autorunsを使って操作)
- Windowsを再起動させる
- vmx86.sysを別名にする
- VMware Workstation Playerを修復インストールする(インストール後再起動)
1. 必要なインスト用ファイルとツールをダウンロード
VMware Workstation 14.1.2 Playerをまだダウンロードしていなければ、「ダウンロード VMware Workstation Player」からダウンロード(VMware-player-14.1.2-8497320.exeが入手)します。(注:ここでは14.1.2の64-bitを選択していますが、問題を起こしている該当バージョンとタイプを入手してください)
↑「ダウンロード↓」をクリックして、適切な場所に保存してください
続いて、Autoruns for Windowsを「Windows Sysinternals」からダウンロードします。
↑「Autoruns を実行する」をクリックすると、autoruns.exeがダウンロードされますので適切な場所に保存してください。
2. SysInternals Autorunsでvmx86.sysを非ロード処理
ダウンロードした autoruns.exe を「管理者として実行」で起動します。
↑ 上部のタブ「Drivers」を選択して、「vmx86」をスクロールダウンして探し、チェックボックスのチェックを外します(スクリーンショットではチェックが付いていますが、クリックしてチェックを消してください)。これで次のWindowsの起動時に「vmx86.sys」ドライバーがロードされません。
3. ここで一旦Windowsを再起動
Windowsを再起動させます。
4. vmx86.sysをリネーム
Windowsの起動後に、C:\Windows\System32\driversにあるvmx86.sysを、例えばvmx86_old.sysのように別の名前にします。
5. VMware Workstation Playerを修復インストール
最初にダウンロードした「VMware-player-14.1.2-8497320.exe」を実行
↑「次へ(N)」
↑「修復(P)」を選択
↑「修復(P)」を押して、次に進める
↑ 処理が進みます
↑ 完了。「完了 (F)」をクリック
↑ Windowsを再起動させます。「はい(Y)」をクリック
以上で作業は終了です。再起動後、C:\Windows\System32\driversにある vmx86.sys のプロパティで「詳細」を確認してみます。
↑ 更新されました(バージョンが上がりました)
この作業の結果、VMware Authorization Serviceもスタートしていて、VMware Workstation PlayerでゲストOSも正常に起動できるようになりました。問題は解決しました!
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
SMBus Host Controller not enabled!
VMware Workstation 14 Player上に Ubuntu 17.10.1を構築していますが、ときどき正常に起動できなくなります。
Ubuntuのデスクトップまでたどり着けず、「(initramfs)」というプロンプトを表示させて止まってしまうのです。そのたびに、「fsck」コマンドでファイルシステムの修復を行い、正常にブートさせるという操作を行っていました。
少し気にはなってはいたのですが、対応していなかったVMware Workstation Player起動時のコンソールに現れるエラーメッセージ(以下)が原因かも知れないので調べてみました。
piix4_smbus 0000:00:07.3: SMBus Host Controller not enabled!
↓実際に出力されたメッセージのスクリーンショット
これまでこのエラーメッセージを無視していたのですが、今回解決策を調査して見たところ、ネット上にはESXiやVirtualBox上でも上記のエラーメッセージが出現するという情報がありました。
先ず、解決策として簡単そうだったのは「.vmxファイルに以下の行を追加」という情報でした。
cpuid.1.eax = "0000:0000:0000:0001:0000:0110:1010:0101"
参考:https://www.youtube.com/watch?v=CCplWoIcwx4
結果は、効果なし、でした。起動時のメッセージは相変わらず表示されます。
効果があったのは、以下のサイトにある解決策でした。
http://tomos-umi-tsubame.cocolog-nifty.com/blog/2012/01/vsphere-41-50-f.html
上記サイトに書かれている情報は、ESXi 5.0とUbuntu11.10の環境での対策ですが、今回のVMware Workstation 14 PlayerとUbuntu 17.10.1においても効果がありました。そのコマンド(方法)を転記し、少し説明を加えます。(以下、Ubuntuが起動してデスクトップ上での操作になります)
[1].ロードされているカーネルモジュールの中にi2c_piix4が存在するかを確認します。起動時にメッセージが出現するのですから、存在しているはずです。
以下のコマンドを一般ユーザーとして実行(スーパーユーザーでも可)
[2].ic2_piix4のモジュール名やサイズが出力(表示)されます。存在することが確認されたら、スーパーユーザー(ルート特権)として、以下の2つのコマンドを実行します。
最初のコマンドで削除するi2c_piix4モジュールを指定し、2番目のコマンドでinitramfsを更新します。
update-initramfs -u -k all
update-initramfs(initramfsの更新)では、処理に時間が少しかかりますが、以下のログ(スクリーショット)が表示されました。スクリーンショットのアンダーラインを引いた最初の行は、入力したコマンドです。
Ubuntuを再起動して、このトピックの最初に記載したエラーメッセージ(piix4_smbus 0000:00:07.3: SMBus Host Controller not enabled!)が起動時に現れなくなることを確認しました。
上記で行った対処で、VMware Workstation Player上でUbuntuがときどき起動不能になる、という問題が解決したかどうかはもう少し様子を見る必要があります。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
VMware Workstation PlayerでLinuxから音を出す
Mac OS X(macOS)風のGUIスタイルとジェスチャーをもつLinuxとして、Pearl Linux OS 4.0(PearlDesktop-wGnome-4.0-1-09116 amd64)の日本語表示と日本語入力などの記事をアップしてきました。
Pearl Linux OS 4.0は、説明の画面をキャプチャーするため、VMware Workstation 14 Player上に構築し操作を行いました。
もし、同じようにVMware Workstation Playerの上で、Pearl Linux OS 4.0を構築していると、ある環境条件下では「音がでない」現象が発生している可能性があります。
ホストマシン(Windows)でサウンドカードがRealtek High Definition Audio Deviceの場合に起きる現象です。
問題を起こした(問題の可能性のある)今回の環境をまとめると以下になります。
■ サウンドカード:Realtek Hight Definition Audio Device
■ 仮想環境:VMware Workstation 14 player
上記の環境で、ゲストOS(この場合は、Pearl Linux OS 4.0)起動時に下記のメッセージが表示されます。
デフォルト サウンド デバイスを開くことができません: システムにとって範囲外のデバイス ID を使用しました。 サウンドが切断されます。
The default sound device cannot be opened: A device ID has been used that is out of range for your system. Failed to connect virtual device sound.
この障害対応を調べてみると、ホストOS(Windows)の「Realtek HD オーディオマネージャ」からコネクタ設定を変更すると解決する、という情報がネット上にはあります。「フロントパネルジャック検出を無効にする」にチェックを入れればVMwareのゲストLinuxで音が出るようになる、という解決策です。しかし・・・。
↑「Realtek HD オーディオマネージャ」からコネクタ設定を開いた画面です。ここで「フロントパネルジャック検出を無効にします」にチェックを入れても、問題は解決しません!
解決できたのは、VMware TECHNOLGY NETWORKにある情報でした。
文中に"Here is the real solution."とありましたので信じて試してみました。この記事の環境(Windows 7/8)と異なりホストOSがWindows 10 ですが、この方法が有効でした。
以下は、具体的な問題解決ステップを記述している箇所の原文です。
In order to solve the problem, enable the "Stereo Mix" option:
1. Right-click on the sound card volume icon in the tray.
2. Select "Recording Devices"
3. In a blank or "white" space where the recording devices are listed, right-click and enable "Show disabled devices".
4. The "Stereo Mix" option should appear.
5. Right-click on the "Stereo Mix" option, and select Enable.
6. Make sure that the virtual sound card is set to connect at startup for the guest VM in question.
7. Enjoy working sound in your Guest VMs.
If the "Stereo Mix" option doesn't appear in the recording devices panel, then you need to install the latest Realtek AC'97 codec drivers here:
After installation of the updated drivers, repeat steps #1-#7.
Hope this helps and makes the solution official.
適宜、補足を加えながら日本語訳を下に示します(参考です)。
問題の解決には、「ステレオ ミキサー」オプションを有効にする必要があります。
- トレイにあるサウンドアイコン(スピーカーのアイコン)を右クリック
- メニューから「録音デバイス(R)」を選択
- (サウンドの「録音」タブに)録音デバイスが表示されていない箇所で、右クリックして「無効なデバイスを表示」にチェックを入れる
- 「ステレオ ミキサー」が表示される
- 表示された「ステレオ ミキサー」を右クリックして、メニューの「有効」を選択
- ゲストOS(linux)の仮想サウンドカード設定で「起動時に接続(O)」にチェックが入っていることを確認
- ゲストOS(linux)で音が出るので楽しんで!
もし、「ステレオ ミキサー」オプションが「録音デバイス」パネル(サウンドの「録音」タブ)に出てこないときは、最新のRealtek AC'97コーデックドライバーを以下のリンクからインストールしてください。
最新ドライバーのインストールが終了したら、上記の#1~#7のステップを再度行ってください。
この方法が役に立って、公式な解決手段となることを期待しています。
私の環境では、#3の録音デバイスの表示で既に「ステレオ ミキサー」が表示されていましたので、#5の「有効」にするだけでした。
↑サウンドの「録音」タブに「ステレオ ミキサー」が表示され、設定は「有効」の状態です。
そして重要なのは、上記には記述がないのですが、#6の後にホストOS(Windows)の再起動が必要でした。
Pearl Linux OS 4.0でのテストは、GNOME Flashback(Compiz)セッションにログインして行えます。
↑右上の時刻を示すアイコンの左となりのアイコンをクリックして、「サウンド設定...」を選択。
↑「サウンド」設定画面が開きます。右下の「スピーカーのテスト(T)」ボタンをクリック。
↑左前[テスト]や右前[テスト]をクリックすると、『sound left』『sound right』の音声が出ます。
上記のようなめんどくさいテストをしなくても、Youtubeなどで音楽を聴くなどして確認しても良いですね。
ゲストマシンのメモリトラブルがホストマシンまで影響(Page Fault)
- 仮想化ソフト
- ゲストマシン
- ホストマシン
- ゲストマシン上
- コミット済み(コミットチャージ)と使用物理メモリーの割合は両方とも100%近くに達していた。ゲストマシンでメモリーを多く消費しているのは、Windows Updateサービスに関連するsvchost(netsvcs)というプロセス 。
- ホストマシン上
- コミット済み(コミットチャージ)が物理メモリーと仮想メモリーの合計値にじわじわと近づき、最終的にコミットチャージが100%に達する。 このとき、使用物理容量の使用割合は1/4以下。 メモリーのコミット済みの量は増えるのに物理メモリー使用量が連動して増えない。
- ゲストマシンでsvchost.exe(netsvcs)の負荷が高いことから、Windows Updateの負荷を抑えたい。 そのため、あらかじめ重要な更新プログラムをダウンロードしておきゲストマシンで実行(今回は、KB4015546とKB4014661)。 2. ゲストマシンのセキュリティソフト変更
- Microsoft Security Essentialsをやめて、COMODO Internet Securityに変更。
- VMware Workstation Playerの環境設定で、「仮想プリンタを有効にする」のチェックを外す。
- dural portsにするため、以前、外しておいたNICをPCIeに増設(今回の障害に関連しないと思うが、後でdual ports構成を利用予定)。
上記の対策項目をひとつずつ行うともっと原因追及ができたかも知れませんが、時間的な余裕がありませんでした。
ゲストマシン(OS)上のメモリトラブルがゲストマシン内だけに収まらずに、ホストマシン(OS)まで派生するのは意外でした。 Windowsのメモリ管理の問題なのか、VMware Workstationのメモリ管理の問題なのか分かりません。
4項めのNIC増設は、障害対応には無関係だと思います(ついでなので増設しただけ)。
ゲストOS起動のためのバッチファイルとWshShellのRunメソッド
通常、ゲストOSの起動は、デスクトップにある「VMware Workstation Player」をクリックしてライブラリーを開き、次に目的のゲストOSをクリックして起動する、という操作になります。
【1】メモ帳などのテキストエディタを使って次の1行のコマンドを書きます。ファイル名を「VMwin7x64start.bat」などとして保存します。ここでは例として、保存する場所を「C:\tools\VMstart」とします。
このまま、VMwin7x64start.bat バッチファイルをダブルクリックすることで、ゲストOSをVMware Workstation Playerライブラリーを介さずに起動できます。
参考にさせていただいたのは、「VBScriptで外部コマンドを実行する方法・Runメソッド」です。第2パラメータに「ウィンドウを非表示にし、別のウィンドウをアクティブにする」という値「0(ゼロ)」を使えば良さそうです。第3パラメータの指定ですが、今回は1個のプログラムを起動するだけなので、「True」でも「False」でも構いません。
【2】メモ帳などのテキストエディタを使って次の4行のコマンドを書きます。ファイル名を「VMwin7x64start.vbs」などとして保存します。
<注>
ランキングに参加しています。
VMware Workstation Player - ゲストOSの名前変更

すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。