VMware vCloud Director и сертификат со "звездочкой"

Для обладателей сертификатов со звездочкой *.zone.xxx есть достаточно удобный и быстрый способ подружить vCloud Director c таким сертификатом.

Для приготовления нам понадобятся: сertificate.crt - сам сертификат и кey_certificate.key закрытый ключик.

Используемый vCloud Director-ом JCEKS и keytool не умеют работать напрямую с *.crt и *.key, потому на первом этапе нам придется засунуть Certificate.crt и Key_certificate.key в какое-нибудь достойное хранилище сертификатов и закрытых ключей, например, PKCS#12 используя openssl:

> openssl pkcs12 -export -in Certificate.crt -inkey Key_certificate.key -out cert_http.p12 -passout pass:<PASSWORD> -name http

Обязательным условием является добавление алиаса -name http и consoleproxy, в дальнейшем этот шаг позволит нам экспортировать из PKCS#12 в JCEKS и добавить необходимые VMware vCloud Director alias.

> openssl pkcs12 -export -in Certificate.crt -inkey Key_certificate.key -out cert_consoleproxy.p12 -passout pass:<PASSWORD> -name consoleproxy

После этого подключаемся к VMware vCloud Director и переносим сертификаты из хранилища PKCS#12 в JCEKS

Для alias http:

> keytool -importkeystore -srckeystore cert_http.p12 -srcstoretype PKCS12 -srcstorepass <PASSWORD> -deststorepass <PASSWORD> -destkeypass <PASSWORD> -deststoretype JCEKS -destkeystore certificates.keystore -alias http

Для alias consoleproxy:

> keytool -importkeystore -srckeystore cert_consoleproxy.p12 -srcstoretype PKCS12 -srcstorepass <PASSWORD> -deststorepass <PASSWORD> -destkeypass <PASSWORD> -deststoretype JCEKS -destkeystore certificates.keystore -alias http

Корректность переноса из одного хранилища в другое проверяем

> keytool -keystore certificates.ks -storetype JCEKS -storepass <PASSWORD> - list

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, который будет проходить необходимые проверки, подложите его к машинке, а после импорта замените. Вариант работает, но я не несу никакой ответственности если используя такой вариант вы что-то сломаете, как, впрочем, вообще не несу никакой ответственности в любой другой ситуации.