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の文字があることを確認してください。

VMware Workstation PlayerでゲストOSのスリープからの復帰をエミュレートする

***本記事にはプロモーションが含まれています。***

Windows 10で、フリーのバックアップソフトを使ってみたときのこと。

なぜかわからないのですが、パソコンをスリープさせると、すぐに復帰とスリープを繰り返します。

他のマシンでも同じことが起こるのか確認をするために、VMware Workstation Playerで、Windows 10 のクリーンインストールをしたあと、バックアップソフトをインストールして確認してみました。

この、スリープから復帰することを確認するのに、VMware Workstation Playerでは、ACPI S3 Sleepというスリープの状態をエミュレートすることができます。.vmxファイルに次のようなエントリを付け加えてからVMware Workstation Playerを起動します。

chipset.onlineStandby = TRUE

こちらの情報より。
VMware Workstation 5.0 Guest ACPI S1 Sleep

通常スリープすると、仮想マシンが終了してしまって電源が切れた状態になります。

このエントリを付け加えてWindows 10を起動しスリープすると、画面が黒くなったまま待機してくれて、時間が来るとスリープから復帰することを確認することができました。

実験的な実装で、すべてのOSで動くわけではないそうですが、Windows 10では大丈夫でした。ただ、タスクで復帰してもイベントビューワーでは電源ボタンが原因になっていて完全にエミュレートされているわけではないようでした。

肝心のバックアップソフトは、Windows 10のコンピューターの管理、サービスから、サービスを手動で起動することにして、Windowsの起動時にはサービスが起動しないようにすることで対処することにしました。ただ、スケジュールを使ったバックアップが使えなくなりました。

以上、VMware Workstation Playerを使って、ゲストOSのスリープからの復帰について確認するお話でした。

VMware Workstation 15.1.0 Playerにアップデート

***本記事にはプロモーションが含まれています。***

VMware Workstation Playerを15.1.0にアップデートした。

Ubuntu 18.04、CentOS 7.6といったところは問題なく動いたけど、open-vm-toolsでは共有フォルダが使えず、手動でVMware Tools 10.3.10をインストールしました。
最近open-vm-toolsが使えなくなっている気がします。

それと、VirtualBoxでグラフィックアダプターにVMSVGAを指定していると、画面をリサイズしたときに右と下が切れてしまう現象を確認しています。VirtualBoxでVBoxVGAに設定を変えると起こらなくなります。ご注意ください。

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は、バグを持っている感じがします。

VMware Workstation Playerを15.0.2にアップグレード

***本記事にはプロモーションが含まれています。***

VMware Workstation Playerの14.1.2の上で、Ubuntu 18.04とopen-vm-toolsを使っていたのですが、共有フォルダが使えなくなっていました。

そこで、VMware Workstation Player 15.0.2にアップグレードしました。すると、画面もちゃんと表示されなくなってしまいました。そこで、open-vm-toolsをアンインストールして、VMware Tools 10.3.2をインストールしました。これで、共有フォルダとコピーペーストが使えるようになりました。

open-vm-toolsがいつも使えればいいのですが、時々、使えなくなったりするのが問題ですね。そのたびに、VMware Toolsをインストールしなおしている気がします。

VMware Toolsをインストールしようとして、open-vm-toolsが入ってないのに入っていると警告が出る時は、設定ファイルが残っているかもしれません。その時は、

$ sudo apt-get purge open-vm-tools

して、設定ファイルを消すといいです。

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上でもサポートされるよう気長に待ちましょう。

コンテナからSR-IOVデバイスを利用

***本記事にはプロモーションが含まれています。***

コンテナと聞くと、ソフトウェア的にホストと環境を分離する技術だと思っていました。ホストの環境をただコピーして利用しているだけだと。

けれど、次の記事でSR-IOV対応デバイスを利用できることが紹介されています。

第539回 LXDのコンテナからSR-IOV対応デバイスを利用する

SR-IOV対応デバイスであるイーサネットカードにVirtual Functionを設定してそれを利用するのだそうです。

2つのコンテナから利用していることも驚きでした。SR-IOVは、ゲストOSからデバイスを占有する方法じゃなかったのでしょうか。

Dockerからだとpipeworkというのを使うとできるらしいです。

Host with SR-IOV NIC - Docker containers to use each VF individually

性能もオーバーヘッドなく使えているみたいですね。

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を動かそうとしてもエラーになって動かないです。便利だか不便だかわからないなと思いました。自動更新は止められるのでしょうけど、今後の課題です。

ARM用のDockerイメージをQEMUを使って作る

***本記事にはプロモーションが含まれています。***

ARM用のDockerイメージを作る時に、QEMUのqemu-user-staticを使ってCPUエミュレーションを行う方法が紹介されています。

Jetson 上で Docker イメージをビルドするのが辛かったので EC2 上にビルド環境を作った

ARM用のバイナリを作る時に、ARM上のシステムでは時間がかかって仕方ないため、x86_64上のシステムで作ってしまおうということですね。

エミュレーションでどれくらいのスピードが出るのか使ったことがないのでわかりませんが、ARMネイティブで作るよりはいいみたいですね。

最近のQEMUをWindowsで作ってみた

***本記事にはプロモーションが含まれています。***

QEMUをWindowsで作るには、MSYS2という環境を使うわけです。msys2-x86_64-20161025.exeというのを使って作ったMSYS2で、去年QEMUを作ろうとしたらエラーで作ることもできずそのままになっていました。

そこで、ちょっと本腰を入れて作ってみました。

エラーは、export dashlessという表示がされるエラーなのですが、調べてみるとMSYS2のエラーのようです。

そこで、pacman -Syuでパッケージを全部アップデートして対処しました。このエラーは出なくなりました。

ところが、capstone.libをmakeするルールがありません、というエラーが出ます。仕方ないのでconfigureに--disable-capstoneをつけて対処しました。

すると、めでたくQEMUを作ることができました。

こんな感じのconfigureです。

./configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --disable-capstone

Python2については、MSYSのものを使ったので指定しています。capstone.libはMinGW64の問題のようでメーリングリストにも出ていましたが、使わないように指定するしか今のところ対処の方法はなかったです。あとtexinfoの警告が出ていますが、MSYS2の問題です。

簡単ですが、何かの参考になれば。

仮想化やクラウドについて