Преобразование euca-import-volume зависло в ожидании
Я следую документам руководства по работе с образами, чтобы создать резервный образ EBS: https://docs.eucalyptus.cloud/eucalyptus/4.4.5/index.html#image-guide/img_task_install_hvm_image.html
#import to volume
euca-import-volume CentOS-7-x86_64-GenericCloud-1901.raw --format raw --availability-zone zone-1 --bucket imagebucket --description "ebs backed centos7"
Задача преобразования после импорта застряла в Pending conversion в ApproximateBytesConverted 0 и не выполняется. Любые идеи об общих причинах этого?
[root@desktop ~]# euca-describe-conversion-tasks
TaskType IMPORTVOLUME TaskId import-vol-a6baf98c ExpirationTime Wed Apr 17 09:25:47 EDT 2019 Status active StatusMessage Pending conversion
DISKIMAGE DiskImageFormat RAW DiskImageSize 8589934592 VolumeId vol-4ddda573 VolumeSize 8 AvailabilityZone zone-1 ApproximateBytesConverted 0
Работник обработки изображений настроен с m2.2xlarge, но я вижу противоречивую информацию о том, запускается ли он.
[root@cloud ~]# euca-describe-instances --filter tag-value=euca-internal-imaging-workers
[root@cloud ~]# esi-describe-images
SERVICE VERSION ACTIVE IMAGE INSTANCES
imaging 4.4.101 * emi-ebfa1114 1
loadbalancing 4.4.101 * emi-ebfa1114 0
Ответы 2
Мне удалось использовать вспомогательный метод экземпляра вручную для создания образов hvm с поддержкой EBS: https://docs.eucalyptus.cloud/eucalyptus/4.4.5/index.html#image-guide/img_task_install_hvm_image.html
Вариант C. Установите образ EBS с помощью вспомогательного экземпляра.
Это является технически поддерживаемый метод, поэтому я не чувствую, что это обходной путь, но было бы удобно понять, почему вариант A (euca-import-volume) не работает для меня, как описано.
Если задача преобразования находится в состоянии ожидания, это означает наличие проблемы. с экземпляром работника обработки изображений.
Причина, по которой вы не видите вывод из euca-describe-instances, заключается в том, что
работник обработки изображений работает в сервисной учетной записи (eucalyptus)imaging
а не аккаунт eucalyptus. Чтобы просмотреть сведения об экземпляре:
#
# euare-rolelistbypath --as-account '(eucalyptus)imaging'
arn:aws:iam::123456789012:role/internal/imaging/euca-internal-imaging-service-Role-XXXXXXXXXXXXX
arn:aws:iam::123456789012:role/imaging/ImagingServiceAdministrator
#
#
# eval $(euare-assumerole arn:aws:iam::123456789012:role/imaging/ImagingServiceAdministrator)
#
#
# euca-describe-instances
RESERVATION r-3170...
#
#
# eval $(euare-releaserole)
#
#
Если есть проблемы с запуском экземпляра, CloudFormation сервис может иметь полезные детали, например:
# euform-describe-stacks
# euform-describe-stack-events
Самая распространенная проблема с работником обработки изображений — забыть установить ntp. сервер для использования, например:
# euctl services.imaging.worker.ntp_server=time.google.com
это всего лишь пример, вы должны использовать сервер ntp для вашей среды.
Чтобы вы могли подключаться по SSH к экземпляру рабочего образа и проверять журналы,
следует использовать euca-import-keypair в качестве администратора службы обработки изображений и
затем настройте имя ключа:
# euctl services.imaging.worker.keyname=KEYNAMEHERE
Простой способ перезапустить образ работника и принять любые изменения конфигурации:
# euctl services.imaging.worker.configured=false
# # wait for shutdown ...
# euctl services.imaging.worker.configured=true
Может оказаться полезным включить этот параметр в инструкции по настройке среды выполнения для рабочего образа. Поиск документов показывает, что он упоминается только в несвязанном указателе параметров среды, но точные настройки времени, по-видимому, являются требованием для правильно работающего экземпляра работника обработки изображений.
Я открыл проблему с документацией, чтобы включить параметр github.com/Corymbia/documentation/issues/17 ntp-сервера работника обработки изображений.
Это правильный ответ. Время работы с euca image worker истекло. euctl services.imaging.worker.ntp_server=[ваш сервер времени] сделал свое дело. Спасибо, Стив.