発端
KVMのCentOS 5！の仮想マシンをEC2にマイグレーションしたいという案件があったのでAWS VM Import/Exportを試してみた。
VMDKやVHDに限らず、実はRAWであれば対応してるので、KVMのフォーマットさえ合えばいけるはず。
モノ
渡されたのはAccount情報も設定も知らされずに、まるっとイメージだけ。
$ ls -alh XX-WEB01.img
-rw-rw-r-- 1 ec2-user ec2-user 16G Aug 13 09:26 XX-WEB01.img
はあ、そうですか。。
マイグレーション
さて、気を取り直して移行を試す事に。
準備
- テンポラリー領域のs3 bucket
aws s3api create-bucket --bucket my bucket --create-bucket-configuration LocationConstraint=ap-northeast-1
- 作業用EC2 instance
今回はAWS系のツールが既に入っているAmazon Linux
Import
awscliは対応してないっぽいので、ec2-api-toolsでimport。ディスクやinstance sizeは少し大きめに。
$ ec2-import-instance RR-WEB01.img -f RAW -p Linux -t m3.xlarge -a x86_64 -b mybucket -s 20 GiB -o AKIXXXXX -w SECRETKEYXXXXX --region ap-northeast-1`
WARNING: Ignoring extra parameter(s): [ GiB ]
WARNING: Ignoring extra parameter(s): [ GiB ]
Requesting volume size: 20 GB
TaskType IMPORTINSTANCE TaskId import-i-ffnkny62 ExpirationTime 2015-08-25T12:33:25Z Status active StatusMessage Pending InstanceID i-8e7b5f7b
DISKIMAGE DiskImageFormat RAW DiskImageSize 17179869184 VolumeSize 20 AvailabilityZone ap-northeast-1c ApproximateBytesConverted 0 Status active StatusMessage Pending : Downloaded 0
Creating new manifest at mybucket/847281c9-7afc-40a3-8177-7dc3e5170613/XX-WEB01.imgmanifest.xml
Uploading the manifest file
Uploading 17179869184 bytes across 1639 parts
----------------------------------------------------------------------------------------------------
Upload progress Estimated time Estimated speed
/ 012% [==>..................] 03m 47s 66.451 MBps
ちょっと待ちます。
ステータス確認は
ec2 describe-conversion-tasks --conversion-task-ids import-i-12345678
{
"ConversionTasks": [
{
"ConversionTaskId": "import-i-ffnkny62",
"ImportInstance": {
"InstanceId": "i-12345678",
"Volumes": [
{
"Status": "active",
"AvailabilityZone": "ap-northeast-1c",
"Image": {
"Size": 17179869184,
"ImportManifestUrl": "https://mybucket.s3.amazonaws.com/847281c9-7afc-40a3-8177-7dc3e5170613/XX-WEB01.imgmanifest.xml?AWSAccessKeyId=AKIAXXXXXXXX&Expires=1440516804&Signature=Ob7Q2WJ%2xxXXx4SxbJ9cFChXXXXXXX",
"Format": "RAW"
},
"Volume": {
"Size": 20
},
"BytesConverted": 0,
"StatusMessage": "Pending : Downloaded 14973665280"
}
]
},
"ExpirationTime": "2015-08-25T12:33:25Z",
"State": "active",
"StatusMessage": "Pending"
}
]
}
この変換中の状態がしばらく長く続いて、何やらs3 bucketにデータが入っていく。
$ aws s3 ls s3://mybucket
PRE 847281c9-7afc-40a3-8177-7dc3e5170613/
aws s3 ls mybucket/847281c9-7afc-40a3-8177-7dc3e5170613/
2015-08-18 09:58:00 10485760 XX-WEB01.img.part0
2015-08-18 09:58:00 10485760 XX-WEB01.img.part1
2015-08-18 09:58:00 10485760 XX-WEB01.img.part10
2015-08-18 09:58:14 10485760 XX-WEB01.img.part100
.
.
2015-08-18 10:00:32 10485760 XX-WEB01.img.part998
2015-08-18 10:00:32 10485760 XX-WEB01.img.part999
2015-08-18 09:57:57 1497470 XX-WEB01.imgmanifest.xml
昔懐かしのinstance storeのbundleっぽい感じ。
変換用の領域なんで、実際はEBS instanceが出来上がる。
そして、起動してget system logで見ると
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux: Disabled at runtime.
type=1404 audit(1439903722.869:2): selinux=0 auid=4294967295 ses=4294967295
INIT: version 2.86 booting
Welcome to CentOS release 5.8 (Final)
Press 'I' to enter interactive startup.
時計 (utc) を設定中: 2015年 8月 18日 火曜日 22:15:25 JST [ OK ]
udev を起動中: [ OK ]
標準キーマップ (jp106) を読み込み中: [ OK ]
ホストネームを www.example.com に設定中: [ OK ]
論理ボリューム管理を設定中: 2 logical volume(s) in volume group "VolGroup00" now active
[ OK ]
ファイルシステムを検査中
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/mapper/VolGroup00-LogVol00
/dev/mapper/VolGroup00-LogVol00: clean, 165555/3964928 files, 1659777/3964928 blocks
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/hda1
/boot: clean, 60/26104 files, 43779/104388 blocks
[ OK ]
おお、起動してる！
アクセス
さて、起動はしたけど、アカウントがない状態ではアクセスのしようがないので、中身をいじる。
手順は
- 移行instanceを停止してvolumeをdetach
- 作業用instanceにvolumeをattachし、マウント
- 中身をごにょごにょ
- 作業用instanceからvolumeをアンマウントして、detach
- volumeを移行instanceにattachして、起動
停止
aws ec2 stop-instances --instance-ids i-12345678
volume detach
aws ec2 detach-volume --volume-id vol-aabbccdd
{
"AttachTime": "2015-08-18T14:32:37.000Z",
"InstanceId": "i-12345678",
"VolumeId": "vol-aabbccdd",
"State": "detaching",
"Device": "/dev/sda1"
}
volume attach
aws ec2 attach-volume --volume-id vol-aabbccdd --instance-id i-87654321 --device /dev/sdf
{
"AttachTime": "2015-08-18T14:42:37.806Z",
"InstanceId": "i-87654321",
"VolumeId": "vol-aabbccdd",
"State": "attaching",
"Device": "/dev/sdf"
}
volume describe
$ aws ec2 describe-volumes --volume-id vol-aabbccdd
{
"Volumes": [
{
"AvailabilityZone": "ap-northeast-1c",
"Attachments": [],
"Tags": [
{
"Value": "kvm",
"Key": "Name"
}
],
"Encrypted": false,
"VolumeType": "standard",
"VolumeId": "vol-aabbccdd",
"State": "available",
"SnapshotId": null,
"CreateTime": "2015-08-18T09:58:06.276Z",
"Size": 20
}
]
}
mount
$ sudo vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
$ sudo vgchange -a y
2 logical volume(s) in volume group "VolGroup00" now active
$ sudo mount /dev/VolGroup00/LogVol00 /mnt
unmount
$ sudo umount /mnt
$ sudo vgchange -an VolGroup00
0 logical volume(s) in volume group "VolGroup00" now active
ごにょごにょ
こんな感じに中身を少々いじってみた。
- iptables無効化
cat 'iptables -F' | sudo tee -a /mnt/etc/rc.local
- ssh public keyの追加
sudo vi /mnt/root/.ssh/authorized_keys
- sshの設定を変更
sudo vi /mnt/etc/ssh/sshd_config
PermitRootLogin yes
PasswordAuthentication no
AllowUsers user1 user2 user3 user4 root
他のユーザの権限も分からないので、気持ち悪いけどrootログイン許可。
もちろんSecurity Groupで制限した上で。
結論
動いた。
でも、実は最終的にOSにログインするまで、volumeのattach/detachを繰り返して試行錯誤をしたので時間がかかってしまった。
やれやれ。