Changes required to create AMI from OS disk EBS volume manually

Question

I have a VMware VM whose OS raw disk is backed up to AWS S3. I can create AMI from the OS disk raw using import-image. I cannot use import-image everytime because it is extremely slow and because I am creating an application where you can backup your VM to AWS cloud, where in the first backup will be FULL backup which will take longer, but the consequent INCREMENTAL backup should take very less time(depending on the amount of data changed).I am creating AMI during every backup i.e. FULL or INCREMENTAL backup.

Hence, it is OK and explainable that FULL backup is taking time but for INCREMENTAL it should take less time.

The problem is, while creating AMI from RAW data during incremental backup, AWS is not aware that there is already an AMI (and also corresponding EBS snapshot) created during FULL backup which should be used(or compared) with latest data to find data changes and hence should create AMI out of the changed data only, which will in turn take less time.

So, I have following options :

1) import-snapshot API = converts the raw OS disk to EBS snapshot file.

2) copy OS Disk data = create a EBS volume and attach it to a running EC2 instance. Then copy all OS disk raw data to the volume. Then create snapshot from the EBS volume. From the EBS snapshot, we can create AMI.

I have tried both options but everytime I try to launch EC2 instance from the AMI, I get below error :

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

After going through various forums, I came to know that the above error occurs if there is mismatch in AKI and ARI while creating AMI from snapshot. Correct AKI and ARI is fetched from source EC2 instance from which the snapshot is created (as this is expected by AWS).

In my case, I have not created snapshot from a running EC2 instance but from a VMWare VM OS disk.

I figured out that import-image API also creates snapshots while creating AMI. So, I compared the snapshot created by import-image and the snapshot created by me using option-1 and option-2.

I compared the list of files in /boot/ and their md5sum. I found out the snapshot created by AWS import-image API has "initramfs-3.10.0-327.36.3.el7.x86_64.img.vmimport" file and has modified many files in /boot/grub2 directory.

As per AWS documentation, https://docs.aws.amazon.com/vm-import/latest/userguide/vm-import-ug.pdf, AWS modifies filesystem : - installs Citrix PV drivers either directly in OS or modifies initrd/initramfs to contain them, - modifies /etc/fstab, - modifyies grub bootloader settings such as the default entry and timeout.

So, do I need to do above changes in my EBS volume as well ? How to do these changes (code, script, tool, etc) ?

Please suggest any better option if someone has.

I explored Packer but found out that it needs source_ami to create AMI, hence not applicable to me as I am not creating AMI from source AMI, Please correct me if I am wrong.

Mukden

"it is extremely slow" One assumes that this is because there is a large amount of work to do, and if you try to do it yourself, you are likely to find that it is still slow, for the same reasons. Creating a new volume from raw data, then snapshotting that volume, as is necessary in this process (launching an instance requires an AMI, and creating an AMI requires a snapshot), can take a significant number of hours. – Ingot

@Michael-sqlbot, I have edited my question to show how it is acceptable for FULL backup that AMI creation is taking lot of time, but not for INCREMENTAL backup. – Mukden

@Eric Hammond, Can you please check this ? I have seen various answers from you on AWS forums and stackoverflow, and your website Alestic regarding similar cases. – Mukden

can you confirm the volume types of your VMs are MBR-partitioned volumes that are formatted using the ext2, ext3, ext4, Btrfs, JFS, or XFS file system? Because GUID Partition Table (GPT) partitioned volumes are not supported by vm-import. – Babushka

Yes, my volume type is MBR. – Mukden