Update VMware vCenter 6.0U3b to 6.5U1(c,d,e)

Дождавшись зелененькой галочки на пересечении 6.0U3 и 6.5U1(c,d,e), я решил выполнить обозначенное обновление в полном соответвии с матрицей обновлений от VMware

.... и на выходе получил:

"A problem has occurred. The source vCenter Server might have been Powered of durring this process..."

Огорчился, скачал 6.5U1d, повторил - результат аналогичный
Опять огорчился, скачал 6.5U1с, повторил - результат аналогичный

Решил посмотреть, что на эту тему пишут уважаемые люди. На vcdx133.com нашел "решение" аналогичной проблемы, которое заключается в следующем:

Rollback to vCSA 6.0

1. Verify the upgrade was a failure and you want to rollback to vCSA 6.0.

2. Power-off the vCSA 6.5 instance.

3. Power-on the vCSA 6.0 instance.

4. Verify the rollback was completely successful and all services that rely on vCSA 6.0 are correctly functioning.

5. Delete the vCSA 6.5 instance.

...and repeat

Repeat я уже делал - не помогло, действуем по следующей инструкции:

1. Громко с матами ругаемся на качество кода VMware

2. Игнорируем сообщение об ошибке

3. Перегружаем в ручном режиме "новый vCenter"

4. Получаем обновленный до 6.5U1(c,d,e) и корректно работающий vCenter (с успешно импортированными настройками, с/без статистикой по ивентам, тасками, статистикой производительности)

5. Громко с матами ругаемся на качество кода VMware

VMware ESXi Patch Tracker

Пока все увлеченно изучают анонс App Volumes 3.0, разбираясь в нововведениях и надеясь, что все предыдущие "not a bug but a feature" устранены, мне хотелось бы рассказать о вещах более приземленных, но весьма полезных.

Где-то далеко в застенках буржуазного запада правильный инженер и vExpert Andreas Peeta сделал весьма полезный сервис под названием VMware ESXi Patch Tracker. Ресурс предоставляет информацию о всех патчах и обновлениях, вышедших для ESXi начиная с версии 5.0.0 и заканчивая 6.0.0. Агрегатор работает в автоматическом режиме и позволяет получить следующую параметры: название, дата выхода, версия, категория, классификация по важности и номер KB с детальным описанием для каждого vib, патча или обновления. Есть информация по всем vib включенным в обновления "U". Доступны прямые ссылки для скачивания.

Одну из возможностей данного ресурса необходимо описать отдельно:

При наведении курса на обновление появляется всплывающее окно следующего содержания



Описанные выше, несложные манипуляции позволят скачать напрямую с хоста необходимое обновление, распаковать и установить.

Предварительно необходимо разрешить Remote Tech Support Mode (как вариант сделать это из консоли ESXi в разделе Troubleshooting Options) и подключиться к хосту по SSH, скопировать содержимое описанное выше и запустить на выполнение. Естественно, все это будет работать если у хоста есть доступ в интернет.

Удачи в борьбе с тем, что мы называем "баг", а вендоры "фичей".

VMware vCloud Director WebMKSConsole (vmrc console) disconnected...

В жизни каждого инженера, делающего облака, наступает блаженный момент создания первой виртуальной машины через web интерфейс vCloud Director. Но чаще всего с первой попытки это бесчувственное чудовище отвечает вот такой картинкой:

vmrc console disconnected и беленький пустой экран в том месте, где должна быть консоль виртуальной машины. 

Причин такого беспредела может быть много. С самыми простыми и тривиальными все понятно: 

1. Некрасивенький не поддерживаемый браузер. Об этом vCD предварительно честно сообщит. Список поддерживаемых браузеров описан в kb. Все это дело сопровождается очень неприятной поправкой:

The vCloud Director Web Console is only compatible with 32-bit browsers. If a browser is listed as supported on a 64-bit operating system platform, the use of a 32-bit browser is assumed. 

... и отсутствием в списке поддерживаемых платформ OS X

2. С некоторых пор для работы с web console стало обязательным использование сертификатов, которые вы генерируете/импортируете при установке vCD. Поэтому необходимо корневые сертификаты импортировать в хранилище корневых доверенных. Данное условие необходимо выполнить как для интерфейса vCD, так и для console address (это такой второй интерфейс vCD, куда и происходят все редиректы при подключении к web console)

3. Сертификаты должны быть свежие и вкусно пахнущие действующие. Если вы внимательно их генерируете это не проблема, т.к. сами указываете срок действия сертификата. Если вы все делаете по любимому методу next/next/next, то сгенерированные, самоподписанные сертификаты будут валидны 3 месяца.

4. Нет разницы: используете вы самоподписанные сертификаты или выданные взрослым центром сертификации. Работает и с теми, и с другими.

5. ... и самое интересное:

даже если все вышеописанное выполнено, вы все равно увидите унылую картинку №1
Природа жизнедеятельности java остается непознанной всем разумным человечеством, поэтому посмотрим, что в таком случае нам говорит сама java:

в отладочном режиме java консоль сообщает неутешительное - "я попробовала это сделать, но не смогла". Однако в красненьких сообщениях есть полезная информация: в строке подключений указан IP адрес, а не имя. В сертификатах мы же указали, естественно, имя.

Для сертификатов, выданных сторонним центром сертификации, данную проблему можно решить обходным путем, добавив поддержку альтернативных имен и внеся IP адреса интерфейсов в список этих самых альтернативных имен.

Для самоподписанных, использование которых не есть правильно, так сделать не получится, поэтому мы вынуждены сделать все правильно:

В настройках vCD необходимо прописать адреса интерфесов в строках "vCloud Director secure public URL" и особенно в "vCloud Director public console proxy address", не обращая внимания на ключевое "public":

Прописывание адреса для REST API на работоспособность REST API никак не влияет.

По мотивам бесед с достойнейшим из достойнейших @Константином Введенским

VMware vSphere 6.0.0b - работа над ошибками

Пару дней назад закончив ругаться на невнятные ошибки при импорте vAPP template из vSphere я описал ситуацию "нерабочести" такого действа в совокупности с включенным sDRS.

А уже вчера любимая компания зарелизила 6-ку до 6b-ки и указанная фича была пофикшена:

vApp creation fails when storage DRS is enabled 

When you use vCloud Director 5.5.3 with vSphere 6.0, any operation that clone a vApp, including add to my cloud, instantiate a vApp template, copy, relocate, or import a vApp might fail when the target virtual data center includes a storage DRS-enabled storage cluster that does not support source virtual machine's storage profile.
This failure logs an error message similar to the following:
Could not find datastore to create VM ...Cannot use datastore [vcId=nnnn, moref=datastore-nn] since it does not support storage policy SDRS_SP

Из полезного в новой сборке пофикшены баги с SSO, VASA, Host Profile, куча глюков в vCenter appliance, ошибки с отображением Hardwsre Status хостов, пакет глюков с VMware Tools, и невозможность создать vmfs5 размером большим 16 ТБ

Из МЕГО-полезного: стал возможен перенос SSL сертификатов VPXD при обновлении с 5.x на 6-ку

VPXD SSL certificates might not be migrated after upgrade to vCenter Server 6.0 

After you upgrade from vCenter Server 5.5 to 6.0 using an external Single Sign-On, the VPXD SSL certificates might not be migrated if the VPXD certificate is replaced by custom certificate prior to upgrade.

Также в сборку за буквой "b" добавлены все патчи, вышедшие после резина 6-ки.

Полные списки изменении для ESXi и vCenter. Доступны обновления и для закачки - ESXi и vCenter Server.

vCloudDirector import vAPP template from vSphere vs SDRS

Organization Catalog, доказавший свою состоятельность и полезность в vCloudDirector, успешно клонировался в vSphere.

Однако, не смотря на всю кажущуюся простоту работы с ним, низкая информативность ошибок в совокупности со слабой описательной частью в различных вендорных мануалах, зачастую приводят к долгим изысканиям на тему "почему же оно не работает как надо".

Одной из самых удобных функций при формировании каталога является импорт виртуальных машин в каталог из vSphere. 

На начальной стадии импорт редко проходит успешно и чаще завершается малопонятными ошибками как эти:

"The operation could not be reformed because the argument is invalid. A specified parameter was not correct.

StoragePlacementSpec.podSelectionSpec.initialVmConfig[].disk.diskid"

Row was updated or deleted by another transaction (or unsaved value mapping was incorrect)

Не смотря, на кажущиеся отличия в описании этих ошибок, природа их одинакова. Обе ошибки связаны с отсутствием "чего-то" в кластере, на ресурсах которого хранится и используется Organization Catalog. 

Теперь о необходимых шагах, чтобы такой импорт прошел без ошибок:

1. Предположим, что у нас есть 2 кластера: кластер управления и ресурсный кластер (в рамках которого и хранится каталог). Не смотря на то, что импорт доступен из любого из кластеров, исходной lun хранения vm должен быть доступен для хостов ресурсного кластера. 

Шарить один lun между разными кластерами не является хорошей практикой, но это придется сделать для машин, зарегистрированных в кластере управления или исходную vm необходимо будет переместить на ресурсный кластер и в нем же vm зарегистрировать.

2. Настройки vm, как контейнера, должны быть максимально обезличены:

Никаких подключены дисков и сетевых адаптеров c подмапленными сетями. 

3. Самое неочевидное и смело попадающее в категорию "not a bug but a feature" - в качестве назначения хранения каталога нельзя использовать storage cluster с включенным SDRS. В случае невыполнения данного условия импорт падает с ошибкой, описанной выше. Этим VMware как бы намекает, что каталоги необходимо хранить в рамках отдельного lun, который, кстати, должен быть доступен всем хостам ресурсного кластера, но может быть недоступен как часть ресурса пользовательского VDC. Если такой возможности нет, и вы храните системный каталог в рамках общего storage cluster с включенным SDRS - на время импорта отключайте SDRS

Ну и напоследок: если вы ленивы, просто создайте универсальный vmx, который будет проходить необходимые проверки, подложите его к машинке, а после импорта замените. Вариант работает, но я не несу никакой ответственности если используя такой вариант вы что-то сломаете, как, впрочем, вообще не несу никакой ответственности в любой другой ситуации. 

nbbf: vShield Manager & Specify a vCenter user

Один известный производитель ПО для виртуализации продолжает радовать багами фичами в своих продуктах.
Ролевой доступ, казалось бы, куда уж проще, но нет.

Возникла необходимость предоставить доступ сетевому инженеру к vShield Manager.
Пошел на SSO, сделал учетку и добавил ее через интерфейс vShield Manager.

Красота. Высылаю login | password. А мне вот так в ответ:

Думаю, ладно промазал с паролем два раза. Меняю пароль еще раз, высылаю сетевику, а он мне - "ничего не изменилось". Сетевики люди специфические, особенные - проверил сам, результат - "ничего не изменилось"

В поисках решения вопроса с очередной фичей логики было мало, но был результат. 

Чтобы доступ заработал пришлось дать доступ Администратора на объект "виртуальная машина"

Красота... при полном отсутствии логики.