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

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

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

# ファイル入手元
https://wiki.almalinux.org/cloud/Generic-cloud.html#download-images

この、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ファイルを配布しているとなりで、マシンイメージ（呼び名はまちまち）を、提供しているようです。

# 環境と概要
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/b0847d84-aeaa-0aa7-6360-3ef1cb76327c.png)

- ホスト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) ログインします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/2ba07dce-35c6-8f66-3516-26e2beb50a86.png)

## 3. VM作成

(1) メニューから、「仮想マシン」を選びます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/cea29cf2-0cd9-49e4-b161-5068f685f61a.png)

(2) 右上の、「仮想マシンの作成」を選びます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/697cf0bd-1abd-fa7a-e5c8-bf453c65f1ac.png)

(3) ウイザードが開かれるので、作成するVMの情報を入れます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/8ca20c46-0662-4d24-a658-1aa919de2ea0.png)

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

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

(4) 「自動化」タブを押し、作成するVMのユーザ情報を指定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/775a0860-8cf5-7f54-92f9-68712544bb9f.png)

(5) 「作成して実行する」を押します。VMが作成され、仮想マシン一覧表示に追加されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/9f05bb9c-8aa5-a311-4d28-92f2ab211e11.png)

(6) VM名を選択し、コンソールを開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/f5d10560-04c7-b035-2992-7304b9350800.png)

(7) ログインプロンプトが表示されていますので、ログインして、VMを使用できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468232/a16982e6-1069-7423-b233-73725041ac34.png)


## 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コンソールの方が、わかりやすいし、楽かなと思います。