Product SiteDocumentation Site

12.2. 仮想化

仮想化は最近のコンピューティングにおける最も大きな進歩の 1 つです。仮想化という用語は、実際のハードウェアに対するさまざまな独立性の度合いを持つ仮想コンピュータを模倣するさまざまな抽象化と技術を指します。1 台の物理的なサーバが同時かつ隔離された状態で動く複数のシステムをホストすることが可能です。仮想化アプリケーションは数多く存在し、隔離された仮想システムを使うことができます。たとえば、さまざまに設定されたテスト環境を作ったり、安全性を確保する目的で異なる仮想マシン間でホストされたサービスを分離したりすることが可能です。
複数の仮想化ソリューションが存在し、それぞれが利点と欠点を持っています。本書では Xen、LXC、KVM に注目しますが、他にも以下のような注目すべき実装が存在します。

12.2.1. Xen

Xen は「準仮想化」ソリューションです。Xen には薄い抽象化層が含まれ、この抽象化層は「ハイパーバイザ」と呼ばれ、ハードウェアとその上にあるシステムの間に位置します。さらにハイパーバイザは審判員として振る舞い、仮想マシンからハードウェアへのアクセスを制御します。しかしながら、Xen ハイパーバイザは命令のほんの一部だけを取り扱い、残りは Xen ハイパーバイザではなくハードウェアによって直接的に実行されます。こうすることによる主な有効性は性能が低下せず、システムがネイティブ速度に迫る性能を発揮するという点です。一方で欠点は Xen ハイパーバイザ上でオペレーティングシステムを実行するには実行されるオペレーティングシステムのカーネルを修正しなければいけないという点です。
用語の解説に少し時間を割きましょう。Xen ハイパーバイザはカーネルよりも下層の最も低い層に位置し、ハードウェア上で直接動きます。Xen ハイパーバイザは残りのソフトウェアをいくつかのドメインに分割することが可能で、ドメインは多数の仮想マシンと考えられます。これらのドメインの 1 つ (最初に起動されたもの) は dom0 と呼ばれ、特別な役割を担います。なぜなら、dom0 だけが Xen ハイパーバイザを制御することが可能だからです。他のドメインは domU として知られています。ユーザ視点で言い換えれば、dom0 は他の仮想システムにおける「ホスト」、これに対して domU は「ゲスト」になります。
Debian の下で Xen を使うには 3 つの要素が必要です。
  • The hypervisor itself. According to the available hardware, the appropriate package will be either xen-hypervisor-4.11-amd64, xen-hypervisor-4.11-armhf, or xen-hypervisor-4.11-arm64.
  • A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 4.19 version present in Buster.
  • さらに i386 アーキテクチャでは、Xen を活用するための適切なパッチを組み込んだ標準的なライブラリが必要です。このライブラリは libc6-xen パッケージに含まれます。
The hypervisor also brings xen-utils-4.11, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.
これらの前提要件をインストールしたら、次に dom0 の挙動をテストします。テストを行うには、Xen ハイパーバイザと Xen カーネルの再起動が必要です。システムは標準的な方法で起動するべきです。初期化の早い段階でコンソールにいくつかの追加的メッセージが表示されます。
これで、実用システムを domU システムに実際にインストールできるようになりました。これを行うには xen-tools に含まれるツールを使います。xen-tools パッケージには xen-create-image コマンドが含まれます。xen-create-image コマンドはインストール作業の大部分を自動化します。必須のパラメータは --hostname だけで、このパラメータは domU の名前を設定します。他のオプションは重要ですが、オプションを /etc/xen-tools/xen-tools.conf 設定ファイルに保存することが可能です。そして、コマンドラインでオプションを指定しなくてもエラーは起きません。このため、イメージを作る前にこのファイルの内容を確認するか、xen-create-image の実行時に追加的パラメータを使うことが重要です。以下に注目すべき重要なパラメータを示します。
  • --memory。新たに作成する domU システム専用の RAM のサイズを指定します。
  • --size--swap。domU で利用できる「仮想ディスク」のサイズを定義します。
  • --debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as buster).
  • --dhcp。domU のネットワーク設定を DHCP で取得することを宣言します。対して、--ip は静的 IP アドレスを定義します。
  • 最後に、作成されるイメージ (domU からはハードディスクドライブに見えるイメージ) の保存方法を選択します。最も簡単な方法は、--dir オプションを使い、各 domU を格納するデバイス用のファイルを dom0 上に作成する方法です。LVM を使っているシステムでは、--lvm オプションを使い、VG の名前を指定しても良いでしょう。この場合 xen-create-image は指定された VG から新しい LV を分割し、この LV をハードディスクドライブとして domU から利用できるようにします。
これらを選んだ後、将来の Xen domU 用のイメージを作成することが可能です。
# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=buster --role=udev

[...]
eneral Information
--------------------
Hostname       :  testxen
Distribution   :  buster
Mirror         :  http://deb.debian.org/debian
Partitions     :  swap            512M  (swap)
                  /               2G    (ext4)
Image type     :  sparse
Memory size    :  256M
Kernel path    :  /boot/vmlinuz-4.19.0-5-amd64
Initrd path    :  /boot/initrd.img-4.19.0-5-amd64
[...]
Logfile produced at:
         /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  buster
MAC Address     :  00:16:3E:0C:74:2F
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA)
SSH Fingerprint :  SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA)
SSH Fingerprint :  SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519)
SSH Fingerprint :  SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA)
Root Password   :  EwmQMHtywY9zsRBpqQuxZTb
これで仮想マシンが作成されましたが、仮想マシンはまだ実行されていません (このため dom0 のハードディスク上の領域が使われているだけです)。もちろん、異なるパラメータを使ってより多くのイメージを作成することが可能です。
仮想マシンを起動する前に、仮想マシンにアクセスする方法を定義します。もちろん仮想マシンは隔離されたマシンですから、仮想マシンにアクセスする唯一の方法はシステムコンソールだけです。しかし、システムコンソールだけで要求を満足できることはほとんどないと言っても過言ではありません。ほとんどの時間、domU はリモートサーバとして機能し、ネットワークを通じてのみアクセスされます。しかしながら、各 domU 専用のネットワークカードを追加するのはかなり不便です。このため Xen は仮想インターフェースの作成機能を備えています。各ドメインは仮想インターフェースを参照し、標準的な方法で使うことが可能です。これらのネットワークカードは仮想的なものですが、ネットワークに接続されている状況下でのみ役に立つという点に注意してください。Xen は以下に挙げる複数のネットワークモデルを備えています。
  • 最も単純なモデルは bridge モデルです。この場合、すべての eth0 ネットワークカードが (dom0 と domU システムに含まれるものも含めて) 直接的にイーサネットスイッチに接続されているかのように振る舞います。
  • 2 番目に単純なモデルは routing モデルです。これは dom0 が domU システムと (物理) 外部ネットワークの間に位置するルータとして振る舞うモデルです。
  • 最後が NAT モデルです。これは dom0 が domU システムとその他のネットワークの間に位置するモデルですが、domU システムに外部から直接アクセスすることは不可能です。dom0 の行ういくつかのネットワークアドレス変換がトラフィックを仲介します。
これら 3 種類のネットワークノードは vif*veth*peth*xenbr0 などの独特な名前を付けられた数多くのインターフェースと関係を持ちます。Xen ハイパーバイザは定義された配置に従いユーザ空間ツールの制御の下でインターフェースを準備します。NAT と routing モデルは特定の場合にのみ適合します。このためわれわれは bridge モデルを使います。
The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils-4.11 package recommends it) to replace the existing eth0 entry:
auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0
After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 1024 (megabytes).
# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  1894     2     r-----      63.5
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  1505     2     r-----     100.0
testxen                                     13  1024     0     --p---       0.0
testxen domU は仮想メモリではなく RAM から取った物理メモリを使います。このメモリ領域は testxen domU が起動していなければ dom0 が使えるメモリ領域だったという点に注意してください。このため、サーバを作ることが Xen インスタンスをホストすることを意味する場合、それに応じて十分なサイズの物理 RAM が必要になるという点に注意が必要です。
おめでとうございます! 仮想マシンが開始されました。仮想マシンにアクセスするには 2 種類の方法があります。通常の方法は、真のマシンに接続するのと同様に、ネットワークを介して「リモートで」仮想マシンに接続することです。そしてこれを行うには、通常別の DHCP サーバや DNS 設定をセットアップすることが必要です。別の方法は xl console コマンドから hvc0 コンソールを使う方法です。ネットワーク設定が正しくない場合にはこれが唯一の方法です。
# xl console testxen
[...]

Debian GNU/Linux 10 testxen hvc0

testxen login: 
仮想マシンのキーボードの前に座っているかのごとくセッションを開くことが可能です。このコンソールからデタッチするには、Control+] キーの組み合わせを使用します。
domU の起動完了後、domU は他のサーバと同様に使うことが可能です (domU は結局 GNU/Linux システムに過ぎません)。しかしながら、domU の仮想マシンの状態はいくつかの追加的機能を備えています。たとえば、xl pausexl unpause コマンドを使って domU を一時的に停止したり再開することが可能です。一時的に停止された domU は全くプロセッサを使いませんが、割り当てられたメモリを解放しません。xl savexl restore コマンドを考慮することは興味深いかもしれません。なぜなら xl save で domU を保存すれば domU の使っていた RAM などの資源が解放されるからです。また、xl restore で domU を元に戻す時 (ついでに言えば xl unpause で再開する時)、domU は時間が経過したことに全く気が付きません。dom0 を停止した時に domU が動いていた場合、パッケージに含まれるスクリプトが自動的に xl save で domU を保存し、dom0 の次回起動時に自動的に xl restore で domU を再開します。もちろんこれにはラップトップコンピュータをハイバネートする場合と同様の標準的な不便さがあります。特に、domU が長い間一時停止されていた場合、ネットワーク接続が切断される可能性があります。今現在 Xen は ACPI 電源管理のほとんどに互換性がない点にも注意してください。このため、ホスト (dom0) システムを一時停止することは不可能です。
domU を停止したり再起動するには、domU の内部から (shutdown コマンドを使って) 行ったり、dom0 から xl shutdown または xl reboot を使って行うことも可能です。

12.2.2. LXC

LXC は「仮想マシン」を作るために使われるにも関わらず、厳密に言うと仮想システムではなく、同じホスト上で実行されるプロセスのグループを隔離するためのシステムです。LXC は近年 Linux カーネルに対して行われた数々の機能の利点を活用しています。これらの機能はまとめて control groups として知られています。control groups を使うことにより、「グループ」と呼ばれるさまざまなプロセス群に対してシステム全体の特定の側面の状態を強制することが可能です。中でも最も注目すべき側面はプロセス ID、ネットワーク接続、マウントポイントです。隔離されたプロセスのグループはシステムの他のプロセスにアクセスできませんし、グループによるファイルシステムへのアクセスを特定の一部に限定することが可能です。さらにグループにネットワークインターフェースとルーティングテーブルを設定することにより、グループがシステム上の利用できるデバイスの一部だけを見えるように設定することが可能です。
These features can be combined to isolate a whole process family starting from the init process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: LinuX Containers), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).
LXC による隔離は単純な仮想化と異なるため、LXC コンテナを設定することは仮想マシン上で単純に debian-installer を実行するよりも複雑な作業です。このため、いくつかの必要条件を説明した後、ネットワーク設定を行います。こうすることで、コンテナの中で実行するシステムを実際に作成することが可能です。

12.2.2.1. 準備段階

lxc パッケージには LXC を実行するために必要なツールが含まれるため、必ずこのパッケージをインストールしなければいけません。
LXC を使うには control groups 設定システムが必要で、/sys/fs/cgroup に仮想ファイルシステムをマウントする必要があります。Debian 8 からは init システムとして systemd が採用されており、systemd は control groups に依存しているため、設定せずとも /sys/fs/cgroup は起動時に自動でマウントされます。

12.2.2.2. ネットワークの設定

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.
The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:
auto eth0
iface eth0 inet dhcp
このエントリを無効化し、以下の通り書き換えます。
#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
  bridge_ports eth0
この設定により、コンテナをホストと同じ物理ネットワークに接続されたマシンとして考えた場合と、同様の効果が得られます。この「ブリッジ」設定はすべてのブリッジされたインターフェース間のイーサネットフレームの通過を管理します。これには物理的な eth0 およびコンテナ用に定義されたインターフェースが含まれます。
In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.
この「ぜいたくな」設定を行うには bridge-utilsvde2 パッケージが必要です。/etc/network/interfaces ファイルは以下のようになります。
# eth0 インターフェースは同じものを使います
auto eth0
iface eth0 inet dhcp

# 仮想インターフェース
auto tap0
iface tap0 inet manual
  vde2-switch -t tap0

# コンテナ用のブリッジ
auto br0
iface br0 inet static
  bridge_ports tap0
  address 10.0.0.1
  netmask 255.255.255.0
コンテナのネットワークは静的またはコンテナのホスト上で動く DHCP サーバを使って動的に設定されます。また、DHCP サーバを br0 インターフェースを介した問い合わせに応答するように設定する必要があります。

12.2.2.3. システムのセットアップ

それではコンテナがファイルシステムを使うようにファイルシステムを設定しましょう。コンテナという「仮想マシン」はハードウェア上で直接的に実行されないため、標準的なファイルシステムに比べていくつかの微調整を必要とします。これは特にカーネル、デバイス、コンソールが該当します。幸いなことに、lxc にはこの設定をほぼ自動化するスクリプトが含まれます。たとえば、以下のコマンド (debootstraprsync パッケージが必要です) で Debian コンテナがインストールされます。
root@mirwiz:~# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
root@mirwiz:~# 
ファイルシステムは最初に /var/cache/lxc の中に作成され、その後目的のディレクトリに移動されます。こうすることで、同一のコンテナが極めて素早く作成されます。なぜなら、単純にコピーするだけだからです。
Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.
これで、新規に作成されたファイルシステムが最低限の Debian システムを含むようになりました。デフォルト状態だとこのコンテナにはネットワークインターフェースがありません (ループバックインターフェースすらありません)。これは全く望むべき状態ではないため、コンテナの設定ファイル (/var/lib/lxc/testlxc/config) を編集し、いくつかの lxc.network.* エントリを追加します。
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.hwaddr = 4a:49:43:49:79:20
これらのエントリの意味するところはそれぞれ、仮想インターフェースはコンテナによって作られます。そして仮想インターフェースはコンテナが開始された時に自動的に利用できる状態にされます。そして仮想インターフェースはホストの br0 ブリッジに自動的に接続されます。さらに仮想インターフェースの MAC アドレスは指定したものになります。最後のエントリを削除するか無効化した場合、ランダムな MAC アドレスが生成されます。
以下のようにすることで、設定ファイル内でホスト名を設定することも可能です。
lxc.uts.name = testlxc

12.2.2.4. コンテナの開始

Now that our virtual machine image is ready, let's start the container with lxc-start --daemon --name=testlxc.
In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd. Now we can login:
root@mirwiz:~# lxc-console -n testlxc
Debian GNU/Linux 9 testlxc console	

testlxc login: root
Password: 
Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@testlxc:~# ps auxwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  56736  6608 ?        Ss   09:28   0:00 /sbin/init
root        32  0.0  0.1  46096  4680 ?        Ss   09:28   0:00 /lib/systemd/systemd-journald
root        75  0.0  0.1  67068  3328 console  Ss   09:28   0:00 /bin/login --
root        82  0.0  0.1  19812  3664 console  S    09:30   0:00  \_ -bash
root        88  0.0  0.1  38308  3176 console  R+   09:31   0:00      \_ ps auxwf
root        76  0.0  0.1  69956  5636 ?        Ss   09:28   0:00 /usr/sbin/sshd -D
root@testlxc:~# 
これでコンテナの中に入りました。プロセスへのアクセスはコンテナ自身によって開始されたものだけに制限されていることがわかります。同様に、ファイルシステムへのアクセスも testlxc コンテナ専用に割り当てられた完全なファイルシステムの一部分 (/var/lib/lxc/testlxc/rootfs) に制限されています。コンソールを終了するには Control+a q を使います。
lxc-start--daemon オプションを渡したおかげで、コンテナがバックグラウンドプロセスとして実行されていることに注意してください。コンテナを中止するには lxc-stop --name=testlxc などのコマンドを使います。
lxc パッケージには、ホストの起動時に自動的に 1 つまたは複数のコンテナを開始するための初期化スクリプトが含まれます (この初期化スクリプトは lxc.start.auto オプションが 1 に設定されているコンテナを起動する lxc-autostart に依存しています)。起動順序を非常に細かく制御するには lxc.start.orderlxc.group を使います。デフォルトの場合、初期化スクリプトは onboot グループに所属するコンテナを起動し、その後いかなるグループにも所属しないコンテナを起動します。どちらの場合も、グループ内の起動順序を制御するには lxc.start.order オプションを使います。

12.2.3. KVM を使った仮想化

KVM は Kernel-based Virtual Machine を意味しており、仮想化システムの使うほとんどの基礎構造を提供する最初で最高のカーネルモジュールです。しかしながら、LVM 自身は仮想化システムではありません。仮想化の実際の制御を行うには QEMU に基づくアプリケーションを使います。この節で qemu-* コマンドがあっても心配しないでください。なぜならこのコマンドは KVM に関連するものだからです。
他の仮想化システムと異なり、KVM は最初から Linux カーネルにマージされていました。KVM の開発者はプロセッサが備える仮想化専用命令セット (Intel-VT と AMD-V) を有効活用することを選びました。仮想化専用命令セットを活用することで、KVM は軽量で簡潔でリソースを大量に消費しないものになっています。もちろんその代償として KVM にも欠点があります。それはすべてのコンピュータが KVM を動かせるわけではなく、適切なプロセッサを備えたコンピュータでなければ KVM を動かせないという点です。x86 ベースのコンピュータで /proc/cpuinfo 内の CPU フラグに「vmx」または「svm」が含まれている場合、そのプロセッサは KVM を動かすことができることを意味します。
Red Hat が KVM の開発を活発に支援したことで、KVM は事実上 Linux 仮想化の基準点になりました。

12.2.3.1. 準備段階

VirtualBox などのツールと異なり、KVM は仮想マシンを作成管理するためのユーザインターフェースを含みません。仮想マシンを開始することが可能な実行ファイルおよび適切なカーネルモジュールを読み込むための初期化スクリプトを含むパッケージが qemu-kvm パッケージです。
幸いなことに、Red Hat は libvirt ライブラリおよび関連する仮想マシンマネージャツールを開発することで、この問題に対処するためのツールを提供しています。libvirt により仮想マシンを管理する方法が統一され、仮想マシンの管理方法が裏で動く仮想システムに依存しなくなります (libvirt は現在 QEMU、KVM、Xen、LXC、OpenVZ、VirtualBox、VMWare、UML をサポートしています)。virtual-manager は仮想マシンを作成管理するために libvirt を使うグラフィルインターフェースです。
We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.
virtinst パッケージには virt-install コマンドが含まれます。virt-install を使うことで、コマンドラインから仮想マシンを作成することが可能になります。最後に、virt-viewer を使うことで、仮想マシンのグラフィカルコンソールにアクセスすることが可能になります。

12.2.3.2. ネットワークの設定

Xen や LXC と同様に、最もよく使われるネットワーク設定は仮想マシンのネットワークインターフェースをグループ化するブリッジです (第 12.2.2.2 節「ネットワークの設定」を参照してください)。
ネットワーク設定には別の方法もあります。KVM の提供するデフォルト設定の中では、仮想マシンに (192.168.122.0/24 の範囲内に) プライベートアドレスが割り当てられており、さらに NAT が設定されています。この設定により仮想マシンは外部ネットワークにアクセスすることが可能です。
この節の残りでは、ホストが eth0 物理インターフェースと br0 ブリッジを備え、eth0br0 に接続されていることを仮定します。

12.2.3.3. virt-install を使ったインストール

仮想マシンの作成は普通のシステムをインストールするのとよく似ています。違いは、仮想マシンの性質をコマンドラインから非常に長々と指定する点です。
具体的に言えば、これはホストシステムに保存された Debian DVD イメージを挿入された仮想 DVD-ROM ドライブから仮想マシンを起動することにより Debian インストーラを使うことを意味します。仮想マシンは VNC プロトコル (詳しくは第 9.2.2 節「リモートグラフィカルデスクトップの利用」を参照してください) を介してグラフィカルコンソールに表示されます。これによりインストール作業を操作することが可能になります。
最初にディスクイメージの保存先を libvirtd に伝える必要があります。デフォルトの保存先 (/var/lib/libvirt/images/) でも構わないならばこれは必要ありません。
root@mirwiz:~# mkdir /srv/kvm
root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

root@mirwiz:~# 
それでは仮想マシンのインストール作業を開始し、virt-install の最も重要なオプションを詳細に見て行きましょう。virt-install は仮想マシンとそのパラメータを libvirtd に登録し、インストールを進めるために仮想マシンを開始します。
# virt-install --connect qemu:///system  1
               --virt-type kvm           2
               --name testkvm            3
               --memory 1024             4
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  5
               --cdrom /srv/isos/debian-10.2.0-amd64-netinst.iso  6
               --network bridge=virbr0   7
               --graphics vnc            8
               --os-type linux           9
               --os-variant debian10

Starting install...
Allocating 'testkvm.qcow'             |  10 GB     00:00

1

--connect オプションは使用する「ハイパーバイザ」を指定します。これは仮想システムを表す URL (xen://qemu://lxc://openvz://vbox:// など) と VM をホストするマシン (ローカルホストの場合、空でも構いません) の形をしています。QEMU/KVM の場合、これに加えて各ユーザは制限されたパーミッションで稼働する仮想マシンを管理できます。この場合 URL パスは「システム」マシン (/system) かその他 (/session) かで識別されます。

2

--virt-type kvm を指定することで KVM を使うことが可能です。--connect で指定した URL を一見すると QEMU が使われるように見えますが、これは KVM は QEMU と同じ方法で管理されているためです。

3

--name オプションは仮想マシンの (一意的な) 名前を定義します。

4

The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.

5

The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2) allows starting with a small file that only grows when the virtual machine starts actually using space.

6

--cdrom オプションはインストール時に利用する光学ディスクの場所を指定するために使われます。場所には ISO ファイルのローカルパス、ファイル取得先の URL、物理 CD-ROM ドライブのデバイスファイル (例 /dev/cdrom) のどれか 1 つを使うことが可能です。

7

--network オプションはホストネットワーク設定の中に仮想ネットワークを統合する方法を指定します。デフォルトは既存のネットワークブリッジに仮想ネットワークを統合する方法です (例では明示的にこの挙動を指定しています)。指定したブリッジが存在しない場合、仮想マシンが到達できるネットワークは NAT を介した物理ネットワークだけに限定されるので、仮想マシンはプライベートサブネット範囲 (192.168.122.0/24) に含まれるアドレスを割り当てられます。

8

--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see 第 9.2.1.3 節「ポート転送を使った暗号化トンネルの作成」). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.

9

--os-type--os-variant オプションは、指定されたオペレーティングシステムの備える既知の機能に基づいて、仮想マシンのいくつかのパラメータを最適化するためのものです。
virt-install を実行した時点で仮想マシンが実行されます。インストール作業に進むためには、グラフィカルコンソールに接続する必要があります。上の操作をグラフィカルデスクトップ環境から行った場合、自動的に接続が開始されます。そうでない場合、グラフィカルコンソールを開くために virt-viewer を任意のグラフィカル環境から実行します (この時にリモートホストの root パスワードが 2 回尋ねられる点に注意してください。なぜなら、この操作には 2 つの SSH 接続を必要とするからです)。
$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: 
root@server's password: 
インストール作業が終了したら、仮想マシンが再起動されます。これで仮想マシンを利用する準備が整いました。

12.2.3.4. virsh を使ったマシンの管理

これでインストールが終了しました。利用できる仮想マシンを取り扱う方法に移りましょう。最初に virsh を使って libvirtd が管理している仮想マシンのリストを確認します。
# virsh -c qemu:///system list --all
 Id Name                 State
----------------------------------
  8 testkvm              shut off
それではテスト用仮想マシンを起動しましょう。
# virsh -c qemu:///system start testkvm
Domain testkvm started
そして、グラフィカルコンソールへの接続命令を出します (接続する VNC 画面を vncviewer へのパラメータの形で指定することが可能です)。
# virsh -c qemu:///system vncdisplay testkvm
127.0.0.1:0
その他の利用できる virsh サブコマンドには以下のものがあります。
  • reboot。仮想マシンを再起動します。
  • shutdown。仮想マシンを正常にシャットダウンします。
  • destroy。仮想マシンを無理やり停止します。
  • suspend。仮想マシンを一時停止します。
  • resume。一時停止された仮想マシンを再開します。
  • autostart。ホスト起動時にこの仮想マシンを自動的に起動することを有効化します (または --disable オプションを付けて無効化します)。
  • undefine。仮想マシンのすべての痕跡を libvirtd から削除します。
ここに挙げたすべてのサブコマンドは仮想マシン識別子をパラメータとして受け取ります。

12.2.3.5. yum を使い RPM に基づくシステムを Debian の中にインストールする

仮想マシンが Debian (または Debian 派生物) を実行することを意図している場合、上で述べた通り debootstrap を使ってシステムを初期化することが可能です。しかし、仮想マシンに RPM に基づくシステム (Fedora、CentOS、Scientific Linux など) をインストールする場合、yum ユーティリティ (同名のパッケージに含まれます) を使ってシステムをセットアップする必要があります。
RPM に基づくシステムをインストールする際には、特に yum 設定ファイルなどのファイルの初期セットを展開するために rpm を使い、その後パッケージの残りのセットを展開するために yum を呼び出す必要があります。しかし、chroot の外から yum を呼び出しているため、一時的な修正が必要です。以下に載せた例では、対象の chroot 先は /srv/centos です。
# rootdir="/srv/centos"
# mkdir -p "$rootdir" /etc/rpm
# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-6.1810.2.el7.centos.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.el7.centos.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
warning: centos-release-7-6.1810.2.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo
# yum --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo