VMware Workstation 17 PlayerでUbuntu 22.04 LTSをインストールしようとすると、とても遅い

Ubuntu 22.04 LTSの環境をVMware Workstation 17 Player 17.5.0 build-22583795で作ろうとしたら、インストールするのが酷く遅くて、途中で断念しました。同様の作業をVirtualBox 7.0.12 r159484 (Qt5.15.2)でも行いましたが、順調で、特に問題は起きませんでした。VMplayerを使うと、異常に遅いのは、何か設定の問題なのでしょうか。

 

Webを検索したら「Windows 10 VM Slow in Ubuntu 22.04 Host Workstation Pro 16.2.4 build-20089737」という記事を見つけました。同じような現象を抱えている人はいるようで、解決策もあるようなのですが、VMware Workstation Playerでは、同じ解決策が適用できないようです。

 

 リプライには「I don't see this option with VMware Player. Any hints?」という発言があり、私と同じ（と思われる）問題を抱えている人がいるようです。しかし解決策は提示されていません。

どうもVMware側に何か問題があるのではないかと思いますが、WMware Playerでの解決策が見つかりません。

Windows上VMware Workstation 17 PlayerにUbuntu Server 22.04 LTSをインストールしようとしたら、遅すぎて諦めた

Ubuntu Server 22.04 LTSについて調べてみたい事があったので、自宅で使用しているWindows10を使って、VirtualBox上にインストールしてみました。もう10年ほど前のハードウェアでWindowsを動かしていますので、そもそも速いマシンではありません。しかも仮想環境上にインストールするわけですから、遅くてもやむを得ないと思っていました。しかし気になるほど遅い訳でもなく、インストールできました。

 

ついでにVMware Workstation 17 Playerにもインストールしてみようと思い立ちました。VirtualBox上の環境があるので、別にVMware上にも環境を作らなくても良いのですが、 やってみました。ところが、最初は問題なかったのですが、最終段階あたりになると何故かインストール速度が遅くなりました。遅くてもインストールが完了すれば良いのですが、1時間以上待ってみましたがインストールが終わりそうにもないので、途中で中断してしまいました。

 

 Webを検索してみたところ、VMware上にUbuntu Serverをインストールしようとしたという情報は見つかりましたが、遅くて困ったという情報は見つかりませんでした。速いマシンではないので、超高速でインストールできなくても構わないのですが、VirtualBoxでは問題ないのに、VMwareでは失敗するというのが納得できません。

Windows10でWSL2

いままでWindows10でWSLを利用してきましたが、WSL2も使えるようにしました。

WSL2はWindows10 2004から利用できることになっていますが、去年は2004がいつまで経っても配信されず、なかなかWSL2が使えるようになりませんでした。そのうちに1909でも利用できるというアナウンスが流れたので、2004が待ちきれずに1909でWSL2を使えるようにしてみました。しかしWSL2を使えるようにする設定をおこなうと、VirtualBoxやVMwareに不具合が出たので、WSL2を諦めて、WSLに戻りました。

MicrosoftがWSLとWSL2を同等に機能拡張してくれればよいのですが、WSL2だけしか機能拡張されないような気がするので、なんとかWSL2に移行したいと思っていました。WSL2への移行に挑戦し、もし駄目なら再びWSLに戻るつもりで、移行作業をおこないました。結果としてWSL2が使えるようになりましたが、これまでVirtualBoxで動かしてきた環境が動かなくなるという問題も発生しました。

まずWindow10のバージョンは「バージョン 20H2 (OSビルド 19042.804)」です。ちなみにVirtualBoxは「バージョン 6.1.18 r142142 (Qt5.6.2)」を、VMwareは「VMware(R) Workstation 15 Player 15.5.7 build-17171714」を使っています。

作業手順は次の通りです。「Windows 10 用 Windows Subsystem for Linux のインストール ガイド」を参考にしました。

1. ダイアログ「Windowsの機能」から「Linux用Windowsサブシステム」と「仮想マシンプラットフォーム」を有効にしました。前者は既に有効になっており、後者はWSL2のために有効にしました。
2. ここでマシンを再起動しました。
3. インストールガイドに従い「wsl_update_x64.msi」をダウンロードし、インストールしました。
4. WSLではUbuntuを入れていたので、WSL2へ移行作業をおこないました。この作業に数時間かかったという報告をWebで見かけますが、15分くらいで終わりました。

   C:\Users\FURUSAWA>wsl --set-version Ubuntu 2

   変換中です。この処理には数分かかることがあります...

   WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

   変換が完了しました。

   C:\Users\FURUSAWA>wsl --list --verbose

     NAME      STATE           VERSION

   * Ubuntu    Stopped         2

これで無事にWSL2が使えるようになりましたが、これまでVirtualBoxで動かしていたCentOS 7.4が起動しなくなりました。しかしVMwareを使えばCentOS 7.4が動くので、それで良しとします。VirtualBoxでは、他にも、openSUSE、FreeBSD、NetBSDを動かしており、それらに問題はありませんでした。

WSL2を使おうとするとVirtualBoxやVMwareが動かない

Windows10を2004にすればWSL2が使えるようになるはずですが、20H2がリリースされたのに未だに2004が利用できるようになっていません。しかし1903や1909でもWSL2が利用できるそうなので、ひとまずWSL2を利用する設定をおこなっておきました。WSLではUbuntuを利用していますが、WSL2は別の何か（OpenSUSEなど）を使おうかと考えていました。

WSL2の利用は開始していませんが、VitualBoxを使う用事があったので起動しようとしたら、エラーが出てしまいます。つい先日までは動いていたはずなのですが。それではVMwareを動かしてみたら、これも駄目でした。何が問題なのかわかりませんが、WSL2を有効にしたのが怪しいとは思います。

WSL2を有効にしたというのは、具体的には「Windowsの機能の有効化または無効化」を利用して「仮想マシンプラットフォーム」を有効にしたという事です。だから逆に、それを向こうにしました。ところが相変わらずVirtualBoxでもVMwareでもエラーが出るのです。

同様の障害に見舞われている事例は多いようで対処方法がWebを検索すると見つかります。最終的に解決でき、VirutalBoxもVMwareも動くようになりました。この時に参考になった情報は「Windows10 1903でVirtual Box上の仮想マシンが起動できない」でした。

問題となった環境は次の通りです。もしかすると新しいマシンなら問題なかったのかもしれません。

• Windows10 1909 (OS build: 18363.1139)
• Intel Core i3-3220 3.30GHz

VMware上のCentOS7でavahiを試す

DHCPでアドレスが割り当てられたマシンに対してホスト名でアクセスできるようにするためにはavahiが使えるという情報を得ました。そういうパッケージが存在することは耳にしていました。しかし、どのような設定をすれば良いのか、 何が出来て何が出来ないのか、よくわかりません。そこでVMwareでCentOS7を動かして実験してみることにしました。

設定の参考にしたのはWebで見つけた記事「 CentOS 7でmDNS(Avahi Daemon)を有効にする」です。やる事はシンプルです。設定後に念のために再起動しました。

1. yumでavahiを入れる。
2. avahi-daemonを有効にする。
3. ファイアウォールでサービス「mdns」を通す。

ここでWindows10からpingを飛ばしてみます。すると反応がありました。すばらしい。

C:\Users\FURUSAWA>ping -4 vmware.local

vmware.local [192.168.1.17]に ping を送信しています 32 バイトのデータ:

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 の ping 統計:

    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、

ラウンド トリップの概算時間 (ミリ秒):

    最小 = 0ms、最大 = 0ms、平均 = 0ms

それでは逆にCentOSからWindows10に向かってpingを投げてみましたが、うまくいきません。コマンド「avahi-resolve」ではIPアドレスが見つかっているのに、pingでは名前をわかってくれません。ファイル「/etc/nsswitch.conf」にはmDNSを見に行くように指定している（つもり）なのですが、他にも何かする事があるのでしょうか。

[root@vmware log]# avahi-resolve -n windows10.local

WINDOWS10.local  192.168.1.31

[root@vmware log]# ping -4 windows10.local

ping: windows10.local: Name or service not known

[root@vmware log]# grep '^hosts:' /etc/nsswitch.conf

hosts:        files mdns_minimal [NOTFOUND=return] dns myhostname

VirtualBoxではkdumpが動かないのか

つい先日、VirtualBox上にCentOS7の環境を作りkdumpが動作するか確認しました。するとCentOS 7.0～7.6まで（症状が多少違うところもありますが）全て失敗したので、CentOSでkdumpが動かないものだと判断してしまいました。

しかしWeb上で見つけた情報「カーネルクラッシュダンプの基本や取り方など」によると、CentOS 7.6でkdumpが動いているようです。それならばVirtualBoxで動かないのは、CentOSの問題ではなく、VirtualBoxの問題ということになります。

試しにVMware Workstation Player上にCentOS7の環境を作って、kdumpの実験をしてみました。するとkdumpが動くのです。やはりCentOSの問題ではなく、VirtualBoxの問題だったのでしょう。しかし未だに疑問なのは、VirtualBoxでkdumpできないのは、僕だけなのか、世間一般でそうなのかという事です。VirtualBoxの既知のバグで動かないのであれば、将来のバージョンで動くようになるかもしれません。しかし、何か設定をすることでkdumpできるようにするTipsがあるのであれば、ぜひ知りたいと思います。

それにしても、何が問題なのか情報がないと、調査の糸口も掴めません。CentOSは、旧いOSのように起動時にメッセージがズラズラと出てこないので、何が悪いのか判断する情報が得られないのです。昔は起動時に長々とメッセージがコンソールに流れていましたが、一般受けしないので出さなくする傾向にあるのだと思います。

なんとか情報が得られないかと調べていたら、GRUB2のブートメニューで編集モードに入り、パラメータを変えれば良いようです。パラメータ「rhgb quiet」の指定を消せば昔のOSのように起動ログが出てくるようになります。また更に詳しい情報が必要ならパラメータ「loglevel=7 systemd.log_level=debug」を指定すれば、もっと詳しく情報が出てきます。

この指定をおこなってVirtualBoxでkdumpを起動しようとしたところ、2nd kernelの起動ログが出る前にVirtualBox自体が落ちてしまいました。そもそも2nd kernelに制御が渡っていないようです。

VirtualBoxがエラーを出す原因を突き止める方法がわからない

Windows10にVirtualBoxをインストールして、普通に使えているのに、何故か日曜日なると使えなくなります。このブログの以前の記事に書いた通りです。日曜日の朝にマシンの電源を入れるときは、普段よりも時間がかかっています。ここで行われている何かの処理が原因ではないかと疑っています。もしくは前日の土曜日に電源を落とすときも、普段より時間がかかっているような気がします。もしかすると、ここで行われている処理が原因なのかもしれません。

いずれにせよ、わかっていることは日曜日なるとVirtualBoxが使えなくなるということです。VirtualBox自体は起動するけど、その中にある仮想PC環境が起動しないということです。

同様の現象はWebを検索すると多くの事例が見つかります。解決方法としてセキュリティ対策ソフトとの関係について言及していることがあります。その設定を変更することで、またはセキュリティ対策ソフト自体をアンインストールすることで、問題が解決できると記されています。

僕が利用しているセキュリティ対策ソフトはマカフィーとラポートですが、これらの設定を変えなくても、当初はVirtualBoxが普通に使えているのです。セキュリティ対策ソフトの設定を替えたりしなくても、VirtualBoxは問題なく利用できているのです。ここから考えると、セキュリティ対策ソフトの設定の如何にはよらない気がします。

VirtualBoxは起動していくときの詳細なログをファイルに残しているのですが、見てもサッパリわかりません。ところどころにエラーが出ているのはわかるのですが、それを見ても解決の糸口にはならないのです。

毎日VirtualBoxを利用しているわけではないので、動かなくなったら再インストールして対処するのでも構わないのですが、ちょっとうんざりしているのも確かです。いっそのことVirtualBoxを捨てて VMware Playerに乗り換えようかという気もしてきました。