注記：本記事は2017年時点のVM構築について解説しています。

2020年版については、「Building a Homelab VM Server (2020 Edition)」をご覧ください。

概要

自宅での開発作業のほとんどは、仮想マシン（VM）で行っています。メインのデスクトップPCはWindows 10なので、これまではVirtualBox上でVMを動かしていました。

この構成でも特に問題なく動いていましたが、徐々に不便な点が目立つようになってきました。検索する中で見つけたのが、Brian Moses氏によるこちらの記事です。VM実行専用の「ホームラボ」サーバーを自作した過程が紹介されており、とても魅力的に感じたので自分でも同じように作ってみることにしました。

なぜVMを使うのか

クリーンな環境を保てる

私が書くソフトウェアは、それぞれ特定のソフトウェア環境に依存しています。たとえば、私のプロジェクトであるProsperBotの開発には、Goのツールチェーン、nginx、Redisが必要です。こうした依存関係をすべてメインのデスクトップPCに直接インストールし続けると、さまざまなウェブサーバーやデータベースサーバー、競合するライブラリのバージョンが混在し、環境はすぐに散らかってしまいます。

セキュリティ：VMによる隔離

VMはソフトウェアをメインシステムから隔離することで、セキュリティ面でも役立ちます。新しいツールやアプリを試すのが好きなのですが、アプリが悪意を持っている可能性は常にあります（開発者が意図的に悪意のあるアプリを作った場合もあれば、正規のアプリが攻撃者に乗っ取られてマルウェアの拡散に使われる場合もあります）。アプリをWindowsマシンに直接インストールしてマルウェアに感染してしまえば、それで終わりです。マシン上で動作するごく単純なマルウェアでも、画面の内容をすべて記録したり、GmailやFacebook、GitHubを乗っ取ったり、すべてのファイルを人質に取ったりできてしまいます。

一方、VM内で動作するマルウェアが与える被害ははるかに限定的です。VM内でソフトウェアをインストールし、そこにキーロガーが密かに仕込まれていたとしても、記録できるのはそのVM内でのキー入力だけで、メインのデスクトップマシンには影響しません。もちろんVMも完全な防御になるわけではなく、高度なマルウェアはVMを脱出する可能性もありますが、それでも大きな保護効果があります。

なぜ専用のVMサーバーが必要なのか

これまでメインのWindowsデスクトップ上のVirtualBoxで仮想マシンを動かしてきましたが、いくつか問題がありました。

• メインPCを再起動するたびに、実行中のVMを一つひとつ手作業でシャットダウンまたはサスペンドし、再起動後にまた一つずつ起動し直さなければなりません。
• メインPCは月に一度ほどクラッシュするのですが、VirtualBoxはクラッシュからの復旧が非常に苦手です。再起動するとVMのイメージファイルがロックされたままだと誤認し、ファイルシステムをあれこれいじって修復しなければなりません。

専用のVMサーバーがあれば、最小構成のLinuxサーバーOSを動かせます。マシン上で動くソフトウェアが少なければ少ないほど、再起動が必要になる頻度は下がり、クラッシュする可能性も低くなります。

また、個人的に面白いと感じているピアツーピアのプロジェクト（たとえばOpenBazaarやBitSquareなど）もありますが、これらは常時サーバーを動かしておく必要があります。VirtualBoxで試したこともありますが、前述のような手間がかかるため、VMを動かし続けるモチベーションを保てませんでした。一度VMを立ち上げたらそのまま放置できる環境があれば、こうしたプロジェクトを気軽に試せるようになります。

パーツ選び

CPU

Brian氏のブログ記事では、中古のIntel Xeon CPUの安さを活かせる点に魅力を感じていました。面白い考え方だとは思いましたが、中古のサーバー用ハードウェアは故障のリスクが心配だったので、新品のリテールCPUを選びたいと思いました。

メインPCではCPUをオーバークロックしていますが、そのせいで時々クラッシュも起きています。VMサーバーはできる限り安定させたかったので、今回はオーバークロックしないことにしました。そのおかげで、倍率ロック解除版のCPUやオーバークロック対応マザーボード、高価なCPUクーラーにお金をかける必要がなくなり、パーツ選びも楽で安く済みました。

最終的に選んだのはAMD Ryzen 7 1700です。8コア16スレッドなので多数のVMを動かすのに適しており、最近評価も非常に高かったからです。

マザーボード

私はマンハッタンのかなり狭い1LDKのアパートに住んでいるので、物理的なスペースは非常に貴重です。また、今回の要件上、ディスクドライブやGPU、高価なCPUクーラーといった、PC内で場所を取る多くのパーツが不要でした。

そうした条件からMicroATXのマザーボードに絞り、最終的にASRock AB350M-HDVを選びました。ASRockのボードは過去にも良い経験があったので、堅実な選択に思えました。気になったのはメモリ周りで、RAMスロットが2本しかないため16GB×2枚で埋まってしまい、増設の余地がなくなる点です。ただ、もしRAMが足りなくなった頃には32GB×2枚が手に入るようになっているだろうと考え、そのときは思い切って2枚とも交換すればよいと割り切りました。

振り返ってみると、統合グラフィックス付きのマザーボードにしておけばよかったと思っています（詳しくは後述のパーツレビューをご覧ください）。

メモリ

メインPCは32GBのRAMを積んでいますが、日常的な使い方（Windows 10と複数のVMを動かした状態）でも使用量は15GB前後です。16GBでもなんとかなるとは思いましたが、今後2〜3年は安心して使える上限として32GBにしておくことにしました。選んだのはG.SKILL Flare X Series 32GB（16GB×2）で、マザーボードで動作確認済みのものの中では最も高速な製品だったからです。

ディスク

Brian氏と同じく、十分な容量のNASを持っているので、ローカルストレージに必要なのはホスト／ハイパーバイザーOSを入れるための小さなディスクだけでした。選んだのは250GBのSamsung 850 EVOです。決め手はM.2インターフェースのすっきりさでした。マザーボードにネジで留めるだけのチップで、マウンタやSATAケーブルの取り回しに悩む必要がありません。250GBは必要以上に大きいのですが、M.2 SSDとしてはこれが最小クラスでした。

ケース

ケースはとにかく小さいことを最優先に探しました。サーバーは目立たない場所に隠すつもりだったので、見た目の派手さは不要でした。Rosewill Micro ATX SRM-01は、小型で安価、かつ実用的なケースです。

グラフィックス

このシステムは基本的にヘッドレスで運用し、SSHやAnsibleで管理するつもりですが、初期インストール時やネットワーク設定を誤ってしまったときなど、たまにディスプレイが必要になります。当初はマザーボードの統合グラフィックスが使えると思っていましたが、実際には使えませんでした（詳しくは後述のパーツレビューをご覧ください）。

GPUへの要件は特に厳しくなかったので、安価で評判の良いものをということでEVGA GeForce 8400 GSを選びました。

このシステムのためだけにモニターを買うのは合理的ではありません。99.99%の時間はヘッドレスで管理するからです。残りの0.01%のときは、机の下にもぐり込んでメインモニターのHDMIケーブルをメインPCからVMサーバーに差し替えれば済みます。

ネットワークアダプター

ネットワークは1Gbps環境しかないので、マザーボード内蔵の1Gbps NICをそのまま使うつもりでした。Ubuntu 16.04では一応そのまま認識したのですが、速度が10Mbps程度に制限されていることにすぐ気づきました。調べてみると、Ubuntu 16.04には正しいドライバが含まれておらず、別のapt-getリポジトリを追加してr8168-dkmsパッケージをインストールする必要があることがわかりました。実際にインストールしてみたものの、再起動すると今度はUbuntuがNICをまったく認識しなくなってしまいました……。

この時点で内蔵NICの調整にはうんざりしていたので、Ubuntuでそのまま使えると評判だったPCI接続のNIC、Broadcom BCM5751 NetXtremeを購入しました。何も手を加えずに1Gbpsの速度が出たので、23ドルでこの手間が省けるなら、内蔵NICの問題をこれ以上追う価値はないと判断しました。

ちなみに、内蔵NICは非対応でしたが、BroadcomのNICはESXi 6.5に対応していました。

最終パーツリスト

組み立て

すべてのパーツが揃ったので、いよいよ組み立てです！

組み立て前のパーツ一式です。NICとGPUが写真に写っていないのは、実際に動かしてみるまで必要だと気づかなかったためです。

すべてのパーツを組み込んだ状態のサーバーです。構成がシンプルなので中身はあっさりしています。唯一のディスクがマザーボードに直付けのM.2 SSDなので、電源ケーブルやSATAケーブルの取り回しが不要だったのが特に楽でした。

アパートのスペースが限られているため、目立たない場所に隠せるサーバーにしたかったのです。そこで、机の脇にある引き出しの裏側に置くことにしました。メインのデスクトップと同じくらい手は届きますが、ほとんど視界に入りません。

ホストOSのインストール

VMサーバーのホストOSは、できる限り軽量であるべきです。必要なのはハイパーバイザーを動かすことくらいで、それ以外はほとんど不要です。ホストに入れるソフトウェアが増えるほど、安定運用のために最新に保つべきパッケージも増えてしまいます。

いくつかのLinuxディストリビューションを試しましたが、私のハードウェアですぐに問題なく動いたのはUbuntu Serverだけでした（16.04と17.04の両方で確認済みです）。おそらくRyzenのSMT機能が、他のディストリビューションでのインストール失敗の原因だと思います。BIOSでSMTを無効にして別ディストリビューションをインストールし、カーネルを4.10以上に上げてからSMTを再度有効にすれば回避できるかもしれませんが、どうせ一番使い慣れているディストリビューションでもあるので、Ubuntu 16.04 Serverを使うことにしました。

仮想マシンの実行

KVM

ハイパーバイザーにはKVMを使いました。比較的成熟しており利用者も多いので、困ったときに検索して解決策を見つけやすいのが利点です。エンタープライズ向けのハイパーバイザーの中には、ソフトウェア自体は無料でもライセンスキーを要求するものがありますが、KVMはフリーかつオープンソースなのでそうした煩わしさがありません。

Kimchi

インフラをウェブUIで管理できるのが好みなので、KVMのHTML5ベース管理UIであるKimchiをインストールしました。

Kimchiの印象を一言で言うと「まあまあ」です。ダッシュボードの中にはかなり洗練されたものもあります。

また、ブリッジ接続のネットワークアダプターの作成など、コマンドラインではやや面倒な作業をとてもうまくやってくれます。

弱点は主にUXにあります。簡単な操作でもクリック数が多かったり、ページが自動更新されるタイミング（たとえばゲストVMのシャットダウンが完了したときなど）でコンテキストメニューが消え、操作を最初からやり直さなければならなかったりすることが頻繁にあります。とはいえ致命的な欠点ではなく、使い慣れるにつれてこうしたUX上のクセを避ける動き方が身についてきました。

次点：ESXi 6.5

当初はVMwareの無償ハイパーバイザーであるVMware vSphere Hypervisorを使うつもりでした。より成熟しておりユーザー数も多いので、サポート情報も見つけやすいだろうと考えたからです。しかし、実際にはマザーボードのNICにもRyzen CPUにも対応していませんでした。BroadcomのNICを取り付け、BIOSでCPUのSMTを無効にしてようやく動作しましたが、その頃にはすでにKimchiを数日使って慣れていました。

vSphereがKimchiより明らかに優れているとも感じませんでした。UIははるかに洗練されていますが、こちらも操作フローがぎこちなく、一度間違えると多段階のプロセス全体を最初からやり直さなければならないことがあります。また、コマンドラインでやりたいことを直接実行するためにシェルへアクセスする方法もすぐにはわかりませんでした（おそらく可能なのでしょうが、そこまで深く調べませんでした）。

決め手となったのは、ログインするたびに「VMwareの登録キーを入力しないと60日でソフトウェアが使えなくなります」という警告が大きく表示されることでした。VMwareはライセンスキーを無償で提供していますが、ライセンス認証とは無縁で、使い心地もvSphereとほぼ同等のKimchiがあるなら、わざわざ登録キーを扱う手間はかけたくありませんでした。

サーバープロビジョニングの自動化

私はAnsibleの愛用者なので、VMサーバーを自動でプロビジョニングするためのAnsible Playbookを書きました。内容は以下のとおりです。

• RyzenのSMT機能に対応したバージョンへカーネルを更新する
• KVMとKimchiをインストールする
• VMイメージ保存用のNFS共有をマウントする

同じPlaybookを使って、Ansibleをインストールしたうえで以下のコマンドを実行すれば、ご自身のサーバーもプロビジョニングできます。

VM_SERVER=vmaster # Replace with your VM server's hostname
echo "${VM_SERVER}" > hosts
wget https://mtlynch.io/files/provision-vm-host.yml

# Replace the extra-vars with the values for your NFS share
ansible-playbook provision-vm-host.yml \
  --extra-vars "cifs_share=/nas-hostname/VMs" \
  --extra-vars "cifs_username=foo" \
  --extra-vars "cifs_password=bar"

選択の振り返り

CPUの振り返り

最も判断が微妙だったのはCPUです。確かに非常に高速なのですが、オーバースペックだったかもしれません。5台のVMを動かし、そのうちの数台でCPU負荷の高いジョブを実行しても、全体のCPU使用率が35%を超えたことがないからです。

Ryzenの欠点は、現時点では最先端すぎて互換性が不安定なことです。Fedora 25 Server、Debian 8.7、CentOS 7、ESXi 6.5のインストールを試しましたが、いずれもRyzenに対応していないためインストール中に失敗しました。BIOSでCPUのSMT（マルチスレッディング）を無効にすればインストールできたものもありましたが、それでは16スレッドが8コアになってしまい、なんだかもったいなく感じました。正常にインストールできたOSはUbuntuだけでした（16.04と17.04の両方で成功しています）。

Ryzenのせいで選べるRAMも限られました。マザーボードはDDR4 3200MHzまで対応していますが、Corsairには動作確認済みのメモリがありません。G.SKILLにはありますが、DDR4 2400MHzより速いものはありませんでした。

マザーボードの振り返り

マザーボードの選択にはおおむね満足しています。コンパクトでありながら、すべてのパーツを収めるのに十分なスペースは確保できています。

唯一後悔しているのは、オンボードビデオの仕様をよく読まなかったことです。「オンボードビデオチップセット」の欄にはこう書かれていました。

AシリーズAPUに統合されたAMD Radeon R7/R5シリーズグラフィックス HDMI対応、最大解像度4K×2K（4096×2160）@24Hz／（3840×2160）@30Hz

そこで私は「お、グラフィックスが内蔵されているのか。これで一つパーツが減らせるな」と思いました。しかし実際には、この記述は「AMD AシリーズAPUをお持ちの場合のみグラフィックスをサポートします」という意味だったのです。APUはAMDのCPUとGPUが一体化したチップのことで、Ryzenはそれに該当しないため、結局オンボードグラフィックスは使えませんでした。

もしもう一度やるなら、オンボードGPUがある手軽さからGIGABYTE GA-AB350M-Gaming 3を選ぶと思います。

メモリの振り返り

当初32GBはやりすぎかと思いましたが、さまざまな用途でVMを増やしていくうちにRAM使用量が18GBを超えるようになったので、16GBではなく32GBにしておいてよかったと思っています。

電源の振り返り

電源はシステムに対して十分なワット数があり、動作音もかなり静かです。30ドルという価格を考えればコストパフォーマンスも良好です。

唯一の欠点は、ケーブルが直付け（非モジュラー）なことです。私のシステムは最小構成なので必要なのは24ピンのマザーボード用ケーブルと8ピンのCPU用ケーブルだけで、残りはすべて余分なケーブルになってしまいます。ただ、ケースの5.25インチベイ（もちろん私の場合は空の光学ドライブ用ベイ）にきれいに隠せたので、見た目はすっきり収まりました。

もう一度組むなら、余分なケーブルをなくせるセミモジュラーかフルモジュラーの電源を検討すると思います。

まとめ

このホームラボ用VMサーバーはとても快調に動いています。VMが常時起動していることがわかっているので、VirtualBoxであれこれ立ち上げる手間なく、SSHで接続したりブラウザで確認したりできるのが非常に便利です。

予想外の利点として、ゲストOSへのCPUやRAMの割り当てをケチる必要がなくなったことがあります。メインのデスクトップは8コアのi7に32GB RAMという構成で、VMにリソースを取られてメインOSが枯渇しないように、これまではゲストOSに1CPU＋1GB RAMだけを割り当て、リソース不足が見えてから増やすようにしていました。ホームラボ用VMサーバーなら、誰にでも十分なリソースがあります！今では標準のゲストOSテンプレートは4コア・4GBメモリで、ほとんどの環境にとって十分な上限です。おかげでゲストOSのリソースを手作業で管理する時間が大幅に減りました。

さまざまな開発環境やステージング環境を必要とするソフトウェアプロジェクトに取り組んでいるなら、VMでの作業と、専用のVMサーバーマシンの利用を強くおすすめします。