Четвёртая часть. Предыдущие части: Первая, вторая, третья.
В этой главе: блочные устройства: физические и виртуальные; образы дисков, хранилища.
С точки зрения управления машинами это самая содержательная часть. Даже управление сетью (следующие части) проще, чем диски. Причина проста — дисковые устройства в виртуализации — самые сложные абстракции.
Прежде чем перейти к фактическому описанию, перечислим свойства дисковых устройств:
Каждая строчка из этого списка — отдельное свойство, требующее отдельной реализации (для сравнения у сетевого интерфейса свойств всего два: они могут принимать и отправлять информацию).
Для виртуализации эти свойства разделены в две группы: первая, связанна с хранением информации. Вторая — связанна с доступом к месту хранения информации.
Очевидно, что доступ (процесс доступа) тесно связан с виртуальной машиной. А процесс хранения — нет. Хранить мы можем и без того, кто пишет, а вот писать без того, кто хранит — не можем. Впрочем, вы не можем так же писать информацию и без того, кто пишет, таким образом процесс доступа тесно связан как с виртуальной машиной, так и с хранилищем информации.
Таким образом, мы имеем функциональное разделение на хранение и доступ. В XCP им сопоставлены отдельные сущности: хранение — VDI (virtual disk image), доступ — VBD (virtual block device). VDI может существовать вне контекста виртуальной машины, VBD — нет. VDI может быть подключен к разным виртуальным машинам в разные моменты времени, VBD — нет, без виртуальной машины его не может существовать. Фактически, VBD — это блочное устройство в гостевой виртуальной машине.
Разница между VDI и VBD примерно такая же, как между жёстким диском и /dev/sda — и то и другое диск, но первое в руках подержать можно, а второе — абстракция операционной системы. (И записать на диск мы можем только с помощью /dev/sda, причём у каждого компьютера /dev/sda, хоть и указывать он может на один и тот же диск, который мы перетыкаем между компьютерами).
Сам VBD состоит из двух частей: одна — внутри виртуальной машины, вторая в dom0 (административной виртуальной машине). Драйвер внутри domU (гостевой машине), приняв дисковый запрос почти в неизменном виде передаёт его «наружу» и принимает результат, отдавая его ядру гостевой машины. Половинка драйвера в dom0 много сложнее, она принимает запросы от первой половинки драйвера и занимается всей содержательной работой запроса (чтение, отправка запроса операционной системе или хранилищу), отдавая результат обратно. Разделение в таком виде сделано это для того, чтобы под Xen можно было очень быстро и просто писать драйвера для гостевых систем. К счастью, при администрировании это разделение не видно и VBD можно воспринимать как единую сущность.
VDI в самой примитивной реализации — это побайтовая копия диска. Однако, в реальной жизни это слишком расточительно (место пропадает, много повторных кусков данных), так что VDI чаще всего может иметь существенные отличия от соответствия «байт-в-байт». Во-первых, нижележащее хранилище может делать thin providing, когда повторяющиеся блоки пишутся на физический диск один раз, а остальные являются лишь ссылками. При записи в такие блоки они копируются, а ссылка удаляется (технология copy on write). Кроме того, некоторые хранилища (имеется в виду специализированные железки) могут обеспечивать самостоятельный поиск повторяющихся блоков и их конвертирование в ссылки.
Во-вторых, очевидно, что области, в которые никто ничего не писал (пустое место) легко «сжимать», то есть заменять фактические тысячи нулей записью о том, что «тут одни нули». Самый простой пример этого — sparsed (разреженные) файлы, в которых незаписанные области просто не хранятся, образуя «дыры» в середине файла.
Места хранения VDI'ев называются SR — storage repository. SR — это абстракция, у неё нет физического воплощения. Для указания как именно реализовывать физическое воплощение используются SM (storage manager'ы). У каждого SR указывается через какого SM следует осуществлять доступ и какие при этом параметры следует передавать SM.
Ключевой особенностью Xen Cloud Platform (по сравнению с голыми Xen'ами на нескольких компьютерах), которая делает XCP готовой платформой, является понятие общих хранилищ (shared SR). Это хранилища, к которым одновременно и с одинаковыми настройками подключены все хосты. Именно shared SR обеспечивают возможность миграции машин между хостами за короткое время.
SM — это, грубо говоря, драйвер. Поскольку к одному и тому же хранилищу могут подключаться несколько хостов, то для физического подключения хоста используется ещё одна абстракция — PBD (Physical Block Device). Когда хост подключается к хранилищу (SR) он использует драйвер (SM) с набором параметров. Драйвер устанавливает соединение (как именно — головная боль SM) и выдаёт хосту PBD. Примеры PBD — подмонтированная nfs-шара, подключенное iscsi-устройство, локальный жёсткий диск, отдельный раздел на этом диске и т.д.
Зачем нужна такая сложная схема? Она позволяет максимально абстрагироваться от конкретных особенностей хранилища — «драйвер хранилища» (SM) предоставляет стандартный интерфейс для XCP, позволяющий, например, безболезненно заменить NFS на FiberChannel без изменения какого-либо кода в XCP.
Таким образом, подключение SR к хосту выглядит так: в момент создания нового хранилища всем хостам в пуле посылается команда «создать PBD с SM таким-то и параметрами такими-то, принадлежащий SR такому-то». Каждый хост эту команду выполняет. Аналогично же происходит при приёме хоста в пул (он создаёт все PBD для всех shared SR). При загрузке каждый хост подключает по новой все PBD. Если какие-то PBD не удаётся подключить, они помечаются как unplugged и влияют на порядок выбора хоста для запуска виртуальной машины.
Помимо shared репозиториев есть и «личные» репозитории хоста, но они для продакта не рекомендуются, ибо автоматически лишают виртуальную машину, подключенную к VDI, хранящимся на SR, права на миграцию. Одно из применений локальных SR — доступ к физическим винтам (обычно, при миграции сервера) и/или физическим же CD-дискам.
Кстати, становится понятно, каким образом обеспечивается прозрачная работа с thin providing, sparced-файлами, copy-on-write для хранилищ. Это головная боль SM. Ему сказали «сделай тонкую копию таких-то блоков», SM посмотрел-посмотрел, если смог, сделал тонкую копию (ссылку), если не смог, запустил dd и сделал толстую копию.
Отсюда, кстати, легко понять, что копирование VDI между SR всегда дорогая операция — нужно скопировать каждый блок VDI.
Повторим ещё раз схему подключения диска виртуальной машины:
У виртуальной машины есть VBD, VBD указывает на связанный с ним VDI, VDI (как административная единица) указывает на тот SR, на котором он находится, SR указывает какой SM используется. Виртуальная машина расположена на некотором хосте, у хоста есть ассоциированный PBD, через который и осуществляется доступ.
Самое интересное происходит при миграции машины: на одном хосте VDI закрывается, на втором, через другой PBD в том же SR, доступ устанавливается. Если нет, миграция отменяется и машина остаётся на том же самом хосте (это важно, в случае ошибочной миграции можно получить много тормозов на хостах, но это не скажется на работе виртуальной машины).
Собственно, это те SM, которые поставляются с XCP, поле type для SR:
* iscsi — блочное устройство для одного-единственного VDI (это означает, что весь SR посвящён единственному VDI)
* lvmohba — LVM поверх подключенного Fiber Channel. Основным является возможность хранить множество VDI на одном устройстве за счёт использования логических томов. Тома управляются самим XCP.
* file — локальное хранилище, просто каталог в котором лежат файлы образов дисков
* lvm — локальное хранилище, LVM на локальном жёстком диске. Каждый VDI — отдельный том. Управляется XCP.
* udev — милая игрушка для втыкания флешек в виртуальные машины, SR обслуживает один-единственный VDI, локальное хранилище.
* nfs — образы VDI в виде VHD-файлов хранятся на NFS-шаре. Разница с file в том, что это хранилище глобальное, и в нём подключением шар к хостам управляет XCP.
* dummy — пустышка, не может хранить VDI.
* hba — выделение указанного блочного устройства FC для хранения единственного VDI.
* ext — довольно извращённая конструкция — VDI-файлы хранятся в формате VHD на ext3-разделе, создаваемом XCP на указанном блочном устройстве.
* ISO хранилище ISO-файлов.
* lvmoiscsi — LVM поверх блочного устройства ISCSI.
Как мы видим, в этом списке есть три важных типа: lvmoiscsi, lvmohba, nfs — только они могут использоваться для «виртуальных машин пачками» (остальные тоже могут использоваться, но в специфичных случаях).
Заметим, что при установке XCP спрашивается, делать ли локальное хранилище. Если отвечаете «да», то получаете SR с типом lvm.
К сожалению, у меня малый опыт работы с FC, так что ничего существенного про него я не скажу. Выбор между NFS и ISCSI определяется следующими различиями:
NFS обеспечивает наибольшую плотность использования места (используются sparsed-файлы), обеспечивает весьма хорошее кеширование на чтение.
iscsi даёт большую скорость на запись, меньшие тормоза при первой записи в sparsed-область.
Ещё одним преимуществом NFS является простота манипуляции VDI'ями на хранилище — они выглядят как обычные файлы. В случае iscsi мы имеем lvm поверх блочного устройства (которое на сетевом хранилище может быть разделом или даже файлом), а VDI'и там внтури представляют собой логические тома. Получить к ним «поштучный» доступ с хранилища существенно сложнее. Кроме того, NFS используется третьей версии, в которой нет криптографической защиты и действует только проверка по IP-адресам. В сравнении с этим iscsi использует взаимную аутоидентификацию с помощью chap, так что мой личный совет — использовать iSCSI. Тем паче, что iscsi поддерживает multipath [?], и XCP его поддерживает тоже.
Понятно, что конфигурирование SR выходит за пределы XCP — оно требует ещё и конфигурирования самого хранилища. Самой частой ошибкой является ограничение на количество одновременных подключений к iscsi-хранилищу (штатный режим iscsi-target — одно подключение, XCP же требует разрешения на подключение нескольких) ВТорой частой ошибкой является оставление iscsiID на усмотрение хранилища — после перезагрузки хранилища они могут поменяться и PBD не смогут подключиться.
Операции с SR: create, destroy (данные при этом удаляются!), forget (удаляется только запись о существовании SR, данные сохраняются), introduce («обнаружить» sr и VDI'и на нём), scan (позволяющий обнаружить появившиеся там помимо воли XCP vdi'и, такое особо характерно для NFS). Кроме того, есть команда xe-sr-probe, которая позволяет сконструировать запрос на создание хранилища (точнее, подобрать правильные параметры). Впрочем, этот вопрос подробно разобран в руководстве по XCP.
Важное поле для SR — sm-config (конфигурация SM). В частности, там указывается тип выделения места thick или thin (для iscsi это thick, для nfs — thin).
Как было уже сказано, фактический смысл VBD — это блочное устройство внутри виртуальной машины, позволяющей ей получать доступ к VDI.
Соответственно, VBD имеет следующие важные атрибуты: uuid виртуальной машины, uuid VDI и номер. Номер является просто числом и примерно соответствует номеру SATA-порта на материнской плате. Сами VBD внури линукса называются /dev/xvda, /dev/xvdb, /dev/xvdc… (для любопытствующих: после /dev/xvdz идёт /dev/xvdaa и далее вплоть до лимита на 256 устройств).
По соглашению, каждый раз, при подключении VDI к VM создаётся новый VBD (впрочем, VBD может менять статус plugged/unplugged сколько угодно раз) и уничтожается при уничтожении VDI или VM автоматически.
Важным атрибутом VBD является наличие флага 'bootable'. Аналогию с реальным железом провести сложновато, скажем так, это аналогия указанного в биосе диска для загрузки. Важно: для загрузки виртуальной машины к ней должен быть подключен VBD с флагом bootable=true, причём один и только один. После загрузки к машине можно цеплять что угодно в каком угодно количестве — но для начала загрузки bootable должен быть и должен быть один-единственный.
Кроме этого, vbd имеет ещё два важных атрибута: unplugable и empty. Смысл unplugable понятен из названия (устройство нельзя отключать на ходу, обычно он выставляется для системного диска), Empty забавнее: vbd позволяют «цеплять» не только образы жёсктих дисков, но и ISO-образы, а сам VBD при этом может изображать CD-ROM. Именно для возможности имитировать извлечение диска из привода и предназначен атрибут empty.
Кроме этого, есть атрибут ro, который позволяет подключить диск в режиме «только для чтения» (и из гостевой машины его не обойти).
Для одного и того же VDI может существовать несколько VBD в одну и ту же машину, или даже в несколько. К сожалению, в существующей системе подключен может быть только один в один момент времени (хотя вполне можно себе представить ситуацию, когда VDI подключен к двум виртуальным машинам, которые работают по-очереди).
Типовые операции для VBD: create, destroy (уничтожает связь между диском и машиной без уничтожения данных на диске), plug, unplug. Есть ещё имитация вставления/вынимания cd — load/eject, но это фэнсервис.
Интересные атрибуты: virtual-allocation, physical-utilisation, physical-size. Первые два могут сильно различаться для thin providing. Ещё одно поле content-type было специально сделано для указания, что на SR хранятся ISO'шки. Поле тип указывает на то, диск это или cdrom (разное подмножество доступных команд).
VDI так же имеет атрибуты (на самом деле их очень много, я привожу только самые важные и используемые в работе). Это флаг r/o (да, ro может выставляться на уровне vbd или даже на уровне vdi) и «предков-потомков». Про отношения предок-потомок и подробнее про тонкое копирование для VDI — в следующих главах, когда речь пойдёт о снапшотах.
Интересные атрибуты: virtual_size (задаётся при создании) и physical_utilisation, показывающий объём занятого места (с точки зрения хранилища).
Типовые операции: create, destroy (уничтожает не только данные вместе с VDI, но и VBD — связь между VDI и VM), copy (всегда толстое копирование), clone (если возможно, тонкое копирование с copy-on-write режимом) и… наш любимый, resize. Да, xcp позволяет менять размер дисков, более того, он позволяет делать это на ходу без перерыва в обслуживании. Проблема только в том, что гостевые системы в настоящий момент совсем к этому не готовы и после изящного xe vdi-resize вам придётся делать совсем неизящное изменение размеров раздела, ресайз файловой системы.
Для ISO были придуманы массовые костыли — content-type в свойствах SR, и даже целый набор команд — xe vm-cd-add, xe vm-cd-eject и т.д., хотя на самом деле ISO есть тот же VDI, подключающийся с VBD с типом CDROM. Важно, что это исключительно R/O, никаких CD/DVD-RW при этом не эмулируется.
Тема шаблонов гостевых машин будет разбираться позже, но пока замечу, что при создании машины из шаблона (а это единственный метод создать виртуальную машину в XCP) для новой машины создаётся новый диск. Создаётся он благодаря записанному в поле other-config у шаблона значения provision (просто описание того, каким должен быть диск). Вот пример из одного из шаблонов:
Ещё небольшая заметка по поводу типа (type=system). В XCP задумывалось, что системный диск привязан к VM (и не имеет смысла без неё), а type=User хранит данные и не должен страдать из-за проблем виртуальной машины. К сожалению, в этом месте есть бага, и system в некоторых случаях трактуется как user (спасибо, что не наоборот). Для дисков, созданных при создании машины с типом System действует следующее правило: при удалении машины (vm-uninstall) эти диски уничтожаются. User-диски, нет.
Бага состоит в том, что если создать руками vdi с типом system, то он не будет удалён при удалении машины. В принципе, не очень большая проблема, но если часто делать машины, цеплять к ним system диски и удалять машины, то может закончиться место и придётся тереть ненужные диски руками.
В следующих выпусках: миграция, шаблоны, снапшоты, отношения «родитель-потомок», клонирование машин, установка виртуальных машин, HVM.
В этой главе: блочные устройства: физические и виртуальные; образы дисков, хранилища.
С точки зрения управления машинами это самая содержательная часть. Даже управление сетью (следующие части) проще, чем диски. Причина проста — дисковые устройства в виртуализации — самые сложные абстракции.
Прежде чем перейти к фактическому описанию, перечислим свойства дисковых устройств:
- Они хранят информацию.
- У них есть свободное место для будущей информации.
- Они не связаны с конкретным компьютером и могут переключаться между компьютерами.
- Они позволяют записывать, читать информацию.
- Они позволяют стирать старую информацию и записывать новую поверх старой.
Каждая строчка из этого списка — отдельное свойство, требующее отдельной реализации (для сравнения у сетевого интерфейса свойств всего два: они могут принимать и отправлять информацию).
Для виртуализации эти свойства разделены в две группы: первая, связанна с хранением информации. Вторая — связанна с доступом к месту хранения информации.
Очевидно, что доступ (процесс доступа) тесно связан с виртуальной машиной. А процесс хранения — нет. Хранить мы можем и без того, кто пишет, а вот писать без того, кто хранит — не можем. Впрочем, вы не можем так же писать информацию и без того, кто пишет, таким образом процесс доступа тесно связан как с виртуальной машиной, так и с хранилищем информации.
Таким образом, мы имеем функциональное разделение на хранение и доступ. В XCP им сопоставлены отдельные сущности: хранение — VDI (virtual disk image), доступ — VBD (virtual block device). VDI может существовать вне контекста виртуальной машины, VBD — нет. VDI может быть подключен к разным виртуальным машинам в разные моменты времени, VBD — нет, без виртуальной машины его не может существовать. Фактически, VBD — это блочное устройство в гостевой виртуальной машине.
Разница между VDI и VBD примерно такая же, как между жёстким диском и /dev/sda — и то и другое диск, но первое в руках подержать можно, а второе — абстракция операционной системы. (И записать на диск мы можем только с помощью /dev/sda, причём у каждого компьютера /dev/sda, хоть и указывать он может на один и тот же диск, который мы перетыкаем между компьютерами).
Сам VBD состоит из двух частей: одна — внутри виртуальной машины, вторая в dom0 (административной виртуальной машине). Драйвер внутри domU (гостевой машине), приняв дисковый запрос почти в неизменном виде передаёт его «наружу» и принимает результат, отдавая его ядру гостевой машины. Половинка драйвера в dom0 много сложнее, она принимает запросы от первой половинки драйвера и занимается всей содержательной работой запроса (чтение, отправка запроса операционной системе или хранилищу), отдавая результат обратно. Разделение в таком виде сделано это для того, чтобы под Xen можно было очень быстро и просто писать драйвера для гостевых систем. К счастью, при администрировании это разделение не видно и VBD можно воспринимать как единую сущность.
VDI в самой примитивной реализации — это побайтовая копия диска. Однако, в реальной жизни это слишком расточительно (место пропадает, много повторных кусков данных), так что VDI чаще всего может иметь существенные отличия от соответствия «байт-в-байт». Во-первых, нижележащее хранилище может делать thin providing, когда повторяющиеся блоки пишутся на физический диск один раз, а остальные являются лишь ссылками. При записи в такие блоки они копируются, а ссылка удаляется (технология copy on write). Кроме того, некоторые хранилища (имеется в виду специализированные железки) могут обеспечивать самостоятельный поиск повторяющихся блоков и их конвертирование в ссылки.
Во-вторых, очевидно, что области, в которые никто ничего не писал (пустое место) легко «сжимать», то есть заменять фактические тысячи нулей записью о том, что «тут одни нули». Самый простой пример этого — sparsed (разреженные) файлы, в которых незаписанные области просто не хранятся, образуя «дыры» в середине файла.
Места хранения VDI'ев называются SR — storage repository. SR — это абстракция, у неё нет физического воплощения. Для указания как именно реализовывать физическое воплощение используются SM (storage manager'ы). У каждого SR указывается через какого SM следует осуществлять доступ и какие при этом параметры следует передавать SM.
Ключевой особенностью Xen Cloud Platform (по сравнению с голыми Xen'ами на нескольких компьютерах), которая делает XCP готовой платформой, является понятие общих хранилищ (shared SR). Это хранилища, к которым одновременно и с одинаковыми настройками подключены все хосты. Именно shared SR обеспечивают возможность миграции машин между хостами за короткое время.
SM — это, грубо говоря, драйвер. Поскольку к одному и тому же хранилищу могут подключаться несколько хостов, то для физического подключения хоста используется ещё одна абстракция — PBD (Physical Block Device). Когда хост подключается к хранилищу (SR) он использует драйвер (SM) с набором параметров. Драйвер устанавливает соединение (как именно — головная боль SM) и выдаёт хосту PBD. Примеры PBD — подмонтированная nfs-шара, подключенное iscsi-устройство, локальный жёсткий диск, отдельный раздел на этом диске и т.д.
Зачем нужна такая сложная схема? Она позволяет максимально абстрагироваться от конкретных особенностей хранилища — «драйвер хранилища» (SM) предоставляет стандартный интерфейс для XCP, позволяющий, например, безболезненно заменить NFS на FiberChannel без изменения какого-либо кода в XCP.
Таким образом, подключение SR к хосту выглядит так: в момент создания нового хранилища всем хостам в пуле посылается команда «создать PBD с SM таким-то и параметрами такими-то, принадлежащий SR такому-то». Каждый хост эту команду выполняет. Аналогично же происходит при приёме хоста в пул (он создаёт все PBD для всех shared SR). При загрузке каждый хост подключает по новой все PBD. Если какие-то PBD не удаётся подключить, они помечаются как unplugged и влияют на порядок выбора хоста для запуска виртуальной машины.
Помимо shared репозиториев есть и «личные» репозитории хоста, но они для продакта не рекомендуются, ибо автоматически лишают виртуальную машину, подключенную к VDI, хранящимся на SR, права на миграцию. Одно из применений локальных SR — доступ к физическим винтам (обычно, при миграции сервера) и/или физическим же CD-дискам.
Кстати, становится понятно, каким образом обеспечивается прозрачная работа с thin providing, sparced-файлами, copy-on-write для хранилищ. Это головная боль SM. Ему сказали «сделай тонкую копию таких-то блоков», SM посмотрел-посмотрел, если смог, сделал тонкую копию (ссылку), если не смог, запустил dd и сделал толстую копию.
Отсюда, кстати, легко понять, что копирование VDI между SR всегда дорогая операция — нужно скопировать каждый блок VDI.
Повторим ещё раз схему подключения диска виртуальной машины:
У виртуальной машины есть VBD, VBD указывает на связанный с ним VDI, VDI (как административная единица) указывает на тот SR, на котором он находится, SR указывает какой SM используется. Виртуальная машина расположена на некотором хосте, у хоста есть ассоциированный PBD, через который и осуществляется доступ.
Самое интересное происходит при миграции машины: на одном хосте VDI закрывается, на втором, через другой PBD в том же SR, доступ устанавливается. Если нет, миграция отменяется и машина остаётся на том же самом хосте (это важно, в случае ошибочной миграции можно получить много тормозов на хостах, но это не скажется на работе виртуальной машины).
Типы хранилищ
Собственно, это те SM, которые поставляются с XCP, поле type для SR:
* iscsi — блочное устройство для одного-единственного VDI (это означает, что весь SR посвящён единственному VDI)
* lvmohba — LVM поверх подключенного Fiber Channel. Основным является возможность хранить множество VDI на одном устройстве за счёт использования логических томов. Тома управляются самим XCP.
* file — локальное хранилище, просто каталог в котором лежат файлы образов дисков
* lvm — локальное хранилище, LVM на локальном жёстком диске. Каждый VDI — отдельный том. Управляется XCP.
* udev — милая игрушка для втыкания флешек в виртуальные машины, SR обслуживает один-единственный VDI, локальное хранилище.
* nfs — образы VDI в виде VHD-файлов хранятся на NFS-шаре. Разница с file в том, что это хранилище глобальное, и в нём подключением шар к хостам управляет XCP.
* dummy — пустышка, не может хранить VDI.
* hba — выделение указанного блочного устройства FC для хранения единственного VDI.
* ext — довольно извращённая конструкция — VDI-файлы хранятся в формате VHD на ext3-разделе, создаваемом XCP на указанном блочном устройстве.
* ISO хранилище ISO-файлов.
* lvmoiscsi — LVM поверх блочного устройства ISCSI.
Как мы видим, в этом списке есть три важных типа: lvmoiscsi, lvmohba, nfs — только они могут использоваться для «виртуальных машин пачками» (остальные тоже могут использоваться, но в специфичных случаях).
Заметим, что при установке XCP спрашивается, делать ли локальное хранилище. Если отвечаете «да», то получаете SR с типом lvm.
К сожалению, у меня малый опыт работы с FC, так что ничего существенного про него я не скажу. Выбор между NFS и ISCSI определяется следующими различиями:
NFS обеспечивает наибольшую плотность использования места (используются sparsed-файлы), обеспечивает весьма хорошее кеширование на чтение.
iscsi даёт большую скорость на запись, меньшие тормоза при первой записи в sparsed-область.
Ещё одним преимуществом NFS является простота манипуляции VDI'ями на хранилище — они выглядят как обычные файлы. В случае iscsi мы имеем lvm поверх блочного устройства (которое на сетевом хранилище может быть разделом или даже файлом), а VDI'и там внтури представляют собой логические тома. Получить к ним «поштучный» доступ с хранилища существенно сложнее. Кроме того, NFS используется третьей версии, в которой нет криптографической защиты и действует только проверка по IP-адресам. В сравнении с этим iscsi использует взаимную аутоидентификацию с помощью chap, так что мой личный совет — использовать iSCSI. Тем паче, что iscsi поддерживает multipath [?], и XCP его поддерживает тоже.
Понятно, что конфигурирование SR выходит за пределы XCP — оно требует ещё и конфигурирования самого хранилища. Самой частой ошибкой является ограничение на количество одновременных подключений к iscsi-хранилищу (штатный режим iscsi-target — одно подключение, XCP же требует разрешения на подключение нескольких) ВТорой частой ошибкой является оставление iscsiID на усмотрение хранилища — после перезагрузки хранилища они могут поменяться и PBD не смогут подключиться.
Операции с SR: create, destroy (данные при этом удаляются!), forget (удаляется только запись о существовании SR, данные сохраняются), introduce («обнаружить» sr и VDI'и на нём), scan (позволяющий обнаружить появившиеся там помимо воли XCP vdi'и, такое особо характерно для NFS). Кроме того, есть команда xe-sr-probe, которая позволяет сконструировать запрос на создание хранилища (точнее, подобрать правильные параметры). Впрочем, этот вопрос подробно разобран в руководстве по XCP.
Важное поле для SR — sm-config (конфигурация SM). В частности, там указывается тип выделения места thick или thin (для iscsi это thick, для nfs — thin).
VBD
Как было уже сказано, фактический смысл VBD — это блочное устройство внутри виртуальной машины, позволяющей ей получать доступ к VDI.
Соответственно, VBD имеет следующие важные атрибуты: uuid виртуальной машины, uuid VDI и номер. Номер является просто числом и примерно соответствует номеру SATA-порта на материнской плате. Сами VBD внури линукса называются /dev/xvda, /dev/xvdb, /dev/xvdc… (для любопытствующих: после /dev/xvdz идёт /dev/xvdaa и далее вплоть до лимита на 256 устройств).
По соглашению, каждый раз, при подключении VDI к VM создаётся новый VBD (впрочем, VBD может менять статус plugged/unplugged сколько угодно раз) и уничтожается при уничтожении VDI или VM автоматически.
Важным атрибутом VBD является наличие флага 'bootable'. Аналогию с реальным железом провести сложновато, скажем так, это аналогия указанного в биосе диска для загрузки. Важно: для загрузки виртуальной машины к ней должен быть подключен VBD с флагом bootable=true, причём один и только один. После загрузки к машине можно цеплять что угодно в каком угодно количестве — но для начала загрузки bootable должен быть и должен быть один-единственный.
Кроме этого, vbd имеет ещё два важных атрибута: unplugable и empty. Смысл unplugable понятен из названия (устройство нельзя отключать на ходу, обычно он выставляется для системного диска), Empty забавнее: vbd позволяют «цеплять» не только образы жёсктих дисков, но и ISO-образы, а сам VBD при этом может изображать CD-ROM. Именно для возможности имитировать извлечение диска из привода и предназначен атрибут empty.
Кроме этого, есть атрибут ro, который позволяет подключить диск в режиме «только для чтения» (и из гостевой машины его не обойти).
Для одного и того же VDI может существовать несколько VBD в одну и ту же машину, или даже в несколько. К сожалению, в существующей системе подключен может быть только один в один момент времени (хотя вполне можно себе представить ситуацию, когда VDI подключен к двум виртуальным машинам, которые работают по-очереди).
Типовые операции для VBD: create, destroy (уничтожает связь между диском и машиной без уничтожения данных на диске), plug, unplug. Есть ещё имитация вставления/вынимания cd — load/eject, но это фэнсервис.
Интересные атрибуты: virtual-allocation, physical-utilisation, physical-size. Первые два могут сильно различаться для thin providing. Ещё одно поле content-type было специально сделано для указания, что на SR хранятся ISO'шки. Поле тип указывает на то, диск это или cdrom (разное подмножество доступных команд).
VDI
VDI так же имеет атрибуты (на самом деле их очень много, я привожу только самые важные и используемые в работе). Это флаг r/o (да, ro может выставляться на уровне vbd или даже на уровне vdi) и «предков-потомков». Про отношения предок-потомок и подробнее про тонкое копирование для VDI — в следующих главах, когда речь пойдёт о снапшотах.
Интересные атрибуты: virtual_size (задаётся при создании) и physical_utilisation, показывающий объём занятого места (с точки зрения хранилища).
Типовые операции: create, destroy (уничтожает не только данные вместе с VDI, но и VBD — связь между VDI и VM), copy (всегда толстое копирование), clone (если возможно, тонкое копирование с copy-on-write режимом) и… наш любимый, resize. Да, xcp позволяет менять размер дисков, более того, он позволяет делать это на ходу без перерыва в обслуживании. Проблема только в том, что гостевые системы в настоящий момент совсем к этому не готовы и после изящного xe vdi-resize вам придётся делать совсем неизящное изменение размеров раздела, ресайз файловой системы.
Для ISO были придуманы массовые костыли — content-type в свойствах SR, и даже целый набор команд — xe vm-cd-add, xe vm-cd-eject и т.д., хотя на самом деле ISO есть тот же VDI, подключающийся с VBD с типом CDROM. Важно, что это исключительно R/O, никаких CD/DVD-RW при этом не эмулируется.
Автосоздание VDI
Тема шаблонов гостевых машин будет разбираться позже, но пока замечу, что при создании машины из шаблона (а это единственный метод создать виртуальную машину в XCP) для новой машины создаётся новый диск. Создаётся он благодаря записанному в поле other-config у шаблона значения provision (просто описание того, каким должен быть диск). Вот пример из одного из шаблонов:
<provision><disk device="0" size="8589934592" sr="" bootable="true" type="system"/></provision>. Как мы видим, синтаксис понятный, хотя и слишком XML'ный — нулевое (первое) устройство, загрузочный диск, размер 8Гб.Ещё небольшая заметка по поводу типа (type=system). В XCP задумывалось, что системный диск привязан к VM (и не имеет смысла без неё), а type=User хранит данные и не должен страдать из-за проблем виртуальной машины. К сожалению, в этом месте есть бага, и system в некоторых случаях трактуется как user (спасибо, что не наоборот). Для дисков, созданных при создании машины с типом System действует следующее правило: при удалении машины (vm-uninstall) эти диски уничтожаются. User-диски, нет.
Бага состоит в том, что если создать руками vdi с типом system, то он не будет удалён при удалении машины. В принципе, не очень большая проблема, но если часто делать машины, цеплять к ним system диски и удалять машины, то может закончиться место и придётся тереть ненужные диски руками.
В следующих выпусках: миграция, шаблоны, снапшоты, отношения «родитель-потомок», клонирование машин, установка виртуальных машин, HVM.
