189 8069 5689
Created by
一，实验环境
从微软Azure云,迁移到AWS
主机A 操作系统CentOs6.9 内核vmlinuz-2.6.32-696.3.2.el6.x86_64
本地虚拟主机B操作系统CentOs6.9 内核vmlinuz-2.6.32-696.el6.x86_64
保证两个主机内核版本一定要一致，如果不一致的话最好可以用yum把两个内核更新到一致的版本，这次我迁移的时候才发现两个内核版本不一致。解决方法如下
二，实验步骤
1. 在本地准备好和要迁移的主机操作系统一样的虚拟主机B，最小化安装就可以，我这里用的是VMware，开机快速按F2，进入BIOS模式，选择如下图，
2. 进入救援模式
3. 选择语言
4. 选择键盘
5. 配置网络确保能够连上你要迁移的主机
6. 因为是要迁移主机上所有的数据到本地虚拟机，所以，这边要选择跳过，选择继续的话，系统会挂载你的磁盘，这样，你就不好格式化根分区，所以选择Skip
7. 进入到bash终端
8. 配置ssh
ssh-keygen -t rsa
确保能够免密登陆要被克隆的主机。
9. 我这里本地虚拟机分了两个分区/dev/sda1 mount on /boot 和 /dev/sda2 mount /
在bash里我创建了个目录 /backup 并且把/dev/sda2 挂载到了这上边，一定要确保在挂载之前/dev/sda2没有其他的挂载
挂载好以后，删除/backup 目录里的所有东西，从新格式化/dev/sda2也可以,但是不建议，因为格式化完以后也需要挂载，而且格式化磁盘容易出错。
10. 准备工作完成后我们开始同步数据，这里我使用的是dump/restore
ssh Azure@targetPC dump -0 -f - / | restore -r -f -
这里targetPC是你目标电脑的IP地址。参数“-0”表示完全备份，“-f-”表示使用stdin/stdout做为文件描述符，而“-r”意思是指示restore去重新创建通过网络传送的文件系统到目标电脑上去。更多内容请参考dump(8) 和 restore(8)。下面你看到的是传送主文件系统的输出。
开始后会显示：
DUMP: Date of this level 0 dump: Tue Feb 22 15:50:12 2005
DUMP: Dumping /dev/hda3 (/) to standard output
DUMP: Label: debian
DUMP: Writing 10 Kilobyte records
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 547312 blocks.
DUMP: Volume 1 started with block 1 at: Tue Feb 22 15:50:14 2005
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Volume 1 completed at: Tue Feb 22 15:51:43 2005
DUMP: Volume 1 546590 blocks (533.78MB)
DUMP: Volume 1 took 0:01:29
DUMP: Volume 1 transfer rate: 6141 kB/s
DUMP: 546590 blocks (533.78MB)
DUMP: finished in 89 seconds, throughput 6141 kBytes/sec
DUMP: Date of this level 0 dump: Tue Feb 22 15:50:12 2005
DUMP: Date this dump completed: Tue Feb 22 15:51:43 2005
DUMP: Average transfer rate: 6141 kB/s
DUMP: DUMP IS DONE
Restore通常会创建一个名叫restoresymtable的文件，如果你确信在文件系统重建过程中没有错误发生，你可以将这个文件删掉。完成主文件系统的复制，下面我们依次完成其他子分区的复制。从/usr开始吧(假定你现在的工作目录是未来的主文件系统)。
11. 数据拉取下来以后，由于云上的主机是都在一个分区，所以，直接dump / 会把系统数据全部来下来，如果还有其他挂载磁盘，直接拷贝，或者用上边dump方法都可以。
12. 我这里两台主机内核不一致，我把 从A主机拉取下来的 boot/vmlinuz-2.6.32-696.3.2.el6.x86_64 直接覆盖掉vmlinuz-2.6.32-696.el6.x86_64，但是文件名字还是vmlinuz-2.6.32-696.el6.x86_64
和initramfs-2.6.32-696.3.2.el6.x86_64.img 覆盖掉initramfs-2.6.32-696.el6.x86_64.img 文件名还保持initramfs-2.6.32-696.el6.x86_64.img，不变
13. 设置开机自动挂载，注意这个文件是从A主机拉取下来的，所以要把磁盘挂载情况搞清楚。本地的磁盘还是和以前的一样挂载，我这边就改了两个UUID。
15. 然后reboot，Azure云主机应该是会带一个walinuxagent的东西，启动的时候会报错，由于内核发生变化kdump也会发出警告，而且每次开机重启都会更新，进去以后把他们都关掉。
这样还不能直接导出OVA，然后上传到AWS做成AMI，可能是内核发生改变的原因，我试了好几次，浪费了不少时间，会报ClientError: Multiple different grub/menu.lst files found，这个错。然后我又从在本地最小化安装了新的虚拟机C，这次在这里边先yum update ，升级kernel，并设置开机优先使用，把主机B的kernel也调成一样的，这样在把B的主机同步到C主机，这次boot直接用本地的就可以。做好以后确定数据，机器没问题就可以导出OVA啦，然后在用生成的vmdk文件导入AWS制作成AMI，就可以在云上开心的使用啦。
aws ec2 import-image --description "CentOs6.9 VMDK" --license-type BYOL --disk-containersfile://H:1.json
1.json