Советы – vMind.ru

Подкаст “Серверная виртуализация” от Jet’ов

Гости подкаста «Техничка»:

Андрей Коновалов, независимый эксперт по виртуализации,
Илья Калашников, главный архитектор «РСХБ-Интех».

Серверная виртуализация: что ждет VMware, есть ли подходящая замена на мировом и российском рынке, а также стоит ли использовать open source решения.

Ведущий — Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет».

Veeam Best Practices Analyzer aka Security & Compliance

С двенадцатой версии Veeam Backup&Replication появился анализатор лучших практик, переименованный в Security & Compliance Analyzer в версии 12.1

Данный инструмент сравнивает текущие настройки операционной системы и системы резервного копирования и восстановления данных с рекомендованными.
Типичная картина до закручивания настроек безопасности может выглядеть так: Continue reading “Veeam Best Practices Analyzer aka Security & Compliance”

Обновления Veeam ONE Intelligent Diagnostics

Veeam Intelligent Diagnostics (VID) – это функция Veeam ONE, которая автоматически обнаруживает известные проблемы в конфигурации и производительности инфраструктуры резервного копирования:

The Power of Veeam Intelligent Diagnostics

Многие пользователи, использующие Veeam ONE, не догадываются, что в этом продукте есть обновляемые сигнатуры для диагностики.

Список изменений в сигнатурах можно прочитать на форуме:

Установка производится через Интернет либо вручную через скачанный файл с этого ресурса.

Чтобы обновить нужно открыть Veeam ONE Client -> выбрать панель Veeam Backup & Replication -> Veeam ONE Agents -> Update Signatures (с Интернета) либо Import Signatures (из файла).

После этого могут появится новые уведомления.

Борьба с VMware vSphere ESX Agent Manager

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

Перестал работать DRS по причине невозможности создать виртуальные машины vCLS.
Перестало работать обновление хостов с ошибкой “Failed to login to vCenter as extension, Cannot complete login due to an incorrect user name or password”.

Изучение БЗ VMware навело на две заметки:

Что-то подсказывало, что корень у причины один!

Подали советуемые команды, которые починили сертификат расширения:

 mkdir /certificate
 /usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.crt
 /usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.key
 python /usr/lib/vmware-vpx/scripts/updateExtensionCertInVC.py -e com.vmware.vim.eam -c /certificate/vpxd-extension.crt -k /certificate/vpxd-extension.key -s vcenter-name.loc -u Administrator@vsphere.local
 service-control --stop vmware-eam
 service-control --start vmware-eam

mkdir /certificate

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.crt

/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.key

python /usr/lib/vmware-vpx/scripts/updateExtensionCertInVC.py -e com.vmware.vim.eam -c /certificate/vpxd-extension.crt -k /certificate/vpxd-extension.key -s vcenter-name.loc -u Administrator@vsphere.local

service-control --stop vmware-eam

service-control --start vmware-eam

Отвал FC HBA Emulex 8/16-Gb/s после обновления VMware ESXi 7.0 update 3

После обновления до актуальной буквы VMware ESXi 7.0 update 3 у нас неожиданно отвались 8-гигабитные FC HBA на базе Emulex LPe12000.

При разборе полётов было выяснено, что в Emulex Drivers for ESXi 7.0 с релиза 14.0.326.12 прекращена поддержка адаптеров LPe12000-series, LPe15000-series и LPe16000-series.

Соответственно, последними версиями с поддержкой данных адаптеров являются lpfc 14.0.169.25-5vmw и lpfc 12.8.614.16.

После понижения драйверов адаптеры появились.

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

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

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

2009-й год, я работаю обычным системным администратором на заводе. Windows, Exchange и немножко ДрВеба с Симантеком :).
Тут мне предлагают стать ответственным за администрирование коммутаторов, маршрутизаторов и брандмауэров Cisco. В качестве бонуса еще и немного учат!
Я, конечно же, соглашаюсь. Коллега из соседнего отдела сомневается и отказывается – зачем ему дополнительный головняк?
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:

snmpconfig --show snmpv3

1	snmpconfig --show snmpv3

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

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

aaaconfig --show
aaaconfig --add radius_ip_address -conf radius -p 1645 -t 15 -s secret1234 -a pap -e none
aaaconfig --authspec "radius;local"

aaaconfig --show

aaaconfig --add radius_ip_address -conf radius -p 1645 -t 15 -s secret1234 -a pap -e none

aaaconfig --authspec "radius;local"

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

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

certificates do not conform to algorithm constraints

1	certificates do not conform to algorithm constraints

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

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

seccertmgmt show -cert https

1	seccertmgmt show -cert https

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

Crypto Algorithm
у первого коммутатора
    Signature Algorithm      sha1WithRSAEncryption
у второго
    Signature Algorithm      sha256WithRSAEncryption

Crypto Algorithm

у первого коммутатора

Signature Algorithm sha1WithRSAEncryption

у второго

Signature Algorithm sha256WithRSAEncryption

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

seccertmgmt generate -cert https -type rsa -keysize 2048 -hash sha1 -years 10

1	seccertmgmt generate -cert https -type rsa -keysize 2048 -hash sha1 -years 10

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

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

seccertmgmt generate -cert https -type rsa -keysize 2048 -hash sha256 -years 10

1	seccertmgmt generate -cert https -type rsa -keysize 2048 -hash sha256 -years 10

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

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

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

Copying data from deduplicated volumes requires that the console is installed on Windows Server 2012 R2 or later with the data duplication feature enabled.
Restoring files from  deduplicated volumes requires that the mount server associated with the source backup repository uses Windows Server 2012 R2 or later with data deduplication feature enabled.

Copying data from deduplicated volumes requires that the console is installed on Windows Server 2012 R2 or later with the data duplication feature enabled.

Restoring files from deduplicated volumes requires that the mount server associated with the source backup repository uses Windows Server 2012 R2 or later with data deduplication feature enabled.

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

Import-Module ServerManager
Add-WindowsFeature -name FS-Data-Deduplication

1 2	Import-Module ServerManager Add-WindowsFeature -name FS-Data-Deduplication

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

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

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

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

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

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

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

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

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

uuid.bios = <uuidvalue>

1	uuid.bios = <uuidvalue>

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

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

Parameter	Value
ethernet`X`.addressType	`static`
ethernet`X`.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 (*в примере левые параметры):

featMask.vm.cpuid.Intel = “Val:1”
featMask.vm.cpuid.FAMILY = “Val:6”
featMask.vm.cpuid.MODEL = “Val:0x4f”
featMask.vm.cpuid.STEPPING = “Val:0”
featMask.vm.cpuid.NUMLEVELS = “Val:0xd”
cpuid.brandstring = "Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz"

featMask.vm.cpuid.Intel = “Val:1”

featMask.vm.cpuid.FAMILY = “Val:6”

featMask.vm.cpuid.MODEL = “Val:0x4f”

featMask.vm.cpuid.STEPPING = “Val:0”

featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

cpuid.brandstring = "Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz"

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

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

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

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

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

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

bcdedit /set hypervisorlaunchtype off

1	bcdedit /set hypervisorlaunchtype off

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

bcdedit /set hypervisorlaunchtype auto

1	bcdedit /set hypervisorlaunchtype auto