我有一个VMware VM，其操作系统原始磁盘已备份到AWS S3。我可以使用AMI从操作系统磁盘创建import-image。我不能每次都使用import-image，因为它非常慢，因为我正在创建一个应用程序，您可以将VM备份到AWS云，其中第一个备份将是FULL备份，这将是需要更长时间，但随后的INCREMENTAL备份应该花费更少的时间（取决于更改的数据量）。我在每次备份期间创建AMI，即FULL或INCREMENTAL备份。
因此，可以解释的是，FULL备份需要时间，但对于INCREMENTAL，它应该花费更少的时间。
问题是，在增量备份期间从RAW数据创建AMI时，AWS不知道在FULL备份期间已经创建了AMI（以及相应的EBS快照），应该使用（或比较）查找数据更改的最新数据，因此应仅从更改的数据中创建AMI，这将花费更少的时间。
所以，我有以下选择：
1）import-snapshot API =将原始操作系统磁盘转换为EBS snapshot文件。
2）复制操作系统磁盘数据=创建EBS volume并将其附加到正在运行的EC2 instance。然后将所有OS磁盘原始数据复制到卷。然后从EBS volume创建快照。从EBS snapshot开始，我们可以创建AMI。
我尝试了这两个选项，但每当我尝试从EC2 instance启动AMI时，我都会收到以下错误：
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0)
通过各种论坛后，我发现如果从快照创建AMI时AKI和ARI不匹配，则会出现上述错误。正确的AKI和ARI是从创建快照的源EC2实例获取的（正如AWS所期望的那样）。
就我而言，我没有从正在运行的EC2 instance创建快照，而是从VMWare VM OS磁盘创建快照。
我发现import-image API在创建AMI时也会创建快照。因此，我使用选项-1和选项-2比较了import-image创建的快照和我创建的快照。
我比较了/boot/中的文件列表及其md5sum。我发现AWS import-image API创建的快照有＆＃34; initramfs-3.10.0-327.36.3.el7.x86_64.img.vmimport ＆＃34;文件并修改了/ boot / grub2目录中的许多文件。
根据AWS文档，https://docs.aws.amazon.com/vm-import/latest/userguide/vm-import-ug.pdf， AWS修改文件系统： - 直接在操作系统中安装Citrix PV驱动程序或修改initrd / initramfs以包含它们， - 修改/ etc / fstab， - 修改grub引导加载程序设置，例如默认条目和超时。
那么，我是否还需要对我的EBS卷进行上述更改？如何进行这些更改（代码，脚本，工具等）？
如果有人，请建议任何更好的选择。
我探究了Packer，但发现它需要source_ami来创建AMI，因此不适用于我，因为我没有从源AMI创建AMI，如果我错了请纠正我。