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 vSphere and OpenStack "SelfPortal One for All"

Хорошие ребята из Altoros сделали небольшой Open-sourcing SelfPortal для работы с VMware vSphere и OpenStack.

Если вы предоставляете доступ вашим бизнес-подразделениям возможность деплоить себе машинки из шаблонов, то вполне может сгодиться.

На данный момент поддерживаются следующие штуки:

- An ability to create, modify, and delete VMs
- A web interface with a dashboard, containing a list of users
- Two access roles: a user and an administrator
- HTTP website proxy for external access
- Blacklist for preventing external access to sensitive resources
- Termination of unused VMs or web apps

но ребята обещают продолжить доработку и даже имеют на этот счет roadmap:

- HTTPS website proxy using wildcard certificates
- WebSocket proxy
- VM backups
- Mounting ISO images to vSphere VMs
- Error notifications

Подробнее почитать про SelfPortal можно тут, а скачать в этом месте.

И самое важное: если у вас есть идеи что добавить или что изменить - пишите в комментах или на почту.

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 vs CVE-2017-5715

09.01.2018 VMware зарелизила обновления на CVE-2017-5715, не смотря на предыдущее заявление о том, что уязвимость закрыта более ранним патчем  ESXi650-20172101-SG от 19.12.2017.

Информация на данный момент не доступна на блоге по безопасности VMware *) 

Выпущены обновления для следующих продуктов: 

- VMware vCenter Server (VC)

- VMware ESXi (ESXi)

- VMware Workstation Pro / Player (Workstation)

- VMware Fusion Pro / Fusion (Fusion)

Необходимо установить следующие обновления:

- VC 6.5 обновление 6.5 U1e

- VC 6.0 обновление 6.0 U3d  

- VC 5.5 обновление 5.5 U3g

- ESXi 6.5 обновления ESXi650-201801401-BG, ESXi650-201801402-BG 

- ESXi 6.0 обновления ESXi600-201801401-BG  ESXi600-201801402-BG

- ESXi 5.5 обновление ESXi550-201801401-BG

Обновления ESXi650-201801402-BG, ESXi600-201801402-BG, ESXi550-201801401-BG выпущены со следующим комментарием "These ESXi patches install the microcodes if present for your CPU,

see VMware Knowledge Base article 52085" 

- Workstation 14.x  обновление 14.1.1              
- Workstation 12.x  выпуск планируется в ближайшее время
- Fusion      10.x    обновление  10.1.1                
- Fusion      8.x    обновление  8.5.10 

Ссылки для загрузки и описания доступны по ссылке

ESXi и Reading privileged memory with a side-channel

Пока половина людей продолжает похмеляться после отмечания НГ, вторая половина истошно обсуждает отчет Google "Reading privileged memory with a side-channel" и хайпит на темы:

CVE-2017-5753
CVE-2017-5715
CVE-2017-5754

У VMware вроде все более менне ровно и выглядит примерно так

CVE-2017-5753, CVE-2017-5715 закрыты в ESX 6.5 обновлением от 19.12.2017 за именем ESXi650-20172101-SG

Для остальных версий (6.0 и 5.5) также есть соответсвующие KB и патчи.

А про CVE-2017-5754 написано примерно так: "It does not affect ESXi, Workstation, and Fusion because ESXi does not run untrusted user mode code, and Workstation and Fusion rely on the protection that the underlying operating system provides."

Upgrading VSAN from 6.0 to 6.2. Step by Step

Вчера ночью компания VMware выпустила обновление U2 для платформы виртуализации VMware vSphere 6.0. Обновление косметическо-багафиксельное.
Подробнее о изменениях для ESXi можно почитать здесь, изменения затронули и vCenter.
Полезным и интересным из всего этого оказалось анонсированное ранее обновление VSAN до версии 6.2.

Совершенно случайно у меня есть VSAN версии 6.0 - его и будем обновлять.

Имеется:
- 4 хоста ESXi 6.0U1b
- VMware vCenter Appliance 6.0U1b
- VSAN 6.0
- VMware vCloud Director 8.0.0 for SP (для которого тоже вышло обновление)
- Вся система управления виртуальной платформой расположена на VSAN, других datastore нет.

Компания VMware не выпустила дополнительных рекомендаций по обновлению до U2, будем руководствоваться здравым смыслом и древней KB2109760, в которой нет ни слова о VSAN.
Однако мы знаем, что ядро VSAN интегрировано в ESXi, поэтому выбираем следующую последовательность обновлений:

1. VMware vCenter Appliance 6.0U1b
2.  ESXi 6.0U1b

Обновление vCenter Appliance 6.0U1b до версии 6.0U2

1. Идем на https://<FDQN_vcenter>:5480 (используем учетную запись root)
2. В меню Update выбираем Check Updates -> Check URL (возможна установка обновлений из ранее скачанной iso, но это лишние ручные операции)
3. Система самостоятельно ломится на  https://vapp-updates.vmware.com/vaicatalog/valm/vmw/
и радует нас обновлением 6.0.0U2
4. Смело нажимаем Install Updates

Система замирает на какое-то время на Staging Patch from Repository, и кнопочка ОК становится активной. 

5. Перегружаем vCenter Appliance в ручном режиме и получаем красоту

После обновления vCenter нам должны быть доступно новые элементы управления VSAN, но работать они не должны. Все получилось согласно ожиданиям.

Неработающий новый VSAN Health

Не отображающий ничего нового и полезного Capacity Overview, неработающая Deduplication и Compression.

Не отображающий ничего Compliance для VM

Обновление ESXi 6.0U1b до ESXi 6.0U2 (читать как VSAN 6.0 до VSAN 6.2)

Правильный способ (для слабаков и трусов):

1. Мигрируем все VM с datastore VSAN 

2. Обновляем хосты 

3. Настраиваем VSAN 6.2

Правильный на половину способ (для трусов):

1. Делаем резервные копии всех VM

2. Проверяем, что наши резервные копии не стали резервным захоронением

3. Обновляем хосты

4. Настраиваем VSAN 6.2

Наш путь:

1. Выводим хост с в Maintenance mode c параметром Virtual SAN Data Migration - "Full data migration"

Отдельно для любителей толстого клиента vCenter хочу отметить, что вывод хоста с VSAN в Maintenance mode необходимо делать только через Web клиент.

После обновления первого хоста ситуация выглядит так.

Уже после обновления одного хоста стала корректно отображаться часть информации в Capacity Overview

После обновления всех хостов начинает опять работать VSAN Health, который ненавязчиво предлагает выполнить Upgrade On-disk Format

Нажимаем заветную кнопку "Upgrade On-disk Format", перед этим переведя VSAN в режим ручного добавления дисков

Перед началом обновления нас предупреждают о том, что процедура долгая и сложная, и что лучше удалить, а потом снова добавить диски. Нас это мало волнует, жмем ок и обновляемся.

Процедура обноления на 4-х серверах (1x800Gb SSD + 3x2000Gb NL-SAS) заняла 55 минут. В процессе обновления на дисках находились работающие VM, просадки производительности не наблюдалось. 

После обновления включаем Perfomance Service

Обязательно обновляем HCL database (для VSAN 6.2 в ней произошли изменения)

Протестировать "Deduplication and compression" мне на данный момент не удалось, потому как

это требует "reformat of all disk"

На этом обновление VSAN завершено. Улыбайтесь, Иисус любит вас.

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, скопировать содержимое описанное выше и запустить на выполнение. Естественно, все это будет работать если у хоста есть доступ в интернет.

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

VMUG VMware's EVALExperience

В начале 2015 года для участников VMUG Advantage подписки стала доступна новая программа    - VMware's EVALExperience.

Заплатив две сотни мертвых американских президентов кроме всяких скидок на обучение, курсы, книги, экзамены в рамках EVALExperience предоставляется доступ к всяким полезным лицензионным ключам на продукты компании VMware.

В списке присутствуют все самое вкусное:

• VMware vCenter Server™ 5 Standalone for vSphere 5
• VMware vSphere® with Operations Management™ Enterprise Plus
• VMware vCloud Suite® Standard
• VMware vRealize™ Operations Insight™
• VMware vRealize Operations™ 6 Enterprise
• VMware vRealize Log Insight™
• VMware vRealize Operations for Horizon®
• VMware Horizon® Advanced Edition
• VMware Virtual SAN™

Естественно, все это закрыто унылым "для домашнего использования, не для коммерческих целей и т.п". 

Процесс доступа ко всему этому счастью достаточно простой: регистрация на vmug.com, покупка VMUG Advantage, на почту приходит письмо с ссылкой на https://vmugadvantage.onthehub.com для подтверждения регистрации на EVALExperience,  подтверждаем, логинимся здесь и получаем картинку с доступными продуктами. Дальше как в магазине: выбираем, покуем за 0 $, получаем ссылку на загрузку и ключик. 

ESXi root password reset

Иногда я забываю теряю пароль от root для ESXi. Такое бывает, хостов много разных для разных целей, а привычки "одного пароля на все" у меня нет.

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

Не смотря на все старания VMware, ESXi все еще остается Linuxом, а значит будем действовать старым и проверенным способом.

1. Качаем Linux LiveCD. В моем случае - он народный 

2. Подключаем диск с LiveCD к серверу с ESXi и грузимся с него.

3. В подложке ESXi у нас будет лежать GPT, поэтому не заморачиваясь с fdisk сразу идем в gparted

4. У ESXi жизнь на диске происходит так:

system boot - загрузочный системный раздел

bootbank - системный образ ESXi, именно оно и копируется в оперативную память при загрузке.

altbootbank - резервный для bootbank (на случай беды при обновлении)

vmkDiagnostic - дампы памяти при blue screen purple screen

store - образы VMware Tools

scratch - такой есть если диск больше 5 Гб и туда падают всяческие логи.

5. /dev/sda5 - это то, что нам надо. Монтируем и смотрим что же там есть.

6. А надо нам state.tgz. Закинем его в tmp и распакуем.

7. Теперь нам надо local.tgz

8. Теперь принимаемся за shadow. Делаем из некрасивого shadow:

красивый:

9. Обновляем старый state.tgz до нового state.tgz

10. Отмонтируем /mnt и перегружаем хост.

11. Пароля нет.

P.S> и да, оно работает в 5.5

P.S2> а кто-то говорил, что не бывает ESXi c пустым root паролем...

Клонирование диска VM со снапшотом

Для ESXi без vCenter, к сожалению, нет возможности делать клонирование из GUI.
Для клонирования дисков VM в данном случае спасает vmfstools

При использовании vmfstools для VM со снапшотом есть небольшая особенность - в качестве источника необходимо указывать снапшот:

# vmkfstools -i /vmfs/volumes/Storagetest01/testvm/testvm-000003.vmdk /vmfs/volumes/Storagetest02/testvm/testvm_clone.vmdk

Доступно клонирование только выключенной машины. Однако это ограничение можно обойти так:

1. Делаем снапшот машины.
2. Клонируем исходный не заблокированный vmdk:
# vmkfstools -i /vmfs/volumes/Storagetest01/testvm/testvm.vmdk /vmfs/volumes/Storagetest02/testvm/testvm_clone.vmdk

VMware vCenter Log Insight syslog collector for Windows

Я уже писал про VMware vCenter Log Insight здесь. Про то как он интегрируется с VMware vCenter и VMware vCenter Operations, про то как он кастомизуется, анализирует, строит отчеты, алертует и т.п.

Сегодня мы будем использовать его совсем для другого...

vCenter Log Insight. Private.

А вокруг только и разговоров, что о vCenter Log Insight. Как оно бесконечно прекрасно тюнится и делает жизнь администраторов светлой и радостной. (с)

Профильные ресурсы просто переполнены инструкциями и мануалами по новой игрушке от VMware - vCenter Log Insight. Продукт еще в Beta, но уже заставляет обратить на себя внимание.

- vCenter Log Insight это не очередной logserver. Точнее и он тоже, но ключевым тут является не сбор и хранение, а управление, аналитика, визуализация, структурирование событий от виртуальной инфраструктуры (приложения, vm, хосты, сетевые устройства, межсетевые экраны, ос, СХД).
- поставляется в виде Virtual Appliance, интегрируется с VMware vCenter и VMware vCenter Operations. Второй вариант интересней, т.к. позволяет находить причины проблем отраженных  в Operations искать напрямую в логах.

Все дальнейшее строго ИМХО, основанное на 2-х недельном ковырянии в продукте.

Ресурсы:

Начинал с 2 хостов закончил на 30 - существенной разницы в потребляемых ресурсах не заметил. Добрые люди рассказывали о развертывании на 600+ хостов.

conf vm: 2vcpu, 8gb ram

утилизация в режиме сбора событий:
2-5% СЗГб 5-10% memory, lan (av) 5-10 Kbps (в пиках 100), disk: latency(av) 30, usage(av) 400 Kbps

утилизация в режиме формирования замысловатых выборок по событиям:
10-50% СЗГб 20-80% memory, disk: latency(av) 45, usage(av) 5000 Kbps - все, естественно, зависит от сложности сортировки и количества событий

Положительные моменты:
- заявленная работа в режиме реального времени, почти так и работает...
- удобная и полноценная возможность кастомизации "My Content"
- возможность добавления нескольких vCenter в одном инстансе vCenter LI
- удобная организация fields для группировки и просмотра события по типу, источнику, категории
- предусмотренная из коробки удобная и работающая возможность замены сертификатов
- почти безграничные возможности кастомизации Dashboard.
- возможность группировки алертов по различным тегам (источник, тип события и т.п.) с последующим созданием для таких групп различных типов реакций: отправка сообщения по почте, повторные уведомления и т.п.

"НЕположительные" моменты:
- нет интеграции с LDAP - просто ужасно для продукта, который позиционируется для корпоративного рынка.
- нет возможности самому раскрашивать алерты в графике на Dashboard

Других минусов на данный момент тестирования не заметил.
Списки будут дополняться.

Uninstalling plugin vSphere Data Protection

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

Вот как надо:

1. выключаем VDP, используя shutdown
2. если ничего не собираемся сохранять - по правой кнопке delete from disk
3. идем на https://<vcenterIP>/mob
4. выбираем content, далее выбираем extensionmanager
5. нажимаем unregisterextension, в строке VALUE пишем com.vmware.vdp
6. Invoke Method
7. если повезло, рассматриваем сообщение "Method Invocation Result: Void"
8. Релогин и наслаждаемся результатом.

Инструкция универсальная и подходит для других компонент, добавляющих свои плагины в vCenter Server

симбиоз Citrix XenApp и VMware vSphere

Про PCI DSS пока перерыв, а пока о том, как я "дружил" Citrix XenApp и VMware vSphere, зачем мне это было надо и что из этого получилось.

Citrix XenApp - решение для доставки приложений Windows, позволяющее осуществлять виртуализацию, централизацию, управление из центра обработки данных и доставку приложений по запросу на любое пользовательское устройство вне зависимости от его местоположения.

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

Фермы терминальных серверов Citrix XenApp отлично масштабируется добавлением дополнительных мощностей (серверов) и размазыванием пула пользователей по большему количеству ресурсов, что, естественно, приводит к уменьшению нагрузки на каждый сервер.

В процессе администрирования я столкнулся с рядом "неудобств":

- сервера, ОС имеют свойство ломаться. Как показывает мой опыт администрирования Citrix сервера с XenApp ломаются чаще, чем без него. Конечно, если в вашей ферму полсотни серверов и приложения разнесены по всем бестпрактисам обеспечения отказоустойчивости и производительности - потеря одного сервера не становится глобальной проблемой. Но вот повторное добавление сервера в ферму после ремонта процедура совершенно неинтересная и малопривлекательная, а чтобы восстановиться до исходного состояния все должно быть хорошо задокументировано. Бэкапить физические сервера процедура неудобная, а с учетом динамики изменения настроек серверов Citrix XenApp для поддержания актуального бэкапа - эти неудобства придется терпеть очень часто.
- различные требования публикуемых приложений к CPU и RAM. Казалось бы это не проблема: публикуй на каждом сервере приложение требовательное к CPU и приложение требовательное к RAM и будут задействованы все ресурсы. Все это хорошо "сайзится" на десятке приложений. Когда приложений ставятся сотни + территориальная разнесенность офисов (генерирование специфических нагрузок в разное время суток) + востребованность некоторых приложений в определенные дни месяца - и вот задача эффективного использования доступных ресурсов становится совсем не тривиальной.
- требования безопасников к изоляции приложений на серверах. Зачастую приходится выделять целый сервер под одно приложение + еще один для отказоустойчивости. А приложением может использовать всего пара пользователей...
-требования IT подразделений занимающихся тестированием и отладкой приложений. Обычно, эти ребята тоже хотят под каждое тестируемое приложение отдельный сервер. Это  позволяет избежать "воздействия сторонних факторов создаваемых инородными приложениями". А с учетом того, что тестирование это процесс идущий по графику час тестирую, день не тестирую, то неэффективное использование ресурсов увеличивается.

Решить эти неудобства я попытался с помощью приживления Citrix XenApp в инфраструктуру VMware vSphere:

с реализацией все понятно из схемы, а вот про плюсы и минусы стоит поговорить.

Минусы:
 - это дорого, точнее дороже чем первый вариант. Citrix XenApp лицензируется конкурентными пользовательскими лицензиями, а вот на лицензии ОС и vSphere придется потратиться. Простая истина о том, что нельзя получить отказоустойчиво, удобно, быстро и "задешева" работает.
- накладные расходы: как может показаться с первого взгляда расход гигагерцев и гигабайтов физических серверов на нужды ESXi и большее количество ОС Windows будем достаточно большим. Но при реализации осознанного подхода к разнесению приложений по серверам потери будут соизмеримы с потерями при "сайзинге" первой схемы.

Плюсы:
-восстановление после аварии. тут все очевидно: о удобстве резервного копирования и восстановления виртуальных машин написано уже достаточно, повторятся нет смысла. Делая бэкапы виртуальных машин с Citrix XenApp каждую ночь мы получаем при востановлении полностью эквивалентные по настройкам сервера, а если посмотреть на бэкап сотни виртуальных серверов с Citrix XenApp сквозь призму дедупликации, то на выходе мы получаем еще и небольшой по размеру бэкап большой инфраструктуры.
  - проблема "сайзинга" решена. Выделяйте виртуальным машинам ресурсы согласно потребностям опубликованных на них приложений. Падкое на быстрые гигагерцы приложение публикуйте на виртуальных серверах которым выданы эти гигагерцы, на толстые гигабайты - на серверах с толстыми гигабайтами. А нехватку ресурсов всегда можно мониторить и компенсировать.
- желания и требования любителей схемы одно приложение = один сервер тоже решена.
- траблшутинг ошибок Citrix XenApp исчез как вид. Большинство проблем устраняется восстановлением всей виртуальной машины.