Всегда говори да!

«Обычно люди обращаются за советом, — говорил Атос, — только для того, чтобы не следовать ему, а если кто-нибудь и следует совету, то только для того, чтобы было кого упрекнуть впоследствии.»

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

  1. 2009-й год, я работаю обычным системным администратором на заводе. Windows, Exchange и немножко ДрВеба с Симантеком :).
    Тут мне предлагают стать ответственным за администрирование коммутаторов, маршрутизаторов и брандмауэров Cisco. В качестве бонуса еще и немного учат!
    Я, конечно же, соглашаюсь. Коллега из соседнего отдела сомневается и отказывается — зачем ему дополнительный головняк?
  2. 2011 год, в другом месте мне предлагают взяться за администрирование системы MS Lync Server 2010. Тоже учат, ага…
    Там же ближе к 2017 — внедрить систему резервного копирования NetBackup.

Результатом первой возможности стало более глубокое понимание работы сети и сертификат CCNA (хотя, поработав в интернет-провайдере, я осознал — насколько же это были базовые знания). Пару раз помогало тыкать носом сетевиков в их косяки.
Результатом второй и третьей — приличные знания по обеим системам в качестве T-shape специалиста. В результате, в 2020м меня брали на центрального администратора Commvault с хорошим окладом без практического опыта по нему 😉

Я не могу рассказать о текущем стеке, но он не имеет ничего общего с привычным мне VMware/Microsoft. Когда-нибудь я расскажу и эту историю…

Добавление FC-коммутаторов с FabricOS 9.x в Brocade Network Advisor

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки Broadcom. Любое использование оборудования вне списков совместимости Broadcom может быть использовано только на свой страх и риск. В статье рассматриваются коммутаторы на основе G620 первого и второго поколения. BNA ничего не знает про новую функциональность FabricOS 9.x и не сможет с ней правильно взаимодействовать.

Для управления FC-фабриками мы используем Brocade Network Advisor, который прекратил свой жизненный путь и заменен на SANNav.

К сожалению, SANNav поставляется по подписки и у нас есть проблемы с её приобретением.

Первой проблемой для нас стало то, что последняя версия BNA 14.4.5 перестала интегрироваться с VMware vCenter 7.0. Пришлось интеграцию удалить.

Второй проблемой — отсутствие поддержки Fabric OS 9.x, которая стала базовой для новых и обновленных коммутаторов.

У нас коммутаторы G620 второго поколения отображались в схеме фабрик как имеющие неправильные имя-пароль для подключения. Изменение настроек в разделе snmp коммутаторов и сервера — задание уровня шифрования для пользователя мониторинга в BNA и коммутаторе, включения информера не помогали.

Просмотр текущих настроек snmp:

Изучение настроек BNA выявило, что для сканирования оборудования фабрик используется аккаунт domain\access_bna, то есть коммутаторы должны позволять вход под доменными учётными записями.

Настроили и для новых коммутаторов RADIUS- авторизацию:

После этого коммутатор стал доступен для мониторинга и отобразился в схеме фабрики.

А вот коммутатор в другой фабрике по-прежнему остался недоступным. В консоли BNA выводилась ошибка с фразой:

Начали выяснять отличия первого коммутатора от второго.
Вспомнили, что на первом ломала и пересоздавали сертификат для подключения по https, а второй избежал этой участи, так как  проблема была в браузере — подключаться необходимо из Windows 10 с установленной кодовой страницей профиля пользователя EN-US.

Просмотр сертификатов для https выдается командой:

Разница видна сразу:

Команда генерации сертификата, по найденному лайфхаку, была:

Примечание: не все советы в интернете оказываются полезными. Помните это, читая и данную статью!

Создали новый сертификат с другим алгоритмом, соответствующий второму коммутатору:

После перегенерации сертификата, BNA увидел коммутатор и в этой фабрике.

Veeam Backup&Replication и восстановление дедуплицированных дисков

При попытке восстановить файлы на дедуплицированных томах из виртуальной машины с помощью Veeam BR FLR процесс восстановления зависает.
При запуске восстановления появляется сообщение:

Это связано с отсутствием компонентов дедупликатора. Добавляем их вручную на сервер Veeam BR:

Повторно восстанавливаем файлы.

Удаленное подключение к Linux через VMware Horizon Direct Connection

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки VMware. Любое использование программного обеспечения не соответствующего системным требованиям VMware может быть использовано только на свой страх и риск.

В разгар локдауна от ковида была написана статья о возможности использования прямого подключения к ПК по протоколу Blast (Blast Extreme) без использования серверной инфраструктуры VMware Horizon:

Удаленное подключение к ПК через VMware Horizon Direct Connection


В последние годы Linux приобретает всё большую популярность, как и потребность в удаленном подключении к нему.

В свою очередь, и компания VMware наращивает функциональность агента и клиента Horizon под операционные системы семейства Linux.

12 января 2023 года вышел релиз VMware Horizon 2212 (8.8). В этом релизе в агент для Linux добавили поддержку Debian 11.5, в котором мы и проведём наш эксперимент.

Для установки нам потребуется следующая документация:

и два дистрибутива агента и плагина:

  1. VMware-horizonagent-linux-x86_64-2212-8.8.0-21071111.tar.gz
  2. VMware-horizonagent-linux-vadc-x86_64-2212-8.8.0-21071111.tar.gz

В соответствии с системными требования проверяем версию Linux:

  • Ubuntu 18.04, 20.04, and 22.04
  • Debian 10.13 and 11.5
  • Red Hat Enterprise Linux (RHEL) Workstation 7.9, 8.4, 8.6, 8.7, 9.0, and 9.1
  • Red Hat Enterprise Linux (RHEL) Server 7.9, 8.4, 8.6, 8.7, 9.0, and 9.1
  • CentOS 7.9
  • SUSE Linux Enterprise Desktop (SLED) 15 SP3 and 15 SP4
  • SUSE Linux Enterprise Server (SLES) 15 SP3 and 15 SP4

и тип окружения рабочего стола: Читать далее «Удаленное подключение к Linux через VMware Horizon Direct Connection»

VMware ESXi Host Client 2 теперь и в vSphere 7

С выходом VMware ESXi 8 компания VMware представила новый веб-клиент для управления хостом: новые иконки; фреймворк Clarity; несколько тем, включая тёмную, и их кастомизация; навигация TAB-ом. Заметки о релизе для ESXi 8 — VMware Host Client 2.5.0 Release Notes.

Несколько обзоров:

К нашей радости, компания VMware решила не останавливаться на достигнутом и портировала клиента на ESXi 7 — теперь он стал доступен c версии ESXi 7 update 3i.

Релиз Код Безопасности vGate 4.6

Код безопасности выпустил свежую версию своего продукта для защиты виртуальных сред vGate 4.6. Ключевое отличие обновленной версии продукта – реализация защиты KVM-виртуализации.

В vGate 4.6 добавлена поддержка следующих операционных системам семейства Linux:

  • Ubuntu 18.04.6 LTS, 20.04.3 LTS;
  • Astra Linux Common Edition «Орел» 2.12.22;
  • Альт Сервер Виртуализации 10;
  • Альт Сервер 8 СП;
  • Скала-Р Управление 1.80; 1.92; 1.93.

Полный список новых функций:

  1. Выполнен перенос функции управления фильтрацией трафика vCenter из консоли управления vGate в веб-консоль.
  2. Выполнен перенос функций управления виртуальными сетями, виртуальными машинами, сетевыми адаптерами, хранилищами данных и организациями сервера Cloud Director из консоли управления vGate в веб-консоль.
  3. Выполнен перенос функции объединения объектов виртуальной инфраструктуры в группы из консоли управления vGate в веб-консоль.
  4. Реализована поддержка политик шаблона «CIS for ESXi 7.0».
  5. Реализовано ограничение числа одновременных сеансов АВИ.
  6. Добавлены новые виджеты мониторинга: «Тепловая карта событий аудита», «Объекты и учетные записи по категориям конфиденциальности», «Объекты и учетные записи по уровням конфиденциальности».
  7. Реализована поддержка токенов Рутокен при аутентификации пользователей через вебинтерфейс vGate.
  8. Реализована возможность добавления пользовательских уровней конфиденциальности.
  9. Реализована поддержка контейнеров VMware, включая контроль целостности образов контейнеров, хранящихся во встроенном реестре Harbor, и контроль доступа к vSphere Pods.
  10. Реализована возможность создания разрешающих правил фильтрации, по которым осуществляется однонаправленная передача трафика.
  11. Реализована поддержка KVM-серверов и защита виртуальных машин KVM.
  12.  Добавлена возможность использования символов кириллицы в именах пользователей и групп Active Directory.

Подробная документация:
Читать далее «Релиз Код Безопасности vGate 4.6»

Сохранение активации лицензий ПО при замене оборудования в VMware vSphere 6.7+

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

Время от времени серверы устаревают, а на замену им приходит новое оборудование с новыми процессорами.

Для абстрагирования vCPU от физического процессора от оборудования в VMware vSphere много лет развивается технология маскирования флагов процессора:

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

  1. BIOS/UEFI;
  2. операционной системе;
  3. имени сервера/ПК;
  4. идентификаторам либо серийным номерам жестких дисков;
  5. MAC-адресам сетевых карт;
  6. CPUID, описывающему имя, семейство и модель процессора, доступные SIMD-инструкции.

В соответствии с этим мы можем использовать фиксацию части параметров.

Для фиксации UUID BIOS можно отредактировать VMX-файл:

Также возможны и более хардкорные модификации BIOS/UEFI. Получить данные можно получить через команду wmic bios.

Для привязки по MAC-адресу мы фиксируем адрес с физического сервера лицензий, либо генерируем его сами до получения лицензий. Адрес можно указать в настройках сетевого адаптера либо прописать в VMX-файле:

Parameter Value
ethernetX.addressType static
ethernetX.address MAC_address_of_the_virtual_NIC

В большинстве случаев получается привязать MAC к выключенному адаптеру либо подключенному в пустую виртуальную сеть.

Для сохранения CPUID необходимо собрать следующую информацию:

  • EVC/поколение ЦПУ виртуальной машины в vSphere.
  • Поколение(CPU-Z), название, id и модель процессора в операционной системе (wmic cpu get caption, name, processorid; в Linux /proc/cpuinfo).

После этого в конфигурации выключенной виртуальной машины (vHW>=14) устанавливается нужный уровень Per-VM EVC, при необходимости прописываются в VMX-файл прочие параметры маскинга CPUID (*в примере левые параметры):

Примечание.  При изменении vHW и/или обновлении ESXi версии BIOS/UEFI могут меняться. Изменение BIOS/UEFI, CPUID происходит по время выключения/включения (powercycle) виртуальной машины.

Всегда делайте копию виртуальной машины и VMX-файла перед правками!!!

Митап «VDI на отечественном»

Организация удаленных рабочих мест сотрудников уже давно стала для компаний стандартом работы персонала. С западными VDI-решениями все понятно и отработано. А как с этим дела у отечественных решений? Как обстоят дела с функциональностью, надежностью, масштабируемостью, безопасностью у российских VDI-решений?
Эксперты «Инфосистем Джет», которые уже успели поработать с основными отечественными решениями по клиентской виртуализации, поделились впечатлениями и дали оценку готовности этих решений заменить западные аналоги.

Отключение Hyper-V с помощью BCDEDIT

Решил на домашнем компе поэкспериментировать с виртуальной машиной. Для этого включил компонент Hyper-V, компьютер ушёл в перезагрузку и больше не захотел загружаться.

После 2-3 сбросов я смог попасть в безопасный режим и удалить компонент в оснастке, но при следующей же перезагрузке Windows сказала, что доудалять не может и восстановила Hyper-V  — и система ушла в цикл.

На просторах Интернета нашёл команду, запрещающую старт Hyper-V (запустить в командной строке от имени администратора):

обратная (если понадобится):