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 никак не влияет.

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

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. А мне вот так в ответ:

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

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

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

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

Провайдеры облачных услуг Veeam (VCP)

Все заинтересованные знают о специальной программе VMware для сервис-провайдеров - VSPP.
Все очень просто, если Вы собираетесь сдавать в аренду виртуальные машины VMware vSphere, то VSPP единсвенный выбор для Вас. В любом другом случае Вы нарушите пользовательское соглашение EULA.
Став участником программы, Вы получите возможность использовать и предоставлять в аренду внешним Клиентам виртуальные машины, используя ПО VMware (vCloud Director, View, ThinApp, SRM, vShield, vFabric и т.д.)

Специально для провайдеров облачных сервисов компания Veeam разработала аналогичную программу - Veeam Cloud Providers (VCP).

Участие в VCP позволяет предоставлять услуги хостинга для Veeam:
- Удаленная инфраструктура для заказчиков Veeam Backup & Replication (Rbackup DC)
- BaaS, резервное копирование как сервис. Резевным копированием будет управлять провайдер услуг (VCP), с соблюдением заданных Клиентом показателей RTO и RPO.
- DRaaS, послеаварийное восстановление как сервис на основе решений Veeam
- Хостинг виртуальных машин с защитой Veeam. Провайдер облачных услуг хостит виртуальные машины (VMware, MS), защищенные решением Veeam.

В РБ, на данный момент, к сожалению, данная услуга недоступна по причине отсутсвия VCP провайдеров.

Найти провайдера облачных услуг Veeam в вашем регионе можно здесь.