Записки о виртуализации и о жизни
Andrew Morgan обновил свою незаменимую разработку Horizon Helpdesk Utility. Теперь она умеет показывать полные имена из AD пользователей VDI, а также дополнительную информацию об образах ВМ. Лог изменений.
Также он выпустил новую систему мониторинга VMware Horizon Reach, для администраторами с несколькими POD это может стать универсальным продуктом для определения состояния системы.
Инструкция по установке Horizon Reach.
| Enhanced NAS backup | NetApp ONTAP SVM Processing | EA: RMAN Plugin for Solaris |
| Cloud Tier & SoBR Enhancements | Linux Backup Proxy | EM: SAML 2.0 Support |
| Data Integration API | Linux VIX | VAL: PostgreSQL Processing |
| GFS Retention M Primary Backup Jobs | Block Cloning on XFS | VAL: MySQL Processing |
| Snapshot only Backup Jobs | NFS Backup Repository | VAL Dedupe storage support |
| Backup Copy Job Enhancements | Multi-AM Instant Restore | VAL: CLI Enhancements |
| Transaction Logs Backup Copy Job | VAW: Instant Recovery to vSphere | ONE: General Enhancements |
| WAN Acceleration Enhancements | VAW: Parallel disk processing | ONE: NAS Backup Support |
| Enhanced Nutanix AHV Backup | SAP Enhancements | ONE: Nutanix Support |
Видеозаписи докладов с VMworld 2019 EU доступны на страницах:
Всем привет!
Пятница, вечер, дождик…
1) В одной компании вышел из строя RAID6 на HP Proliant Gen6, виртуальные машины на VMware ESXi стали частично недоступны.
Пошли за бэкапами на систему хранения QNAP – оказалось, что она тоже потеряла два диска в RAID5, вследствие чего бэкапов тоже нет.
Владелец взял где-то два брендовых SATA-диска IBM, объединил их в программное зеркало (динамический диск MS Windows) и скинул туда данные с сервера Hyper-V. Сервер Hyper-V был переформатирован под ESXi.
Когда через месяц-два он раздобыл новый сервер под Hyper-V, оказалось, что оба IBM-диска неживые.
Я не уточнял у него, как он вышел из этой ситуации.
2) В другой компании внезапно стали недоступными виртуальные машины, находящиеся на одном из RAID-массивов. Как оказалось, LUN3, состоящий из двух SSD-дисков в зеркала, решил что ну его…
У нас же есть бэкапы, заявил мой тезка. Угу-угу, VMware Data Protection 6.1.2 не загружался, в консоли висела надпись:
|
1 |
/usr/local/vdr/configure/bin/checkforddrpreset.pl", exit status=0 |
Перезагрузка не помогла, через час все было точно также.
vDP пытались оживить сначала вручную, потом через техподдержку VMware. Третий по счету инженер из EMC смог оживить бэкапы и мы узнали… что последний бэкап сделан год назад. Так как “Retention Policy” требует хранить бэкапы за последние 90 дней…
Тут мой тезка и говорит “у меня есть еще одна система резервного копирования, сохраняющая файлы на сервер в Amazon. Но я залогиниться туда не могу 🙁
В общем, сервер с бэкапами на Amazon оказался заражен каким-то ransomware…
Параллельно была сделана попытка выключить и включить система храения с выдергиванием/втыканием SSD-дисков (потому что она еще и на RAID-контроллер ругалась)…
После включения массива сдохло еще 4 SAS-диска (2 уже не работали), вследствие чего Lun2 ушел следом за Lun3. Как оказалось, MD3220i более 7 лет.
Какие выводы (кроме настройки уведомлений) вы бы сделали из обоих историй?
Какие epic fail были у вас?
В последнее время VMware часто озвучивает новый функционал VCSA VAMI – создание резервных копий конфигурации vCenter на разные хранилища по протоколам FTP/FTPS, HTTP/HTTPS, SCP, NFS, SMB.
Мы сразу после внедрения VCSA 6.7 настроили резервные копии на FTP, время от времени удаляя копии с хранилище.
После реализации поддержки SMB перенастроили на новый протокол, но с удивлением обнаружили, что ротация резервных копий так и не работает.
Поиск в БЗ VMware подсказал ответ – VCSA VAMI backup is failing to delete old backups according to retention policy (70823). То есть проблема нам не померещилась и когда-нибудь будет исправлена, а пока чистим руками…
На днях я сконвертировал несколько виртуальных серверов Hyper-V 2012R2 в VMware vSphere 6.5, и тут коллеги заметили, что VMRC как-то странно ругается.
Опытным путем было выяснено, что он ругается на включенный UEFI в их серверах. Коллеги подтвердили, что сервера были развернуты с системой UEFI и режимом SecureBoot, который после конвертации на VMware был отключен. Причем они сказали, что в Hyper-V GEN2-машинах UEFI включается автоматически.
Я проверил настройку по умолчанию для Windows 2012/2016 в VMware – там рекомендуемый режим – BIOS.
Пойдемте разбираться вместе, кто прав 😉
Однажды мы решили закопать стюардессу поменять наш прокси-сервер Microsoft TMG на что-то более новое. И вот как-то ночью звонит инженер из HPE и срывающимся голосом сообщает, что наша система хранения данных HPE 3PAR перестала отсылать отчеты о своем самочувствии. Так как звонил не круглосуточный диспетчер, было ясно, что это фигня!
На следующий же день я зашел на веб-интерфейс Virtual Service Processor (далее VSP) и выполнил операцию SPmaint -> 2. Network Configuration -> 7. Test 3PAR Secure Service Collector Server.
Ошибка HTTP 407 намекает, что текущий прокси-сервер перестал принимать учетные данные с HPE 3PAR VSP.
Continue reading “HPE 3PAR VSP сброс пароля cpmaint и настройка Proxy”
При подключении к Программе повышения эффективности работы заказчиков (Customer Experience Improvement Program, CEIP), вы может проверить здоровье вашей vSphere через онлайн-анализатор.
Проверки с проблемами пишутся все, а вот беспроблемные только частично. Меня интересовало – что ещё проверяется?
Итак список проверок на момент публикации статьи:
Коллеги поделились решением проблемы установки ESXi на HPE Superdom в режиме Boot from SAN.
—
У нас есть партиция Superdom из двух лезвий gen8, процессоры серии Intel Xeon E7-2800 v2 и HBA Qlogic HP QMH2672 16Gb с версией fw 8.07.16.
Я хотел установить туда HPE ESXi 6.0u3 (preGen9), так как именно она является последней поддерживаемой версией по данным матриц совместимости HPE и VMware.
При установке столкнулся с тем, что Wizard не видит презентованный диск для установки в режиме Boot from FC SAN.
Рядом стоит точно такая же партиция, состоящая из одного лезвия с такой же HBA. Проблем при установке ESXi там не было.
В поисках решения я перепробовал все сборки HPE’шных образов ESXi (а также оригинальных) – только HPE 6.7U1 увидел диск для установки, но его поставить нельзя 🙂
Я начал сравнивать драйверы для QMH2672 в различных образах ESXi и выяснил, что:
В VMware HCL написано, при HBA с прошивкой 8.07.xx в ESXi 6.0U3 должны работать версии драйвера от 2.1.63 до 2.1.70.
Странно – на первую патрицию успешно установился ESXi с версией драйвера 2.1.50, которая отсутствует в HCL 🙂
Затем я попробовал собрать свой образ с драйвером 3.1.16 из offline bundle, но при сборке получил ошибку зависимости, которой нет в 6.0. Не зря этот драйвер входит только в дистрибутив 6.7 😉
На всякий случай, для чистоты эксперимента я снес все зоны и сделал только зонинг только на одну систему хранения, где расположен загрузочный LUN.
УРА! После перезагрузки хост успешно увидел LUN для установки 🙂
Продолжив эксперименты, я нашел причину такого поведения – HPE StoreOnce!!!111
В ESXi до версии 6.7 существует ограничение в 1024 пути. Catalyst, расположенный на StoreOnce, с лихвой переполнял это ограничение.
И только в ESXi 6.7 количество возможных путей увеличено до 4096, вследствие чего хост нормально видел загрузочный лун!
Видеозаписи докладов с VMworld 2019 доступны на страницах: