Начиная с Windows Server 2012 в Hyper-V появилась возможность подключать к виртуальной машине виртуальный Fibre Channel Adapter (vFC или vHBA). Эта функция позволяет гостевой системе напрямую работать с физическими SAN-ресурсами через протокол Fibre Channel, используя механизмы N_Port ID Virtualization (NPIV). ВМ получает свой собственный виртуальный HBA, со своим уникальным World Wide Name, и может обращаться к LUN-ам на хранилище так, как если бы она была "настоящим" сервером с физическим FC HBA. Это открывает ряд интересных возможностей: подключение кластеров Windows Server Failover Clustering или SQL Server AlwaysOn напрямую к SAN, использование снапшотов и резервного копирования на уровне СХД, а также гибкое администрирование через знакомые SAN-инструменты. На фоне конкурентов это долгое время было преимуществом Hyper-V, поскольку VMware и другие гипервизоры предлагали аналогичные возможности либо в более дорогих редакциях, либо с ограничениями, тогда как в экосистеме Microsoft vFC сразу интегрировался в стандартные сценарии высокой доступности и корпоративного хранения.
Добавление компонент интеграции Hyper-V в виртуальную машину с гостевой ОС Debian GNU/Linux 12 'Bookworm', как и в более ранних версиях, предполагает установку пакета hyperv-daemons из официальных репозиториев Debian. В результате установки пакета в системе появляется ряд служб, в числе которых есть служба hv-kvp-daemon.service : Hyper-V key-value pair (KVP) daemon. После запуска этой службы, с интервалом, примерно, в 5 минут в системном логе регистрируется две ошибки о недоступности утилит hv_get_dns_info и hv_get_dhcp_info.
Возникла задача трансляции лицензионного USB-ключа Guardant, подключенного к USB концентратору Digi AnywhereUSB 24 Plus, в виртуальный сервер на базе Debian GNU/Linux 11. В силу особенностей реализации утилиты "AnywhereUSB Manager" для Linux и нашего понимания того, что полновесная графическая среда на Linux-сервере - это излишество, выполнение этой задачи оказалось немного более сложным, чем просто "потыкать мышкой".
После ряда удачных и не очень удачных экспериментов с развёртыванием ПО на хостах виртуализации тестового кластера Hyper-V на базе ОС Windows Server 2016 столкнулись с проблемой потери управления компонентами виртуализации. В частности, при попытке получить информацию о виртуальных машинах (
Импорт виртуальных машин Hyper-V можно выполнять разными способами – как через графические инструменты типа Hyper-V Manager, так и с помощью PowerShell. Мастер импорта в оснастке Hyper-V Manager, взаимодействуя с администратором в интерактивном диалоге, позволяет разрешить ряд проблем, которые могут возникнуть в ходе импорта. Если же для импорта используется PowerShell, то здесь нюансы несовместимости исходной и целевой сред виртуализации могут выливаться в ошибки, останавливающие процедуру импорта. Так при попытке импорта виртуальной машины, подготовленной сторонней организацией мы можем столкнуться с ситуацией, когда PowerShell командлет 
При работе с Linux системами иногда возникают проблемы, разобраться с которыми можно только при прямом подключении к консоли Linux и привычные удобные инструменты удалённого доступа, типа любимого SSH-клиента, в такие моменты могут быть недоступны. В среде виртуализации можно столкнуться с ситуацией, когда Linux система загружается с низким разрешением экрана и это делает крайне неудобной работу с данными, выводимыми на консоль.
При администрировании Hyper-V иногда возникают нетипичные задачи, например, возникает необходимость получить возможность работать с COM-портами в виртуальных машинах Hyper-V Gen2. Хотя многие администраторы, работающие с такими графическими инструментами управления как Hyper-V Manager, Failover Cluster Manager, Virtual Machine Manager знают, что настройки COM-портов есть только свойствах виртуальных машин первого поколения.
В одной из прошлых заметок 
В 
Когда-то мы уже рассматривали 
После применения PSO команда "net user [логин] /domain" отражает неверное время жизни пароля учетных записей с гранулярным паролем, я не…
RSS - Записи
Последние комментарии