マシンイメージからal9のVMを作る

この記事の内容

AlmaLinux9のVMを構築する方法として、以下があります。

• 普通のやり方。インストーラISOファイルからVMを立ち上げ、OSをインストールする。
• パブリッククラウドのインスタンス（=VM）のように、最小パッケージ構成でインストール済みのOSの仮想ディスク（=マシンイメージ）と、cloud-initのISOファイル（初期設定する内容を書いたもの）から、VMを起動する。

後者の方法でVMを作る方法の紹介です。

ファイル入手元

この、Download imagesの、AlmaLinux 9の、x86_64のリンクより。
ここでは、AlmaLinux-9-GenericCloud-latest.x86_64.qcow2 を使用します。
https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/AlmaLinux-9-GenericCloud-latest.x86_64.qcow2

ここでは、AlmaLinuxを例にしていますが、多くのOSディストリビューションは、インストーラISOファイルを配布しているとなりで、マシンイメージ（呼び名はまちまち）を、提供しているようです。

環境と概要

• ホストOS：RHEL8.9、OS標準のKVM仮想化環境。
• ブラウザでホストOSの9090ポート(cockpit)に接続。
• cockpitのWebコンソールでVM作成。

実施手順

1. マシンイメージファイル入手

VMの仮想ディスクは、ストレージプールに置きます。（デフォルトは/var/lib/libvirt/images/）

cd /var/lib/libvirt/images/
curl -O https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/AlmaLinux-9-GenericCloud-latest.x86_64.qcow2

このqcow2ファイルは、virtual sizeが10GiB、実サイズは468MiBでした。

[root@rhel8host images]# qemu-img info AlmaLinux-9-GenericCloud-latest.x86_64.qcow2 | grep size
virtual size: 10 GiB (10737418240 bytes)
disk size: 468 MiB
cluster_size: 65536
[root@rhel8host images]#
[root@rhel8host images]# ls -lsh | grep GenericCloud-latest
469M -rw-r--r--. 1 root root 469M  2月  8 15:57 AlmaLinux-9-GenericCloud-latest.x86_64.qcow2
[root@rhel8host images]#

2. Webコンソールに接続

(1) ブラウザで、「 https://192.168.11.201:9090 」にアクセスします。

前提：

• cockpit.socketがenabledであること。
• cockpit-machinesのパッケージがインストールされていること。

前提を満たしていない場合は、以下をやります。

systemctl enable --now cockpit.socket
dnf install -y cockpit-machines

(2) ログインします。

3. VM作成

(1) メニューから、「仮想マシン」を選びます。

(2) 右上の、「仮想マシンの作成」を選びます。

(3) ウイザードが開かれるので、作成するVMの情報を入れます。

• インストールタイプは、「クラウドベースイメージ」。
• インストールソースは、先にダウンロードした、マシンイメージファイル。

ここでは、作成されるVMの、仮想ディスクのサイズは、16GiBを選んでいます。
これにより、後でゲストOSでfdisk -lすると、/dev/vdaが16GiBと表示されます。

(4) 「自動化」タブを押し、作成するVMのユーザ情報を指定します。

(5) 「作成して実行する」を押します。VMが作成され、仮想マシン一覧表示に追加されます。

(6) VM名を選択し、コンソールを開きます。

(7) ログインプロンプトが表示されていますので、ログインして、VMを使用できます。

4. 確認

fdisk -lすると、以下のように、16GiBと表示されます。

[root@localhost ~]# fdisk -l
Disk /dev/vda: 16 GiB, 17179869184 bytes, 33554432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5B69F67F-B93F-44E8-94F2-EAA1D9D41C02

Device       Start      End  Sectors  Size Type
/dev/vda1     2048     4095     2048    1M BIOS boot
/dev/vda2     4096   413695   409600  200M EFI System
/dev/vda3   413696  2510847  2097152    1G Linux filesystem
/dev/vda4  2510848 33554398 31043551 14.8G Linux filesystem
[root@localhost ~]#

/は14GiBくらい使えます。
パブリッククラウドだと、ルートディスクのデフォルトサイズは10GiBかと思います。

[root@localhost ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           984M     0  984M   0% /dev/shm
tmpfs           394M  5.6M  388M   2% /run
/dev/vda4        15G  895M   14G   6% /
/dev/vda3       960M  131M  830M  14% /boot
/dev/vda2       200M  7.1M  193M   4% /boot/efi
tmpfs           197M     0  197M   0% /run/user/0
tmpfs           197M     0  197M   0% /run/user/1000
[root@localhost ~]#

ホストOSで、作成されたVMの仮想ディスクサイズを見ると、実サイズが23.5MiB、virtual sizeが16GiBになっています。

[root@rhel8host images]# ls -lhs | grep testvm-1
 24M -rw-------. 1 root root  23M  2月  8 16:38 testvm-1.qcow2
[root@rhel8host images]#
[root@rhel8host images]# qemu-img info testvm-1.qcow2 | grep size
virtual size: 16 GiB (17179869184 bytes)
disk size: 23.5 MiB
cluster_size: 65536
[root@rhel8host images]#

qcow2ファイルのvirtual sizeは、一般的に、qemu-img resizeコマンドで、指定サイズに変更できます。
VM作成時に、qcow2ファイルのvirtual sizeを16GiBに変え、続くcloud-initの初期化が、/dev/vda4に、15GiB程度のファイルシステムを作る、ということが、行われているようです。

5. おまけ

• dhcpでIPアドレスは付いている（ip addrで確認可）。
• VMのvCPU数は、作ってから変える。
• OSのパッケージは最低限な構成なので、dnf installで、必要なソフトを追加して使う。
• ホスト名がlocalhostなので、適当に設定すると良い。
• firewalldが入っていない。無防備なので入れた方がいい。
• システム時刻が日本のものじゃない。タイムゾーンをAsia/Tokyoにすると良い。
• デフォルトでは、sshd.serviceがrootのログインを禁止している。
• EL9のWebコンソールだと、VM作成時にsshの公開鍵を登録して、秘密鍵を使ってssh -iでアクセスするよう設定できるが、EL8だとそのメニューがなかった。

ホスト名の設定例：

[root@localhost ~]# hostnamectl hostname testvm-1.internal
[root@localhost ~]#
[root@localhost ~]# hostname
testvm-1.internal
[root@localhost ~]#

タイムゾーンの設定例：

[root@localhost ~]# timedatectl
               Local time: Sat 2025-02-08 07:55:04 UTC
           Universal time: Sat 2025-02-08 07:55:04 UTC
                 RTC time: Sat 2025-02-08 07:55:04
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
[root@localhost ~]#
[root@localhost ~]# timedatectl set-timezone Asia/Tokyo
[root@localhost ~]#
[root@localhost ~]# timedatectl
               Local time: Sat 2025-02-08 16:55:31 JST
           Universal time: Sat 2025-02-08 07:55:31 UTC
                 RTC time: Sat 2025-02-08 07:55:31
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
[root@localhost ~]#
[root@localhost ~]# date
Sat Feb  8 04:55:40 PM JST 2025
[root@localhost ~]#

6. まとめ

マシンイメージを使う主なメリットは、こんなところでしょうか。

• OSインストーラからVMを作るより、早い。（数秒～十数秒で作れる）
• こういうインストール選択で、ゲストOSをインストールしました、というやり取りが省ける。
• 初期状態のVMの、仮想ディスクサイズが、小さく抑えられる。（今回は、23.5MiBだった）

パブリッククラウドのインスタンスと、ほとんど同じようなものを、オンプレミス環境に、すごく簡単に作れる、という捉え方をしておくと、色々な活用方法が浮かぶかと思います。

また、要は、cloud-initの仕組みを使ってVMを作った、という話であり、Webコンソールを使わずとも、cloud-initのisoファイルを作り、virt-installコマンドでVMを作ることもできます。ただ、Webコンソールの方が、わかりやすいし、楽かなと思います。