モチベーション ¶

深い考えがあって、やったわけではなくて単に RHEL8 Betaがリリースされたので、ちょっと試してみたかった。
でも適当な機械がなかったのと、最近自分の PC にローカルの仮想環境を作るのが億劫なので、AWS上にインストールしてみることにした。

イメージの所在など ¶

Red Hat のサイトに行って、デベロッパー登録するとイメージをダウンロードできるようになる。
まあ、この辺りを見ながら適当にポチポチしてたら、ダウンロードできた。
https://developers.redhat.com/rhel8/getrhel8/

VM Import を試みたが…..¶

一からイメージを作るのは面倒なので、カスタマーポータルをウロウロしていたら KVM のイメージを見つけたので、これを VM Import すればいいかなと思って、マニュアルを見ながらポチポチしてみたら、以下のエラーが出て失敗してしまった。

"StatusMessage": "ClientError: Unable to determine kernel version."

イメージの作り方なのか、 VM Import がまだ対応していないのか知らないが、単純にはいかないようだ。

しょうがないので手動で作る。¶

適当に EBS を確保して、手動で RPM パッケージを展開してもいいんだけど、それだとめんどくさいので KVM用のイメージをEBSに書き込んでみることにした。
適当に Amazon Linux 2 のインスタンスを起動して、カスタマーポータルからダウンロードした qcow2 イメージを転送する。後で使いまわしやすいように S3 にアップロードしてEC2 インスタンスでダウンロードした。
ちなみにインスタンスサイズは、m5.large。せっかくなのでNITRO 世代を利用した。
最初に、WEB のコンソールからアップロードしようとしたら、200KB/s 位しか速度がでない。イメージサイズが結構あるので、シャレにならないので、CLI からアップロードすることにした。
10倍速い。ということで S3 は CLI がおすすめです。
さて、qcow2 のままだと EBS に書いても起動しないのでraw イメージに展開する。展開するには qemu-img コマンドを使用した。
まずはコマンドのインストール

$ sudo yum install -y qemu-img

そして変換 qcow2 から raw イメージに変換

$ qemu-img convert -O raw rhel-8.0-beta-1-x86_64-kvm.qcow2 rhel-8.0-beta-1-x86_64-kvm.raw

変換後の確認。

$ qemu-img info rhel-8.0-beta-1-x86_64-kvm.raw
image: rhel-8.0-beta-1-x86_64-kvm.raw
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 10G

無事に変換できた。サイズが 10GB なので、EBS を 10 GB 確保してインスタンスにアタッチする。アタッチしたディスクに dd コマンドでイメージをべた書きする。

sudo dd if=rhel-8.0-beta-1-x86_64-kvm.raw of=/dev/nvme1n1 bs=4096 &

2621440+0 records in2621440+0 records out10737418240 bytes
(11 GB) copied, 80.9751 s, 133 MB/s

bs オプションで書き込みのブロックサイズをある程度大きくしておかないと、異常に時間がかかるので注意が必要だ。
書き込みができたので、パーティションの構成を確認しておく。

$ sudo parted /dev/nvme1n1
GNU Parted 3.1
Using /dev/nvme1n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: NVMe Device (nvme)
Disk /dev/nvme1n1: 10.7GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1075MB  1074MB  primary  xfs             boot
 2      1075MB  2149MB  1074MB  primary  linux-swap(v1)
 3      2149MB  10.7GB  8589MB  primary  xfs

boot、swap、root という割と標準的な感じの構成。
マウントする。ここではカレントディレクトリに tmp というディレクトリを作成して、そこにマウントした。

$ sudo mount /dev/nvme1n1p3 ./tmp
$ sudo mount /dev/nvme1n1p1 ./tmp/boot

$ sudo mount -o rbind /sys ./tmp/sys
$ sudo mount -o rbind /dev ./tmp/dev
$ sudo mount -t proc none ./tmp/proc

sys,dev,proc もマウントしておくのがポイント。それで chroot する。

$ sudo chroot ./tmp

基本的には初期 RAM にディスクドライバが入っていれば起動するはずなので、初期 RAM の再作成を行う。

# dracut -f --kver 4.18.0-32.el8.x86_64

少し待つと初期 RAM が更新される。 lsinitrd コマンドなどで、nvme ドライバが取り込まれていることを確認する。

そして AMI 化だがしかし ¶

とりあえず exit で、chroot を抜けて 1 回 os をリブートする。 mount コマンドを rbind 付きで実行しているので、再帰的にいろいろマウントされていて、umount をするのが異常にめんどくさい。
リブートするとマウントが解除されるので、先ほど書き込んだEBS のスナップショットを作成する。ここはマネジメントコンソールから簡単にできる。そして snapshot から AMI を作成。で AMI から起動を試みた。
がしかし、m5 とか NITRO 世代のインスタンスが選択できない!
でいろいろググってみると、AMI 作成時に ENA サポートを有効にしないといけないらしい。で ENA サポートを有効にするには、現状 CLI で作成しないといけない。
まず EBS デバイスマップを書いた json ファイルを作成する。ここでは単純に devicemap.json というファイルを以下の内容で作成した。 SnapshotId は先ほど作成した snapshot のID

[
  {
    "DeviceName": "/dev/sda1",
    "Ebs": {
      "DeleteOnTermination": true,
      "SnapshotId": "snap-xxxxxxxxxxxxxxxxx",
      "VolumeSize": 10,
      "VolumeType": "gp2"
    }
  }
]

それで以下のコマンドラインで、AMI を作成。

$ aws ec2 register-image \
    --architecture x86_64 \
    --block-device-mapping file://devicemap.json \
    --ena-support \
    --name "RHEL8 Try1" \
    --root-device-name /dev/sda1 \
    --virtualization-type hvm

ポイントは “–ena-support” オプション。環境によっては “–region” オプションが必要になる。適宜追加してほしい。
これで NITRO 世代も選択できるようになった。

起動はできたけれど…..¶

それで、早速 M5.large で起動。 Get System log で、起動ログを見ていると、ちゃんと起動しているように見える。
が、ssh でログインできない。しょうがないので、一旦インスタンスをストップにして、EBS をプチっと取り外して作業用のインスタンスにアタッチして、ログをよく見てみる。
sshd がキーのパーミッションがよろしくないので起動できないというメッセージが出ている。でそのちょっと上にキーのグループの設定に失敗しているログも出ていた。
selinux で deny しているログも見つけたので、おそらくselinux を permissive に設定すればよさそう。
それで、元のディスクを再びマウントして /etc/selinux/config ファイルのSELINUX=enforcing の行を SELINUX=permissive に変更した。