「VirtualBox」カテゴリーアーカイブ

WSL2やHyper-Vと共存できるVirtualBox 6.1.16が公開されました

1. WSL2やHyper-Vと共存できるVirtualBox 6.1.16が公開されました

VirtualBox 6.1.16が公開されました。このバージョンでは、長らく待たれていたWSL2やHyper-Vとの共存がサポートされています。

こちらでも、VirtualBox 6.1.16をインストールしてUbuntu 18.04とCentOS 7でsudo apt upgaradeとsudo yum updateが完了しすることを確認しました。

2. パフォーマンス

VirtualBoxは、安定して動いていますが、パフォーマンスに影響があります。

フォーラムでの報告では、Knoppix ISOでmd5sumでのchecksumを計算する時間の計測です。

最初の計測/2回めの計測 83/56秒 Hyper-Vなし
最初の計測/2回めの計測 42/25秒 Hyper-Vあり

引用元:VirtualBoxフォーラム

これをみると、パフォーマンスが50%ぐらいになっています。実際にsudo apt upgradeしてみると、少し遅くなっていることが感じられます。

3. これまでの経緯

前回も書きましたが、かんたんにこれまでの経過を説明します。

VirtualBoxは、Windows 10 1809のときにバージョン6.0.0でHyper-Vに対応しました。

しかし、Windows 10 1903のときにMicrosoftがAPIを変更してしまい動かなくなりました。

原因は、仮想化のすべての処理をユーザーモードで行わなくてはいけないようにしたからです。

その後、何回かの修正を経て今回は動くようになりました。

4. 不具合の報告

不具合の報告が出ていて、Debianがフリーズするという話があります。お使いのゲストOSによっては、動かないことがあるかもしれません。

5. まとめ

WSL2やHyper-Vに対応したVirtualBox 6.1.16が公開されました。パフォーマンスは悪くなっていますが、安定して動いています。

不具合の報告もありますので、注意が必要です。

WSL2とVirtualBoxの現状

1.WSL2とVirtualBoxの現状

WSL2を有効にしたときにVirtualBoxはどうなのか確認してみました。

結果から言うと、不安定で使えなかったです。

デスクトップが表示されるところまでは行きます。でも、画面の大きさを変えたり、sudo apt upgradeしてもsegmentation faultで止まったりします。

フォーラムでの開発者の発言を聞いていると、とりあえず動くようにはしたけどといった発言が見られます。開発の優先順位は低くて、あまり活発に開発しているようには見えません。

また、安定してきたら試してみようと思います。

2.Hyper-VとVirtualBoxのこれまでの関係

VirtualBoxは、Windows 10 1809のときにHyper-Vに対応しました。VirtualBoxのバージョンは、6.0.0です。

Windows 10 1903のときに、MicrosoftがAPIを変更してしまって、VirtualBoxは動かなくなりました。この変更は、すべての処理をユーザーモードで行うことを強制するものです。VirtualBoxの開発者の方の話では、全てをユーザーモードで処理するのは耐えられないそうです。I/Oのパフォーマンスが出ないそうです。

VirtualBox 6.1.0になって、VirtualBoxとしての最適化は無しでまた動くようにはしたそうです。けれど、自分の方で試した限りでは安定して動いていません。フォーラムを見ていると不具合報告も出ていますが、開発者サイドでは不具合が出ていなくて、特に対応もしていないようです。

3.まとめ

WSL2とVirtualBoxの現状を確認しました。残念ですが、安定して動作していません。

また、安定したら試してみようと思います。

VirtualBox 6.1でIntel CPU上のNested Virtualizationがサポート

はじめに

VirtualBox 6.1でIntel CPU上のNested Virtualizationがサポートされました。

早速使ってみました。ゲストOSが動くことは動くのですが、とても遅いです。そこがちょっと残念。

公式にサポートされているのは、VirtualBox 6.1.0上でVirtualBox 6.1.0を動かすことです。

また、第5世代Core iプロセッサー以降のCPUがサポート対象です。

試した結果

こちらで確認できたのは次の2つです。実マシン上をLevel 0として、ゲストをLevel 1とLevel 2で表します。

なお、実マシンはCore i5 9400の自作PCです。

Level 1 ゲストのVirtualBoxで、ネステッドVT-x/AMD-Vを有効化にチェックが入っていないといけません。
Level 2 ゲストではグレーになってチェックできないようになっています。

VirtualBox上でVirtualBoxを動かす

Windows 10上のVirtualBox 6.1.0で、Ubuntu 18.04を動かし、そのUbuntu上でUbuntu 18.04のLiveCDは動きました。
また、2時間ほどかけてインストールもやってみましたが、正常に終了。

Level 0: Windows 10 VirtualBox 6.1.0
Level 1: Ubuntu 18.04 VirtualBox 6.1.0
Level 2: Ubuntu 18.04

どうして遅いのかをチェック。まず、sysbenchでCPUのスピードをチェック。
sysbenchというベンチマークソフトウェアで測定すると、
Level 1 ゲスト: 1398
Level 2 ゲスト: 1243
1243/1398 = 0.89
でした。
大体89%のスピードで動いているわけですが、体感的にはもっと遅く感じます。

次に、dbenchでディスクI/Oをチェック。Windows上で、シーケンシャルRead/シーケンシャルWrite = 500MB/s / 300MB/sくらい出るSSDを使っています。dbenchでスループットを測定すると、
Level 1 ゲスト: 152MB/s
Level 2 ゲスト: 20MB/s
でした。
ということで、ディスクアクセスが極端に遅くなっていることがわかりました。原因としては、NTFSファイルシステム上のext4ファイルシステム上のext4ファイルシステムということで、ファイルシステムを入れ子にしていることが考えられます。VirtualBoxに、SSDのパーティションを直接アクセスさせる方法があります。Rawハードディスクアクセスという方法です。マニュアルを調べてみると、MBR形式のハードディスクのパーティションは指定できるけれど、GPT形式のハードディスクの記述はないみたいですね。SSDを1つまるごと使うほかないのかな。それを使うと改善されるような気がします。

少しでも速くならないかとLevel 1 ゲストのVirtualBoxで、CPUプロセッサ数を2にしたところ、Level 1 ゲストごとフリーズしました。プロセッサ数は1でないと起動しないみたいです。

KVMを試す

また、KVMを試したところ、Ubuntu上のKVMでFedora 10のResucue CDは動きました。
でも、これは公式にはサポートされていません。

Level 0: Windows 10 VirtualBox 6.1.0
Level 1: Ubuntu 18.04 KVM
Level 2: Fedora 10

まとめ

Intel CPU上のNested Virtualizationを確認しました。安定して動いています。
Level 1 ゲストのVirtualBoxでCPUプロセッサ数を2にするとフリーズします。
まだVirtualBox上のVirtualBoxしかサポートされず、サポート範囲が狭いです。
KVMは一応動作します。
ゲストOSを入れ子にすることで、CPUは89%のスピードで動いています。
ディスクアクセスが極端に遅くなっていることがわかりました。対策すればなんとかなるかな。

おまけ

ちょっと技術的なことを付け加えると、Level 0のVirtualBox 6.1.0で、ゲストOSを動かしたときに、ログファイルを確認すると、VT-x featuresのVMX - Virtual-Machine Extensionsのところがhostとguestとも1になっています。guestが1になっていることがNested Virtualizationを許可するということです。

00:00:02.639739 *********************** VT-x features ***********************
00:00:02.639739 Nested hardware virtualization - VMX features
00:00:02.639740   Mnemonic - Description                                  = guest (host)
00:00:02.639740   VMX - Virtual-Machine Extensions                        = 1 (1)

また、その下の方のVmcsShadowingのところでhostが1になっています。第5世代Core iプロセッサー(Broadwell)以降でないとこの機能が使えないそうです。第4世代のHaswellの一部のプロセッサーでも有効との話がありますが、こちらでは未確認です。
UnrestrictedGuestのhostが1なことが最低でも必要だそうです。

00:00:02.639752   UnrestrictedGuest - Unrestricted guest                  = 0 (1)
00:00:02.639754   VmcsShadowing - VMCS shadowing                          = 0 (1)

ログファイルでVMXとVmcsShadowingが確認できたら、Level 1のゲストの中でLevel 2のゲストが使えると思います。

Level 1のLinuxのゲスト上では/proc/cpuinfoを確認することでもできます。

$ cat /proc/cpuinfo

これでflagsの中にvmxの文字があることを確認してください。

VirtualBox 6.0.8にアップデート

VirtualBoxを5.2.30から6.0.8にアップデートした。

Ubuntu 16.04ゲストでGuestAdditionsをインストールすると、起動途中の壁紙が出たところで画面がちらついたまま安定せず、デスクトップが出てきません。設定のディスプレイで、3Dアクセラレーションを有効化をオフにしたら安定して使えるようになりました。

CentOS 7.6ゲストでは初めから3Dアクセラレーションはチェックされてなくて問題は起きませんでした。

なお、VirtualBox 6.0.4以前にUbuntuをインストールしようとすると、マウスカーソルが表示されなくなる問題が起きているそうです。以下のように設定のディスプレイでグラフィックコントローラーをVBoxVGAにして、システムのポインティングデバイスをUSBタブレットにすると回避できるそうです。

VirtualBox 6.0で作成した仮想マシンにCentOSをインストールしようとするとマウスカーソルが表示されない問題への対処

こちらで、VirtualBox 6.0.8にUbuntu 18.04をインストールしても、マウスカーソルは消えなかったです。でも、VirtualBoxを終了して、VMware Player 15.1.0を使ったときに問題が発生しました。VMware Player 15.1.0の画面をリサイズすると追随してくれなくて、右と下が切れてしまいます。位置もずれて強制的に終了するしかありません。

VirtualBox 6.0.8のUbuntu 18.04の設定で、ディスプレイのグラフィックスコントローラーをVMSVGAになっていたところを、VBoxVGAにしたところ、VMware Playerの変な挙動は直りました。VirtualBoxのグラフィックコントローラーのVMSVGAは、バグを持っている感じがします。

VirtualBox 6.0でNested Virtualization

VirtualBox 6.0 でAMDのCPU上でNested Virtualizationがサポートされました。なんと、Intel CPUではなくAMD CPUです。

何はともあれ、サポートされたことはめでたい。

Nested Virtualiztionというのは、ゲストOSの中でゲストOSを動かせるということです。これで、仮想環境の中でOpenStackなどの仮想化ソフトをテストすることができます。

VMware Playerでは、Intel CPUしかサポートされていないみたいなので、AMDの人には朗報ですね。

でも、フォーラムを見るとThreadripperでは動かないという報告もあるようです。まだ、出来たばかりでバグがあるということでしょう。

Intel CPU上でもサポートされるよう気長に待ちましょう。

VirtualBoxを5.2.18にアップデート

Windows 10 October 2018 Updateにしたら、VirtualBox 5.1.30のネットワークが動かなくなりました。そのため、VirtualBoxを5.2.18にアップデートしました。

無事ネットワークが動いて一安心。

Guest Additionsも再インストールしました。

ここで、CentOS 7は、yum clean all しないと、404 errorでyum updateできなかったです。

CentOSもUbuntuも最近のOSは、再起動すると更新プログラムを自動で見に行っているのですね。手動でyumやaptを動かそうとしてもエラーになって動かないです。便利だか不便だかわからないなと思いました。自動更新は止められるのでしょうけど、今後の課題です。

Windows 10をFall Creators UpdateにアップデートしたときのVMware PlayerとVirtualBox

Windows 10をFall Creators Updateにアップデートしました。

VMware Workstation Player 12.5.5のネットワークがつながらなくなりました。アプリと機能ー>プログラムと機能 から修復を選んで修復。その後、VMware Workstation Playerの設定画面のネットワークアダプタの設定で、VirtualBoxのアダプタを外すことでネットワークにつながりました。

VirtualBoxは動かなくなったので、古いものはアンインストールしてVirtualBoxをダウンロードしてインストールしました。最初5.2.0をインストールしたのですが、画面の大きさが1024x768の固定になってしまったので5.1.30に変えました。5.2系はまだインストールするには早いようです。

VirtualBoxの共有フォルダの自動マウント

VirtualBoxの共有フォルダを自動マウントしようとしたところ、以前とは少し違っていたので紹介します。

まず、VirtualBoxのメニューのデバイス、共有フォルダで設定をします。名前をshareとしました。自動マウントと永続化のチェックは入れておきます。

次に、Ubuntu 16.04 x64で手動でマウントするには以下のようにします。

$ mkdir sharepoint
$ sudo mount -t vboxsf -ouid=hoge,gid=hoge share sharepoint

これを、Ubuntuの起動時に自動でマウントするには/etc/fstabに次のようなエントリーを加えます。
名前がhogeさんの場合です。

/etc/fstab

share	/home/hoge/sharepoint	vboxsf uid=hoge,gid=hoge,comment=systemd.automount	0	0

fstabの各項目の間はtabを使うといいです。

そして、/etc/modulesに次の項目を加えます。

/etc/modules

vboxsf

ここで、手動でマウントできるか確かめてみます。

$ sudo mount share

マウントできれば/etc/fstabの設定は大丈夫です。あとは再起動して自動でマウントできるか確かめます。/etc/modulesの設定を忘れるとUbuntuの起動が途中で止まってしまいます。

以前作ったときは、/etc/fstabにcomment=systemd.automountという設定は必要なかった気がします。systemdではこれがないといけないようです。

VirtualBoxのGuestAdditionsのサービスが起動してからでないとマウントできないからというのが理由だそうです。

Vagrantだと、Vagrantfile内でsynced_folderを設定すると自動でやってくれます。その辺が少し違っていますね。

参考にしたサイト
Virtualbox shared folder mount from fstab fails; works once bootup is complete
VirtualBoxの共有フォルダの自動マウント化

なお、共有フォルダの設定で自動マウントにすると/media/sf_(共有フォルダ名)でマウントされています。でも、所有者がrootグループがvboxsfになっていて使いにくいのですね。それで自分でマウントすることにしました。

そのあたりのことはこちらを参照ください。

VirtualBoxにおいて、ホストOSとゲストOS (CentOS) 間の共有フォルダを作成する方法

追記(2017/06/30)

共有フォルダの自動マウントで設定された/media/sf_(共有フォルダ名)は、vboxsfというグループに自分のユーザー名を加えると簡単に読み書き出ることがわかりました。

sudo gpasswd -a (ユーザー名) vboxsf

こうすれば、わざわざ自分でマウントする必要はなかったですかね。

Vagrantでprivate_networkを指定したときの仕組み

Vagrantでネットワークの設定は3つあります。このうち、private_networkを指定したときにVagrantは少し複雑な処理をしていました。

1つめのVagrantでpublic_networkを指定したときは、VirtualBoxのブリッジアダプターが使われ、外部のルーターなどからDHCPでIPアドレスをもらいます。

2つめのforwarded_portを指定したときは、VirtualBoxのNATが使われて、VirtualBox内蔵のネットワークからDHCPでIPアドレスをもらいます。

3つめのprivate_networkを指定したときは、VirtualBoxのホストオンリーアダプターという仮想ネットワークアダプターが使われます。この場合、上の2つとは少し違っていて、DHCPサーバーはデフォルトでは設定されていません。このことは、ホストの仮想ネットワークアダプターのプロパティからわかります。IPアドレスは、192.168.33.1というアドレスが設定されています。

このため、ゲストOSは192.168.33.x(xは2から254)というネットワークを自分で設定しないといけません。Vagrantではvagrant upのときに、ssh接続を使って/etc/network/interfacesに次のようなエントリーを書き込みます。

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
auto enp0s8
iface enp0s8 inet static
      address 192.168.33.10
      netmask 255.255.255.0
#VAGRANT-END

これでIPアドレスが設定されて、ホストとゲストで通信ができるようになります。このような仕組みのため、vagrant upのときにvagrantというユーザーでSSHで接続できることと、ファイルに書き込む権限がいるためにスーパーユーザーになれることが条件になります。

Vagrantを使わずVirtualBoxのみでプライベートネットワークを組んだ時は、手作業でネットワークインターフェース、この場合はenp0s8の設定をする必要があります。

自分でvagrantboxを作ろうとして、わかったことでした。

VirtualBoxのCUIコンソールでクリップボードのコピーペースト

VirtualBoxのCUI(Character User Interface)コンソールでCtrl-Vでコピーペーストをしようとしたけど^Vが表示されるだけで困っている。コピーペーストはマウスを使わないといけないのかな。

そんな人の悩みに答えます。

この記事では、次のことがわかります。
1. Gnomeデスクトップの端末で、コピーペーストをする方法
2. Gnomeデスクトップが立ち上がる前のVirtualBoxのコンソールでコピーペーストをする方法
3. まとめ

1. Gnomeデスクトップの端末で、コピーペーストをする方法

Gnomeデスクトップが立ち上がっている場合、コピーペーストは端末アプリの編集に、コピーと貼り付けがあります。コピーしたいところをマウスで白黒反転させておいてから、コピーを選び、貼り付けたいところにカーソルを持っていって、貼り付けを選べばいいです。

なお、ゲストOSとホストOSの間でコピーペーストができない場合は、VirtualBoxのGuestAdditionsが動作しているかどうか確認してください。

このときに、キーボードショートカットのCtrl-C/Ctrl-Vを使おうとすると、画面に^Vと表示されてしまって貼り付けできません。

解決方法は、Ctrl-Shift-CとCtrl-Shift-Vを使えばよいです。

Ctrl-Cは、プロセスの終了に割り当てられているため、Gnomeデスクトップの設定でこうなっています。

2. Gnomeデスクトップが立ち上がる前のVirtualBoxのコンソールでコピーペーストをする方法

Gnomeデスクトップが立ち上がる前のVirtualBoxのコンソールでは、ショートカットキーは使えません。そこで、xselというコマンドを使います。

サーバーバージョンのCentOSを使っていて、Gnomeデスクトップがない場合などに相当します。

ここでは、CentOSについて説明します。

2-1. xselのインストールと動作の確認

コンソールでxselと打ち込んでコマンドがない場合は、xselをインストールします。このときに、Xvfbという画面のないXサーバーを使いますので、同時にインストールします。

sudo yum install xsel Xvfb

Xvfbを立ち上げます。

Xvfb -screen 0 1280x720x24 &
export DISPLAY=:0

もし、Xvfbが立ち上がっていなくてxselを使おうとすると、次のようなエラーが出ます。DISPLAY変数がexportされてないときも同様です。

xsel: Can't open display :(null)

準備の最後にVBoxClientを立ち上げます。

VBoxClient --clipboard

これで、ホストOSとゲストOS間でコピーペーストできます。準備は終わりです。

例えば、文字列aaaをクリップボードへにコピーするには、次のようにします。

echo aaa |xsel --input --clipboard

クリップボードからのペーストは次のようにします。

xsel --output --clipboard

これでクリップボードをコマンドで使うことができるようになりました。

2-2. pbcopy/pbpasteコマンドにまとめる

いちいちxselのコマンドを打ち込むのは手間がかかりますので、pbcopy/pbpasteというコマンドにまとめます。pbcopy/pbpasteは同名のMac OSのコマンドです。

ホームディレクトリの.bash_profileの最後にaliasで定義します。

.bash_profile

alias pbcopy="xsel --input --clipboard"
alias pbpaste="xsel --output --clipboard"

aliasを書いたあとは $ source .bash_profileで有効にします。

2-3. viで使う

コンソールの中でviを使ったとき、コピーペーストするにはもう一工夫必要でした。viの中では、:r! 外部コマンドを打つとコマンドの実行結果が入力されます。上で設定したpbpasteを実行しようとしてもエラー127のcommand not foundになってしまいます。

そのため、環境変数BASH_ENVの設定と、.bashenvの設定が必要でした。

.bashenvというファイルを作ります。
.bashenv

shopt -s expand_aliases
alias pbcopy="xsel --input --clipboard"
alias pbpaste="xsel --output --clipboard"

.bashrcの最後でこのファイルを有効にします。

export BASH_ENV=~/.bashenv

これで、viのコマンドモードで

:r!pbpaste

とすると、クリップボードにコピーされた内容を取り込むことができます。

コピーしたいときはビジュアルモードで範囲を選択して、次のようにします。

:!pbcopy;pbpaste

ちなみにpbcopyとpbpasteの間はセミコロンです。

pbopyの前のビックリマークが必要です。また、pbpasteがないと切り取りになってしまいます。

3. まとめ

VirtualBoxのCUI(Character User Interface)コンソールでコピーペーストを使えるようにしました。

CentOSのGnomeデスクトップが立ち上がる前のコピーペーストの方法について説明しました。

設定が完了するとviでクリップボードへのコピーペーストができるようになります。