注記：この記事は2017年当時のVM構築について書かれたものです。

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

概要

自宅での開発作業のほとんどは仮想マシン（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は月に1回ほどクラッシュするのですが、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を積んでいて、日常使いでも15GB前後を使います（Windows 10で複数のVMを動かしている状態でも）。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ケーブルをメインのデスクトップから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はESXi 6.5には非対応でしたが、BroadcomのNICは対応していました。

最終パーツリスト

組み立て

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

組み立て前のすべてのコンポーネントです。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ははるかに洗練されていますが、ちょっと間違えると多段階のプロセス全体を最初からやり直さなければならないような、ぎこちないフローもありました。コマンドラインでやりたいことをやるためにシェルにどうアクセスすればいいのかも直感的ではありませんでした（もちろん可能なはずですが、答えが見つかるまで調べ続ける気にはなりませんでした）。

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

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

私はAnsibleの大ファンなので、VMサーバーを自動でプロビジョニングするためのAnsibleプレイブックを書きました。内容は以下のとおりです。

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

同じプレイブックを使って、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より速いものはありませんでした。

振り返り：マザーボード

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

唯一後悔しているのは、オンボードビデオの対応をよく読まなかったことです。「Onboard Video Chipset」の仕様にはこう書かれていました。

Integrated AMD Radeon R7/R5 Series Graphics in A-series APU Supports HDMI with max. resolution up to 4K x 2K (4096x2160) @ 24Hz / (3840x2160) @ 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 RAMで、ほとんどの環境で十分な上限です。おかげでゲストOSのリソースを手動で管理する無駄な時間を減らせています。

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