Комментарии 34
Скоро 2025 год, а в Hyper-V до сих пор нельзя пробросить USB
Возможно не добавляют прямой функционал из коробки ввиду соображений безопасности )
И до сих пор не придумали механизма телепортации USB-ключей между узлами в кластере.
Если нужно пробросить USB-ключ и чтобы были доступны в виртуальной среде, то можно использовать SEH UTN Manager. Ключ устанавливаются в "dongle server" для эмуляции.
Главное, наличие сетевой связности с dongle сервером.
Мы довольно успешно используем SEH UTN у себя в инфраструктуре для работы с HASP ключами, прикидывая их в виртуальные машины клиентов .
Либо AnywhereUSB. Правда некоторые модели/ревизии/экземпляры не перестают удивлять отвалами или какими-нибудь косяками.
Кстати, уже российские решения появились, отзывы положительные, но мы пока не добрались до их тестов )
Мне не актуально. (геолокация) Понятно, что решение USB-over-IP не самое трудное в реализации :)
Там и с виртуализацией вроде что-то у вас появляется, но я каждый раз смотрю на это всё с выражением лица coolStoryBob и огромным скепсисом с соболезнованием тому, кто это "на коленке побыстрому" будет админить очередной кривой продукт (ибо на него зафорсят пересадку). MS и остальные компании с огромным штатом не могут допилить продукты..
И как это относится к "Hyper-V не умеет пробрасывать USB-ключ"?
Проще перечислить, что нормально работает в Хайперви, чем то, что не не работает. Ибо последний список я могу продолжать бесконечно..
Если не трудно, можно развернутый комментарий или в лс пожалуйста
Косяки:
При создании виртуалки через WSFC или Hyper-V Manager может отвалится создание диска и висеть 10-15 минут до таймаута. Независимо - ВМка создается на текущей ноде или соседней. Порой требуется удалять ВМку, остатки файлов и папок, которые создались. Создавать ее заново. Местами и по 3-4-5 раз.
Операции с диском через WSFC или Hyper-V Manager могут вывалиться в ошибку. Будь то инспект или изменение диска. При этом сама операция как бы проходит. Но ответ от management-а где-то теряется
Gracefull shutdown может выпасть в длинный (10-20-30 минут) таймаут и не давать сделать Turn off ВМке (очень редко видел такое и на Вмваре, но ООООООЧЕНЬ редко. На Hyper-V практически постоянно, если ВМка у клиента поймала "висяк" и отвечает, но не до конца)
В WS2019 не работает VM Affinity. Anti-Affinity. (Как в вмваре рулы Should/not, Must/Not). Ситуация, когда ДЦ или SQL кластер оказались на одной ноде - легкоооо, когда у тебя 500 виртуалок. Сидеть после каждого мейнтененса и смотреть где-что-куда упало - ад. В 2022 изменили cmdlet-ы и с новыми работает, но у меня не 2022 кластер.
CSV может упасть фиг пойми по какой причине в I/O таймаут кратковременно. Дальше возможны развития ситуации:
Кластер быстро восстановил коннект к CSV. Ничего не упало.
Кластер долго думал. ВМки поднялись на других нодах
Кластер долго думал. Половина ВМок поднялась на других нодах. Половина упала в Saved Critical. Еще часть просто продолжила работать с тем, что имеет в RAM. Часто отваливается часть сервисов. Может не работать логин-скрин в консоли или рдп. Но МОЖЕТ И РАБОТАТЬ.
Если выключить ВМку в состоянии последней, то потеряются данные с отвала CSV до момента выключения. Тестили созданием файла.
Обход: лайв миграция перед отключением. Тогда VM world видимо пересоздается и данные записываются
Весело, когда такая ВМка была замечена через неделю работы. Некоторые клиенты так потеряли данные 2-3 недель
Учитывая кол-во падений кластера по разным причинам: шанс поднятия нормального равен примерно 1 к 10. В остальных случаев привет 6-8 часов работы.
Кластер вообще через жопу отрабатывает сценарий блекаута нетворка. Шанс того, что всё поднимется само, даже если отвалилось на 5 минут - минимален.
Пример тест-кейса #1
3 гипервизора в кластере
iSCSI таргет
отдельный ДЦ для кластера
Роняем нетворк до iSCSI таргета (или паузим вмку iSCSI таргета). Допустим ваш сетевик решил, что клево одновременно ребутнуть 2 свитча, т.к. фирмвара не встала, на который iSCSI. Да-да, я такое видел своими глазами.
Ждём 5-10 минут. Поднимаем нетворк обратно.
Наблюдаем свистопляску во даунтайма и после:
ВМки начинают прыгать, кто куда хотят: Часть переезжает, часть остается в saved critical (i/o), часть нормально перезапускаются.
В итоге потом сидеть каждую руками проверять фактически, что точно загрузилась, точно не в R/O (для никсов актуально), точно не в рекавери
Даже если руками указать Critical Action = Turn Off (Forced). В половине случаев оно игнорится. Часть ВМок сделают Turn Off, часть нет. Клево же.
Пример тест-кейса #2 (Вмвара)
3 ESXi
iSCSI таргет
Делаем тоже самое. Или нетворк роняем (симулируем блекаут)
Выжидаем 5-10-15-20 минут. Поднимаем обратно.
Всё перезапустится само или продолжит работу. В случае с никсовыми ВМками - лучше перезапустить кнчн при долгом даунтайме, т.к. скорей всего уйдут в R/O при развале VM World-а
Я провел множество таких тестов. Нода, Несколько нод, Нетворк до iSCSI, Сам iSCSI таргет и т.п. и т.д. Все что касается сторадж трафика - Hyper-V сосет жопу с причмоком. Шанс того, что ОНО ПОДНИМЕТСЯ само - настолько мизерный. Максимум, что оно выдерживает - отвал 1-2 нод. Да и то, т.к. CSV имеет ownership определенный ноды - есть шанс, что огромная часть ВМок перезапустится в другом месте.
Live Migration может просто не сработать. У конкретных ВМок на конкретную ноду. Quick Migration - тоже. Выход только 1. Вырубить ВМку и врубить заново.
Никогда не видел подобных косяков у ВМвары. Максимум - превышало интервал i/o pause (вроде 8 секунд) и тогда кидало таймаут. Но после пары попыток переезжало.Менеджмент консоли (mmc) - любят крешится после долгой работы
Открытая консоль виртуалки - течет. Видел, когда окно консоли сжирало по 10-20-30 ГБ РАМ после недели другой
Время на реинсталл ноды и конфигурацию - космос. Даже с хорошим чеклистом - это ОЧЕНЬ ОЧЕНЬ, мать его, долго: дрова, айскази, бест пратис айскази, настройки на сторадже, домен, кластер, switch embedded team и прочее-прочее. Минимум 2 дня.
Нет встроенного нормального мониторинга. То, что есть - можно утереться. Мониторить CPUReady%, Co-Stop% и другие - привет поиск нужных сенсоров в perfmon-е. А потом поиск того, сколько должно быть.
Половина powershell cmdlet-ов просто не описана. Вышел новый функционал? Как он работает? Да кто его знает. Описаний просто 0! Например та же фича, что не позволяет ВМке выжирать ресурсы. Какой-то там Guard, лень искать. Нашел: EnableHostResourceProtection $true.
Найти описание, что он делает - просто невозможно. У меня мануал на кондей подробнее, чем hyper-v мануалы, где четко описано, если дельта выше N градусов, будет одно, если ниже - другое.Ах да, главное. Интеграции с другим софтом. Например после бэкапа Veeam-ом просаживается у рандомных ВМок IOPS-ы в район дна и поднимается latency VHDшки. Порой до 100-200-500+ мс. Решение? Костыль: лайв миграция после каждого бэкапа :DD
Спустя 16 или 19 страниц и 4-5 лет Вим и Мелкософт наконец перестали переводить стрелки и родили патчи.Кластер Лог - дно дна. После отвала CSV или ноды - найти причину практически невозможно. Get-ClusterLog генерирует такую портянку, что поставить диагноз невозможно.
Это из того, что вспомнил сейчас.
З.Ы. Тот, кто выбирает Hyper-V для себя в проде - извращенец и любитель бубна. Если бы не ситуация с Броадкомом или не принуждение к лицухе (ибо не только своя инфра, а еще и клиентская) - свалил бы в ESXi с vCentr-ом даже с таблеткой от жадности и не имел бы проблем. Но учитывая ситуацию, это нужно было делать лет 5 назад. А сейчас остается только смотреть, куда повернет рынок. Ибо альтернатив адекватных нету. (Про Проксмокс - даже не смешно, щупал)
Про Проксмокс - даже не смешно, щупал
Давайте такую же. Интересно пишете.
@falcon4fun плюсую, про proxmox было бы интересно.
В Hyper-V то, что вы описали - всё есть, в инфре на пару десятков хостов, преимущественно без кластера.
В кластере отказ сети до хранилища - вызывает точно такие же симптомы, в лабе ребутал серваки через ipmi (2 из 3 в кластере), по rdp/консоль не заходили или там безнадежно все зависло.
По поводу дисков/создания вм есть "workaround": powershell cmdlet'ы ни разу не зависали: ~500 проходов создать вм, подключить диски, включать отключать, изменять диски, изменять сетевые адаптеры, удалять вм.
По документации также подтверждаю - часть структур просто нигде не описано, типа что возвращает Get-VMNetworkAdapterVlan - да хрен знает, Microsoft.HyperV.PowerShell.VMNetworkAdapterVlanSetting - а что это и какие поля внутри - сходи на хост и проверь сам, чел :D возможно оно где-то и описано, но я не нашел
Кстати про справку к PowerShell командлетам.
Вы Update-Help делали на узлах виртализации?
Ну крч :D "Здравствуйте, я Анатолий и я пользуюсь Hyper-V в продакшене" - "Привет, Анатооооолий" - хлопки :D Клуб анонимный Hyper-V-голиков
Ну хоть убедился, что у меня не настолько кривые руки, раз вижу, что и у остальных похожее дерьмо случается :)
Пробовали XCP-ng?
Пока нет. Если пробовали, в двух словах опишите, что хорошего есть? Кластер нормальный есть с лайв миграцией?
Проблема любого гипервизора: чем бэкапить это все и быстро. И чтобы работало. На данный момент это Вим. В прошлой версии лишь пару месяцев назад они прикрутили поддержку Проксмокса. На днях видел что-то на тему интеграции с XCP. Но не уверен, что правильно понял.
CSV может упасть фиг пойми по какой причине в I/O таймаут кратковременно.
Угу. И этим ещё и может поломать ФС для виртуалки, которая в этот момент не сохранилась, а просто упала. Могу подтвердить ещё половину из прочих косяков, которые встречал лично. И тоже версия 2019. Пара из проблем (зависающая на выключении виртуалка, например) - была ещё на 2012r2.
Ну, хоть я не одинок. Но у меня еще беда под названием Broadcom. А именно BCM57810. Которые походу дополнительно флапают.
Кто-то очень умный закрутил еще все на драйверный iSCSI с NPR (Dell Network Partition-инг), когда физический порт представляется логическим портом. В итоге из 1 физ порта можно сделать от 4 до 8 портов.
Вот только нюансы: BCM представляет сетевуху как 2 устройства всегда. Даже в Single Function режиме: это системное устройство + сетевое устроство. В 2 раза больше шансов сглючить драйверу на каждом порту. Дальше: такой конфиг не поддерживается ничем официально. MS требует только выделенный iSCSI. Делл пишет "мы тоже не суппортим такое, но оно у нас есть": https://www.dell.com/support/kbdoc/en-lt/000179202/what-is-a-common-network-partition-and-teaming-mode-mistake-that-may-result-in-unexpected-network-issues
Плюс все же живут жизнью "работает - не трогай". В итоге гипервизоры никто почти никогда не обновлял. Фирмвары никто никогда не обновлял с запуска кластера. Вот только свежий патчноут схожего адаптера:
Драйвера никто никогда не обновлял. "Работает же". Такого количества отвалов за два года жизни я еще не видел
Хайпер-Ви - это когда 1 глючащая ВМка может убить кластер, потому что ВМка упала, за ней отвалился RHS (Resource Hosting Subsystem) и забрал с собой еще штук 30-50-70 ВМок на том же RHS-е. Пока перезапускался RHS, ресурсы переехали на другие ноды :D Видел и такое пару раз
Ребут без дрейна ноды ручками - где это видано. Часть ресурсов же спокойно может не переехать при "Pause and Drain roles"..
Короче, лучи поноса разработчикам. Не перестану повторять: "За софт, который бесплатен или дешев заплатится из ЗП админа/архитектора, который будет сношаться с кривым говном днями и ночами, кататься туды-сюды в ДЦ и обратно на выходных и т.п.".
Сейчас пытаюсь съехать на старое и простое: по паре X520-DA2 (x710 какие-то неадекватно дорогие, да и прошивки их оставляют желать лучшего) в Dell R640, разделив трафик заодно на iSCSI + все остальное в SET (Switch Embedded Team): а это heartbeat (включая CSV redirection) + mgmt (AD и менеджмент) + live migration. Ну и допольнительно физический домен контроллер. Возможно, станет лучше. Но не уверен, т.к. тесты на идеальной инфре (тестовой в виртуальной среде, примеры тест кейсов выше) показали, что все равно через пень колоду работает всё.
Забыли про EnableSoftwareRsc, который должен снижать утилизацию ЦП на 100-гигабитных интерфейсах, но вместо этого замедляет сеть у 95% ВМ.
Я, к сожалению, пока не застал что-то больше 10-ки на линк. Свитчей под 25/40 даже нема :D Да и для трафика именно вланов виртуалок реально редко нужна большая шина (мне лично). Пары 10-ок зачастую за глаза :) Но видел не первое и не последнее сообщение на тему группирования пакетов, что работает рандомно в большинстве случаев. И еще сильно зависит от качества сетевухи. x710-ые тому сильный пример (в плохом виде)
Еще RSS и VMQ отдельная тема.
А через DDA пробросить адаптер религия не позволяет? В отличие от сферы, такой проброс позволяет делать бэкапы на лету и без агента.
Тот случай когда каменты кратно интереснее статьи
proxmox, zfs, ceph, pfsense etc- https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D1%87%D0%B0%D1%81%D1%82%D1%8C-2/
В отличие от предыдущих версий, где компонент OpenSSH нужно было устанавливать вручную, в Windows Server 2025 его серверная часть стоит по умолчанию
Вот за этим тоже в комменты зашёл, никто не рассказал, что SSH server готов наполовину. Например, при попытке запуска .ps1 через него он вместо вывода скрипта в shell клиента пишет "access denied, this is a bug, contact Microsoft support" и всё такое, но это именно про текст, сам скрипт отрабатывает. Если скрипт интерактивный, то вводить в него что-то приходится вслепую, но это хотя бы так работает. Поэтому bootstrap с Linux выглядит как подсчёт "сколько раз он уже плюнул ошибкой, ага, вот сейчас можно вводить токен Gitlab". Но зато таким образом получилось убрать скачку скриптов из Gitlab через IE11 либо ручной ввод токена без буфера обмена. Благо, в '25, вон, вижу, Edge появился, был бы он в 2019 - не пришлось бы делать такие костыли.
С Ansible там свои заморочки именно на Windows и в изолированной сети, долго рассказывать. Поэтому всё на .ps1.
Горячие патчи, DTrace по умолчанию и +70% к производительности NVMe: что еще мы знаем о Windows Server 2025