手动从OS磁盘EBS卷创建AMI所需的更改

Sub*_*bbu 7 bootable amazon-ec2 amazon-web-services aws-ebs amazon-ami

我有一个VMware VM其OS原始磁盘备份到AWS S3.我可以AMI从OS盘创建使用import-image.我不能import-image每次都使用,因为它非常慢,因为我正在创建一个应用程序,您可以将VM备份到AWS云,其中第一个备份将是FULL备份,这需要更长时间,但后续INCREMENTAL备份应该花费更少的时间(取决于数据量已更改).我在每次备份期间创建AMI,即FULL或INCREMENTAL备份.

因此,可以解释的是,FULL备份需要时间,但对于INCREMENTAL,它应该花费更少的时间.

问题是,在增量备份期间从RAW数据创建AMI时,AWS不知道在FULL备份期间已经创建了AMI(以及相应的EBS快照),应该使用(或比较)最新数据来查找数据更改因此,应仅从更改的数据中创建AMI,这将花费更少的时间.

所以,我有以下选择:

1)import-snapshotAPI =将原始操作系统磁盘转换为EBS snapshot文件.

2)复制OS磁盘数据=创建EBS volume并将其附加到正在运行的磁盘上EC2 instance.然后将所有OS磁盘原始数据复制到卷.然后从中创建快照EBS volume.从EBS snapshot,我们可以创造AMI.

我尝试了两种选择,但每次尝试从中启动EC2 instanceAMI,都会出现以下错误:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0)
Run Code Online (Sandbox Code Playgroud)

通过各种论坛会后,我才知道,如果有错配出现上述错误AKI,并ARI同时从快照创建AMI.正确的AKI和ARI是从创建快照的源EC2实例中获取的(因为这是AWS所期望的).

就我而言,我没有从正在运行EC2 instance但从VMWare VM OS磁盘创建快照.

我发现import-imageAPI在创建AMI时也会创建快照.因此,我比较了import-image创建的快照和我使用option-1和option-2创建的快照.

我比较了文件列表/boot/和他们的md5sum.我发现AWS import-imageAPI 创建的快照有" initramfs-3.10.0-327.36.3.el7.x86_64.img.vmimport "文件,并修改了/ boot/grub2目录下的许多文件.

根据AWS文档https://docs.aws.amazon.com/vm-import/latest/userguide/vm-import-ug.pdf,AWS修改文件系统: - 直接在OS中安装Citrix PV驱动程序或修改initrd/initramfs包含它们, - 修改/ etc/fstab, - 修改grub引导加载程序设置,例如默认条目和超时.

那么,我是否还需要对我的EBS卷进行上述更改?如何进行这些更改(代码,脚本,工具等)?

如果有人,请建议任何更好的选择.

我探索Packer但发现它需要source_ami来创建AMI,因此不适用于我,因为我不是从源AMI创建AMI,如果我错了请纠正我.