我有一个VMware VM其操作系统原始磁盘备份到AWS S3. 我可以AMI使用import-image. 我不能import-image每次都使用，因为它非常慢，而且因为我正在创建一个应用程序，您可以在其中将您的虚拟机备份到AWS云，在第一次备份中FULL备份将需要更长的时间，但随后的INCREMENTAL备份应该花费更少的时间（取决于更改的数据量）。我在每次备份期间创建 AMI，即 FULL 或 INCREMENTAL 备份。
因此，完全备份需要时间是可以解释的，但对于增量备份应该需要更少的时间。
问题是，在增量备份期间从原始数据创建 AMI 时，AWS 不知道在完整备份期间已经创建了一个 AMI（以及相应的 EBS 快照），应该使用（或比较）最新数据以查找数据更改因此应该仅从更改的数据中创建 AMI，这反过来会花费更少的时间。
所以，我有以下选择：
1) import-snapshotAPI = 将原始 OS 磁盘转换为EBS snapshot文件。
2) 复制 OS 磁盘数据 = 创建 aEBS volume并将其附加到正在运行的EC2 instance. 然后将所有操作系统磁盘原始数据复制到该卷。然后从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，则会发生上述错误。从创建快照的源 EC2 实例ARI中获取正确的 AKI 和 ARI （正如 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修改文件系统： - 直接在操作系统中安装 Citrix PV 驱动程序或修改 initrd/ initramfs 以包含它们， - 修改 /etc/fstab， - 修改 grub 引导加载程序设置，例如默认条目和超时。
那么，我是否还需要对我的 EBS 卷进行上述更改？如何进行这些更改（代码、脚本、工具等）？
如果有人有，请提出任何更好的选择。
我探索Packer但发现它需要 source_ami 来创建 AMI，因此不适用于我，因为我不是从源 AMI 创建 AMI，如果我错了，请纠正我。