CentOs6.9跨云主机整体系统迁移

最新推荐文章于 2024-07-07 07:45:54 发布

chunli8262

最新推荐文章于 2024-07-07 07:45:54 发布

阅读量444

点赞数

文章标签：运维 json 操作系统

原文链接：https://my.oschina.net/u/3571652/blog/1554419

版权

CentOs6.9跨云主机整体系统迁移

Created by 战斗的小涵

2017-10-22

一，实验环境

从微软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-containers file://H:\1.json

1.json