1. 初めに

この記事は私が普段使っている開発環境を仮想環境上に構築した時のメモになります。
開発を初めたばかりの方やこれから始めようという方がまずはつまずくと思われる開発環境の構築について、仮想環境を使うことのメリットと使い方を記載しています。

1.1 仮想化のメリット

仮想化のメリット、特に開発環境構築時においてはスナップショット機能によるインストールや設定変更のやり直しが可能であることが大きいです。

スナップショット機能は、ある時点での仮想環境の状態を保存しておく機能になります。

通常の開発環境構築の難しさの大部分は、ある手順までは正しく作業ができていても途中で少し手順を間違えた時に元の状態に戻す手段がないことに起因しています。
しかし仮想環境では正しく作業が完了したところでスナップショットを作成し、その後作業を継続することで失敗した場合に正しく完了しているところまで仮想環境の状態を戻すことができます。

このように、Try & Errorで動作を確認しながら一歩々々確実に開発環境を構築をすることが仮想化することによる大きなメリットの1つになります。

また、それ以外に運用面においても下記のようなメリットがあります。

環境の移行やバックアップが容易
プロジェクトごとに独立した開発環境の運用が容易
ドキュメント作成が容易

環境の移行やバックアップについては、基本的には仮想環境をまるごとコピーすることで実現可能です。未使用領域やファイルの圧縮なども可能なため、常に仮想環境に割り当てた全領域分のディスク容量が必要になるわけでもありません。

また、プロジェクトやお客様によっては同一のツールを使用していてもバージョンが異なっていたり、オンラインでの打ち合わせに関係ないプロジェクトのデータが入っているPCを使用したくないなどといった場合に、それぞれお客様やプロジェクトと行った単位で仮想環境上に開発環境を構築することもディスク容量さえ十分にあれば簡単に実現できます。

最後に、例えばこのQiitaの記事のようなドキュメントを作成する時、不要なものが入っていないクリーンな環境でスクリーンショットやビデオを取りながら一つずつ手順を確認し、時には以前の状態に戻したりしながら作成するような場合に仮想環境はとても便利に使うことが出来ます。

1.2. 環境

この記事に記載の内容は以下の環境¹で動作確認しています。

ホストOS : Ubuntu 22.04 LTS Desktop 日本語Remix
ゲストOS : Windows 10 Pro²
仮想環境 : kvm + qemu + virtio
ホームゲートウェイ : PR-500KI

2. ホストの設定

ここではUbuntu22.04上でvirt-managerとnm-connection-editorを使ってGUIでWindows10の仮想環境の構築を行います。

なお、ホストに使用しているPCのSecure BootはOFFにしています。
これはゲストOSで使用するvirtioにSecureBootに必要な署名がないためです。
virtioはパフォーマンス向上のため使用する方が望ましいですが使用しなくても動作は可能ですので、必要に応じてSecureBootをONにしvirtioついては読み飛ばしていただければと思います。

2.1. ホストに必要なソフトをインストール

qemu + kvm + virtioな環境で仮想環境を作成するのに必要なソフトをインストールします。

sudo apt update && sudo apt upgrade -y
sudo apt install -y qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager
sudo reboot

再起動後にvirt-managerを実行するとQEMU/KVM環境に接続した状態で仮想マシンマネージャが起動するので、今後GUIをメインに作業したい場合はそのままお気に入りに登録しておくことをおすすめします。

virt-manager

2.2. 仮想ブリッジの作成

ネットワーク構成図に示したようにこのあと生成するWindows10の仮想環境が既存の宅内のLANと同一のセグメントに接続できるように仮想ブリッジを作成します。

nm-connection-editorを実行するとネットワーク接続が起動します。
仮想ブリッジをGUIから設定するにはこのソフトを使用します。
このソフトも今後ネットワーク設定をGUIをメインに作業したい場合はそのままお気に入りに登録しておくことをおすすめします。

nm-connection-editor

ネットワーク接続左下の＋をクリックすると、ネットワークに追加したい物がなにか選択するように促されるので、「仮想」のところからブリッジを選択して作成します。名前は一般的にbr0などとすることが多いので、ここでもbr0の名前で作成します。

更にこのあとにはブリッジ接続で追加のボタンを押下、Ethernetを選択してから作成してデバイスの項目でブリッジの物理ネットワークと接続するデバイスを設定する。

ここで再起動を行い、起動後にnm-connection-editorを起動させ、Ethernetからブリッジで指定したデバイスが消え、代わりにブリッジに接続したbr0 port1が表示されていれば正しく設定されています。

3. ゲストOS(Windows10)のインストール

ここではkvm + qemu + virtio環境にゲストOSとしてWindows10をインストールします。
Windows10をインストールするには、事前にインストールするWindowsのisoファイルとWindows用のvirtioのisoファイルを入手しておきます。下記に入手先(2022/11/06現在)を記載しておきますので参照して下さい。

WindowsのisoはMicrosoftから入手できます。
Microsoft Windows10 Download Site
Windows用のvirtioのisoファイルはgithubで公開されています。下記からStable、またはLatest virtio-win ISOをクリックしてダウンロードして下さい。
Windows用virtio

3.1 仮想環境の作成

Windows10をインストールするための仮想環境を仮想マシンマネージャ(virt-manager)を使って作成します。
仮想マシンマネージャの一番左のアイコン、もしくはファイル(F)メニューの新しい仮想マシン(N)から新しい仮想マシンの作成を行います。

3.1.1. 仮想環境の作成ステップ1

仮想環境の作成のステップ1/5では接続にQEMU/KVMを選択し、インストール方法の選択ではローカルのインストールメディアを選択してFowardします。

3.1.2. 仮想環境の作成ステップ2

仮想環境の作成のステップ2/5ではインストールに使用するisoファイルを指定します。
ここでは先程準備したWindows10のisoファイルを指定してFowardします。

3.1.3. 仮想環境の作成ステップ3

仮想環境の作成のステップ3/5では仮想環境に割り当てるCPUリソースとメモリリソースを指定します。
ここでは自分のPCの環境に合わせて適当な値を設定してFowardします。
このリソースの割当はあとで変更可能なので初期値のままでも問題ないですが、私の体感ではCPUリソースは大体8コア以上、メモリは8GB以上程度割り当てるとそこそこ快適に動作しました。

3.1.4. 仮想環境の作成ステップ4

仮想環境の作成のステップ4/5では仮想環境の起動領域(Cドライブ)に割り当てるディスクサイズを指定します。
これまで使用してきた感覚では最低128GBは必要です。128GB以上割り当ててForwardします。
なおデータ領域を拡張したくなった場合は別ドライブとしていつでも追加可能です。

3.1.5. 仮想環境の作成ステップ5

仮想環境の作成のステップ5/5では仮想環境の名前の入力とネットワークの選択を行います。
また、ストレージの下にあるインストール前に設定をカスタマイズする(u)にチェックを入れます。
以上を入力して完了(F)を押下します。

インストール前に設定をカスタマイズする(u)のチェックを忘れるとvirtioをインストールできなくなるので注意して下さい

3.1.6. 仮想環境の設定のカスタマイズ

仮想環境の設定のカスタマイズでは3箇所の変更が必要です。
1つはCPU数の設定で、初期設定ではシングルコアのCPUが複数個の設定になっているためWindowsがCPUのコアを2個までしか認識しないため変更が必要になります。
もう1つはSATA CDROMの追加が必要で、Windowsのインストール時にインストール先のディスクのフォーマットを行う際にvirtioドライバを読み込むために使用します。
最後に起動領域(Cドライブ)のディスクバスにVirtIOを指定し、仮想環境でのディスクのIOにvirtioを使用するように設定します。

3.1.6.1. CPU数の設定変更

CPU数の設定のトポロジーにあるCPUトポロジーの手動設定にチェックを入れます。
ソケット数を1、スレッド数を2に設定し、あとは設定した仮想CPU割当の数に合うようにコア数を設定します。
設定した後はApplyを押下します。

試してはいませんがソケット数を2以下にしてソケット数×コア数×スレッド数が仮想CPU割当の数になっていれば特に問題はないと思います。
ただし、現実離れしたCPUトポロジの設定にした場合にOSを含む現状のソフトウェアが効率よく動作できると思えないため上記のような設定にしています。

Applyを押下しないと変更した内容は破棄され反映されないため注意して下さい。

3.1.6.2. SATA CDROMの追加

UIの左下にあるハードウェアの追加(D)を押下します。
次に追加するハードウェアとしてストレージを選択し、デバイスの種類(D)でCD-ROMデバイスを選択して完了します。

その後追加したSATA CDROM2を選択し、仮想でディスクに事前にダウンロードしておいたWindows用のvirtioのisoファイルを指定してApplyする。

Applyを押下しないと変更した内容は破棄され反映されないため注意して下さい。

3.1.6.3. 起動領域(Cドライブ)のディスクバス変更

SATA DISK1のディスクバスでVirtIOを選択してApplyを押下します。

Applyを押下しないと変更した内容は破棄され反映されないため注意して下さい。
ここは最後のApplyなので比較的忘れにくいですがCPU数、及びSATA CDROM2の設定が反映されているか確認したほうが無難かもしれません。

最後にUIの左上のインストールの開始を押下してWindows10のインストールを開始します。

3.2. Windows10のインストール

Windowsのインストールが始まるのでWindowsセットアップを進めます。

インストールの種類ではカスタムを選択します。

初期状態ではWindowsのインストール先に設定した起動領域が表示されません。
これはvirtioのドライバを読み込んでいないことが原因なのでドライバーの読み込み(L)を実行します。

インストールをするドライバーの選択では参照(B)からCD-ROM上のドライバーを保存してあるフォルダを指定してOKします。

CD-ROMを指定しただけではWindowsはドライバを探してくれず、CD-ROM内のamd64\w10まで指定する必要があります。

インストールするドライバーの選択にVirtIOのSCSIコントローラが表示されるようになるので選択して次へ(N)進みます。

起動領域(Cドライブ)が見えるようになったので、あとはWindowsセットアップを勧めてWindowsのインストールを最後まで行います。

3.3. 仮想環境のWindowsの設定

仮想環境のWindowsではホストとクリップボードの共有を行うことが出来ます。また、USBデバイスのリダイレクトを設定することでホストに接続したUSBデバイスを直接ゲストへ転送することが出来ます。
これらについては、実際に仮想環境上でWindowsを使用する場合に必要になるので設定しておきます。

ホストコンピュータとのファイル共有について
kvm+qemu環境でのゲストとホストの間のファイル共有機能はゲストがWindowsの場合は使用できないため、一般的にはホストでsambaサーバを運用し、Windowsからはネットワークドライブの割当などで共有することが多いようです。
なお、sambaの設定やネットワークドライブの割当方法については仮想環境とは特に関係ないためこの記事では省略しています。

3.3.1. クリップボードの共有

SPICEのDownload SiteのWindows binariesにあるspice-guest-tools(spice-guest-tools-latest.exe)をダウンロードしてインストールするだけです。
SPICEのDownloadSite

私の環境ではspice-guest-toolsをインストールすると何故か画面の解像度がリセットされてしまいましたが再度設定し直すことで問題なく復帰しました。

3.3.2. USBデバイスの使用

USBデバイスを使用する場合は2通りの方法があります。
1つは仮想環境起動時に決まったUSBデバイスを毎回固定的に割り当てる方法で、私はノートPCの指紋認証用のデバイスをこれに割り当てています。
もう一つは使用する時に割り当てる方法でUSBメモリやデバッガ、計測機器などを接続する場合に使用しています。

3.3.2.1. USBデバイスを起動時に毎回割り当てる方法

表示(V)メニューの詳細(D)から、もしくは上部のアイコンの左から２番めの仮想マシンの情報を表示からハードウェアの追加(D)を行い、USBホストデバイスから起動時に毎回割り当てたいUSBデバイスを選択して完了します。

3.3.2.1. USBデバイスを使用時に割り当てる方法

仮想マシン(M)メニューのUSBデバイスのリダイレクト(R)からリダイレクト対象のデバイスを選択(チェックボックスにチェックを入れる)して閉じる(C)で閉じます。

なお、多数のUSBデバイスを同時に使用しようとするとリソースが不足しCan't redirect:There are no free USB channelsとエラーメッセージが表示されます。
このような場合はハードウェアの追加からUSBリダイレクトを選択して必要なだけ追加します。

USBリダイレクトの追加は完了するだけで特に必要な変更はありません。
種別(T)についてもSpiceチャンネルの他に選択できるものはありません。

4. 仮想環境の運用

ここでは仮想環境の機能であるスナップショットを使った操作のやり直しやコマンドラインからの命令で仮想環境のバックアップを行います。

4.1. スナップショット

開発環境を構築する際に仮想環境を使用することの最大のメリットはスナップショットの機能があり、途中で失敗しても上手く出来たところから何度でもやり直しが出来るところが初心者には特に有用です。

スナップショットは普通にWindowsの起動中に作成することができます。
表示(V)メニューのスナップショット(P)か上部のアイコンの一番右の仮想マシンのスナップショットを管理から新しいスナップショットを作成(UI左下)から新しいスナップショットを作成します。

スナップショットは開発環境構築を進める中で、ここまでは正しく出来たと思う度に作成していくことをおすすめします。

作成したスナップショットにはいつでも復帰することが出来ますが、現在の状態は破棄されるので注意して下さい。ただし、開発環境構築中の場合は現在の状態というのは既に間違った状態になっていると思いますので、あまり気にする必要はないかもしれません。
ある時何処かで失敗していたことに気付いてあそこのスナップショットまで戻って動作を確認したいというような場合は、当該のスナップショットを左のリストから選択して左下の選択したスナップショットを実行を行うことで仮想環境が戻りたかった場面に戻ってくれます。

スナップショットが作成できない場合は概要のハイパーバイザーの種類を確認して下さい。
チップセット(T)、またはファームウェア(W)を下図にあるデフォルト設定から変更しているとスナップショットの機能に対応できないことがあります。

4.3. バックアップ

バックアップはxmlファイルとqcow2ファイルをコピーします。
デフォルトの設定の場合、xmlファイルは/etc/libvirt/qemu/に、qcow2ファイルは/var/lib/libvirt/images/にそれぞれ保存されています。
パーミッションが厳しく設定されているのでコピーにはsudoが必要になります。

バックアップしたファイルから復元する場合は、元あったところにコピーしたファイルを起き、virsh defineで復元します。

/etc/libvirt/qemu$ sudo virsh define ./win10.xml

4.3.1 イメージファイルの最適化

バックアップはイメージファイル(*.qcow2)をコピーで問題ありませんが、virt-sparsifyを使用することでイメージファイルの未使用領域を削除して最適化することも出来ます。
下の例ではインストールした直後ということもあり13%弱のサイズになっています。

export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
sudo virt-sparsify -v -x /var/lib/libvirt/images/win10.qcow2 /var/lib/libvirt/images/win10-back.qcow2

-rw-r--r-- 1 root root  17683120128 11月  6 19:40 win10-back.qcow2
-rw------- 1 root root 137460187136 11月  6 19:14 win10.qcow2

4.3.2 イメージファイルの圧縮

イメージファイルは使用していない領域を削除する他にiemu-imgで圧縮することも出来ます。
下の例では先程未使用領域を削除して最適化したファイルをさらに圧縮しています。

sudo qemu-img convert -c -p -f qcow2 -O qcow2 /var/lib/libvirt/images/win10-back.qcow2 /var/lib/libvirt/images/win10-back-c.qcow2

ついでに最適化前のイメージファイルも圧縮してみました。

sudo qemu-img convert -c -p -f qcow2 -O qcow2 /var/lib/libvirt/images/win10.qcow2 /var/lib/libvirt/images/win10-c.qcow2

ファイルサイズを比較してみたところおおよそ予想通りになったので、イメージファイルを圧縮するのが何となく壊れそうで嫌というのでなければオリジナルのイメージを直接圧縮して保存しておくのが処理時間を考えると一番無難なバックアップの運用のように思います。

-rw-r--r-- 1 root root  11377178112 11月  6 20:13 win10-back-c.qcow2 //最適化したファイルを圧縮
-rw-r--r-- 1 root root  17683120128 11月  6 19:56 win10-back.qcow2   //オリジナルを最適化
-rw-r--r-- 1 root root  11393758720 11月  6 20:21 win10-c.qcow2      //オリジナルを直接圧縮
-rw------- 1 root root 137460187136 11月  6 20:05 win10.qcow2        //オリジナル

5. まとめ

とりあえずここまで記載した内容で一通りは日常的に仮想マシン上のWindows10で作業をしても不自由は感じないと思います。
今後は複数環境の使い分けのために仮想環境を増やしたりデータ領域のドライブを追加したりなど、必要に応じていろいろ試してみるのも面白いかと思います。

私個人は普段デスクトップで作業している環境を出張用のノートPCにそのままコピーして持ち運んで現場でデモを行うのに使用したり、PCを買い替えたときにもすぐに環境移行が出来たりとなかなか便利に使っています。
また、ゲストOSでリモートの会議に出席中に他のゲストOSやホストOSの作業内容などは一切相手に伝わる心配がないのも気に入っています。

今後はLinux開発環境のためにコンテナ(lxc)の利用や、仮想ネットワークの構築、ハイパーバイザを使った仮想化とコンテナによる仮想化の違いなどについて記事を書いていきたいと考えていますので、機会がありましたらそちらの記事も読んでみていただければと思います。

最後になりましたが、記載のミスや指摘事項、感想、仮想環境のこんな使い方しているけど便利だよ等ご意見ありましたらよろしくお願いいたします。

Windows10+Hyper-V上でWindowsやLinuxを動作させることも一応可能でしたが、私の環境ではファイル共有や音声の再生で問題があったため現在の環境にしています。 ↩
ゲストOSにUbuntuを用いた仮想化については、別途lxc編としてコンテナ(lxc)を用いた開発環境の仮想化のメモを作成する予定です。また、Windows10の仮想化にはkvm+qemuを用い、Ubuntuにはlxcを用いる理由についても別途仮想化についてのメモを作成する予定です。 ↩

開発環境仮想化のすすめ (kvm+qemu+virtio編)