LoginSignup
35
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sshatari

【OCIクラウド移行ガイド】Oracle Cloud Migrations で Rocky Linux をOCIに移行する

Last updated at Posted at 2025-02-27

OCIクラウド移行ガイドとは

オンプレミスやAWSなど、複数のプラットフォームからOracle Cloud Infrastructureへの移行プロジェクトに取り組んでいるクラウドエンジニア（@araidon,@kazunishi,@yama6,@tktk2712,@ritokuna,@nomu_kyou,@ora-777,@sshatari,@makoji,@miztana）による、OCI移行手順をまとめたシリーズ記事です。
各回、サンプルワークロードから対象サービスを取り上げ、移行手順をガイドいたします。
まとめ記事は以下になります。

Oracle Cloud Migrations とは

Oracle Cloud Migrations は、Oracle Cloud Infrastructureに移行を行うためのOCIネイティブのサービスです。こちらのサービスでは、オンプレミスなどに存在するVMware環境の仮想マシンおよびAWS上のEC2をOCIのコンピュート・インスタンスに移行できます。

image.png

今回は、Oracle Cloud MigrationsのAmazon EC2移行機能を利用し、Rocky Linuxの移行検証を行います。

OCIにおけるRocky Linuxの技術サポートについて

OCIとしてのRocky Linuxの技術サポートはありません。
各OSにおけるOCIでの技術サポートの有無については下記リンクのスライドの通りです。
https://speakerdeck.com/ocise/ociji-shu-zi-liao-konpiyutosabisu-gai-yao?slide=44

Rocky Linuxは「その他のLinux」に該当し、オラクルから提供される技術サポートの方針は「特に無し（必要に応じて別途OSベンダー等と有償のサポート契約を行う）」とされています。

カスタムイメージでBYOIする場合のサポートについて

Rocky Linux OSのイメージは、オラクルとして動作保証はされません。

OCIではイメージを指定してコンピュートインスタンスを作成します。その際に、独自に作成したカスタムイメージを準備して作成することもできます。Oracle Cloud Migrationsでは移行元のEC2インスタンスのカスタムイメージを作成し、カスタムイメージからコンピュートインスタンスを立ち上げるということを内部的に実行しています。

OCIでは、カスタムイメージからのコンピュートインスタンスの起動時に、一部のOSについてインスタンスの起動とSSHを使用したアクセスの動作が保証されており、技術サポートがオラクルから提供されます。
Rocky Linuxはその対象には含まれないとのことです。
対象のOSは以下：
【概要資料】カスタム・イメージへのインポートがサポートされているOS
【ドキュメント】カスタムLinuxイメージのインポート

OCIにおけるRocky Linuxのライセンス課金について

Rocky Linuxのソフトウェア料金自体は無償で使えるようです。
有償のサポート契約が必要な場合は別途OSベンダーとの契約が必要になります。

【参考】Oracle Cloud Migrationsを使った移行とは無関係ですが、新規のインスタンスを立ち上げる場合にはOCI MarketplaceにてOSベンダー（Ctrl IQ, Inc.）によってサポートされるRocky Linuxイメージが使えます。
Marketplaceにて提供されるイメージの一覧は以下：

Marketplaceイメージ 課金体系 アーキテクチャ 説明
Rocky Linux with CIQ Enterprise Support BYOL x86_64またはarm64 CIQ社から別途エンタープライズ サポート契約を購入し、ライセンスを持ち込む
Rocky Linux (Latest 8/9 Releases) with CIQ Enterprise Assurance (x86_64) サブスクリプション
※JPYでは利用不可		 x86_64 CIQ社へのライセンスをサブスクリプション形式で支払うモデル。提供自体はあるが、OCIの支払いに設定している通貨がJPYの場合使用できないことに注意。
Rocky Linux 8 (Community Edition) - Provided by CIQ (x86_64) 無償 x86_64 CIQ社から提供される、無償で使えるコミュニティ版のイメージ
Rocky Linux 9 (Community Edition) - Provided by CIQ (x86_64) 無償 x86_64 CIQ社から提供される、無償で使えるコミュニティ版のイメージ
Rocky Linux 8 (Community Edition) - Provided by CIQ (aarch64) 無償 aarch64 CIQ社から提供される、無償で使えるコミュニティ版のイメージ
Rocky Linux 9 (Community Edition) - Provided by CIQ (aarch64) 無償 aarch64 CIQ社から提供される、無償で使えるコミュニティ版のイメージ

0. 前提

前提条件のデプロイ

Oracle Clould Migrationsを使用するには、前提条件となるリソースがたくさんあり、またユーザやサービスに対するポリシー設定も多く、手動で設定作業を行うとなると非常に煩雑な作業になります。
そこで、「前提条件の作成」という機能が提供されているので、これを利用することによりterraformによって必要なコンパートメントやタグ、ポリシーなどを作成してくれます。
手動で作成することも可能ですが、抜け漏れを防ぐためにもこちらの機能を使用することを推奨します。
前提条件の作成では、以下のようなリソースが作られます。
前提条件デプロイのスタックで自動作成されるリソース
また、必要なIAMポリシー設定は以下です：
・ユーザに対するポリシー設定
・サービスに対するポリシー設定

作成方法については以下のマニュアルを参照してください。
必要な移行前提条件のデプロイ

本記事では、「前提条件の作成」機能で作成されるリソースについてはすでに作成済みのものとします。

ユーザ側で明示的に作成が必要なリソース

今回必要になるリソースをざっくりと書きだしました。すべてのリソースを網羅しているわけではありません。
image.png

緑字で記載のリソースが、上記の前提条件の作成機能で払い出されるものです。
紫字で記載のリソースは、ユーザ側で作成いただく必要があるものです。本記事は作成済みのものとして進めていきます。

  • OCI関連リソース
サービス名 用途/必要な設定 参考資料
ターゲット・コンパートメント 後述の「アセット・ソースの作成」で、ルートコンパートメントは以下のサブコンパートメントを指定する必要のある工程があります。 【OCIチュートリアル】コンパートメントの作成手順
ネットワーク関連リソース（VCN/セキュリティリスト/ルート表/ゲートウェイ等） 移行先インスタンスを配置するためのネットワークの作成が必要です。移行先インスタンスへの接続テストができるよう、セキュリティリストやルート表の設定も入れておいてください。ウィザードを使ったVCNの作成が便利です。 【OCIチュートリアル】VCNの作成手順
オブジェクトストレージ 移行元インスタンスからのデータのレプリケーション時にステージング領域として利し使用されるオブジェクトストレージが必要です。 【OCIチュートリアル】OCIオブジェクトストレージの作成手順
  • AWS関連リソース
サービス名 用途/必要な設定
ネットワーク（VPC/サブネット/ルートテーブル等） 移行元となるEC2インスタンスを作成するためのネットワークリソースを作成しておいてください。

1. 移行元インスタンスの準備

AWSコンソールにて、移行元となるEC2インスタンスを作成します。
作成するインスタンスのAMIですが、今回はAWS Marcketplaceイメージで提供される Rocky Linux 8 (Official) を使って起動します。
※こちらのイメージもRocky Linuxのソフトウェア利用料は無償
インスタンスタイプはt2.smallを選択しました。
作成したインスタンスの詳細は以下：

ec2詳細1.png

AMIの詳細は以下：
AMI.png

2. アセット・ソースを作成する

アセット・ソースとは、移行元となるAWS環境（ソース環境）の接続情報が定義されるOCI上のリソースです。アセット・ソースを作成していきます。

OCIコンソールのメニューより、[移行とディザスタ・リカバリ]>[クラウド移行]>[検出]をクリックします。
アセット・ソースの作成画面にて、以下の項目を入力します。

アセット・ソース・タイプ

AWSを選択します。
アセットソース作成1.png

アセット・ソース情報

ソースとなるAWS環境の接続情報を入力します。
image.png

  • 名前：任意の名前をつけます。
  • アカウントID：AWSのアカウントIDを入力します。AWSコンソール上で確認可能です。
  • リージョン：移行元インスタンスが配置されているAWSリージョンを指定します。
  • コンパートメント：アセットソースの配置先コンパートメントを指定します。前提条件の作成時に払い出された「Migration」コンパートメントの使用を推奨します。
  • ターゲット・コンパートメント：移行先インスタンスの配置先となるとなるターゲットコンパートメントを指定します。この際、ターゲットコンパートメントはルートコンパートメントのサブコンパートメントであることが必要です。ルートコンパートメントを指定するとソースの検出作業に失敗するのでご注意ください。

リモート接続ソース環境

アセットソース作成3.png

  • 名前：任意の名前を入力します。
  • コンパートメントに作成：前提条件の作成時に払い出された「Migration」コンパートメントの使用を推奨します。

検出資格証明

OCIからAWS環境にアクセスするのに必要な資格情報の入力、およびその情報をセキュアに扱うための設定を行います。
image.png

  • 「シークレットを作成」を選択します。

  • 名前：任意の名前を入力します。

  • コンパートメントで選択：AWSの資格情報を暗号化するためのボールトが置かれているコンパートメントを選択します。

  • ボールト：使用するボールトを選択します。前提条件の作成時に払い出されたボールトの使用を推奨します。

  • マスター暗号化キー：選択したボールトに保管されるキーのうち、使用するキーを選択します。前提条件の作成時に払い出されたキーの使用を推奨します。

  • アクセス・キーID：AWSコンソールで作成したアクセスキーを入力します。 ※作成方法は後述

  • シークレット・アクセス・キー：AWSコンソールで作成したアクセス・キーに付随するシークレット・アクセス・キーを入力します。 ※作成方法は後述
    以下、AWSアクセス・キーの作成方法です。
    AWSコンソールの右上のアカウント名をクリックし、「セキュリティ認証情報」をクリックします。

    アクセスキー欄より、「アクセスキーを作成」をクリックします。
    image.png
    アクセスキーの作成画面に遷移します。「アクセスキーを作成」をクリックします。
    アクセスキー3.png
    アクセスキーが作成されました。アクセスキーおよびシークレットアクセスキーをコピーします。シークレットアクセスキーはコピーの機会が一度しかないのでご注意ください。
    image.png

    上記の手順で取得したアクセスキーの情報を、アセットソース作成画面にて入力します。

そのほかの設定項目

すべてデフォルトの設定のままとします。
アセットソース作成5.png

上記すべてを入力できたら、「作成」ボタンをクリックします。

アセット・ソースが作成できました。
image.png

3. アセットを検出する

アセットとは、ソース環境における、仮想マシンおよび関連付けられたデータ・ディスクを含む移行単位のことです。AWS上の移行元インスタンスおよび関連付けられたEBSボリュームを検出します。

作成したアセットソースのページより、「検出の実行」をクリックします。
image.png

AWSアセットの検出作業が開始されます。作業リクエストに、新しい作業リクエストが表示されます。
image.png

検出が成功すると、指定したAWS環境に存在するEC2インスタンスとアタッチされたEBSボリュームの情報が取得され、「アセット」欄に表示されます。
image.png

検出されたEC2インスタンスおよびアタッチされたEBSボリュームの詳細は以下：
image.png

image.png

4. 移行プロジェクトの作成

言葉の定義を確認します。

  • 移行プロジェクトとは：
    • 移行プラン（後述）やレプリケーションを管理するRootフォルダのようなもの
    • プロジェクトの中に移行対象とする移行アセットを追加する。1つのプロジェクトに複数の移行プランを作成できる。
  • 移行プランとは：
    • どのような戦略で移行するか、ターゲットのネットワークやシェイプなどを定義する
    • 移行プロジェクト配下でテスト用プランと本番用プランなど複数の移行プランを作成可能

移行プロジェクトにて、ソース環境のどのリソース（移行アセット）を、OCIのどこをターゲットとしてどのように移行していくか（移行プラン）を定義していきます。

OCIコンソールのメニューより、[移行とディザスタ・リカバリ]>[クラウド移行]>[移行]をクリックします。
[移行プロジェクトの作成]ボタンをクリックします。
移行プロジェクトの作成.png

移行の作成画面にて、以下の項目を入力していきます。

移行プロジェクト単体で作成、または移行プランも含めてまとめて作成できるウィザードを起動することができます。
今回はまとめて作成するため、「初期移行プランを使用して移行プロジェクトを作成します」を選択し、「移行プロジェクトの作成」ボタンをクリックします。
image.png

基本情報

image.png

  • 表示名：任意の移行プロジェクト名を指定します。
  • コンパートメント：移行プロジェクトのリソースの配置場所を指定します。
  • レプリケーション・スケジュール：移行元からのデータのレプリケーションを手動実行するか、スケジュールベースで実行するかを決めます。今回は手動実行するものとし、「レプリケーション・スケジュールがありません」を選択します。
    「次へ」をクリックします。

アセット

移行対象のアセットを指定します。「OCMインベントリからの追加」をクリックします。
image.png

検出済みのアセットが一覧表示されます。
image.png

すべてのアセットが表示されてしまっているため、コンパートメントで絞り込んだり、アセットタイプやアセット名などで絞り込むことが可能です。
image.png　image.png

アセットタイプがAWS EC2インスタンスであるものだけに絞り込みます。
移行元となるEC2インスタンスのアセットにチェックを入れ、「移行アセットの追加」をクリックします。
image.png

追加されました。「次へ」をクリックします。
image.png

レプリケーション位置

ソース環境となるEC2インスタンスからデータをレプリケーションする際、OCIオブジェクトストレージをステージング領域として指定する必要があります。
あらかじめ作成済みのオブジェクトストレージバケットを選択します。
レプリケーション位置.png

データをレプリケートしたいアセットにチェックを入れ、「レプリケーション場所の編集」をクリックします。
ここでもレプリケーション・バケットとして、任意のOCIオブジェクトストレージを選択します。
image.png

「次へ」をクリックします。

初期移行プラン

image.png

  • 表示名：任意の表示名を入力します。
  • コンパートメント：任意のコンパートメントを指定します。
  • ターゲット・コンパートメント：任意のターゲットコンパートメントを指定します。
  • 戦略：移行の推奨事項を構成するための戦略を定義します。何を基準に移行先インスタンスをサイジングするかを定義することができます。今回は、リソース・タイプはデフォルト、戦略タイプは現状維持を選択します。戦略の決め方についてはこちらのスライド（移行戦略の概要）が参考になりました。
    image.png image.png

「ターゲット環境」欄を入力していきます。
image.png

  • 優先シェイプ・タイプ：移行先となるOCIコンピュートのシェイプを決めます。「優先シェイプ・タイプの選択」より、ユーザ側で明示的にシェイプを指定することも可能です。今回は「システム推奨の使用」を選択します。
  • VCN：ネットワーク配置を決めます。あらかじめ作成済みのVCNを指定します。
  • サブネット：あらかじめ作成済みのサブネットを指定します。
  • 専用仮想マシン・ホスト：移行先として専用仮想マシン・ホストを利用する場合には指定します。
    「次へ」をクリックします。

確認および作成

image.png

「送信」ボタンをクリックします。
image.png

移行プロジェクトが作成されました。
image.png

ターゲットとなるOCIコンピュートの推定コストなどが確認できます。
image.png

5. 移行元インスタンスの確認

移行元のEC2インスタンスに接続し、テストファイルを用意しておきます。

Using username "rocky".
Authenticating with public key "rsakey"
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Sun Feb  9 04:56:01 2025 from 49.98.165.32
[rocky@ip-10-0-7-232 ~]$ touch test
[rocky@ip-10-0-7-232 ~]$ ls
test
[rocky@ip-10-0-7-232 ~]$

6. レプリケーションの実行

データ移行を行うため、レプリケーションを実行します。
5で作成した移行プロジェクトの詳細画面にて、「レプリケート」ボタンをクリックします。
image.png

「レプリケート」をクリックします。
image.png

レプリケーション作業が開始しました。
image.png

レプリケーションが完了すると、移行プロジェクトの「作業リクエスト」欄に表示される「移行のレプリケート中」操作のステータスが「成功」になります。
image.png

「移行のレプリケート中」操作の詳細画面です。20分ちょっとで作業が完了しました。
image.png

レプリケーションを実行したことにより作成されたものを確認していきます。
レプリケーションの実行に必要なインスタンスとして、以下２つのインスタンスがOCMによって自動的に立ち上げられます。
① vanilla-instance：ブートボリュームを生成するためだけに起動され、ボリュームを生成できたらすぐに終了されるインスタンス　
② HydrationAgent：EBS Direct APIを実行し、ブートボリュームにEBSからデータを書き込むインスタンス
Migrationコンパートメントに２つのインスタンスが起動され、レプリケーション作業の終了とともに自動でTerminateされていました。HydrationAgentの方はレプリケーション完了後もしばらく数十分稼働したままでしたがやがて停止しました。
image.png

7. 移行プランの実行

移行プランからリソースマネージャのスタックを作成し、デプロイすることでターゲットのインスタンスを作成していきます。

【任意の作業】インスタンスのネットワーク設定の変更

スタックを作成する前に、デフォルトだとインスタンスにパブリックIPが付与されないので、事前にインスタンスのネットワーク設定を変更していきます。そのためにターゲット・アセットの構成を変更します。
移行プランの「ターゲット・アセット」欄をクリックし、移行対象とする移行アセットにチェックを入れます。
image.png

チェックを入れた状態で、[アクション]>[構成]をクリックします。
image.png

内容を更新したいプロパティを選択します。今回はサブネットを選択します。
image.png
ネットワーク配置をパブリックサブネットとした上で、パブリックIPアドレスについて「パブリックIPv4アドレスの割り当て」にチェックを入れます。デフォルトでは割り当てない設定となっています。
承認事項にチェックを入れた上で、「構成」をクリックします。
image.png
構成が上書きされました。
image.png

スタックの生成

まずはスタックを生成します。移行プラン詳細画面から「RMSスタックの作成」をクリックします。
image.png

「RMSスタックの生成」をクリックします。
image.png

作業が開始されました。
image.png

およそ１０分弱でスタックの生成が完了しました。
image.png

生成されたスタックは、リソース・マネージャにて確認できます。
OCIコンソールのメニューより、[開発者サービス]>[リソース・マネージャ]>[スタック]をクリックすると、一覧表示されます。
image.png

スタックのデプロイ

生成されたスタックを使い、スタックをデプロイします。
移行プラン詳細画面から「RMSスタックのデプロイ」をクリックします。
image.png

「RMSスタックのデプロイ」をクリックすると、スタック内にジョブが作成され、実行されます。
image.png

ジョブの実行状況については、スタック内の「ジョブ」欄を確認します。
「成功」と表示され、無事に実行が完了しました。
image.png

ジョブの詳細画面では、実行ログの確認も可能です。
image.png
image.png

ジョブの実行ログの内容
2025/02/09 06:30:29 [[INFO]] Getting providers from registry and/or custom terraform providers
2025/02/09 06:30:29 [[INFO]] 
2025/02/09 06:30:29 [[INFO]] Initializing provider plugins...
2025/02/09 06:30:29 [[INFO]] - Finding latest version of hashicorp/oci...
2025/02/09 06:30:29 [[INFO]] - Installing hashicorp/oci v6.25.0...
2025/02/09 06:30:29 [[INFO]] - Installed hashicorp/oci v6.25.0 (unauthenticated)
2025/02/09 06:30:29 [[INFO]] 
2025/02/09 06:30:29 [[INFO]] Terraform has created a lock file .terraform.lock.hcl to record the provider
2025/02/09 06:30:29 [[INFO]] selections it made above. Include this file in your version control repository
2025/02/09 06:30:29 [[INFO]] so that Terraform can guarantee to make the same selections by default when
2025/02/09 06:30:29 [[INFO]] you run "terraform init" in the future.
2025/02/09 06:30:29 [[INFO]] 
2025/02/09 06:30:29 [[INFO]] Terraform has been successfully initialized!
2025/02/09 06:30:29 [[INFO]] 
2025/02/09 06:30:29 [[INFO]] You may now begin working with Terraform. Try running "terraform plan" to see
2025/02/09 06:30:29 [[INFO]] any changes that are required for your infrastructure. All Terraform commands
2025/02/09 06:30:29 [[INFO]] should now work.
2025/02/09 06:30:29 [[INFO]] 
2025/02/09 06:30:29 [[INFO]] If you ever set or change modules or backend configuration for Terraform,
2025/02/09 06:30:29 [[INFO]] rerun this command to reinitialize your working directory. If you forget, other
2025/02/09 06:30:29 [[INFO]] commands will detect it and remind you to do so if necessary.
2025/02/09 06:30:32 [[INFO]] oci_core_instance.ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoias7y4ge3o5qarmnioedslpdbrnbpock5tuugiwmoklsjq: Creating...
2025/02/09 06:30:42 [[INFO]] oci_core_instance.ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoias7y4ge3o5qarmnioedslpdbrnbpock5tuugiwmoklsjq: Still creating... [10s elapsed]
2025/02/09 06:30:52 [[INFO]] oci_core_instance.ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoias7y4ge3o5qarmnioedslpdbrnbpock5tuugiwmoklsjq: Still creating... [20s elapsed]
2025/02/09 06:30:58 [[INFO]] oci_core_instance.ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoias7y4ge3o5qarmnioedslpdbrnbpock5tuugiwmoklsjq: Creation complete after 26s [id=ocid1.instance.oc1.ap-tokyo-1.anxhiljrcxq6uwyc6fhztcybwft5ltfwe6zqhgw7t6fhyqkdifb54i22s5za]
2025/02/09 06:30:59 [[INFO]] 
2025/02/09 06:30:59 [[INFO]] Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
2025/02/09 06:30:59 [[INFO]] 
2025/02/09 06:30:59 [[INFO]] Outputs:
2025/02/09 06:30:59 [[INFO]] 
2025/02/09 06:30:59 [[INFO]] ocid1_ocmtargetasset_oc1_ap-tokyo-1_amaaaaaa556ckoias7y4ge3o5qarmnioedslpdbrnbpock5tuugiwmoklsjq-id = "ocid1.instance.oc1.ap-tokyo-1.anxhiljrcxq6uwyc6fhztcybwft5ltfwe6zqhgw7t6fhyqkdifb54i22s5za" 
2025/02/09 06:30:59 [[INFO]]

8. 移行されたインスタンスへの接続確認

作成されたインスタンスを確認します。
OCIコンソールのメニューより、[コンピュート]>[コンピュート]>[インスタンス]をクリックし、インスタンス一覧を見ます。
Rockyインスタンスが作成されています。
image.png

作成されたインスタンスの詳細を確認します。
image.png
image.png

生成されたパブリックIPを使って、ターゲットインスタンスにアクセスします。
image.png

はじめに作成したtestファイルも確認できました。

ターゲットインスタンス上でのテスト
Using username "rocky".
Authenticating with public key "rsakey"
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Sun Feb  9 04:57:04 2025 from 49.98.165.32
[rocky@ec2-rockey ~]$ ls
test
[rocky@ec2-rockey ~]$
[rocky@ec2-rockey ~]$
[rocky@ec2-rockey ~]$ uname -r
4.18.0-513.5.1.el8_9.x86_64
[rocky@ec2-rockey ~]$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="8.9 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.9"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.9 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2029-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-8"
ROCKY_SUPPORT_PRODUCT_VERSION="8.9"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.9"
[rocky@ec2-rockey ~]$

【補足】
Amazon Linux OSで稼働するEC2をOCIコンピュートに移行する場合、デフォルトでインストールされているモジュールの違いにより接続が成功しない場合があるようです。具体的には、OCIではホストカーネルに接続するインターフェイスに「virtio_scsi」モジュールを使用しているがこれはAmazon Linuxには入っていないため、OCMを使ってOCIに移行する場合には事前に移行元のEC2インスタンスにこのモジュールをインストールの上実行する必要があるとのことです。Rocky Linuxにはデフォルトでインストールされていたため、問題なく接続できました。

Rocky Linux上でvirtio_scsiモジュールの有無を確認
[rocky@ip-10-0-7-232 ~]$ find /usr/lib | grep virtio_scsi
/usr/lib/modules/4.18.0-513.5.1.el8_9.x86_64/kernel/drivers/scsi/virtio_scsi.ko.xz

9. 移行の完了

移行が無事に完了できたら、移行プロジェクトにて「移行完了とマーク」をクリックします。
image.png

移行プロジェクトが完了済みのステータスに切り替わります。
image.png

移行が完了しました。

まとめ

今回はOracle Cloud Migrationsを使い、EC2からOCIインスタンスへの移行を検証しました。
筆者は特に詰まることなく、最後までスムーズ実行できました。
本記事がご参考になれば幸いです！

35
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
35
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?