会社のPCでずっとこの問題に悩まされているので現時点での解消法をメモとして残します。

現象について

VirtualBox / Vagrant環境で$ vagrant upしてLinux(Ubuntu)を起動すると、default: SSH auth method: private keyのところでずっと止まってしまいます。

運が良ければ数分待ってから起動するのですが、運が悪いとずっとUbuntuが起動しないままです。

スペック

• Windows 10 / 11
• VirtualBox 6.1
• Vagrant

使ったBOX

• ubuntu/trusty64
• ubuntu/focal64
• bento/ubuntu-20.04
• bento/ubuntu-16.04
• bento/ubuntu-18.04

A. 権限変更 継承の無効化

Windowsの$ vagrant upするディレクトリの.vagrant/machines/default/virtualBox内のprivate_keyファイルの権限を変更する。

ファイルを右クリックしてプロパティ > セキュリティ > 詳細設定 > 継承の無効化を押す。

アクセス許可のアクセス許可エントリないにいるユーザーを1人にする。ユーザーはusername(USERNAME\username)でアクセスはフル コントロールで継承元はなしにしてOKボタンで閉じる。

Aの結果

たしか1回やったらうまく行った。でも次からはうまく行かず。

B. 権限変更 継承の有効化

Windowsの$ vagrant upするディレクトリの.vagrant/machines/default/virtualBox内のprivate_keyファイルの権限を変更する。

ファイルを右クリックしてプロパティ > セキュリティ > 詳細設定 > 継承の有効化を押す。

Bの結果

Aがうまく行かなくなって、Bをやったらうまく行った。でも次からはうまく行かず。 Aをやってvagrant up。次回はBをやってvagrant up。次回はAをやって...と交互にやっていけばうまく行くかもしれないがそんなのに付き合えないのでこの方法は却下。

C. vb.customizeで設定を追加

Vagrantfileに設定を追加する。下記サンプルのココから、ココまでを追加する。

Vagrant.configure("2") do |config|
  config.vm.box = "<box名>"
  # ココから
  config.vm.provider "virtualBox" do |vb|
    vb.customize [
        "modifyvm", :id,
        "--hwvirtex", "on",
        "--nestedpaging", "on",
        "--largepages", "on",
        "--ioapic", "on",
        "--pae", "on",
        "--cableconnected1", "on",
        "--paravirtprovider", "kvm" ]
      vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
      vb.customize ["modifyvm", :id, "--uartmode1", "file", File::NULL]
  end
  # ココまで
end

Cの結果

うまく行ったり行かなかったりと安定しないのでおそらくこの方法はあまり関係なかった。

D. VirtualBoxアプリを起動してプレビューを表示する

VirtualBoxアプリを起動(表示)させて、左側にあるマシンのリストから起動したい（default: SSH auth method: private keyで止まっちゃってる）マシンを選択すると右側にプレビュー画面が表示される。プレビュー画面にごちゃごちゃと小さい文字で表示が出ているがしばらくするとログインっぽい画面が表示されるはずなのでそれまで待つ。ログインっぽい画面が表示されたら、$ vagrant upをしたターミナルに戻るとおそらく起動されている。

Dの結果

Cと併用すると起動する確率はかなりアップしたように感じた。

E. CPUのコア数を指定する

使用するCPUのコア数を指定する。下記Vagranfileサンプルのココの部分でコア数を指定。

Vagrant.configure("2") do |config|
  config.vm.box = "<box名>"
  config.vm.provider "virtualBox" do |vb|
    # ココ
    vb.cpus = 2
  end
end

Eの結果

Dと併用すると起動確率はほぼ100％になった。

結論

D(VirtualBoxアプリを起動してプレビューを表示する)とE(CPUのコア数を指定する)を併用することでvagrant upしてほぼ起動するようになりました。この問題とはもうかれこれ3年くらい付き合っていますがやっとちゃんと起動するようになりました。

一応私の経験からの感覚ですが、Dの方法はdefault: SSH auth method: private keyで止まっちゃうUbuntu以外のBoxでも有効な気がします。同じマシンでCentOSを起動するときにDの方法を行うとdefault: SSH auth method: private keyで止まることが少ないように感じました。

また、Eの方法はUbuntuのBoxで有効なような気がしています。CentOSのボックスでは特にcpuのコア数指定はしていなくても起動するからです。

CPUのコア数の指定とか、VirtualBoxアプリを起動してマシンのプレビューを表示するとかほとんど意味ないように思える対策なのに効果が出るというのが私にはよくわかりません。

適当なLinux環境であればWSL2を使えばいいし、「本格的」なLinux環境がほしいのであれば使ってないPCにLinuxをインストールするとかAWSとかのクラウドサービスでLinuxマシンを作ればいいだけな気もします。それでいいのであればWindowsマシンからVirtualBoxとVagrantをアンインストールしちまいましょう。この際Windowsマシンの入ってるPCにはUbuntuデスクトップでもインストールしちゃえばこんな悪夢ともおさらばできます。

でも、使ってないPCなんて無い、AWSとかのクラウドサービスなんかにお金は使えない、Windows環境は必要。などという場合はWindows上で「本格的」なLinuxが動くVirtualBox/Vagrantの環境はやはり魅力的です。メモリの余裕さえあればWindows上でLinuxが動きます。

補足

なお、WSL2とVirtualBox/Vagrant環境を共存させるには「Windowsの機能の有効化または無効化」で下記の項目をオンまたはオフにしておく必要があるようです。

[ Windowsの機能の有効化または無効化 の項目]

• Hyper-V: オフ
• Linux用Windowsサブシステム: オン
• Windowsハイパーバイザープラットフォーム: オン
• 仮想マシンプラットフォーム: オン

WSL2を使わない場合はLinux用WindowsサブシステムはオフでOKなようです。