Метка: vSphere

Фильтры, задания и снимки в VMware vSphere 6.7

Многие читатели бложика, наверное, заметили, что мы проигнорировали VMware vSphere 6.5 ;). Одна из ключевых причин — отсутствие C# (толстого) клиента для управления средой виртуализации.

По причине перехода на VMware vSphere 6.7 приходится сравнивать 4 (четыре) клиента:

  1. vSphere Client (C#) — классика жанра, очень быстр, отображение состояния инфраструктуры близко к реальному времени при многопользовательской работе. Подключение к хосту и vCenter.
  2. ESXi Embedded Host Client — хостовый встроенный клиент, из полезного — умеет читать логи ВМ, не требует установки.
  3. vSphere HTML5 Web Client — перспективный клиент, очень много радости у людей с нелюбовью к Adobe Flash, но допилить никак не могут. Оценить задержки по времени от реального состояния инфраструктуры затрудняюсь — без кнопки Обновить при одновременной работе нескольких админов не обойтись, в IE работает с тормозами.
  4. vSphere Web Client (Flex) — вот из-за него-то и не стали переходить на 6.5 после реализации 6.0, а VMware его пилили-пилили, местами допилили. Есть задержки от реального времени, но есть Live Refresh и интервалы обновлений можно уменьшить до 10 секунд.

Неожиданно для себя нахожу полезняшки в vSphere Web Client, коими и спешу поделиться.

Назначенные задания и перезагрузка виртуальных машин Читать далее «Фильтры, задания и снимки в VMware vSphere 6.7»

Срок выхода vSphere 5.0

На проходящем мероприятии VMware’s Partner Exchange озвучены сроки выхода следующей версии виртуальной инфраструктуры от VMware vSphere 5.0. Читать далее «Срок выхода vSphere 5.0»

Книга «Администрирование VMware vSphere 4.1»

Михаил Михеев выпустил новую редакцию своей хитовой книги ″Администрирование VMware vSphere 4.1″. Поздравляем его с появлением  её на интернет-полках.

По самой низкой цене — книга на ОЗОНе.

Новая версия EMC Storage Viewer

По сообщению от Virtual Geek вышла новая версия EMC Storage Viewer 2.1. В данной версии добавлена поддержка vSphere 4 update 1, детальная информация о состоянии репликации, средства просмотра многопутевого ввода-вывода, автоматическое обнаружение массивов.

Подробной обзор.

Новая справочная карта по vSphere

Вышла версия 2.0 справочной карты по vSphere от сайта vreference.com.

Из нового:

  • Проведена большая работа над оформлением
  • Актуализированы лимиты по ESX 4 Update 1.
  • Раскрыта информация по: PVLAN, определениям dvUplink и Network VMotion, опциям vDS VLAN, TPGS, ALUA и прочее.

Всем брать тут.

Интеграция vSphere в системах хранения EMC CLARiiON CX4

С каждым годом поддержка серверной виртуализации в системах хранения данных поднимается на уровень выше: это поддержка общих LUN с актив-актив доступом, thin provisioning, вендорная сертификация.

Компания EMC, в структуру которой входит VMware, решила интегрировать поддержку хранилищ виртуальных машин в интерфейс самого хранилища. Это выразилось в создании новой версии операционной системы Flare 29 для EMC CLARiiON CX4.

В интерфейсе хранилища Navisphere теперь вы можете увидеть:

Свойства подключенного хоста

attached_esx

«Подмапленные» LUN

mapping_lun

Виртуальные машины(!)

host_vm

Хранилища виртуальных машин (RDM или VMFS, размещение файлов, тонкие или толстые, ёмкость)

vm_lun

Если с выходом «четверки» мы получили управление хранилищами на стороне хоста, то теперь получаем управление хранением на уровне виртуальных машин на стороне хранилища.

Подробнее тут.

Пятьдесят семь RDM

Филипп Зыков aka philzy делится с нашими читателями опытом:

По целому ряду причин, а точнее из-за особенностей организации хранения данных пользователей потребовалось поэкпериментировать с массовым подключением RDM в MSCS кластере . Чтобы прекратить все вопросы почему так – отвечаю. У нас есть такое понятие как диск подразделения («исторически так сложилось»), оно реализуется через подключение сетевых дисков на рабочих станциях, которые смотрят в DFS. Для поддержания порядка в расходе дискового пространства первое время пользовались квотированием, но пользователи скандалили, так как свободное место показывалось некорректно. Поэтому соорудили систему с диким количеством LUN .
Всего было 46 LUN на EMC CX3-40F выбрано для эксперимента по их подключению.
При подключении 31 LUN начиналась череда дивных «глюков» связанных с вылетами по таймауту при запуске такой VM, проблемы с невозможностью сохранить конфигурацию VM.
Чтение документации от Vmware ничего не проясняло, кроме одного маленького упоминания о том, что кворумный диск лучше подключать на SCSI-адрес 1:1. О причинах и ограничениях там мило умолчали, предоставив пользователям строить догадки на эту тему. Методом научного тыка поиска было обнаружено, что адреса контроллеров 1:0, 2:0, 3:0 не пригодны для работы с RDM при количестве более 30 шт. При переходе границы этого числа ничего не работало, совсем и никак.

57rdmТаким образом, методом нехитрого сложения показаний выясняется, что ограничение на 60 дисков на одну VM это не так, в случае RDM, это всего лишь 57.
Еще одной дивной особенностью оказалось их подключение через VI-клиент. На подобную операцию уходит примерно 1,5-2 часа из-за абсолютно неудачного интерфейса. Почему нельзя было сделать множественный выбор? Непонятно. Скриптами не пользовались принципиально, так как на написание нужно было потрать кучу времени, а это была разовая операция. Ну, так казалось в начале эксперимента.
Таким образом, подобная VM с 46 RDM «взлетает» за 3 минуты, а останавливается за 5 мин. Работа такой VM в кластере особых вопросов не вызывает.
По-поводу RDM и чем они лучше VMDK узнал на собственной шкуре. Случайно удаленный vmdk-файл в Vsphere восстановить нельзя. Про бэкапы я более чем в курсе, но не будешь же экспериментальные VM бэкапить постоянно.

Устройство снимков виртуальных дисков в VMware VI3

Оригинал данной статьи находится здесь, я же являюсь не более, чем пристрастным переводчиком данного текста. 🙂 Статья рекомендуется к прочтению всем адептам VMware VI3 и VMware vSphere.

Введение

Вчера я потратил полдня, решая проблему, возникшую из-за рассинхронизации снимка VMware VI3. Это был неприятный опыт, зато я узнал о важности CID-цепи!
После нескольких часов пинания мертвой ВМ, мой коллега, Дан, и я натолкнулись на CID-цепи.
Мы пришли к выводу, что .vmdk-файлы, которые создаются в VI3 каждый раз при снятии снимка, связаны с другими .vmdk через сгенерированные случайным образом значения CID. VI3 присваивает каждому новому файлу снимка CID, причем это значение меняется при каждой перезагрузке ВМ.
Если цепь CID разрывается, то ВМ не может подключить свой виртуальный диск.

Проблема

Ваши виртуальные диски не подключаются при включении ВМ, вы получите следующее сообщение об ошибке:
“Cannot open the disk ‘/vmfs/volumes/INSERT SPECIFIC VALUE HERE.vmdk’ or one of the snapshot disks it depends on.
Reason: The parent virtual disk has been modified since the child was created.”
“Не удается открыть диск ‘/vmfs/volumes/lalala.vmdk’ или один из файлов снимков, от которых он зависит.
Причина: первичный виртуальный диск был изменен, после создания вторичного.”

Черт!

Что вам делать?!
1) Только не паникуйте 🙂
2) Полностью выключите ВМ.
3) Ничего не изменяйте!
4) Прочтите эту статью!
Если вы не вносили изменения в .vmdk файлы, вероятнее всего, у вас получится исправить эту проблему.

Анализ

Эта проблема возникла, вероятно, потому что вы сделали один или несколько снимков одного или нескольких виртуальных дисков, связанных с ВМ, и снимки рассинхронизировались. Скорее всего, вы получили эту проблему в средах ESX/VI3.
Причина этой проблемы связана с тем, как VI3 управляет снимками и дельтами изменений относительно первоначального виртуального диска (.vmdk). Вероятно, нарушилась логика иерархии снимков, и вторичные .vmdk-файлы, уже не ссылаются на первичные.
Ключ к складыванию головоломки из снимков находится в восстановлении цепи CID.
Каждому .vmdk файлу назначается свой CID-идетификатор. Кроме того, в каждом .vmdk содержится ссылка на CID и .vmdk предыдущего (родительского) файла. CID “родителя” должен указывать на .vmdk файл, созданный непосредственно перед созданием снимка.
При загрузке ВМ CID в .vmdk-файлах меняется на случайным образом. Если после загрузки ВМ цепь CID не в том же состоянии, как и до загрузки, то связь вторичный CID -> первичный CID нарушается. Таким образом VI3 определяет подлинность снимков. Единственный способ вновь синхронизировать CID-цепь – вручную отредактировать все .vmdk файлы в этой цепи.
Пример CID-цепи:
Первичный .vmdk = vdisk.vmdk
.vmdk, созданный после 1 снимка = vdisk-000001.vmdk
.vmdk, созданный после 2 снимка = vdisk-000002.vmdk
Если эта цепочка нарушается, то:
вручную делаем ссылку vdisk-000002.vmdk -> vdisk-000001.vmdk;
vdisk-000001.vmdk -> vdisk.vmdk.

Обратим внимание на три поля в .vmdk-файле:
— поле CID;
— ссылка на parentCID;
— поле parentNameHint.
Примечание: первичный .vmdk не содержит поля «parentNameHint», а его «parentCID» всегда равняется «ffffffff».

Примеры

Пример содержимого первичного vdisk.vmdk:
[root@myvi3server]# cat vdisk.vmdk
# Disk DescriptorFile
version=1
CID=7f81b951
parentCID=ffffffff
createType=»vmfs»
# Extent description
RW 50331648 VMFS «vdisk-flat.vmdk»
# The Disk Data Base
#DDB
ddb.virtualHWVersion = «4»
ddb.geometry.cylinders = «3133»
ddb.geometry.heads = «255»
ddb.geometry.sectors = «63»
ddb.adapterType = «lsilogic»
ddb.toolsVersion = «7202»

Пример второго файла — vdisk-000001.vmdk:
[root@myvi3server]# cat vdisk-000001.vmdk
# Disk DescriptorFile
version=1
CID=8eb633b8
parentCID=7f81b951
createType=»vmfsSparse»
parentFileNameHint=»/vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername/vdisk.vmdk»
# Extent description
RW 50331648 VMFSSPARSE «vdisk-000001-delta.vmdk»
# The Disk Data Base
#DDB
ddb.toolsVersion = «7202»
Примечание: файл из “parentNameHint” находится на iSCSI SAN. Длинный шестнадцатиричный GUID – идентификатор этого VMFS-хранилища.

Пример третьего — vdisk-000002.vmdk:
[root@myvi3server]# cat vdisk-000002.vmdk
# Disk DescriptorFile
version=1
CID=249e6aff
parentCID=8eb633b8
createType=»vmfsSparse»
parentFileNameHint=»sryulris0cogp01-000001.vmdk»
# Extent description
RW 50331648 VMFSSPARSE «vdisk-000002-delta.vmdk»
# The Disk Data Base
#DDB
ddb.toolsVersion = «7202»
Примечание: Путь к файлу в «parentNameHint» поле указывает на файл, который располагается в том же каталоге, что и vdisk-000002.vmdk. Если файл находится в другом каталоге, то в пути указывается каталог.

Решение

Следующие шаги синхронизируют файлы снимков VI3 так, что ESX/ESXi успешно проверит их связь друг с другом, а также их подлинность:
Примечание: Выполните следующие действия в текстовом редакторе. Сохраните резервную копию оригинального файла до внесения каких-либо изменений.

Измените vdisk-000002.vmdk:
1) Запомним CID у vdisk-000001.vmdk (= 8eb633b8);
2) Запомним путь к vdisk-000001.vmdk (= локальный каталог);
3) Исправьте parentCID для vdisk-000001.vmdk -> ParentCID=8eb633b8;
4) Исправьте parentNameHint на vdisk-000001.vmdk -> ParentFileNameHint=»vdisk-000001.vmdk».

Измените vdisk-000001.vmdk:
1) Запомним CID у vdisk-000001.vmdk (=7f81b951);
2) Запомним путь к vdisk-000001.vmdk (=»/ vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername /);
3) Исправьте parentCID для vdisk.vmdk -> ParentCID=7f81b951;
4) Исправьте parentNameHint на vdisk.vmdk файл -> ParentFileNameHint=»/ vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername/vdisk.vmdk».

Если виртуальные диски не были изменены, вас можно поздравить. Если же виртуальные диски были изменены или вы удаляли их из виртуальной машины, а затем добавляли снова, необходимо будет вручную изменить настройки соответствующего виртуального SCSI-контроллера в файле настроек ВМ — .vmx-файле (указать .vmdk последнего снимка в вашей CID-цепи).

Примечание: Выполните следующие действия в текстовом редакторе. Естественно, сохраните резервную копию исходного файла до внесения каких-либо изменений. 🙂

Измените servername.vmx:
1) Найдите SCSI контроллер, на котором находится виртуальный диск, который мы восстанавливаем. Первый виртуальный диск, как правило, назначается на SCSI-контроллер scsi0:0, второй — scsi0:1, а третий — scsi0:2;
2) Предположим, что мы восстанавливаем второй виртуальный диск. Найдите раздел, ссылающийся на scsi0:1;
3) Укажите в поле ссылку на .vmdk последнего снимка в нашей цепи:
scsi0:1.fileName=»/ vmfs/volumes/46fd62d479749c9697e30015c5fd9308/servername/vdisk-000002.vmdk».
Примечание: Путь к файлу может быть изменен, хотя по умолчанию снимки сохраняются в том же каталоге, что и первичный .vmdk (vdisk.vmdk). Поэтому введите полный путь к .vmdk снимка (vdisk-000002.vmdk), включая iSCSI GUID и т.д…
4) Сохраните файл и перезагрузите ВМ;
5) Если ВМ не загружается, или выдает ошибку “The parent virtual disk has been modified since the child was created.”, проверьте иерархию CID и пути к файлам, а затем повторите попытку. Если ВМ прежнему не загружается, а CID-сеть и пути к файлам корректны, то первичный или последующие .vmdk-файлы, вероятно, были изменены некорректным образом и их не удается восстановить!