VMWare仮想マシンをVM Importを使用してEC2に移行し、差分を確認してみる。
ハジメマシテ。hayakawaです。
ハジメテのブログなので、胡散臭い固有名詞とか拙い日本語はご容赦ください。
それでは、ハジメテのブログテーマとして、AWSの「VM Import」を使用して
VMWare上の仮想マシンをEC2へ移行したらOS上でどんな変化が起こるのだろう？
という所にスポットを当てていきたいと思います。
(実にオンプレ脳の考え方ですね)
VM Importとは？
仮想化環境(VMWare/Hyper-V/Xen)上で動作する仮想マシン(VM)を、AMIとしてインポートするサービスとなります。
本記事では、以下について確認していきます。
・VMWare仮想マシン(以下VM)を、AWS EC2(以下EC2)への移行手順
(今回はCentOS7.6を移行対象とします)
・移行前(VM)、移行後(EC2)の設定ファイルを比較し、変更箇所を確認
確認に使用した環境は以下となります。
移行時の注意点
移行時の注意点を公式から抜粋し、本環境への対応について記載します。
他にも色々注意点があるので、公式をご確認ください。
【公式】ext2、ext3、ext4、Btrfs、JFS、XFS ファイルシステムを使用してフォーマットされた、MBR パーティション分割ボリュームをサポート。
【対処】/bootは xfsでフォーマット(CentOS7デフォルト)し、/ パーティションは、LVM内にxfsで作成。
【公式】Linux オペレーティングシステムは BYOL ライセンスのみをサポートします。
【対処】CentOSのため、ライセンスの考慮は不要。
【公式】UEFI/EFI ブートパーティションは、イメージ形式として VHDX を使用する Windows ブートボリュームでのみサポートされています。
【対処】VMのプロパティでBIOSを設定。
【公式】インポートされた Linux VM は 64 ビットイメージを使用する必要があります。
【対処】CentOS7.6 64bitイメージを使用。
【公式】インポートされた Linux VM では、最良の結果を得るためにデフォルトのカーネルを使用してください。
【対処】yum updateにてkernelおよびパッケージのマイナーアップデートを実施。kernelの手動リビルドは実施しない。
【公式】現在、複数のネットワークインターフェイスはサポートされていません。インポート後、VM にはアドレスの割り当てに DHCP を使用する 1 つの仮想ネットワークインターフェイスが与えられます。
【対処】NICはシングル構成とし、DHCPに設定済み。
【公式】インターネットプロトコルバージョン 6 (IPv6) の IP アドレスはサポートされていません。
【対処】IPv6はNICの設定で無効化。ただし、カーネルレベルでの無効化は未実施。
【公式】VMware VM から VMware Tools をアンインストールします。
【対処】open-vm-toolsを使用しているため、アンインストールはしない。
※揚げ足を取るようですが、VMWare Toolsと書かれているため。
【公式】あらゆる (仮想または物理) CD-ROM ドライブを切断します。
【対処】エクスポート前にドライブの設定を確認。
【公式】リモートアクセスの Secure Shell (SSH) を有効にします。
【対処】パスワードおよびrootユーザログインを有効化。(AWS的には非推奨、テストなので許してください)
【公式】ホストのファイアウォール (Linux iptables など) で SSH へのアクセスが許可されていることを確認します。
【対処】firewalldを停止および、自動起動を無効化。
VMからEC2へ移行してみる
移行手順
～手順概要～
手順１：VMをOVF形式でエクスポート
手順２：OVFをS3にアップロード
手順３：ロールの作成
手順４：OVF(VMDK)からAMIへインポート
手順５：AMIからEC2の登録
～手順詳細～
手順１：VMをOVF形式でエクスポート
1-1. vSphere Clinetから対象VMを選択し、「ファイル」→「エクスポート」→「OVFテンプレートエクスポート」を選択。名前とフォルダを指定します。
※ドキュメント上では、OVAについても対応している記載がありますが、今回はOVF形式でエクスポートします。
手順２：OVFをS3にアップロード
2-1. S3にバケットを作成する。すでにあるバケットを使用する場合は、作成不要です。
(作成方法は省略します)
2-2. バケットにVMをエクスポートした際に作成されたフォルダごとアップロードします。
以下は本手順で格納した際のイメージです。
vmdk以外は不要な気がしますが、不明のためフォルダごとアップロードしています。
手順３：ロールの作成
3-0. (前提)AWS CLIが使用可能なことを前提に記載しているので、AWS CLIを使用したことがない場合、または利用できない場合は、以下URIを参考にAWS CLIを利用可能な状態にする必要があります。
(URI:https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-configure.html)
3-1. AWS CLIが利用可能となるマシン(今回は踏み台EC2(Amazon Linux2))上で、ロール設定を定義したファイル(/tmp/trust-policy.json)を作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "vmie.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals":{
"sts:Externalid": "vmimport"
}
}
}
]
}
3-2. 続いてAWS CLIコマンドにて、上記で定義したファイルを参照し、ロールを作成します。
aws iam create-role --role-name vmimport --assume-role-policy-document "file:///tmp/trust-policy.json"
3-3. 次にロールのポリシーを定義したファイル(/tmp/role-policy.json)を作成します。
※バケット名やフォルダ名は環境に合わせ適宜修正してください。
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource":[
"arn:aws:s3:::バケット名",
"arn:aws:s3:::バケット名/*"
]
},
{
"Effect":"Allow",
"Action":[
"ec2:ModifySnapshotAttribute",
"ec2:CopySnapshot",
"ec2:RegisterImage",
"ec2:Describe*"
],
"Resource":"*"
}
]
}
3-4. 上記で定義したファイルを参照し、ロールにポリシーをアタッチします。
aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document "file:///tmp/role-policy.json"
作成したロールおよびポリシーについては、AWSコンソールから参照可能となります。
手順４：OVF(VMDK)からAMIへインポート
4-1. それでは、OVF(VMDK)をインポートする準備ができたので、実際にインポートする準備をします。まずはインポートするためのタスクを記載したファイル(/tmp/containers.json)を作成します。
※バケット名やフォルダ名は環境に合わせ適宜修正してください。
[
{
"Description": "First disk",
"Format": "vmdk",
"UserBucket": {
"S3Bucket": "バケット名",
"S3Key": "フォルダ名/インポート対象VMDK"
}
}
]
例）
"Description": "First disk",
"Format": "vmdk",
"UserBucket": {
"S3Bucket": "vmtoec2ovfbucketXXXXXXXX",
"S3Key": "vm-ec2/vm-ec2-disk1.vmdk"
4-2. 上記で定義したファイルを読み込み、インポートを実施します。
aws ec2 import-image --description "vmec2mig" --disk-containers "file:///tmp/containers.json"
4-3. インポートタスクが完了するまで時間がかかるので、気長に待ちます。
以下のコマンドを発行することで、インポートステータスを確認することができます。
定期的にコマンド発行して何をやっているのかを見るのも楽しいですよ。
※インポートタスクIDについては、インポートを実施した際に表示されています。
aws ec2 describe-import-image-tasks --import-task-ids インポートタスクID
4-4. “Status”が”completed”になれば、インポートが完了です。
AWSコンソールのAMIから確認ができます。
手順５：AMIからEC2の登録
5-1. AWSコンソールからインポートしたAMIを選択し、「起動」を選択すると、
EC2の設定画面が開くので、各設定を完了するとEC2として登録されます。
5-2. 登録されたEC2を起動して、ログインしましょう。
ログインできない場合は、ネットワークACLやセキュリティグループを確認してみてください。
それでもログインできない場合は、移行前のssh設定等を確認です。
設定ファイル比較
みなさんお待ちかねの設定比較です。
設定比較については、以下の観点で比較しています。
※すべてを網羅することはめんどく・・・大変なので、OSに関わりそうなところだけを抽出しています。
～設定ファイル比較概要～
/etc を`ls -alR`で取得して、差分の出たファイルを比較する。
エクスポート前に設定変更したファイルの変更確認
インポート後に設定変更されたファイルの変更確認
個人的に重要と思われるコマンドを比較する。
システム関連のコマンド(getenforce / uname -a)
ディスク関連のコマンド(pvscan / vgscan / lvscan / fdisk -l)
ネットワーク関連のコマンド(ip a / ip r)
パッケージ関連のコマンド(rpm -qa / systemctl -get-default / systemctl -list-unit-files)
～設定ファイル比較結果～
・エクスポート前に設定変更したファイルの変更確認
/etc/ssh/sshd_config
(変更なし)rootログイン許可、パスワードログイン許可のまま
/etc/selinux/config
(変更なし)disabled
・インポート後に設定変更されたファイルの変更確認
/etc/default/grub
オリジナルファイルは、”grub-bkup”としてバックアップされています。
(追記)console=ttyS0
(修正)GRUB_TIMEOUT=5 → 30
移行前の状態
GRUB_TIMEOUT=5 GRUB_CMDLINE_LINUX="rd.lvm.lv=vg00/root rd.lvm.lv=vg00/swap rhgb quiet"
移行後の状態
GRUB_TIMEOUT=30 GRUB_CMDLINE_LINUX="rd.lvm.lv=vg00/root rd.lvm.lv=vg00/swap rhgb quiet console=ttyS0"
/etc/fstab
オリジナルファイルは、”fstab.orig”としてバックアップされています。
(修正)スペース数が変更され、内容の変更はありません。
※公式によると不要な行はコメントアウトされるようです
/etc/pam.d/vmtoolsd
(削除)”vmtoolsd”ファイルが削除されています。
/etc/resolv.conf
(修正)DHCP割り当てによって自動更新されています。
/etc/rc.local
デフォルト値を使用していたので変更はありませんが、
”rc.local.vmimport”ファイル作成され、タイムスタンプが更新されていたいので、書き換えられる可能性があります。
/etc/sysconfig/network
(追記)NETWORKING=yes
/etc/sysconfig/network-script/ifcfgファイル
IF名が変更されたため、設定ファイルが変更されています。
(リネーム)ifcfg-ens160 ＞ vmimport.ifcfg-ens160
(新規)ifcfg-eth0
(新規)vmimport.ifcfg-eth0
新規作成された「ifcfg-eth0」はこちら
# Automatically generated by the vm import process DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp TYPE=Ethernet NM_CONTROLLED=no
/etc/vmware-tools/
(削除)ディレクトリ内部に存在するフォルダ/ファイルを削除されています。
～コマンド比較結果～
システム関連のコマンド(getenforce / uname -a)
(変更なし)
ディスク関連のコマンド(pvscan / vgscan / lvscan / fdisk -l)
(変更)デバイス名が”sda”から”xvda”に変更されています。
移行前の状態(fdisk -l)
デバイス ブート 始点 終点 ブロック Id システム /dev/sda1 * 2048 2099199 1048576 83 Linux /dev/sda2 2099200 15736831 6818816 8e Linux LVM
移行後の状態(fdisk -l)
デバイス ブート 始点 終点 ブロック Id システム /dev/xvda1 * 2048 2099199 1048576 83 Linux /dev/xvda2 2099200 15736831 6818816 8e Linux LVM
ネットワーク関連のコマンド(ip a / ip r)
(ip a 変更)IF名がens160からeth0修正
(ip a 変更)MTUが1500から9001に修正
(ip a 変更)MACの修正
(ip a 変更)IPの修正
(ip r 追加)link local address
(ip r 変更)デフォルトゲートウェイ
移行前の状態(ip a)
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
移行後の状態(ip a)
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
移行前の状態(ip r)
default via 192.168.31.1 dev ens160 proto dhcp metric 100 192.168.31.0/24 dev ens160 proto kernel scope link src 192.168.31.103 metric 100
移行後の状態(ip r)
default via 192.168.1.1 dev eth0 169.254.0.0/16 dev eth0 scope link metric 1002 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.197
パッケージ関連のコマンド(rpm -qa / systemctl -get-default / systemctl -list-unit-files)
(rpm -qa 削除)open-vm-tools
(systemctl -list-unit 削除)session-2.scope , vgauthd.service ,vmtoolsd.service
まとめ
ディスクデバイス名や、eth名が変わることに衝撃を受けました。
(Cent7でeth名をethXに変えるのは面倒だと聞いていたので)
移行する手順はシンプルなので、アプリケーションやサービスを意識しなければ
簡単に移行することが可能な便利なツールだと思います。
ただ、デバイス名やeth名が変更されるとなると、
アプリケーションやサービスで名前で参照されていないか注意が必要ですね。
なので、業務影響がないVMをAWSに移行して使い勝手を見てみよう！
程度な使用感がいいかもしれませんね。
ちなみに、cloudinitファイルは作成されていなかったので
起動毎に設定が戻るという事はなさそうです。
