У меня есть VMware VM, чей диск ОС копируется в AWS S3.Я могу создать AMI из необработанного диска ОС, используя import-image.Я не могу использовать import-image каждый раз, потому что он очень медленный и потому что я создаю приложение, в котором вы можете сделать резервную копию вашей виртуальной машины в AWS облаке, где в первой резервной копии будет FULL резервная копия, которая займет больше времени, но в результатеINCREMENTAL Резервное копирование должно занимать очень мало времени (в зависимости от объема измененных данных). Я создаю AMI при каждом резервном копировании, т.е. ПОЛНОЕ или НЕПРАВИЛЬНОЕ резервное копирование.
Следовательно, все в порядке и объяснимо, что ПОЛНОЕ резервное копирование требует времени, но для НЕПРАВИЛЬНОГО это должно занимать меньше времени.
Проблема заключается в том, что при создании AMI из данных RAW во время инкрементного резервного копирования AWS не знает, что уже существует AMI (а также соответствующий моментальный снимок EBS), созданный во время полного резервного копирования, который следует использовать (илипо сравнению с последними данными, чтобы найти изменения данных и, следовательно, следует создавать AMI только из измененных данных, что, в свою очередь, займет меньше времени.
Итак, у меня есть следующие варианты:
1) import-snapshot API = преобразовывает необработанный диск ОС в файл EBS snapshot.
2) копирует данные диска ОС = создает EBS 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)
Пройдя по разным форумам, я узнал, что вышеуказанная ошибка возникает, если в AKI и ARI возникает несоответствие при создании AMI из снимка.Правильный AKI и ARI извлекаются из исходного экземпляра EC2 , из которого создается моментальный снимок (как этого и ожидает AWS).
В моем случае я не создал снимок из запущенного EC2 instance, но с диска VMWare VM OS.
Я понял, что import-image API также создает моментальные снимки при создании AMI.Итак, я сравнил снимок, созданный import-image, и снимок, созданный мной, используя option-1 и option-2.
Я сравнил список файлов в /boot/ и их md5sum.Я обнаружил, что снимок, созданный AWS import-image API, имеет файл " 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_amiAMI, следовательно, не относится ко мне, поскольку я не создаю AMI из источника AMI. Пожалуйста, исправьте меня, если я ошибаюсь.