ステップ 1 - まずは qcow2 または VHD 形式の単一イメージ・ファイルを用意する

Linux ベースの独自のカスタム・イメージを作成するには、まずは、qcow2 または VHD 形式の単一のイメージ・ファイルが必要です。 クラウド対応のベンダー・イメージを用意しておくと便利な場合があります。

カーネル・ログは、ブート関連の問題をデバッグする際に重要です。 カーネル・ログがシリアル・コンソールに出力されるようにするには、 console=ttyS0 カーネル・コマンド・ライン引数を使用します。 さらに、2021 年半ばより前にリリースされた古いカーネルのブート・プロセス中の表示関連の問題を解決するために、 nomodeset および nofb カーネル・パラメーターが使用されます。 新しいカーネルは、ビデオ・モード設定をカーネルに使用します。

ステップ2 - virtioドライバをチェックする

1. virtio ドライバーが、virtio が必要とするコードとともに、ご使用のオペレーティング・システム・イメージにインストールされていることを確認します。 Virtio ネットワーク・ドライバーは、ネットワーキングを有効にするために必要です。 以下のコマンドを実行して、virtio ドライバがカーネルにインストールされているかどうかを確認します：

   grep -i virtio /boot/config-$(uname -r)
   

   出力で VIRTIO_BLK と VIRTIO_NET を探します。 これらの行が存在しない場合、virtio ドライバーはカーネルに組み込まれていません。

2. VIRTIO_BLK 、 VIRTIO_NET の行が存在する場合、以下のコマンドを実行し、ドライバが一時的なルート・ファイル・システムに存在することを確認する：

   lsinitrd /boot/initramfs-$(uname -r).img | grep virtio
   

   Debian オペレーティング・システムを使用している場合は、以下のコマンドを使用します。

   lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio
   

   virtio blk ドライバとその依存関係 virtio.ko、 virtio_pci、 virtio_ring が存在することを確認する。 virtio の依存関係が存在しない場合は、ルートファイルシステムを回復する必要があります。

ステップ3 - ネットワークインターフェースが自動設定に設定されている

ネットワークインターフェイスがゲストイメージで定義されている場合は、少なくとも1つのネットワークインターフェイスが に設定されていることを確認します。 すべてのインターフェイスを手動コンフィグレーションに指定することはできない。 一般的には、インターフェースは DHCP を使用するように設定します。 DHCP の構成方法について詳しくは、ご使用の Linux ディストリビューションの資料を参照してください。

ステップ 4-イメージが cloud-init 対応であることを確認する

イメージが cloud-init 対応になっていることを確認してください。 cloud-init バージョン 0.7.9 以上が必要です。

1. cloud-initがインストールされているかどうかを調べるには、以下のコマンドを実行する： cloud-init --version

   • 場合によっては、cloud-init はインストールされているのに、環境の PATH に設定されていないことがあります。
   • ExecStart で cloud-init のパスを検索するには、コマンド systemctl cat cloud-init を実行します。

2. cloud-init をインストールするには、次のどちらかのコマンドを使用します。

   • Ubuntu または Debianの場合は、コマンド apt-get install cloud-init を実行します。
   • CentOS または Red Hatの場合は、コマンド yum install cloud-init を実行します。

3. datasources_list プロパティーが /etc/cloud/cloud.cfgに存在する場合は、そのプロパティーに NoCloud のみが含まれていることを確認するか、 datasources_list プロパティーを完全に削除します。 ConfigDrive はサポートされていません。 データ・ソースについて詳しくは、 データ・ソースを参照してください。 IBM Cloud cloud-init イメージは、 NoCloud データ・ソースを使用してメタデータを提供することで環境用に作成されます。

   ブロック・デバイスが提供されます。 以下の例を参照してください。

   blkid
   /dev/vdb: UUID="2023-03-15-16-50-02-00" LABEL="cidata" TYPE="iso9660"
   

   このブロック・デバイスは cloud-init によって検出され、以下のファイルを含みます。

   • メタデータ・インスタンス ID: INSTANCE_ID ローカル・ホスト名: NAME
   • user-data インスタンスの作成時に指定されたオプションのユーザー・データ。 詳しくは、 ユーザー・データ を参照してください。
   • vendor-data インスタンスの作成時に提供された SSH 鍵から派生したクラウド構成 SSH 許可および追加の初期化情報を含む MIME 形式のファイル。

4. /etc/cloud/cloud.cfg ファイルで、cloud_final_modules セクションに scripts-vendor モジュールが含まれていて、有効にされていることを確認します。 デフォルトでは、Red Hat Enterprise Linux および CentOS には、IBM Cloud VPC インフラストラクチャーにインスタンスをプロビジョンするために必要な scripts-vendor モジュールが含まれていません。 Linux カスタム・イメージを使用して IBM Cloud VPC 仮想サーバー・インスタンスをプロビジョンするには、 scripts-vendor モジュールを有効にする必要があります。

   Red Hat Enterprise Linux (RHEL) イメージの場合、以下のパッケージがベースイメージの一部としてデフォルトで含まれており、cloud-init を正常に実行するために必要です： subscription-manager ethtool および rpm。 さらに、cloud-init-local.service、cloud-init.service、cloud-config.service、および cloud-final.service の各サービスが有効になっている必要があります。

5. 仮想サーバーへのログインにSSHを使用するようにイメージを設定してください。

RHEL ベースのカスタムイメージのデフォルトユーザーは cloud-user です。 cloud-initの有効化の詳細については、 cloud-initの設定を参照してください。

ステップ5 - ブートディスクのサイズ

イメージのブートディスクサイズが10～250GBであることを確認してください。 10GB未満の画像は10GBに切り上げられます。

クラシックインフラストラクチャから移行する仮想サーバーをカスタマイズしている場合は、 クラシックインフラストラクチャからの仮想サーバーの移行に 戻り、移行手順を完了します。

ステップ 6-イメージを IBM Cloud Object Storage にアップロードする

イメージを IBM Cloud Object Storage にアップロードします。 IBM Cloud® Object Storage バケットの Objects ページで、 Upload をクリックします。 200MBを超える画像をアップロードするには、 Aspera 高速転送プラグインを使用できます。 IBM Cloud Object Storage にアップロードする方法について詳しくは、データのアップロードを参照してください。

次のステップ

Linux カスタム・イメージが作成され、 IBM Cloud Object Storageで使用可能になったら、 カスタム・イメージを VPC にインポート し、 VPC の仮想サーバー・イメージをオンボード できます。 イメージをインポートするための IBM Cloud Object Storage へのアクセス権限が付与されている ことを確認してください。

プライベート・カタログを使用してカスタム・イメージを管理する予定の場合は、まずそのイメージを IBM Cloud VPCにインポートしてから、仮想サーバー・イメージをプライベート・カタログにオンボードする必要があります。

カスタム・イメージをインポートした後、そのカスタム・イメージを使用して、 IBM Cloud® Virtual Private Cloud インフラストラクチャーに仮想サーバーをデプロイできます。