Американский национальный стандарт

Проект Изображение Государственного Герба Республики Казахстан НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН Информационная технология. Спецификация открытого формата виртуализации (OVF) СТ РК ISO/IEC 17203–_____ Настоящий национальный стандарт является идентичным осуществлением международного стандарта ISO/IEC17203: 2011 (E), Американского национального стандарта для информационных технологий INCITS469-2010 Настоящий проект стандарта не подлежит применению до его утверждения Комитет технического регулирования и метрологии Министерства по инвестициям и развитию Республики Казахстан (Госстандарт) Астана СТ РК ISO/IEC 17203–__ (проект, редакция 1) Предисловие 1 ПОДГОТОВЛЕН И ВНЕСЕН Акционерным обществом «Казахская академия транспорта и коммуникаций им. М.Тынышпаева». 2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Председателя Комитета технического регулирования и метрологии Министерства по инвестициям и развитию Республики Казахстан от __________________ № ________. 3 Настоящий стандарт идентичен международному стандарту ISO/IEC17203: 2011 (E) Information technology — Open Virtualization Format (OVF) specification (Информационная технология. Спецификация открытого формата виртуализации (OVF). Международный стандарт ISO/IEC17203: 2011 (E) разработан Техническим комитетом ISO/TC 204, Интеллектуальные транспортные системы. ИСО/МЭК 17203 был подготовлен ANSI INCITS (как INCITS 469: 2010) и был принят в рамках специальной " fasttrack procedure "( быстрой процедуры трека), Объединенным техническим комитетом ISO/IEC JTC 1, Информационных технологий, параллельно с его утверждением национальных органов ИСО и МЭК. Перевод с английского языка (en). Официальный экземпляр Международный стандарт ISO10711: 2012 (E), на основе которого разработан настоящий стандарт, и на которые даны ссылки, имеются в Едином государственном фонде нормативных технических документов. Степень соответствия – идентичная (IDT). 4 В настоящем стандарте реализованы положения государственной программы «Информационный Казахстан – 2020». 5 СРОК ПЕРВОЙ ПРОВЕРКИ ПЕРИОДИЧНОСТЬ ПРОВЕРКИ 201_ год 5 лет 6 ВВЕДЕН ВПЕРВЫЕ 1 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Нормативные документы по стандартизации», а текст изменений и поправок – в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Комитета технического регулирования и метрологии Министерства по инвестициям и развитию Республики Казахстан. 2 СТ РК ISO/IEC 17203–__ (проект, редакция 1) НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН Информационная технология. Спецификация открытого формата виртуализации (OVF) Дата введения Предисловие ИСО (Международная организация по стандартизации) и МЭК (Международная электротехническая комиссия) образуют специализированную систему всемирной стандартизации. Национальные органы, являющиеся членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, установленные соответствующей организацией, чтобы иметь дело с конкретными областями технической деятельности ИСО и МЭК. Технические комитеты сотрудничают в областях, представляющих взаимный интерес. Другие международные организации, правительственные и неправительственные, связанные с ИСО и МЭК, также принимают участие в работе. В области информации технологии, ИСО и МЭК создали объединенный технический комитет ISO/IEC JTC 1. Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, часть 2. Основной задачей совместного технического комитета является подготовка международных стандартов. Проекты международных Стандартов, принятые объединенным техническим комитетом, рассылаются национальным органам для голосования. Публикация в качестве Международного стандарта требует одобрения, по меньшей мере, 75% национальных органов, участвующих в голосовании. Следует обратить внимание на то, что некоторые из элементов этого документа могут быть объектом патентных прав. ИСО и МЭК не несут ответственность за идентификацию какого-либо или всех таких патентных прав. ИСО/МЭК 17203 был подготовлен ANSI INCITS (как INCITS 469: 2010) и был принят в рамках специальной " fasttrack procedure "( быстрой процедуры трека), Объединенным техническим комитетом ISO/IEC JTC 1, Информационных технологий, параллельно с его утверждением национальных органов ИСО и МЭК. 3 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Американский национальный стандарт Утверждение Американского национального стандарта требует просмотра по ANSI, что требует соответствующей правовой процедуры, консенсуса, и выполнения других критерий для утверждения разработчиком стандартов. Консенсус устанавливается, когда, по мнению Совета ANSI по просмотру стандартов, достигается существенная договоренность непосредственно и материально пострадавших интересов сторон. Существенное соглашение означает гораздо больше, чем простое мнение большинства, но не обязательно единогласие. Консенсус требует, чтобы все взгляды и возражения были рассмотрены, и что бы согласованные усилия были предприняты для принятия решения. Использование Американских Национальных Стандартов является полностью добровольным; их существование ни в коем-случае никого не исключает, независимо от того утвердил он стандарт или нет, от производства, маркетинга, закупок, или с использованием продуктов, процессов, или процедур несоответствующих стандартам. Американский национальный институт стандартов не разрабатывает стандарты, и ни при каких обстоятельствах, не дает толкования Американского национального стандарта. Кроме того, ни один человек не имеет права или полномочия выпускать интерпретацию американского национального стандарта от имени Американского Национального Института Стандартов. Запрос для получения интерпретаций следует направлять в секретариат или спонсору, чье имя указано на титульном листе настоящего стандарта. Внимание: Этот американский Национальный стандарт может быть пересмотрен или отозван в любое время. Процедуры Американского Национального Института Стандартов требуют принятия мер, для того, чтобы периодически утверждать, пересматривать или отзывать этот стандарт. Покупатели Американских Национальных Стандартов могут получить текущую информацию обо всех стандартах, позвонив или написав в Американский Национальный Институт Стандартов. Внимание: Разработчики данного стандарта просят, чтобы владельцы патентов, которым могут быть необходимы толкования стандарта для реализации, адресовать такие патенты издателю. Тем не менее, ни разработчики, ни издатель не предпринимают патентный поиск с целью выявления, если таковые имеются, патенты могут применяться к настоящему стандарту. По состоянию на дату публикации настоящего стандарта и после звонков для идентификации патентов, которые могут потребоваться для реализации данного стандарта, никакие претензии не были сделаны. Никаких дополнительных патентных поисков не проводится разработчиками и 4 СТ РК ISO/IEC 17203–__ (проект, редакция 1) издателем в отношении любого стандарта, который они разрабатывают. Не производится представление или подразумевание, что лицензии не требуется, чтобы избежать нарушения в использовании данного стандарта. 5 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Содержание 1 2 3 4 5 5.1 5.2 5.3 5.4 6 7 7.1 7.2 7.3 7.4 8 8.1 8.2 8.3 8.4 9 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 10 11 11.1 11.2 6 Предисловие Область применения Нормативные ссылки Термины и определения Символы и сокращенные термины OVF пакеты Структура OVF пакетов Форматы виртуальных дисков Распределение в виде отдельного файла Распределение в виде набора файлов OVF Дескриптор Оболочка Element Файловые Ссылки Элемент Content Расширяемость Соответствия Описание Виртуального Оборудования Раздел VirtualHardwareSection Расширяемость Элементы виртуальных аппаратов Диапазоны на элементов Разделы основных метаданных Радел DiskSection Раздел сети Раздел распределения ресурсов Раздел аннотации Раздел ProductSection Раздел EulaSection Раздел ввода в эксплуатацию Раздел развертывания вариантов Раздел операционных систем Раздел установок Интернационализация OVF среда Документ Environment Транспорт 9 13 13 14 16 17 17 20 20 21 21 22 23 25 27 28 29 29 31 31 34 36 37 39 40 41 41 46 47 48 51 51 52 54 54 56 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Приложение A (справочное) Символы и обозначения Приложение B (справочное) Журнал изменений Приложение C (обязательное) Открытый формат виртуализации XSD Приложение D (справочное) Библиография 58 59 60 61 7 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Таблицы Таблица 1 Таблица 2 Таблица 3 Таблица 4 Таблица 5 Таблица 6 Таблица 7 Таблица 8 8 – Префиксы пространств имен XML – Действия для дочерних элементов с OVF: требуемого атрибута –Элементы HostResource – Элементы виртуальных устройств и контроллеры – Основные разделы метаданных – Типы свойств – Классификация свойств – Основные разделы 22 31 33 33 36 45 45 56 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Предисловие (Это предисловие не является частью американской национального стандарта INCITS 469-2010). Спецификация открытого формата виртуализации (OVF) Спецификация описывает открытый, безопасный, портативный, эффективный и расширяемый формат для упаковки и распространения программного обеспечения, чтобы запускать его в виртуальных машинах. Ключевые свойства формата таковы: - Оптимизирован для распределения: OVF поддерживает проверку целостности содержимого и проверки на основе отраслевого стандарта ключевой общественной инфраструктуры, и он обеспечивает основными схемами для управления лицензированием программного обеспечения. - Оптимизирован для простого, автоматизированного пользовательского опыта: OVF поддерживает проверку всей упаковки и каждой виртуальной машины или метаданных компонента OVF во время установки фаз процесса управления жизненным циклом виртуальной машины (BM). Он также имеет пакеты с пакетом необходимой пользователю читабельной и описательной информации о том, что платформа виртуализации может быть использована для опыта установки поточной линии. - Поддержка одной ВМ и нескольких ВМ-конфигураций: OVF поддерживает оба стандартных одноместных пакета и пакеты, содержащие комплекс ВМ., многоуровневые услуги, состоящие из нескольких взаимозависимых виртуальных машин. - Портативное пакетирование ВМ: OVF это платформа нейтральной виртуализации, а также позволяющая усовершенствование конкретной платформы. Он поддерживает полный спектр виртуальных форматов жестких дисков, используемых для гипервизоров сегодня, и это экстенсивность, которая позволяют ему вместить форматы, которые могут возникнуть в будущем. Виртуальные свойства машины охвачены лаконично и точно. -Продавец и независимость платформы: OVF не полагается на использование конкретной платформы, платформу виртуализации, или гостевую операционную систему. - Расширенный: OVF сразу используется и расширяется. Он предназначен, чтобы использоваться так, как промышленность движется вперед с технологией виртуальных приборов. Он также поддерживает и позволяет кодировку метаданных конкретного производителя, чтобы поддержать конкретный вертикальный рынок. - Локализуемый: OVF поддерживает пользовательские видео описания в нескольких местах, и поддерживает локализацию интерактивных процессов во время установки приборов. Эта возможность позволяет одному упакованному прибору обслужить множество рыночных возможностей. 9 СТ РК ISO/IEC 17203–___ (проект, редакция 1) - Открытый стандарт: OVF возник в результате сотрудничества ключевых поставщиков в промышленность, а так же разработан и принят на отраслевом форуме, как будущий стандарт для портативных виртуальных машин. Явной целью OVF не является быть эффективным исполнительным форматом. Гипервизору разрешается, но не требуется запускать программное обеспечение в виртуальных машинах непосредственно из открытого формата виртуализации. Этот стандарт содержит четыре приложения. Приложение C является нормативным и считается частью настоящего стандарта. Приложения A, B, D и являются информативными и не являются частью настоящего стандарта. Запросы о толковании, предложения по улучшению или дополнения, или сообщения о дефектах приветствуются. Они должны быть направлены в Международный комитет по стандартам информационных технологий (INCITS), ITI, 1101 KStreet, NW, Люкс 610, Вашингтон, округ Колумбия 2005. 10 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Этот стандарт был разработан и утвержден для представления в ANSI по INCITS. Утверждение комитетом этого стандарта не обязательно означает, что все члены комитета проголосовали за его утверждение. На момент утверждения данного стандарта, INCITS присутствовали следующие члены: Дон Райт, председатель Дженифер Гарнер, секретарь Представленные организации Имя представителя AdobeSystems, Inc Скот Фоши, Стив Зилес (Alt.) AIMGlobal, Inc Дэн Мален, Чарльз (Alt.) AppleComputer, Inc Квок Лау, Хелен Уоркман (Alt.) David Singer (Alt.) Управление дистрибутивного Джон Крандэл, Джэт Хиланд, (Alt.) менеджмента задачами Electronic Industries Alliance Эдвард Микоски, Дж. Генри Касчиэри (Alt.) Корпорация EMC Гари Робинсон Farance, Inc Фрэнк Фаранс, Тимоти Счёчл (Alt.) Google Захеда Борат GS1 US Рэй Делниски, Фрэнк Шарки(Alt.), Джэймс Кроновски(Alt.), Мэри Вилсон(Alt.) Hewlett-Packard Company Карэн Хигинботом, Пол Джэран (Alt.) Корпрация IBM Джэральд Лэйн, Роберт Уэйр (Alt.) IEEE Бил Эш, Тэри Дэ Коусэл (Alt.), Джоди Хасз(Alt.)Боб Лэйбэл (Alt.) Intel Филип Уэнблом Грэйс Уэй (Alt.) Стэфэн Балог (Alt.) Лексмарк Интернэшнл Дон Райт, Дуайт Льюис(Alt.) Пол Менард(Alt.) КорпорацияМикрософт Джим Хьюджэс, Дэйв Уэлш (Alt.) Марк Райлэнд (Alt.) Джон КалхоунJ(Alt.) Национальный институт Микаэл Хоган, Элайн Баркер стандартов и технологий (Alt.),Дэн Бенигни (Alt.) Фернандо Подио (Alt.), Тереза Шварцхофф (Alt.), Во Чанг (Alt.) Корпорация Oracle ДональдР. Дьютш, Джим Мэлтон (Alt.) Микаэл Каваноф (Alt.) Тошихиро Сузуки (Alt.),Джэф Мишкинский (Alt.),Тони Ди Сэнзо (Alt.),Эдуардо Гутэнтаг (Alt.) 11 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Университет Пурду Storage Networking Industry Association (SNIA) Департамент обороны США Департамент внутренней безопасности США. Стэфэн Элиот Гари Филипс, Арнольд Джонс (Alt.)Дэйв Тиел (Alt.) Джэри Смит Дэнис Девера(Alt.) Дэйв Браун (Alt.) Леонард Левин (Alt.) . Питэр Шебэл, Грэг Пьермарини (Alt.) Спецификация Открытого Формата виртуализации (DSP0243) была подготовлена отделом систем виртуализации и рабочей группой кластеризации DMTF. Эта спецификация была разработана в результате совместной работы с несколькими частными лицами и группами, в том числе: Лоурэнс Дж. Ламэрс, В Муэя (председатель) Стефэн Грарэп, VM ware (со-редактор) Рини В. Шмидт, VM ware (со-редактор) Саймон Кросби, Citrix Systems, Inc. Рон Дойл, IBM Майк Геринг, IBM Майкл Джионфридо, Sun Microsystems Стив Хэнд, Symantec Марк Харпер, Sun Microsystems Даниель Хилтген, VM ware Майкл Джохансэн, IBM Джон Леунг, Intel Corporation Фумио Мачида, NEC Corporation Андреас Майэр, IBM Эван Мелор, Citrix Systems, Inc. Джон Парчем, Microsoft Шишир Пардикар, Citrix Systems, Inc. Стэфэн Дж. Шмидт, IBM Эндрю Уофилд, Citrix Systems, Inc. Марк Д. Уэйтзэл, IBM Джон Вилсон, Dell 12 СТ РК ISO/IEC 17203–__ (проект, редакция 1) АМЕРИКАНСКИЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ INCITS 469-2010 Американский Национальный Стандарт для Информационных Технологий Спецификация открытого формата виртуализации (OVF) 1 Область применения Спецификация Открытого Формата виртуализации (OVF) описывает открытый, безопасный, портативный, эффективный и расширяемый формат для упаковки и распространения программного обеспечения, чтобы запускать в виртуальных машинах 2 Нормативные ссылки Следующие стандарты содержат положения, которые посредством ссылок в этом тексте составляют положения настоящего стандарта. Все стандарты подлежат пересмотру, и стороны соглашений, основанных на этом американском Национальном стандарте, рекомендуется изучить возможность применения самых последних изданий стандартов, показанных ниже ANSI/IEEEСтандарт1003.1-2008, IEEE Стандарт для информационных технологий - Интерфэйс портативных операционных систем (POSIX). Основные спецификации, выпуск, 7, Институт инжинеров в области электричества и электроники, декабрь 2008, http://standards.ieee.org/index.html DMTF CIM Schema 2.22, http://www.dmtf.org/standards/cim DMTFDSP0004, Общая информационная модель (CIM) Спецификация инфраструктуры 2.5, http://www.dmtf.org/standards/published_documents/DSP0004_2.5.pdf DMTFDSP0230, WS-CIM Спецификация оформления в карту1.0, http://www.dmtf.org/standards/published_documents/DSP0230_1.0.pdf DMTFDSP1041, Профильраспределения ресурсов (RAP) 1.1, http://www.dmtf.org/standards/published_documents/DSP1041_1.1.pdf DMTFDSP1043, Профиль способов распределения (ACP) 1.0, http://www.dmtf.org/standards/published_documents/DSP1043_1.0.pdf IETFRFC1738, T. Berners - Lee, Универсальные локаторы ресурсов (URL), December1994, http://www.ietf.org/rfc/rfc1738.txt IETFRFC1952, P. Deutsch, GZIPверсияспецификацииформатафайлов4.3, May1996, http://www.ietf.org/rfc/rfc1952.txt IETFRFC5234, Дополненная BNF для спецификации синтаксиса: ABNF, http://www.ietf.org/rfc/rfc5234.txt IETFRFC2616, R. Fieldingetal, Протокол передачи гипертекста- HTTP/1.1, June1999, http://www.ietf.org/rfc/rfc2616.txt IETFRFC3986, Идентификаторы универсальных ресурсов (URI): Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt ISO 9660, 1988Обработкаинформации- томаиструктурыфайлов CD-ROM for information interchange, 13 СТ РК ISO/IEC 17203–___ (проект, редакция 1) http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber= 17505 ISO, ISO/Директивы, часть2, Правила для структуры и составления проекта международных стандартов, http://isotc.iso.org/livelink/livelink.exe?func=ll&objId=4230456&objAction= browse&sort=subtype 3 Термины и определения Для достижения целей настоящего документа, используются следующие термины и определения: 3.1 может используется для утверждений о материальной, физической или причинной возможности и способности, 3.2 не может используется для утверждений о материальной, физической или причинной возможности и способности, 3.3 условный указывает требования, которым надо строго следовать, чтобы соответствовать требованиям документа, когда указанные условия выполнены 3.4 обязательное указывает на требования, которым надо строго следовать, чтобы соответствовать требованиям документа и в которых отклонения не допускаются 3.5 может указывает на направление действий допустимых в пределах документа 3.6 не надо указывает на направление действий допустимых в пределах документа 3.7 необязательный 14 СТ РК ISO/IEC 17203–__ (проект, редакция 1) указывает на направление действий допустимых в пределах документа 3.8 должен указывает требования, которым надо строго следовать, соответствовать документу и в котором отклонений не допускается чтобы 3.9 не должны указывает требования, которым надо строго следовать, соответствовать документу и в котором отклонений не допускается чтобы 3.10 должен указывает, что из нескольких возможностей, один рекомендуется как особенно подходящий, без упоминания или исключения других, или что определенный курс действий является предпочтительным, но не обязательно требуется 3.11 не следует указывает, что определенная возможность или образ действий является устаревшим, но не запрещён 3.12 прибор см виртуальное устройство (3.18) 3.13 платформа развертывания продукт, который устанавливает пакет OVF 3.14 гостевое программное обеспечение программное обеспечение, которое хранится на виртуальных дисках, который работает, когда виртуальная машина работает на гостевой обычно, операционная система и некоторые приложения и услуги на уровне пользователя. 3.15 OVF пакет OVF дескриптор XML-файл в сопровождении нуль или более файлов 15 СТ РК ISO/IEC 17203–___ (проект, редакция 1) 3.16 OVF дескриптор OVF XML файл дескриптор 3.17 платформа см платформу развертывания (3.13) 3.18 виртуальное устройство услуга поставляется как полный стек программного обеспечения, установленного на одной или нескольких виртуальных машинах. Виртуальный прибор, как правило, как предполагается, будет доставлен в пакете OVF. 3.19 виртуальное оборудование аппараты (в том числе процессоры, контроллеры, устройства Ethernet, и диски), что видно по гостевому программному обеспечению 3.20 виртуальная машина полная среда, которая поддерживает выполнение гостевого программного обеспечения виртуальной машины, полная инкапсуляции виртуального аппаратного обеспечения, виртуальных дисков, и метаданных, связанных с ним. Виртуальные машины позволяют осуществить мультиплексирование основной физической машины через программный слой, который называется гипервизор. 3.21 коллекция виртуальных машин Служба состоит из набора виртуальных машин Сервисом может быть простой набор из одного или нескольких виртуальных машин, или это может быть комплексное обслуживание, построенное из комбинации виртуальных машин и других коллекций виртуальных машин. Потому, что коллекция виртуальных машин может быть составлена, она позволяет иметь сложные вложенные компоненты. 4 Символы и сокращенные термины Следующие символы и сокращения используются в данном документе 16 СТ РК ISO/IEC 17203–__ (проект, редакция 1) 4.1.1 ОИМ Общая Информационная Модель 4.1.2 ИП Интернет протокол 4.1.3 OVF Открытый формат виртуализации 4.1.4 ВМ Виртуальная Машина 5 OVF пакеты 5.1 Структура OVF пакетов OVF пакет состоит из следующих файлов: • один OVF дискриптор c расширением .ovf • ноль или один OVF, который проявляется с расширением .mf • ноль или один OVF сертификат с расширением .cert • ноль или более файлов образа диска • ноль или более дополнительных ресурсных файлов, таких как ISO образы Следует использовать файловые расширения .ovf, .mf и .cert. ПРИМЕР1: Следующий перечень файлов является примером OVF пакета: package.ovf package.mf de-DE-resources.xml vmdisk1.vmdk vmdisk2.vmdk resource.iso ПРИМЕЧАНИЕ: Предыдущий пример использует VMDK дисковые файлы, но было поддерживалось несколько форматов дисков. Пакет OVF может храниться либо как единое целое или набор файлов, как описано в 5.3 и 5.4. Оба режима должны поддерживаться. Пакет OVF может иметь файл манифеста, содержащий SHA-1 17 СТ РК ISO/IEC 17203–___ (проект, редакция 1) дайджестов отдельных файлов в пакете. Файл манифеста должен иметь расширение .mf и то же имя как .ovf файл и быть сходным .ovf файлу. Если файл манифеста присутствует, потребитель пакета OVF должен проверить дайджест обрабатывает путем вычисления фактических SHA-1 дайджестов и сравнивая их с дайджестами, перечисленными в файле манифеста. Если файл манифеста присутствует, потребитель пакета OVF должен проверить дайджесты, путем вычисления фактических SHA-1 дайджестов и сравнивая их с дайджестами, перечисленных в файле манифеста. Определения синтаксиса ниже использования ABNF с исключениями, перечисленными в Приложении А. Формат файла манифеста заключается в следующем: manifest_file = *( file_digest ) file_digest = algorithm "(" file_name ")" "=" sp digest nl algorithm = "SHA1" digest = 40( hex-digit ) ; 160-bit digest in 40-digit hexadecimal hex-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" |"b" | "c" | "d" | "e" | "f" sp = %x20 nl = %x0A ПРИМЕР 2: В следующем примере показано частичные содержимое файла манифеста: SHA1(package.ovf)= 237de026fb285b85528901da058475e56034da95 SHA1(vmdisk1.vmdk)= 393a66df214e192ffbfedb78528b5be75cc9e1c3 Пакет OVF может быть подписан через подписание файла манифеста. Дайджест файла манифеста хранится в файле сертификата с расширением. сертификат подать вместе с базовой 64 кодировкой X.509 сертификата. Файл .cert должен иметь то же имя, как .ovf файл и быть родственным .OVF файлу. Потребитель пакета OVF должен проверить подпись и должен проверить сертификат. Формат файла сертификата должен быть следующим: certificate_file = manifest_digest certificate_part manifest_digest = algorithm "(" file_name ")" "=" sp signed_digest nl algorithm = "SHA1" signed_digest = *( hex-digit) certificate_part = certificate_header certificate_body certificate_footer certificate_header = "-----BEGIN CERTIFICATE-----" nl certificate_footer = "-----END CERTIFICATE-----" nl certificate_body = base64-encoded-certificate nl ; base64-encoded-certificate is a base64-encoded X.509 ; certificate, which may be split across multiple lines hex-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a"| "b" | "c" | "d" | "e" | "f" sp = %x20 nl = %x0A 18 СТ РК ISO/IEC 17203–__ (проект, редакция 1) ПРИМЕР 3: Следующий подписанного пакета OVF. список файлов является примером package.ovf package.mf package.cert de-DE-resources.xml vmdisk1.vmdk vmdisk2.vmdk resource.iso ПРИМЕР 4: Следующий пример показывает содержимое файла образца сертификации OVF, где был подписан SHA1-дайджест файла манифеста с 512 битным ключом: SHA1(package.mf)=7f4b8efb8fe20c06df1db68281a63f1b088e19dbf00e5af9d b5e8e3e319de7019db88a3bc699bab6ccd9e09171e21e88ee20b5255cec3fc28350613b 2c529089 -----BEGIN CERTIFICATE----MIIBgjCCASwCAQQwDQYJKoZIhvcNAQEEBQAwODELMAkGA1UEBhMCQVUxDDAKBgNV BAgTA1FMRDEbMBkGA1UEAxMSU1NMZWF5L3JzYSB0ZXN0IENBMB4XDTk1MTAwOTIz MzIwNVoXDTk4MDcwNTIzMzIwNVowYDELMAkGA1UEBhMCQVUxDDAKBgNVBAgTA1FM RDEZMBcGA1UEChMQTWluY29tIFB0eS4gTHRkLjELMAkGA1UECxMCQ1MxGzAZBgNV BAMTElNTTGVheSBkZW1vIHNlcnZlcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC3 LCXcScWua0PFLkHBLm2VejqpA1F4RQ8q0VjRiPafjx/Z/aWH3ipdMVvuJGa/wFXb /nDFLDlfWp+oCPwhBtVPAgMBAAEwDQYJKoZIhvcNAQEEBQADQQArNFsihWIjBzb0 DcsU0BvL2bvSwJrPEqFlkDq3F4M6EgutL9axEcANWgbbEdAvNJD1dmEmoWny27Pn Ims6ZOZB -----END CERTIFICATE----- Манифест и файлы сертификатов, если присутствуют, не должны быть включены в раздел Ссылки дескриптора OVF (7.1). Это гарантирует, что содержание дескрипторов OVF не зависит от того, имеет ли пакет OVF манифест или подписан, и решение добавить манифест или сертификат на пакет может быть отложено на более поздний срок. Расширения файлов .mf и . cert может быть использован для других файлов в пакете OVF, пока они не занимают родственные URL адреса или имена путей, где они будут интерпретированы как манифест пакета или сертификат. 5.2 Форматы виртуальных дисков OVF не требует какого-либо конкретного формата диска для использования, но надо соблюдать с этой спецификацией формата диска, которые должны быть предоставлены по URL, который идентифицирует неизрасходованный спецификации о том, как интерпретировать формат диска. Спецификация не обязательно должна быть машиночитаемой, но он должен быть статическим и уникальным, так что URL может быть использован в качестве ключа с помощью программного обеспечения при чтении пакета OVF однозначно определить формат диска. Спецификация должна 19 СТ РК ISO/IEC 17203–___ (проект, редакция 1) предоставлять достаточную информацию, так что специалист может правильно интерпретировать формат диска для чтения и записи данных на диске. Он рекомендован, чтобы эти идентификаторы URIбыли разрешимы. 5.3 Распределение в виде отдельного файла Пакет OVF может быть сохранен как один файл, используя формат TAR. Расширение этого файла будет .ova (открыть виртуальное устройство или приложение). ПРИМЕР: В следующем примере показан пример файла для пакета OVF этого типа: D:\virtualappliances\myapp.ova Для OVF пакетов сохраняется как один файл, все ссылки на файлы в дескрипторе OVF должны быть ссылками относительного пути и должны указывать на файлы, включенные в архиве TAR. Относительные каталоги внутри архива допускаются, но ссылки относительного пути не должны содержать ".." точки-сегментов. Обычно инструментом для извлечения TAR было сканирование всего архива, даже если запрашиваемый файл находится в начале, из-за замены файлов могут быть добавлены без изменения остальные части архива. Для OVF TAR файлов, копирование не допускается в архиве. Кроме того, файлы должны быть в следующем порядке внутри архива: 1) Дескриптор OVF 2) OVF манифест (необязательный) 3) Свидетельство OVF (необязательный) 4) Остальные файлы должны быть в том же порядке, как указано в списке литературы раздел (см.7.1). Обратите внимание, что любые внешние строки Файла ресурсов для интернационализации должны быть сначала в Ссылки раздела (см. раздел 10). 5) OVF манифест (необязательный) 6) Свидетельство о OVF (необязательный) Обратите внимание, что файл сертификата не является обязательным. Если файла сертификата нет, то файл манифеста также является необязательным. Если файлы сертификатов активны или присутствуют, они должны, либо оба быть размещены после дескриптора OVF, или оба быть помещены в конец архива. При развертывании, ограничение гарантирует, что порядок можно извлечь дескриптором OVF из архива для OVF без сканирования всего архива. Для генерации, ограничение заказа гарантирует, что файл OVF ТАR легко генерируется на лету. Ограничения не допускают OVF TAR файлов и создаются с использованием стандартных инструментов ТАR архива. Формат ТАR используется в соответствии формату USTAR (Uniform 20 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Standard Tape Archive - Единый стандарт ленты архива), как определено в группе POSIX IEEE 1003.1 стандартов. 5.4 Распределение в виде набора файлов Пакет OVF может быть доступен в виде набора файлов, например, на стандартном веб-сервере. ПРИМЕР: Пример пакета OVF в виде набора файлов на веб-сервер следующим образом: http://mywebsite/virtualappliances/package.ovf http://mywebsite/virtualappliances/vmdisk1.vmdk http://mywebsite/virtualappliances/vmdisk2.vmdk http://mywebsite/virtualappliances/resource.iso http://mywebsite/virtualappliances/de-DE-resources.xml 6 OVF Дескриптор Все метаданные о пакете и его содержимом, хранится в дескрипторе OVF. Это расширяемый документ XML для кодирования информации, такой как сведения о продукте, виртуальные аппаратные требования, и лицензирование. dsp8023_1.1.0.xsd XML схема файла определения для OVF дескриптора содержит элементы и атрибуты. Статьи 7, 8, и 9, описывают семантику, структуру и расширяемость дескриптора OVF. Эти положения не являются заменой для чтения определения схемы, но они дополняют определения схемы. XML-документ дескриптора OVF должен содержать один элемент Конверта, который является единственным элементом, допускающимся на высшем уровне. Пространства имен XML, используемые в данном описании, приведены в Таблице 1. Выбор любого префикса пространства имен, является произвольным и семантически не значим. Таблица 1 –Префиксы пространства имен XML Префикс ovf ovfenv rasd vssd cim Пространства имен XML http://schemas.dmtf.org/ovf/envelope/I http://schemas.dmtf.org/ovf/environment/I http://schemas.dmtf.org/wbem/wscim/1/cimschema/2/CIM ResourceAllocationSettingData http://schemas.dmtf.org/wbem/wscim/1/cimschema/2/CIM VirtualSystemSettingData http://schemas.dmtf.org/wbem/wscim/1/common 21 СТ РК ISO/IEC 17203–___ (проект, редакция 1) 7 Оболочка Element Элемент Конверт описывает все метаданные для виртуальных машин (в том числе в виртуальной среде), а также структуру самого пакета OVF. Наружный уровень состоит из следующих частей: • Индикация версии, определяется URI, пространства имен XML, • Список ссылок на файлы для всех внешних файлов, которые являются частью пакета OVF, определяемый • Элемент ссылок и его дочерние элементы файла. Они, как правило, файлы виртуальных дисков, ISO изображения и интернационализации ресурсов, часть метаданных, определенных разделом элементов, как определено в пункте 9. • Описание содержания, одной виртуальной машины (элемент виртуальной системы) или коллекции из нескольких виртуальных машин (элементовколлекции виртуальных систем). Спецификация пучков сообщений в ресурсах для нуля или более мест, определяемых строками элементов для каждого региона. ПРИМЕР: Пример структуры дескриптора OVF с верхним уровнем Конверт элемента следующим образом: <?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cimschema/ 2/CIM_VirtualSystemSettingData" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cimschema/ 2/CIM_ResourceAllocationSettingData" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns="http://schemas.dmtf.org/ovf/envelope/1" xml:lang="en-US"> <References> <File ovf:id="de-DE-resources.xml" ovf:size="15240" ovf:href="http://mywebsite/virtualappliances/de-DEresources.xml"/> <File ovf:id="file1" .ovf:href="vmdisk1.vmdk"ovf:size="180114671"/> <File ovf:id="file2" .ovf:href="vmdisk2.vmdk"ovf:size="4882023564" ovf:chunkSize="2147483648"/> <File ovf:id="file3" ovf:href="resource.iso" ovf:size="212148764" ovf:compression="gzip"/> <File ovf:id="icon" ovf:href="icon.png" ovf:size="1360"/> </References>  <DiskSection> <Info>Describes the set of virtual disks</Info> 22 СТ РК ISO/IEC 17203–__ (проект, редакция 1)  </DiskSection>  <NetworkSection> <Info>List of logical networks used in the package</Info>  </NetworkSection> <SomeSection ovf:required="false"> <Info>A plain-text description of the content</Info>  </SomeSection>  <VirtualSystemCollection ovf:id="Some Product">  </VirtualSystemCollection > <Strings xml:lang="de-DE">  </Strings> </Envelope> Необязательный xml:lang: языковой атрибут на элементе конверт должен указать на локализацию по умолчанию для сообщений в дескрипторе. Элементы дополнительной строки должны содержать пучки ресурса строк для различных языков. См. раздел 10 для более подробной информации по поддержке интернационализации. 7.1 Файловые Ссылки Часть файловой ссылки определяется элементом Ссылки и позволяет инструменту легко определить целостность пакета OVF без разбора или интерпретирования всей структуры дескриптора. Инструментом можно смело манипулировать (например, скопировать или поместить в архив) OVF пакетов без риска потерять файлы. Внешний ресурс строк, которые расслаивают файлы для интернационализации должны быть помещены сначала в элемент ссылки, см. раздел 10 для деталей. Каждому элементу файла в справочной части дается идентификатор, используя атрибут ovf:id. Идентификатор должен быть уникальным внутри пакета OVF. Каждый элемент файла должен быть указан с использованием атрибута ovf:href, который должен содержать URL. Ссылки относительно пути и схемы URL "файл", "http", и "https" должны поддерживаться, см RFC1738 и RFC3986. Другие схемы URL не должны быть использованы. Если URL не указан, значение атрибута ovf:href должен толковаться как путь из 23 СТ РК ISO/IEC 17203–___ (проект, редакция 1) указанного файла, что является относительным к местоположению самого дескриптора OVF. Относительный путь должен использоваться как синтаксис ссылок относительных путей в RFC3986. Указанный файл должен существовать. Два различных элемента файла не должен ссылаться на один и тот же файл с их ovf:href атрибутов. Размер указанного Файла может быть определён с помощью атрибута ovf:size. Устройство этого атрибута всегда определяется в байтах. Если присутствует, значение атрибута ovf:size должен соответствовать фактическому размеру указанного Файла. Каждый файл, на который ссылается элемент Файл, может быть сжат, с использованием gzip (см RFC1952). Когда элемент Файла сжимается с помощью GZIP, то атрибут ovf:compression, должен быть установлен на "gzip". В противном случае, атрибут ovf:compression должен быть установлен в "identity" или весь атрибут опущен. В качестве альтернативы, если HREF является URLHTTP или HTTPS, то сжатие может быть задано сервером HTTP с помощью HTTP-заголовка Content-Encoding: gzip (см RFC2616). Использование кодировки содержимого HTTP в сочетании с атрибут ovf:compression допускается, но в целом не улучшает степень сжатия. При использовании сжатия, тем атрибут ovf:size должен указать размер фактического сжатого файла. Файлы, на которые есть ссылки, могут быть разделены на части, чтобы приспособить ограничения размера файла на некоторых файловых системах. Формирование фрагментов указывается в наличии атрибута ovf:chunksize; значение ovf: chunksize будет размером каждого блока, за исключением последнего фрагмента, который может быть меньше. Когда ovf:chunkSize указан, элемент файла должен ссылаться на файл, представляющий фрагмент всего файла. В этом случае в значении ovf: href атрибута указывается только часть URL, и синтаксис для URL обращающегося к фрагменту файла состоит в следующем. Синтаксис использует ABNF с исключениями, перечисленными в Приложении А. chunk-url = href-value "." chunk-number chunk-number = 9(decimal-digit) decimal-digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" В этом синтаксисе, значение - href является значением атрибута ovf:href, и фрагмента номер 0 на основе положение фрагмента начиная со значением 0 и увеличивается с шагом 1 для каждого блока. Разделение на порции может быть объединено со сжатием, всего файла, т.е. сжиматься перед блоком и каждый фрагмент должен быть равен части сжатого файла, за исключением последнего фрагмента, который может быть меньше, за исключением предыдущего. 24 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Если пакет OVF имеет файл манифеста, имя файла в манифесте записей должно соответствовать значению атрибута файла ovf:href, за исключением, случая, когда файл разбит на несколько фрагментов, в этом случае должна быть использована гиперссылка и файл манифеста должен содержать запись для каждого фрагмента. Для блочных файлов, файлу манифеста разрешается содержать записи для всего файла; если они присутствуют дайджест должен быть проверен. ПРИМЕР 1: В следующем примере показаны различные типы ссылок файлов: <File ovf:id="disk1" ovf:href="disk1.vmdk"/> <File ovf:id="disk2" ovf:href="disk2.vmdk" ovf:size="5368709120" ovf:chunkSize="2147483648"/> <File ovf:id="iso1" ovf:href="resources/image1.iso"/> <File ovf:id="iso2" ovf:href="http://mywebsite/resources/image2.iso"/> ПРИМЕР 2: В следующем примере показаны манифест записи, соответствующие ссылкам файлов, которые представлены выше SHA1(disk1.vmdk)= 3e19644ec2e806f38951789c76f43e4a0ec7e233 SHA1(disk2.vmdk.000000000)= 4f7158731ff434380bf217da248d47a2478e79d8 SHA1(disk2.vmdk.000000001)= 12849daeeaf43e7a89550384d26bd437bb8defaf SHA1(disk2.vmdk.000000002)= 4cdd21424bd9eeafa4c42112876217de2ee5556d SHA1(resources/image1.iso)= 72b37ff3fdd09f2a93f1b8395654649b6d06b5b3 SHA1(http://mywebsite/resources/image2.iso)= d3c2d179011c970615c5cf10b30957d1c4c968ad 7.2 Элемент Content Виртуальные машины в конфигурации пакета OVF представлены элементом VirtualSystem или VirtualSystemCollection. Эти элементы должны быть приведены идентификатором, используя атрибут ovf:id. Прямые дочерние элементы в VirtualSystemCollection должны иметь уникальные идентификаторы. В схеме OVF, элементы VirtualSystem и VirtualSystem Collection являются частью группы замены с содержанием элемента в качестве главы группы замены. Содержание элемента абстрактно и не может быть использовано непосредственно. Дескриптор OVF должен иметь один или более элементов Контента. Элемент VirtualSystem описывает единую виртуальную машину и просто контейнер раздела элементов. Эти элементы описывают раздел 25 СТ РК ISO/IEC 17203–___ (проект, редакция 1) виртуального оборудования, ресурсы и информацию о продукте и подробно описаны в пунктах 8 и 9. Структура элемента VirtualSystem заключается в следующем: <VirtualSystem ovf:id="simple-app"> <Info>A virtual machine</Info> <Name>Simple Appliance</Name> <SomeSection>  </SomeSection>  </VirtualSystem> Элемент VirtualSystemCollection представляет собой контейнер из нескольких VirtualSystem или VirtualSystemCollection элементов. Таким образом, могут быть описаны произвольные сложные конфигурации. В разделе элемента на уровне VirtualSystemCollection описываются данные прибора, свойства, потребности в ресурсах, и так далее, и подробно описаны в разделе 9. Структура элемента VirtualSystemCollection заключается в следующем: <VirtualSystemCollection ovf:id="multi-tier-app"> <Info>A collection of virtual machines</Info> <Name>Multi-tiered Appliance</Name> <SomeSection>  </SomeSection>  <VirtualSystem ovf:id="...">  </VirtualSystem>  </VirtualSystemCollection> Все элементы в содержании замещающей группы должны содержать элемент информации и могут содержать название элемента. Информационный элемент содержит удобочитаемое описание значения данного лица. Имя элемента является необязательным локализуемым отображаемое имя содержания. См. раздел 10 для деталей о том, как локализовать данные и имя элемента. 7.3 Расширяемость Эта спецификация позволяет добавить пользовательские метаданные, к OVF дескрипторам несколькими способами: • Новые элементы раздела могут быть определены как часть Раздела 26 СТ РК ISO/IEC 17203–__ (проект, редакция 1) замещения группы, и использоваться там, где схемы OVF позволяют разделам присутствовать. Все подтипы Раздела содержат элемент Информация, который содержит удобочитаемое описание значения данного лица. Значения элемента Информация могут быть использованы, например, чтобы дать значимые предупреждения для пользователей, когда раздел существенно пропускается, даже если анализатор ничего о разделе не знает. См пункт 10 для деталей о том, как локализовать элемент Информация. • Схемы OVF используют открытую модель содержания, где все существующие типы могут быть продлены в конце с дополнительными элементами. Точки расширения объявлены в схемах OVF с xs:any декларации с namespace="##other". • Схемы OVF позволяют дополнительные атрибуты существующих типов. Пользовательские расширения не должны использовать пространства имен XML, определенные в данной спецификации. Это относится и к пользовательским элементам и пользовательским атрибутам. На пользовательских элементах, Логический атрибут ovf:required определяет, требуется ли информация в элементе для правильного поведения или по желанию. Если не указан, то атрибут ovf:required по умолчанию ИСТИНА. Потребитель из пакета OVF, который обнаруживает расширение, которое требуется, и если он не понимает, потерпит неудачу. Для известных элементов Раздела, если дополнительные дочерние элементы, которые не понятны, найдены и значение их атрибута ovf:required имеет значение ИСТИНА, то потребитель пакета OVF должен интерпретировать весь раздел в качестве одного, который он не понимает. Проверка не является рекурсивной; это относится только к прямым дочерним элементам Раздела. Такое поведение гарантирует, что старые анализаторы отвергают новые спецификации OVF, если явно не указано, не делать этого. На пользовательских атрибутах, информация в атрибуте не требуется для правильного поведения. ПРИМЕР 1: <!—- Optional custom section example --> <otherns:IncidentTrackingSection ovf:required="false"> <Info>Specifies information useful for incident tracking purposes</Info> <BuildSystem>Acme Corporation Official Build System</BuildSystem> <BuildNumber>102876</BuildNumber> <BuildDate>10-10-2008</BuildDate> </otherns:IncidentTrackingSection> 27 СТ РК ISO/IEC 17203–___ (проект, редакция 1) ПРИМЕР 2: <!—- Open content example (extension of existing type) --> <AnnotationSection> <Info>Specifies an annotation for this virtual machine</Info> <Annotation>This is an example of how a future element (Author) can still be parsed by older clients</Annotation>  <otherns:Author ovf:required="false">John Smith</otherns:Author> </AnnotationSection> ПРИМЕР 3: <!—- Optional custom attribute example --> <Network ovf:name="VM network" otherns:desiredCapacity="1 Gbit/s"> <Description>The main network for VMs</Description> </Network> 7.4 Соответствия Эта спецификация определяет три уровня соответствия на OVF дескрипторах, с 1 являющимся самым высоким уровнем соответствия: • Дескриптор OVF использует только разделы и элементы, и атрибуты, определенные в этой спецификации. Соответствие уровня: 1. • Дескриптор OVF использует пользовательские разделы и элементы и атрибуты, которые не определены в этой спецификации, и все такие расширения являются необязательными, как определено в 7.3. Соответствие уровня: 2. OVF дескриптор использует пользовательские разделы или элементы, которые не определены в данном описании, и по крайней мере, одно такое продолжение требуется, как определено в 7.3. Определения всех необходимых расширений должны быть общедоступными в открытом и не израсходованном XML-схемы. Полная спецификация может быть включена в XML схеме, либо в качестве отдельного документа. Соответствие уровня: 3. Использование уровня соответствия 3 ограничивает портативность и её следует избегать, если это вообще возможно. Уровень соответствия не указан непосредственно в дескрипторе OVF, но должен быть определен в правилах выше. 28 СТ РК ISO/IEC 17203–__ (проект, редакция 1) 8 Описание Виртуального Оборудования 8.1 Раздел VirtualHardwareSection Каждый элемент VirtualSystem может содержать один или более элементов, VirtualHardwareSection каждое из которых описывает виртуальный аппаратных средств, необходимых виртуальной системе. Виртуальное аппаратное обеспечение виртуальной машины указано в VirtualHardwareSection элементов. Эта спецификация поддерживает абстрактные или неполные описания аппаратных, в котором описаны только основные устройства. Гипервизор может создавать дополнительные виртуальные аппаратные контроллеры и устройства, при условии, что необходимые устройства, перечисленные в дескрипторе, реализуются. Это описание виртуальных аппаратных средств основано на классах CIM CIM_VirtualSystemSettingData и CIM_ResourceAllocation SettingData. Представление XML-модели CIM основано на отображении WS-CIM (DSP0230). ПРИМЕР: Пример VirtualHardwareSection: <VirtualHardwareSection ovf:id="minimal" ovf:transport="iso"> <Info>500Mb, 1 CPU, 1 disk, 1 nic virtual machine</Info> <System> <vssd:ElementName>Virtual System Type</vssd:ElementName> <vssd:InstanceID>0</vssd:InstanceID> <vssd:VirtualSystemType>vmx-4</vssd:VirtualSystemType> </System> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:Description>Memory Size</rasd:Description> <rasd:ElementName>512 MB of memory</rasd:ElementName> <rasd:InstanceID>2</rasd:InstanceID> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>512</rasd:VirtualQuantity> </Item>  </VirtualHardwareSection> Элемент VirtualSystem должен иметь прямой дочерний элемент VirtualHardwareSection. VirtualHardwareSection запрещена в прямой дочерний элемент коллекции VirtualSystemCollection и элемента Envelope. Несколько находок элемента VirtualHardwareSection допускается в пределах одного элемента VirtualSystem. Потребители пакета OVF должны выбрать наиболее подходящее виртуальное описание аппаратного обеспечения для конкретной платформы виртуализации. Элемент 29 СТ РК ISO/IEC 17203–___ (проект, редакция 1) VirtualHardwareSection может содержать атрибут ovf:id, который может быть использован для идентификации элемента. Если присутствует, значение атрибута должно быть уникальным в пределах VirtualSystem. Атрибут OVF:transport определяет типы транспортных механизмов, с помощью которых передаются свойства для виртуальной машины в среде документа OVF. Этот атрибут поддерживает подключаемую и расширяемую архитектуру, для обеспечения механизмов гость/коммуникационная платформа. Несколько видов транспорта может быть отделены друг от друга одним пробелом. См. 9.5 для описания свойств и статьи 11 для описания типов транспортных и OVF средах. Элемент vssd:VirtualSystemType определяет виртуальный идентификатор типа системы, реализацию которой определяет строка, которая однозначно идентифицирует тип виртуальной системы. Например, виртуальная система идентификатор может быть типа vmx-4 для четвертого поколения виртуального оборудования или Xen-3 компании VMware для третьего поколения виртуального оборудования Xen. Ноль или более виртуальных типов идентификаторов системы могут быть указаны, разделенных одним пробелом. Для того, чтобы система виртуальной OVF была развертываемая на целевой платформе, виртуальная машина на целевой платформе должна поддерживать, по крайней мере, один из виртуальных типов систем, определенных в элементе vssd:VirtualSystemType. Виртуальные типы идентификаторов системы, указанные в элементах vssd: VirtualSystemType, как ожидается, будут сопоставляться постоянные значения VirtualSystemTypesSupported CIM класса CIM_VirtualSystemManagementCapabilities. Виртуальные характеристики оборудования описаны в виде последовательности элементов пункта. Элемент товара является XMLпредставление экземпляра класса CIM_ResourceAllocationSettingData CIM. Элемент может описать всю память и требования центрального процессора, а также виртуальные аппаратные устройства. Несколько подтипов устройства может быть указано в элементе Item, разделенных одним пробелом. ПРИМЕР: <rasd:ResourceSubType>buslogiclsilogic</rasd:ResourceSubType> 8.2 Расширяемость Дополнительный атрибут ovf:required на элемент Item определяет, будет ли реализация элемента (например, CD-ROM, USBконтроллер или) требуется для правильного поведения гостевым программным обеспечением. Если не указано, ovf:required по умолчанию 30 СТ РК ISO/IEC 17203–__ (проект, редакция 1) ИСТИНА. На дочерних элементах единицы Item, дополнительный логический атрибут ovf:required не должен толковаться, даже если эти элементы находятся в другом пространстве имен RASDWS-CIM. Инструмент разбора Item элемент должен действовать в соответствии с таблицей 2 Таблица 2 - Действия для дочерних элементов с OVF требуемого атрибута Исходящий элемент Значение атрибута ovf:required Действие Известный ИСТИНА или не указано Должен интерпретировать Item Известный ЛОЖЬ Должен интерпретировать Item Неизвестный ИСТИНА или не указано Отказ Item Неизвестный ЛОЖЬ Игнорирование Item 8.3 Элементы виртуальных аппаратов Общий вид любого пункта элемента в VirtualHardwareSection выглядит следующим образом: элементе <Item ovf:required="…" ovf:configuration="…" ovf:bound="…"> <rasd:Address> ... </rasd:Address> <rasd:AddressOnParent> ... </rasd:AddressOnParent> <rasd:AllocationUnits> ... </rasd:AllocationUnits> <rasd:AutomaticAllocation> ... </rasd:AutomaticAllocation> <rasd:AutomaticDeallocation> ... </rasd:AutomaticDeallocation> <rasd:Caption> ... </rasd:Caption> <rasd:Connection> ... </rasd:Connection>  <rasd:ConsumerVisibility> ... </rasd:ConsumerVisibility> <rasd:Description> ... </rasd:Description> <rasd:ElementName> ... </rasd:ElementName> <rasd:HostResource> ... </rasd:HostResource> <rasd:InstanceID> ... </rasd:InstanceID> <rasd:Limit> ... </rasd:Limit> <rasd:MappingBehavior> ... </rasd:MappingBehavior> <rasd:OtherResourceType> ... </rasd:OtherResourceType> <rasd:Parent> ... </rasd:Parent> <rasd:PoolID> ... </rasd:PoolID> <rasd:Reservation> ... </rasd:Reservation> <rasd:ResourceSubType> ... </rasd:ResourceSubType> <rasd:ResourceType> ... </rasd:ResourceType> 31 СТ РК ISO/IEC 17203–___ (проект, редакция 1) <rasd:VirtualQuantity> ... </rasd:VirtualQuantity> <rasd:Weight> ... </rasd:Weight> </Item> Элементы представляют свойства, доступные в классе CIM_ResourceAllocationSettingData. Они имеют семантику определенных настроек, как определено в DSP1041, любые профили, полученные из DSP1041 для конкретных типов ресурсов, и этот документ. ПРИМЕР: В следующем примере показано, описание размера памяти: <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:Description>Memory Size</rasd:Description> <rasd:ElementName>256 MB of memory</rasd:ElementName> <rasd:InstanceID>2</rasd:InstanceID> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>256</rasd:VirtualQuantity> </Item> Элемент Description используется для обеспечения дополнительных метаданных о самом элементе. Этот элемент позволяет потребителю пакета OVF обеспечить описательную информацию о всех предметах, в том числе о предметах, которые были неизвестны на момент подачи письменного заявления. Элементы Caption, Description и ElementName, которые локализуются с помощью атрибутов ovf: msgid из пространства имен оболочки OVF. См раздел 10 для более подробной информации по поддержке интернационализации. Дополнительный атрибут ovf:configuration содержит список имен конфигурации. См. 9.8 о вариантах развертывания для семантики этого атрибута. Дополнительный атрибут ovf:bound используется, чтобы указать диапазоны; см 8.4. Устройства, такие как диски, CD-ROM, и сетеи должны иметь пленку с платформы развертывания. Требования на обложке либо указать с помощью HostResource или при помощи элемента Connection. Для адаптера Ethernet, логическое имя сети задается в элементе Connection. Ethernet адаптеры, которые относятся к той же логической сети в имени пакета OVF, должны быть развернуты в той же сети. Элемент HostResource используется для обозначения ресурсов, включенных в дескрипторе OVF, а также логических устройств на платформе развертывания. Значения HostResource элементов, связанных с ресурсами, включенных в дескрипторе OVF отформатированы как URI, как указано в таблице 3. 32 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Таблица 3 - Элементов HostResource Содержание Описание ovf:/file/<id> Ссылка на файл в OVF, как указано в разделе Ссылки. <id> должно быть значением атрибута элемента File ovf:id ovf:/disk/<id> Ссылка на виртуальном диске, как указано в DiskSection. <id> должно быть значением атрибута элемента диска ovf: diskid. Если оборот не определен для прибора который требует оборота, платформа развертывания сделает правильный выбор, например через помощь пользователю. Определение более чем одного оборота для прибора не разрешается. Таблица 4 дает краткий обзор того, как используются элементы чтобы описать приборы и контролеры. Таблица 4 –Элементы виртуальных приборов и контролеры Элемент rasd:Description rasd:ElementName rasd:InstanceID rasd:HostResource rasd:ResourceType rasd:OtherResourceType rasd:ResourceSubtype rasd:AutomaticAllocation rasd:Parent Использование Читаемое описание значения информации человеком Например, «Определение размера памяти виртуальной». Описание содержания, читаемое человеком. Например , "256MB память". Уникальный пример ID элемента внутри раздела Абстрактно определяет, как прибор связывается с ресурсом на платформе развертывания. Не всем приборам нужен оборот. См. Таблицу 3. Указывает тип устройства, которое будет описано. Для приборов, которые соединяются, такие как флопидиски, CD-ROM и Ethernet адаптеры, этот элемент определяет, следует ли прибор подключать к электросети. Пример ID исходного контролера (если есть). 33 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Продолжение Таблицы 4 rasd:Connection rasd:Address rasd:AddressOnParent rasd:AllocationUnits rasd:VirtualQuantity rasd:Reservation rasd:Limit rasd:Weight Для Ethernet адаптера, он определяет название абстрактной сети связи к виртуальной машине. Все Ethernet адаптеры. Которые определяют одно и то же название связи абстрактной сети в OVF пакете должны быть расширены в одной и той же сети. Абстрактное имя сетевого подключения должно быть перечислено в NetworkSection на внешнем уровне оболочки Специфика прибора. Для Ethernet адаптера он определяет MAC адрес. Для прибора, это определяет его расположение на контролере. Определяет используемые единицы распределения. Например, "байт* 2^20". Уточняет количество представленных ресурсов. Например, "256". Уточняет минимальное количество ресурсов гарантированных для доступа. Уточняет максимум количества ресурсов, которые допускаются Уточняет относительное преимущество для этого распределения относительно других распределений. Только поля, непосредственно связанные с описывающих устройств упоминаются. Обратитесь к CIM MOF для полного описания всех полей, каждое поле соответствует одноименного свойства в классе CIM_ResourceAllocationSettingData. 8.4 Диапазоны элементов Дополнительный атрибут ovf:bound может быть использован для определения диапазонов для пункта Item. Диапазон имеет минимум, нормально, и максимальное значение, обозначаемое min, normal и max, где min <= normal<= max. Значения по умолчанию для min и max значениям, указанным для normal. Платформа развертывания пакета OVF рекомендует начать с нормального значения, и отрегулировать значение в пределах диапазона для 34 СТ РК ISO/IEC 17203–__ (проект, редакция 1) текущей настройки производительности и проверки. Для пункта элементов в VirtualHardwareSection и элементов ResourceAllocationSection, определяется следующая дополнительная семантика:  Каждый элемент Item имеет необязательный атрибут ovf:bound. Это значение может быть указано, как min, max, или normal. По умолчанию используется normal. Если атрибут не указан или указан как normal, то элемент интерпретируется как часть регулярного виртуального аппарата или распределение ресурса описания.  Если ovf:bound значение указано в любом min или max, элемент используется для указания верхней или нижней границы для одного или нескольких значений для данного экземпляра id. Такой элемент называется диапазон маркер. Семантика сторон маркера такова:  InstanceID и ResourceType должны быть указаны и ResourceType должен соответствовать другим единицам Item с таким же InstanceID. • Задание более одного min диапазона маркера или более чем одного маркера max расстояния для данного RASD (отождествляется с InstanceID) является недействительным. • Пункт Item с диапазоном маркера должен иметь соответствующую единицу Item без диапазона маркера, то есть, единица элемента с не ovf:bound атрибут или ovf:bound атрибут со значением normal. Это соответствующая единица определяет значение по умолчанию. • Для единицы Item, где только указан min диапазон маркера, значение max неограниченно вверх в наборе допустимых значений для свойства. • Для элемента Item, где только указан max диапазон маркера, то min значение неограниченно вниз в наборе допустимых значений для свойства. • Значение по умолчанию должно быть внутри диапазона. • Использование нецелых значений элементов маркера диапазона RASDs, является недействительным. ПРИМЕР: В следующем примере показано использование маркеров дальности: <VirtualHardwareSection> <Info>...</Info> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:ElementName>512 MB memory size</rasd:ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:ResourceType>4</rasd:ResourceType> 35 СТ РК ISO/IEC 17203–___ (проект, редакция 1) <rasd:VirtualQuantity>512</rasd:VirtualQuantity> </Item> <Item ovf:bound="min"> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:ElementName>384 MB minimum memory size</ rasd: ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:Reservation>384</rasd:Reservation> <rasd:ResourceType>4</rasd:ResourceType> </Item> <Item ovf:bound="max"> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:ElementName>1024 MB maximum memory size</rasd:ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:Reservation>1024</rasd:Reservation> <rasd:ResourceType>4</rasd:ResourceType> </Item> </VirtualHardwareSection> 9 Разделы основных метаданных В таблице 5 приведены основные разделы метаданных, которые определены. Таблица 5 - Основные разделы метаданных Раздел Расположение DiskSection Оболочка Описывает мета-информацию о виртуальных дисках в пакете NetworkSection Раздел сети описывает логические сети используемые в пакете ResourceAllocationSection Определяет бронирование, лимиты, и доли в данных ресурсах, такие как память или процессор для коллекции виртуальных машин AnnotationSection Определяет аннотации в свободной форме 36 Множественность Ноль или один Оболочка Ноль или один Коллекция виртуальных систем Ноль или один Виртуальные системы Коллекция виртуальных систем Ноль или один СТ РК ISO/IEC 17203–__ (проект, редакция 1) Продолжение Таблицы 5 ProductSection Определяет информацию о продукте для пакета, такую как название продукта и версия, вместе с набором свойств которая может быть конфигурирована EulaSection Определяет лицензированное соглашение для программного обеспечения в пакете Виртуальные системы Коллекция виртуальных систем Ноль или более Виртуальные системы Коллекция виртуальных систем StartupSection Коллекция Определяет как коллекция виртуальных виртуальных машин включается систем DeploymentOptionSection Оболочка Задает дискретное множество потребностей в предназначенных ресурсах OperatingSystemSection Виртуальные Определяет установленные гостевые системы операционные системы виртуальной машины InstallSection Виртуальные Определяет, что виртуальной машине системы нужно сначала инсталлироваться и конфигурировать программное обеспечение Ноль или более Ноль или один Ноль или один Ноль или один Ноль или один Следующие подразделы описывают семантику основных разделов и приводят несколько примеров. Разделы используются в нескольких местах оболочки OVF; описание каждого раздела определяет, где он может быть использован. Смотрите схему OVF для детального уточнения всех атрибутов и элементов. В схеме OVF, все секции являются частью группы замены элемента с Section в качестве главы группы замены. Элемент Section абстрактный и не может быть использован непосредственно. 9.1 Раздел DiskSection DiskSection описывает мета-информацию о виртуальных дисках в 37 СТ РК ISO/IEC 17203–___ (проект, редакция 1) пакете OVF. Виртуальные диски и их метаданные описаны вне виртуальной аппаратной, чтобы способствовать обмену между виртуальными машинами в пределах пакета OVF. ПРИМЕР: В следующем примере показано описание виртуальных дисков: <DiskSection> <Info>Describes the set of virtual disks</Info> <Disk ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:capacity="8589934592" ovf:populatedSize="3549324972" ovf:format= "http://www.vmware.com/interfaces/specifications/vm dk.html#sparse"> </Disk> <Disk ovf:diskId="vmdisk2" ovf:capacity="536870912" </Disk> <Disk ovf:diskId="vmdisk3" ovf:capacity="${disk.size}" ovf:capacityAllocationUnits="byte * 2^30" </Disk> </DiskSection> DiskSection является действительным разделом только в удаленном уровне оболочки. Каждый виртуальный диск представлен элементом Disk, которому должен быть дан идентификатор с помощью ovf:diskId атрибута; идентификатор должен быть уникальным в пределах DiskSection. Емкость виртуального диска должна быть указана атрибутом ovf:capacity с xs:long. По умолчанию единицей распределения должен быть байт. Необязательный строковый атрибут ovf:capacityAllocationUnits могут быть использованы для указания конкретного подразделения распределения. Значения для ovf:capacityAllocationUnits должны соответствовать формату программных единиц, определенных в DSP0004 с ограничением, что базовый блок должен быть "байт". Атрибут ovf: fileRef обозначает содержание виртуального диска путем выявления существующего элемента File в элементе References, элемент File определяется путем сопоставления его атрибута ovf:id со значением атрибута ovf:fileRef. Опускаемый атрибут ovf:fileRef указывает на пустой диск. В этом случае, диск должен быть создан, и полное содержание диска обнуляется во время установки. Гостевое программное обеспечение, как правило, форматирует пустые диски в некотором формате файловой системы. Формат URI (см 5.2) из непустого виртуального диска должен быть указан атрибутом ovf:format. 38 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Различные элементы Disk не должны содержать ovf: fileRef атрибуты с одинаковыми значениями. Элементы Disk должны быть заказаны, так что они определяют какие-либо элементы File в том же порядке, как это определено в элементе References. Для пустых дисков, вместо указания фиксированного объем виртуального диска, емкость для пустого диска может быть дана с помощью свойств OVF, например ovf:capacity="${disk.size}". В отделе OVF решает xs:long целое значение. См 9.5 для описания свойств OVF. Атрибут ovf:capacityAllocationUnits полезен при использовании свойства OVF, так как пользователю может быть предложено, а затем можно ввести диск информации о размерах, например, гигабайты. Для непустых дисков, при текущем использовании размер диска, необязателен, может быть определен с помощью атрибута ovf:populatedSize. Устройство этого атрибута всегда байт, позволяет оценивать использованние размера диска, но не должен быть больше, чем ovf:capacity. VirtualHardwareSection должен быть определен в атрибуте rasd:HostResource на элементе DiskSection. Если элемент rasd:VirtualQuantity задается вместе с rasd:HostResource, виртуальное значение количества не должно быть рассмотрено и может иметь любое значение. OVF обеспечивает образ диска, чтобы быть представленным как набор модифицированных блоков в сравнении с родительским образом. Применение родительских дисков зачастую может существенно снизить размер пакета OVF, если в ней несколько дисков с одинаковым содержанием. Для элемента Disk, родитель диск, необязательно, может быть указан с помощью атрибута ovf:parentRef, который должен содержать действительный ovf:DiskID ссылку на другой элемент Disk. Если на диске блок не существует локально, поиск для этого блока на диске, то происходит в родительском диске. В DiskSection, элементы родительского диска должна произойти до элементов дочерних Disk, которые относятся к ним. 9.2 Раздел сети Элементу NetworkSection следует причислить все логические сети, используемые в пакете OVF. <NetworkSection> <Info>List of logical networks used in the package</Info> <Network ovf:name="red"> <Description>The network the Red service is available on</Description> </Network> 39 СТ РК ISO/IEC 17203–___ (проект, редакция 1) <Network ovf:name="blue"> <Description>The network available on</Description> </Network> </NetworkSection> the Blue service is NetworkSection является допустимым элементом во внешнем уровне оболочки. Все сети, упомянутых элементов Connection всех элементов VirtualHardwareSection должны быть определены в NetworkSection. 9.3 Раздел распределения ресурсов Элемент ResourceAllocationSection описывает все требования к распределению ресурсов из коллекции VirtualSystemCollection. Эти выделения ресурсов осуществляются при развертывании пакета OVF. <ResourceAllocationSection> <Info>Defines reservations for CPU and memory for the collection of VMs</Info> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:ElementName>300 MB reservation</rasd:ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:Reservation>300</rasd:Reservation> <rasd:ResourceType>4</rasd:ResourceType> </Item> <Item ovf:configuration="..." ovf:bound="..."> <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> <rasd:ElementName>500 MHz reservation</rasd:ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:Reservation>500</rasd:Reservation> <rasd:ResourceType>3</rasd:ResourceType> </Item> </ResourceAllocationSection> Дополнительный атрибут ovf:configuration и содержит список имен конфигурации. См 9.8 о вариантах развертывания для семантики этого атрибута. Дополнительный атрибут ovf:bound содержит значение min, max, или normal.. См 8.4 для семантики этого атрибута. 9.4 Раздел аннотации Элемент AnnotationSection является определенным пользователем аннотации на объект. Такие аннотации могут отображаться при 40 СТ РК ISO/IEC 17203–__ (проект, редакция 1) развертывании пакета OVF. <AnnotationSection> <Info> Аннотации на этом сервисе. Это может быть проигнорировано </Info> <Annotation> Обратитесь в службу поддержки клиентов, если у вас есть какие-либо проблемы </Annotation> </AnnotationSection > AnnotationSection является действительным элементом для VirtualSystem и VirtualSystemCollection. См. раздел 10 для деталей о том, как локализовать элемент Annotation. 9.5 Раздел ProductSection Элемент ProductSection определяет продукт-информацию для прибора, такую как название продукта, версию и поставщика <ProductSection ovf:class= "com.mycrm.myservice" ovf:instance="1"> <Info>Describes product information for the service</Info> <Product>MyCRM Enterprise</Product> <Vendor>MyCRM Corporation</Vendor> <Version>4.5</Version> <FullVersion>4.5-b4523</FullVersion> <ProductUrl>http://www.mycrm.com/enterprise</ProductUrl> <VendorUrl>http://www.mycrm.com</VendorUrl> <Icon ovf:height="32" ovf:width="32" ovf:mimeType="image/png" ovf:fileRef="icon"> <Category>Email properties</Category> <Property ovf:key="admin.email" ovf:type="string" ovf:userConfigurable="true"> <Label>Admin email</Label> <Description>Email address of administrator</Description> </Property> <Category>Admin properties</Category> <Property ovf:key="app.log" ovf:type="string" ovf:value="low" ovf:userConfigurable="true"> <Description>Loglevel for the service</Description> </Property> <Property ovf:key="app.isSecondary" ovf:value="false" ovf:type="boolean"> <Description>Cluster setup for application server</Description> </Property> <Property ovf:key="app.ip" ovf:type="string" ovf:value="${appserver-vm}"> 41 СТ РК ISO/IEC 17203–___ (проект, редакция 1) <Description>IP address of the application server VM</Description> </Property> </ProductSection> Дополнительный элемент Product определяет название продукта, в то время как дополнительный элемент Vendor задает имя поставщика продукта. Необязательный элемент Version определяет версию продукта в краткой форме, в то время как элемент FullVersion описывает полную версию продукта в полной форме. Дополнительный элемент ProductUrl определяет URL, который должен быть разрешен человеку чтобы четко описывать продукт, в то время как дополнительный VendorUrl определяет URL, который должен разрешить человеку четкое описание поставщика. Дополнительный элемент AppUrl указывает URL разрешающий, к примеру, развертку продукции; этот элемент является экспериментальным. Дополнительный элемент Icon определяет отображение образа для продукта; этот элемент является экспериментальным. Элементы Property задают параметры настройки на уровне приложений и особенно актуальны для приборов, которые должны быть настроены во время развертывания с конкретными настройками, такими как сеть идентичности, IP-адреса DNS-серверов, шлюзов и других. ProductSection является действительным разделом для VirtualSystem и организации VirtualSystemCollection. Элементы Property могут быть сгруппированы с помощью элементов Category. Множество элементов Property, сгруппированных по категории элемента является последовательностью элементов Property после элемента Category, до тех пор, пока не включены элементы, которые не является элементами Property. Для OVF упаковок, содержащих большое количество элементов Property, это может обеспечить более простой опыт установки. Аналогично, каждый элемент Property может иметь краткую метку, определяемую дочерним элементом Label, в дополнение к описанию и определяется дочерним элементом Description. См раздел 10 для деталей о том, как локализовать элемент Category, описание и дочерних единиц Label элемента Property. Каждый элемент Property в разделе ProductSection дается как идентификатор, который является уникальным в пределах ProductSection с помощью атрибута ovf:key. Каждому элементу Property в ProductSection задается тип с помощью атрибута ovf: type и возможно, отборочные типы с использованием атрибута ovf:qualifiers. Допустимые типы перечислены в таблице 6, и действительные в отборочных приведены в таблице 7. 42 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Необязательный атрибут ovf:value который используется для обеспечения значение по умолчанию для свойства. Один или более атрибутов Value, могут быть использованы для определения альтернативных значений по умолчанию для конкретной конфигурации, как определено в 9.8. Необязательный атрибут ovf:userConfigurable пользователем определяет, является ли значение свойства настраиваемым на этапе монтажа. Если значение ovf:userConfigurable ЛОЖЬ или опущен, то атрибут ovf:value определяет значение, которое будет использовано для этого параметра настройки во время установки. Если ovf:userConfigurable ИСТИНА, атрибут ovf:value определяет значение по умолчанию для этого параметра настройки, который может быть изменен во время установки. Простая реализация OVF, такая как командная строка установщика, как правило, использует значения по умолчанию для свойств и не подскажет, хотя ovf:userConfigurable установлен в TRUE. Для принудительного наведения при запуске, опуская атрибут ovf:value достаточно для целых типов, потому что пустая строка не является допустимым целым числом. Для строковых типов, побуждение может быть достигнуто добавлением определителя требующий определения непустая строка, таблица 7. Необязательный Логический атрибут ovf:password показывает, что стоимость имущества может содержать конфиденциальную информацию. Значение по умолчанию неверно. OVF реализация запроса на значения свойств советует скрыть эти значения, когда ovf:password установлен на значение TRUE. Это похоже на HTML ввод текста типа password. Следует отметить, что этот механизм обеспечивает только ограниченную защиту безопасности. Хотя чувствительные значения маскируются от случайных наблюдателей, значения по умолчанию в дескрипторе OVF и назначенные значения в окружающей среде OVF-прежнему передаются в незашифрованном виде. Ноль или более ProductSections могут быть указаны VirtualSystem или VirtualSystemCollection. Как правило, ProductSections соответствует конкретному программному продукту, который установлен. Каждый раздел продукции на том же уровне, что и предприятие должно иметь уникальный ovf:class и ovf:instance атрибута. Для общего случая, когда используется только один ProductSections, атрибуты ovf:class и ovf:instance являются необязательными и по умолчанию к определению пустая строка. Рекомендуется, чтобы свойства ovf:class можно было использовать для однозначной идентификации программного продукта с помощью обратного домена конвенции. Примеры значений com.vmware.tools и org.apache.tomcat. Если несколько экземпляров одного и того же 43 СТ РК ISO/IEC 17203–___ (проект, редакция 1) продукта установлены, атрибут ovf:instance используется для идентификации разных экземпляров. Свойства элементов подвергаются гостевому программному обеспечению через среду OVF, как описано в пункте 11. Значение ovfenv:key атрибут элемента Property подвергается в OVF среде, должно быть построено из стоимости ovf:key соответствующего элемента Property, определенной в ProductSection субъекта дескриптора OVF следующим образом: key-value-env = [class-value"."] key-value-prod ["." instance-value] где:  class-value является значением ovf:class атрибута элемента Property, определенной в ProductSection объект. Продукт [classvalue "."] должно присутствовать, если и только если class-value не является пустой строкой.  key-value-prod- значение атрибута ovf:key элемента Property, определенный в части ProductSection. Продукт ["."instance-value] должно быть, если только instance-value не пустая строка. Пример: В следующем OVF примере показывается, как среда свойства может быть распространена на гостевое программное обеспечение: <Proper ovf:k "co vmwa tool logLev ovf:valu none"/> <Proper ovf:k "or apach tomc . . ovf:valu debug"/> ty ey= m. re. s. el" e=" <Proper ovf:k "or tomc . normal"/> ty ey= g. apach e. at logLeve . 1 ovf:valu e=" ty Потребитель ey= g.пакета e. at должен logLeve 2 e=" OVF запросить свойства, где значение l " l ovf:userConfigurable ИСТИНА. Эти" свойства могут быть определены в нескольких ProductSections а также в суб-объектах в пакете OVF. Если существует ProductSection, то первая часть ProductSection определяется в содержании верхнего уровня элемента Content и должна определить суммарную информацию, которая описывает весь пакет. После установки, потребитель пакета OVF может выбрать, чтобы сделать эту информацию доступной в качестве экземпляра класса CIM_Product. Элементы Property, указанные в VirtualSystemCollection также видимы его непосредственными производными (см пункт 11). Производные могут обратиться к свойствам исходного VirtualSystemCollection с использованием макросов на форме ${name} в качестве значения для атрибута ovf:value. Таблица 6 перечисляет допустимые типы для свойств. Они представляют собой подмножество CIM встроенных типов, определенных в DSP0004, которые также определяют значение пространства и формат для 44 СТ РК ISO/IEC 17203–__ (проект, редакция 1) каждого встроенного типа. Каждый элемент Property указывает тип использования атрибута ovf:type. Таблица 6 - Типы свойств Тип Описание uint8 Неподписанный 8-бит целое sint8 Подписанный 8- бит целое uintl6 Неподписанный 16- бит целое sintl6 Подписанный 16- бит целое uint32 Неподписанный 32- бит целое sint32 Подписанный 32- бит целое uint64 Неподписанный 64- бит целое sint64 Подписанный 64-разрядное целое число string Строка boolean Логический real32 IEEE 4-байт плавающая запятая real64 IEEE 8-байт плавающая запятая В таблице 7 Классификация свойств, поддерживаемых типов CIM, определенных в DSP0004. Каждый элемент Property может дополнительно указать отборочные типы с использованием атрибутов ovf:qualifiers с несколькими классификаторами, разделенные запятыми; см представленный qualifierList в Приложении А "МФ Синтаксис Грамматики Описания" в DSP0004. Таблица 7 - Классификация свойств Тип Описание string MinLen(min) MaxLen(max) ValueMap{...} 45 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Продолжение Таблицы 7 uint8 sint8 uint16 sint16 uint32 sint32 uint64 sint64 uint32 sint32 uint64 sint64 ValueMap{...} 9.6 Раздел EulaSection EulaSection содержит юридические условия для использования исходного элемента Content. Эта лицензия должна быть показана и принимается в течении развертывания пакета OVF. Несколько EulaSections может присутствовать в OVF. Если без просмотра установки будут разрешены, все лицензии неявно принимаются. <EulaSection> <Info>Licensing agreement</Info> <License> Lorem ipsum dolor sit amet, ligula suspendisse nulla pretium, rhoncus tempor placerat fermentum, enim integer ad vestibulum volutpat. Nisl rhoncus turpis est, vel elit,congue wisi enim nunc ultricies sit, magna tincidunt. Maecenas aliquam maecenas ligula nostra, accumsan taciti. Sociis mauris in integer, a dolor netus non dui aliquet,sagittis felis sodales, dolor sociis mauris, vel eu libero cras. Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor class, ut adipiscing, aliquet sed auctor, imperdiet arcu per diam dapibus libero duis. Enim eros in vel, volutpat nec pellentesque leo, scelerisque. </License> </EulaSection> EulaSection является действительным разделом для VirtualSystem и части VirtualSystemCollection. См раздел 10 для деталей о том, как локализовать элемент License. 46 СТ РК ISO/IEC 17203–__ (проект, редакция 1) 9.7 Раздел ввода в эксплуатацию StartupSection определяет, как коллекция виртуальная машина работает и выключается. <StartupSection> <Item ovf:id="vm1" ovf:order="0" ovf:startDelay="30" ovf:stopDelay="0" ovf:startAction="powerOn" ovf:waitingForGuest="true" ovf:stopAction="powerOff"/> <Item ovf:id="teamA" ovf:order="0"/> <Item ovf:id="vm2" ovf:order="1" ovf:startDelay="0" ovf:stopDelay="20" ovf:startAction="powerOn" ovf:stopAction="guestShutdown"/> </StartupSection> Каждый элемент Content, является прямым потомком в VirtualSystemCollection и может иметь соответствующий элемент Item в StartupSection объекта данного VirtualSystemCollection. Обратите внимание, что элементы Item могут соответствовать как VirtualSystem и VirtualSystemCollection образований. Когда начало или остановка действия выполняется на VirtualSystemCollection объект, соответствующие действия по этим Item элементов его StartupSection объект вызываются в указанном порядке. Всякий раз, когда Item элемент соответствует (вложенному) части VirtualSystemCollection, действия по этим Item элементов его StartupSection объект должны ссылаться на действие Item элемента, соответствующего этой VirtualSystemCollection объект вызывается (т.е. в глубину обхода). Следующие необходимые атрибуты по Item поддерживаются, где указаны VirtualSystem и VirtualSystemCollection. • ovf:id должно соответствовать значению ovf:id атрибута элемента содержимого, который является прямым исходным этого VirtualSystemCollection. Этот элемент Content описывает виртуальную машину или сбор виртуальных машин, в которой действия, определенные в применяемой единице Item. • ovf:order определяет порядок запуска, используя неотрицательные целые значения. Item с таким же идентификатором заказа может быть запущен одновременно. Порядок исполнения стоп действия является в численном порядке убывания значений. Следующие необязательные атрибуты элемента поддерживаются, где указано VirtualSystem: • ovf:startDelay определяет задержку в секундах, чтобы ждать, 47 СТ РК ISO/IEC 17203–___ (проект, редакция 1) пока перейдёт к следующему в порядке последовательности запуска. Значение по умолчанию равно 0. • ovf: waitingForGuest позволяет платформе для возобновления последовательности запуска после гостевого программного обеспечения сообщила, что она готова. Интерпретация этой платформы развертывания специфичны. Значение по умолчанию FALSE • ovf:startAction определяет начальное действие, чтобы использовать. допустимые значения powerOn и none. Значение по умолчанию powerOn. • ovf: stopDelay определяет задержку в секундах, чтобы ждать, пока приступить к предыдущему в порядке последовательности остановки. Значение по умолчанию равно 0. • • определяет стоп действия, чтобы использовать допустимые значения выключения, guestshutdown, и нет. Интерпретация guestshutdown от платформы развертывания специфична. Значение по умолчанию выключено. • ovf: stopAction определяет стоп действия, чтобы использовать. Допустимые значения powerOff, guestShutdown, и none. Интерпретация guestShutdown от платформы развертывания специфичны. Значение по умолчанию powerOff. Если не указано, неявный Item по умолчанию создается для каждого объекта в коллекции с ovf:order="0". Таким образом, для тривиального последовательного запуска startupSection не нужно указывать. 9.8 Раздел развертывания вариантов DeploymentOptionSection определяет дискретный набор предназначенных конфигураций ресурсов. Автор пакета OVF может включать в себя метаданные для калибровки различных конфигураций. Потребитель в OVF должен выбрать конфигурацию, например, путем подсказки пользователю. Выбранная конфигурация является видимым в среде OVF, позволяя гостевому программному обеспечению адаптироваться к выбранной конфигурации. См пункт 11. DeploymentOptionSection определяет идентификатор, этикетку и описание для каждой конфигурации. <DeploymentOptionSection> <Configuration ovf:id="Minimal"> <Label>Minimal</Label> <Description>Some description</Description> </Configuration> <Configuration ovf:id="Typical" ovf:default="true"> <Label>Typical</Label> <Description>Some description</Description> 48 СТ РК ISO/IEC 17203–__ (проект, редакция 1) </Configuration>  </DeploymentOptionSection> DeploymentOptionSection имеет следующую семантику: • Если присутствует, DeploymentOptionSection действует только на уровне огибающей, и только одинраздел должен быть указан в дескрипторе OVF. • • Дискретный набор конфигураций описан с элементами Configuration, которые должны иметь идентификаторы, указанные в атрибуте ovf:id, которые являются уникальными в пакете. • элемент Configuration по умолчанию может быть указан с дополнительным атрибутом ovf:default. Если значение по умолчанию не указано, то первый элемент в списке по умолчанию. Задание более одного элемента по умолчанию является недействительным. • Элементы Label и Description локализуемые с помощью атрибута ovf:msgid. Смотрите пункт 10 для более подробной информации по поддержке интернационализации. Конфигурации могут быть использованы для управления ресурсами для виртуального оборудования и коллекций виртуальных машин. Item элементы в элементах VirtualHardwareSection описать ресурсы для VirtualSystem образований, в то время как Item элементов в ResourceAllocationSection описывают ресурсов для коллекций виртуальных машин. Для этих двух типов элементов определяется следующая дополнительная семантика: Каждая единица элемента имеет необязательный атрибут ovf:configuration, содержащий список конфигураций отделенных друг от друга одним пробелом. Если не указано, то пункт должен быть выбран для любой конфигурации. Если указано, пункт должен быть выбран только, если выбранная конфигурация ID есть в списке. Атрибут конфигурации не должен содержать идентификатор, который не указан в DeploymentOptionSection. В пределах одного VirtualHardwareSection или ResourceAllocationSection, несколько единиц элемента допускаются, чтобы обратиться к той же InstanceID. Один в сочетании элемент Item для данного InstanceID должен быть сконструирован, подбирая дочерние элементы каждого элемента Item, с дочерних элементов бывшего элемента Item в дескрипторе OVF не взятого, если есть сходно названный дочерний элемент в последнем пункте элемента. Любые атрибуты, указанные на дочерних элементах единицы Item, которые не подобрали, таким образом, не являются частью комбинированной единицы Item. 49 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Все элементы Item должны указать ResourceType, и элемент Item с той же InstanceID договариваются о ResourceType. ПРИМЕР 1: В следующем примере показан раздел виртуальной аппаратуры: <VirtualHardwareSection> <Info>...</Info> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:ElementName>512 MB memory size and 256 MB reservation</rasd:ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:Reservation>256</rasd:Reservation> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>512</rasd:VirtualQuantity> </Item> ... <Item ovf:configuration="big"> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:ElementName>1024 MB memory size and 512 MB reservation</rasd:ElementName> <rasd:InstanceID>0</rasd:InstanceID> <rasd:Reservation>512</rasd:Reservation> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>1024</rasd:VirtualQuantity> </Item> </VirtualHardwareSection> Следует отметить, что атрибуты ovf:configuration и ovf:bound элемент Item может быть использован в сочетании, чтобы обеспечить очень гибкие варианты конфигурации. Конфигурации в дальнейшем могут быть использованы для управления значения по умолчанию для свойств. Для элементов Property внутри ProductSection, следующая дополнительная семантика определяется:  Можно использовать альтернативные значения свойств по умолчанию для различных конфигураций в DeploymentOptionSection. В дополнение к Label и элементу Description, каждый элемент Property может содержать элементы Value. Элементы Value должны иметь атрибут ovf:value, определяющий альтернативный по умолчанию и атрибут ovf:configuration, указывающий конфигурацию, в которой должны быть использованы эти новые значения по умолчанию. Несколько элементов Value не относятся к одной и той же конфигурации. ПРИМЕР 1: В следующем примере показан раздел ProductSection: <ProductSection> 50 СТ РК ISO/IEC 17203–__ (проект, редакция 1) <Property ovf:key="app.log" ovf:type="string" ovf:value="low" ovf:userConfigurable="true"> <Label>Loglevel</Label> <Description>Loglevel for the service</Description> <Value ovf:value="none" ovf:configuration="minimal"> </Property> </ProductSection> 9.9 Раздел операционных систем OperatingSystemSection определяет установленную на виртуальной машине. операционную систему, <OperatingSystemSection ovf:id="76"> <Info>Specifies the operating system installed</Info> <Description>Microsoft Windows Server 2008</Description> </OperatingSystemSection> Допустимые значения для ovf:id определяются ValueMap в свойстве CIM_OperatingSystem.OsType. отборочного 9.10 Раздел установок Раздел InstallSection, как указано, показывает, что виртуальная машина должна быть загружена для того, чтобы установить и / или настроить гостевое программное обеспечение. Гостевое программное обеспечение, как предполагается имеет доступ к среде ОВФ в этом багаже, и закрывается после завершения установки и / или настройки программного обеспечения, выключения гостя. Если раздел InstallSection не указан, то это означает, что виртуальная машина не должна быть включена, чтобы завершить установку гостевым программным обеспечением <InstallSection ovf:initialBootStopDelay="300"> <Info>Specifies that the virtual machine needs to be booted once after having created the guest software in order to install and/or configure the software </Info> </InstallSection> InstallSection является действительным раздел для только объекта VirtualSystem. Дополнительный атрибут ovf: initialBootStopDelay определяет ожидание задержки в секундах, для выключения виртуальной машины. Если не установлено, реализуется ожидание виртуальной машины, для самостоятельного выключения. 51 СТ РК ISO/IEC 17203–___ (проект, редакция 1) В случае истечения просрочки, и виртуальная машина не выключена, потребитель пакета OVF должен указать на отказ. Обратите внимание, что гость программного обеспечения в виртуальной машине может сделать несколько перезагрузок перед выключением. Несколько VMs в коллекции виртуальной машины может иметь определенный InstallSection, в этом случае вышеуказанный шаг сделан для каждой VMs машины, потенциально одновременно. 10 Интернационализация Следующие элементы поддерживают локализуемые сообщения, используемые дополнительно атрибутом ovf:msgid: • Info в элементе Content • • Name в элементе Content • • Info в разделе Section • Annotation в элементе AnnotationSection • License в элементе EulaSection • Description в элементе NetworkSection • Description в элементе OperatingSystemSection • Description, Product, Vendor, Label, и Category в элементах ProductSection • Description и Label в элементах Property • Description и Label в элементе DeploymentOptionSection • ElementName, Caption и подэлементы Description элемента System в VirtualHardwareSection • ElementName, Caption и подэлементы Description элементы Item в VirtualHardwareSection • ElementName, Caption и подэлементы Description в элементы Item в ResourceAllocationSection. Атрибут ovf:msgid содержит идентификатор, который относится к сообщению, которое может иметь различные значения в разных местах. ПРИМЕР 1: <Info ovf:msgid="info.text">Default info.text value if no locale is set or no locale match</Info> <License ovf:msgid="license.tomcat-6_0"/>  Атрибут xml:lang на элементе Envelope должен указать локализацию по умолчанию для сообщений в дескрипторе. Атрибут является необязательным со значением по умолчанию " en-US". 52 СТ РК ISO/IEC 17203–__ (проект, редакция 1) Пакеты ресурсов сообщение могут быть внутренними или внешними по дескриптору OVF. Внутренние пакеты ресурсов представлены в виде Strings элементов в конце элемента Envelope. ПРИМЕР 2: <ovf:Envelope xml:lang="en-US"> ... ... Разделы и содержание здесь... ... <Info msgid="info.os">Operating System</Info> ... <Strings xml:lang="da-DA"> <Msg ovf:msgid="info.os">Operativsystem</Msg> ... </Strings> <Strings xml:lang="de-DE"> <Msg ovf:msgid="info.os">Betriebssystem</Msg> ... </Strings> </ovf:Envelope> Внешние пакеты ресурсов должны быть указаны первыми в разделе References и ссылаться на элементы Strings. Внешний пучок сообщения по той же схеме, что и встроенный. Именно один элемент Strings должна присутствовать во внешнем пучке сообщений, и этот элемент Strings не может иметь атрибут ovf:fileRef как указано. ПРИМЕР 3: <ovf:Envelope xml:lang="en-US"> <References> ... <File ovf:id="it-it-resources" ovf:href="resources/it-it-bundle.msg"/> </References> ... sections and content here ... ... <Strings xml:lang="it-IT" ovf:fileRef="it-itresources"/> ... </ovf:Envelope> ПРИМЕР 4: Примерное содержание внешних ресурсов / -это bundle.msg файлы, на которые ссылались в предыдущем примере: <Strings xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns="http://schemas.dmtf.org/ovf/envelope/1" xml:lang="it-IT"> <Msg ovf:msgid="info.os">Sistema operativo</Msg> ... </Strings> 53 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Элементы встроенных и внешних Strings могут чередоваться, но они должны быть помещены в конце элемента Envelope. Если несколько вхождений атрибута msg:id происходит с данного места, то последнее значение перезаписывает предыдущее. 11 OVF среда Среда OVF определяет, как гостевое программное обеспечение и платформа развертывания взаимодействуют. Эта среда позволяет гостевому программному обеспечению иметь доступ к информации о платформе развертывания, такой как заданные пользователем значения для свойств, определенных в дескрипторе OVF. Спецификация среды разделяется на 2 части: протокола и транспортную части. Часть протокола определяет формат и семантику XML документа, который можно сделать доступными для гостевого программного обеспечения. Транспортная часть определяет, как сообщается информация между платформой развертывания и гостевым программным обеспечением. Файл определение схемы XML - dsp8027_1.1.0.xsd для окружающей среды OVF содержит элементы и атрибуты. 11.1 Документ Environment Документ среда представляет собой расширяемый XML-документ, который предоставляется гостевым программным обеспечением об окружающей среде, в которой она выполняется. Таким образом, получается, что документ зависит от типа транспортного обеспечения. ПРИМЕР: Пример структуры среды OVF выглядит следующим образом: <?xml version="1.0" encoding="UTF-8"?> <Environment xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:ovfenv="http://schemas.dmtf.org/ovf/environm ent/1" xmlns="http://schemas.dmtf.org/ovf/environment/1" ovfenv:id="identification of VM from OVF descriptor">  <PlatformSection> <Kind>Type of virtualization platform</Kind> <Version>Version of virtualization platform</Version> <Vendor>Vendor of virtualization platform</Vendor> <Locale>Language and country code</Locale> <TimeZone>Current timezone offset in minutes from UTC</TimeZone> </PlatformSection> 54 СТ РК ISO/IEC 17203–__ (проект, редакция 1)  <PropertySection> <Property ovfenv:key="key" ovfenv:value="value">  </PropertySection> <Entity ovfenv:id="id of sibling virtual system or virtual system collection"> <PropertySection>  </PropertySection> </Entity> </Environment> Значение ovfenv:id атрибута элемента Environment должны соответствовать значению ovf:id атрибута объекта VirtualSystem, описывающего эту виртуальную машину. Элемент PlatformSection содержит дополнительную информацию, представленную платформе развертывания. Элементы: Kind, Version и Vendor описывают развертывание подробностей о платформе поставщика; эти элементы являются экспериментальными. Элементы: Locale и TimeZone описывают текущую локализацию и часовой пояс; эти элементы являются экспериментальными. Элемент PropertySection содержит элементы объекта Property с парой ключ/значение, соответствующие всем свойствам, указанным в дескрипторе OVF для текущей виртуальной машины, а также свойствами, указанными в непосредственной исходной/родительской VirtualSystemCollection, если таковой существует. Среда представляет свойства, как простой список, чтобы сделать его легким для анализа приложения. Кроме того, единый формат поддерживает список переопределения семантики, где это свойство на VirtualSystem может переопределить один, определенный в материнской коллекции VirtualSystemCollection. Переопределенное свойство не должно быть в списке. Может случиться, что переопределение свойства в текущей виртуальной машине и свойства в материнской коллекции VirtualSystemCollection будут иметь одинаковые атрибуты экземпляра ovf:key, ovf:class, и ovf:instance; см. 9.5. В этом случае, значение перекрытого исходного/родительского имущества может быть получено путем добавления разных имен исходному свойства, ссылающегося на исходное/родительское свойство с помощью макроса; см. 9.5. Элемент Entity существует как родственный для каждой VirtualSystem и VirtualSystemCollection, если они присутствуют. Значение атрибута ovfenv:id элемента Entity должно соответствовать значению атрибута ovf:id родственного объекта. Элемент Entity 55 СТ РК ISO/IEC 17203–___ (проект, редакция 1) содержит пары ключ/значение недвижимости в OVF среде родственных документов, так содержание элемента Entity для конкретного и родственного документа должен содержать точный раздел PropertySection видимый этим родственным. Эта информация может быть использована, например, чтобы сделать информацию о конфигурации, такой как IP-адреса, доступной для VirtualSystems являющейся частью многоуровневого приложения. В таблице 8 показаны основные разделы, которые определены. Таблица 8 – Основные разделы Раздел PlatformSection Обеспечивает информацией из платформы развертывания PropertySection Содержит пары ключ/значение соответствующие недвижимости обозначенной в OVF дескрипторе Локализация Environment Множестве нность Ноль или один Environment Entity Ноль или один Документ среда является расширяемым и предоставляет новые типы разделов. Потребитель документа не должен обращать внимание неизвестные типы разделов и элементы. 11.2 Транспорт Информация о документах раздела среда может быть передана несколькими способами гостевого программного обеспечения. Эти способы называются типами транспорта. Типы транспорта указаны в дескрипторе OVF по атрибуту ovf:transport раздела VirtualHardwareSection. Несколько видов транспорта может быть указано и разделено одним пробелом, в этом случае реализация может свободно использоваться любой из них. Типы транспорта определяют методы, с помощью которых документ о среде передается от платформы развертывания в гостевое программное обеспечение. Для обеспечения совместимости, эта спецификация определяет "iso" тип транспорта, все реализации, которого поддерживают CD-ROM устройства, необходимые для поддержки. Iso транспорта связан с документом окружающей среды, производя динамически генерируемые изображения ISO доступные для гостевого программного обеспечения. Для поддержки транспорта типа iso, перед загрузкой виртуальной машины, реализация 56 СТ РК ISO/IEC 17203–__ (проект, редакция 1) должна быть сделана ISO только для чтения образа диска, которая поставляется в качестве поддержки для отключенного CD-ROM. Если выбран iso транспорта для раздела VirtualHardwareSection и по крайней мере, один отключен, CD-ROM устройство должно быть представлено в этом разделе. Созданный ISO-образ должен соответствовать ISO 9660 спецификации с поддержкой расширений Joliet. ISO образ должен содержать среду OVF для этой конкретной виртуальной машины и среда должна присутствовать в XML файле ovfenv.xml, который содержится в корневом каталоге образа ISO. Теперь гостевое программное обеспечение может получить доступ к информации, используя стандартные инструменты гостевой операционной системы. Если виртуальная машина до загрузки имела более одного отключенного CD-ROM, гостевое программное обеспечение, возможно, будет сканировать подключенные CD-ROM устройства для того, чтобы найти изображение ISO, содержащие файл ovf-env.xml. ISO образ, содержащий среду OVF должен быть доступнымдля гостевого программного обеспечения при каждой загрузке виртуальной машины. Поддержка "iso" транспортного типа не является обязательным требованием для виртуальных аппаратных архитектур или гостевых операционных систем, которые не имеют поддержки CD-ROM устройства. Чтобы быть совместимым с этой спецификацией, любой транспортный формат, кроме ISO должен быть задан URI, который идентифицирует неизрасходованные спецификации о том, как использовать транспорт. Спецификация не обязательно должна быть машиночитаемый, но она должна быть статической и уникальной, так чтобы она могла быть использована в качестве ключа для чтения с помощью программного обеспечения дескриптора OVF, чтобы однозначно определить формат. Спецификация должна быть достаточно существенной для восприятия специалиста, чтобы правильно интерпретировать транспортный механизм для толкования протоколов. Он рекомендован, чтобы эти идентификаторы URI были разрешимы. 57 СТ РК ISO/IEC 17203–___ (проект, редакция 1) Приложение А (справочное) Символы и обозначения Примеры XML использования префиксов пространства имен XML, определенные в таблице 1. Примеры XML используют стиль не указанные в префиксах пространств имен на дочерних элементах. Обратите внимание, что правила XML определяют, что дочерние элементы, указанные без префикса пространства имен, находятся в пространстве имен исходного/родительского элемента, а не от имен по умолчанию документа XML. В тексте документа, пробелы в значениях элементов XML используются для удобства чтения. На практике, служба может принять и удалить начальные и конечные пробелы в пределах значений элементов, как если бы не были использованы пробелы. Определения синтаксиса в расширенной БНФ (ABNF) использования ABNF, как определено в IETFRFC5234, со следующими исключениями: • Правила разделенные чертой (|) представляют выбор, вместо использования косой черты (/), как определено в ABNF. • Любые символы должны быть четко обработаны, без учета регистра, как определено в ABNF. • Пробелы (т.е., пробел U+0020 и символ табуляции U+0009) допускаются между синтаксическими элементами, вместо сборных элементов без пробелов, как определено в ABNF. 58 СТ РК ISO/IEC 17203–__ (проект, редакция 1) ПРИЛОЖЕНИЕ B (справочное) Журнал изменений Версия Дата Описание 1.0.0 2009-02-22 DMTF стандарт 1.1.0 2010-01-12 DMTF стандарт 59 СТ РК ISO/IEC 17203–___ (проект, редакция 1) ПРИЛОЖЕНИЕ С (обязательное) Открытый формат виртуализации XSD Нормативные копии XML-схем для этой спецификации могут быть извлечены путем нахождения следующих адресов: http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd http://schemas.dmtf.org/ovf/environment/1/dsp8027_1.1.0.xsd Содержание любой xs:documentation в XML-схеме для этой спецификации является информативным и предоставляется только для удобства. Нормативные копии XML-схем для отображения WS-CIM (DSP0230) из CIM_ResourceAllocationSystemSettingsData и CIM_VirtualSystemSettingData могут извлекаться путем обращения по следующим адресам: http://schemas.dmtf.org/wbem/wscim/1/cimschema/ 2.22.0/CIM_VirtualSystemSettingData.xsd http://schemas.dmtf.org/wbem/wscim/1/cimschema/ 2.22.0/CIM_ResourceAllocationSettingData.xsd Эта спецификация базируется на следующих MOFsCIM: CIM_VirtualSystemSettingData.mof CIM_ResourceAllocationSettingData.mof CIM_OperatingSystem.mof 60 СТ РК ISO/IEC 17203–__ (проект, редакция 1) ПРИЛОЖЕНИЕ D (справочное) Библиография ISO 9660, Спецификация Joliet расширения, май 1995 г. W3C, Ю. Савоурель и др. Самая лучшая практика для XML интернационализации, Рабочий проект, октябрь 2007 г., проект, http://www.w3.org/TR/2007/WD-xml-i18n-bp-20071031 DMTF DSP1044, Профиль устройства процессора виртуализации ресурсов 1.0 http://www.dmtf.org/standards/published_documents/DSP1044_1.0.pdf DMTF DSP1045, Профиль виртуализации ресурса памяти 1.0 http://www.dmtf.org/standards/published_documents/DSP1045_1.0.pdf DMTF DSP1047, Профиль виртуализации ресурса сохранения 1.0 http://www.dmtf.org/standards/published_documents/DSP1047_1.0.pdf DMTF DSP1022, Профиль процессора 1.0, http://www.dmtf.org/standards/published documents/DSP1022 1.0.pdf DMTF DSP1026, Профиль памяти системы 1.0, http://www.dmtf.org/standards/published_documents/DSP1026_1.0.pdf DMTF DSP1014, Профиль порта Ethernet 1.0, http://www.dmtf.org/standards/published_documents/DSP1014_1.0.pdf DSP1050, Профиль виртуализации ресурса порта Ethernet 1.0 http://www.dmtf.org/standards/published_documents/DSP1050_1.0.pdf УДК 625.144.1:006.354 МКС 45.040 Ключевые слова: виртуализация, образ диска, файл, сертификат, дескриптор, пространство имен, виртуальная машина, атрибут, конфигурация пакета OVF, дочерние элементы, содержание элемента, структура элемента, соответствие уровня, коллекции, XML файл. 61 СТ РК ISO/IEC 17203–___ (проект, редакция 1) УДК 625.144.1:006.354 МКС 45.040 Ключевые слова: виртуализация, образ диска, файл, сертификат, дескриптор, пространство имен, виртуальная машина, атрибут, конфигурация пакета OVF, дочерние элементы, содержание элемента, структура элемента, соответствие уровня, коллекции, XML файл. РАЗРАБОТЧИК АО «Казахская академия транспорта и коммуникаций им. М.Тынышпаева» 62 Исполнительный директор по научной работе Б.Р. Кангожин Профессор И.Т. Утепбергенов

Американский национальный стандарт

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib