Hyper-V Security или безопасность Hyper-V Часть 2 | Denis Abramenko: Blog

Введение

Ранее я рассказывал об установке и настройке Hyper-V Server 2022 R2, предыдущей версии бесплатного гипервизора. К сожалению, те методы настройки hyper-v в рабочей группе без домена неактуальны в версии 2022. В частности, утилита hvremote не работает на новой версии.

Но в общем и целом мне нравится гипервизор hyper-v, поэтому я решил внимательно проработать вопрос установки и первоначальной настройки для дальнейшего использования по мере необходимости. К плюсам hyper-v в целом и бесплатной версии в частности я отношу следующие моменты:

  1. Поддержка всех популярных ОС. Нет никаких проблем с совместимостью, нет необходимости отдельно ставить какие-то драйвера или тулсы. Поддержка hyper-v присутствует во всех windows системах, в ядре линукс, не помню точно с какой версии, но все современные системы ее имеют, в ядре freebsd, начиная с 10-й версии. То есть вы просто берете установочный диск и ставите систему на hyper-v, больше от вас ничего не требуется.
  2. Много различных способов бэкапа виртуальных машин. Это могут быть простые скрипты, бесплатные программы, либо полноценные платные версии крупных компаний, специализирующихся на программном обеспечении для бэкапа.
  3. Стандартная панель управления гипервизором, которую легко установить на компьютер под управлением windows, начиная с win 8.1.
  4. В основе Hyper-V Server популярная серверная система, с которой понятно и удобно работать. К примеру, чтобы загрузить или забрать файл с гипервизора, вам достаточно расшарить на нем папку стандартным образом, как вы это делаете в любой windows системе.

Это мое личное мнение, основанное на опыте работы с малыми и средними компаниями, где нет каких-то особенных требований к надежности и доступности сервисов. Где используются несколько серверов с виртуальными машинами, не всегда есть домен windows. Конечно, помимо плюсов, есть и минусы.

Похожее:  ТВ приставка Ростелеком: неверный логин, что делать, как исправить

Первый и главный для меня минус – первоначальная настройка. Нельзя просто взять, установить Hyper-V Server и начать им пользоваться. Необходимо производить какие-то непонятные и не очевидные действия на хосте и управляемой машине. Дальше вы поймете, что я имею ввиду.

Hyper-v security или безопасность hyper-v часть 2

В первой части данной статьи  (Hyper-V Security или безопасность Hyper-V Часть 1) мы рассмотрели следующие темы:

  • Обзор систем виртуализации Microsoft;
  • Архитектура Hyper-V;
  • Безопасность управляющей ОС.

    Теперь рассмотрим следующую тему (рекомендацию) это делегирование управления виртуальными машинами.

    Разграничивайте права доступа в среде Hyper-V.

    Когда на одном или нескольких серверах Hyper-V развертываются несколько десятков виртуальных машин, появляется необходимость правильно разграничить права доступа между пользователями. Настроить необходимые разрешения на создание, управление, удаление и конфигурацию виртуальных машин.

    Рекомендуется использовать управление доступом на основе ролей, которое дает возможность задавать управление доступом в терминах организационной структуры компании, то есть путем создания нового объекта, называемого ролью. Пользователям назначаются роли для выполнения своих должностных обязанностей. Hyper-V использует политики диспетчера авторизации для управления доступом на основе ролей.

    Для стандартной небольшой инфраструктуры рекомендуется разделять полномочия администраторов по следующему типу:

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

    Администраторы виртуальных машин – это административные учетные записи, обладающие административным доступ к виртуальным машинам, для которых сопоставлены те или иные виртуальные машины, и области. Архитектура Hyper-v позволяет создать схему, при которой администраторы виртуальных машин не могут управлять операционной системой управления.

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

    Следует помнить что: по умолчанию администраторы виртуальных машин не могут выполнять локальный вход на хост Hyper-V и изменять какие-либо настройки ОС.

    Для большинства ситуаций такая конфигурация является приемлемой, однако может возникнуть ситуация, когда Вам потребуется более тонко разграничить права доступа к управлению виртуальными машинами. Для этого рассмотрим инструменты делегирования виртуальных машин. Интерфейс консоли управления Hyper-V позволяет полностью управлять виртуальными машинами на хосте Hyper-V. По умолчанию все учетные записи включенные в группу локальных администраторов могут управлять виртуальными машинами на этом узле. Консоль управления Hyper-V обеспечивает минимальный функционал для работы с виртуальными машинами, и не позволяет в полной мере разграничивать права доступа, это может вызвать определенные трудности при администрировании.

    Для этого существует ряд инструментов позволяющих в полной мере разграничивать права доступа между пользователями и администраторами.  Одними из таких инструментов является Authorization Manager и System Center Virtual Machine Manager:

    Использование Authorization Manager для делегирования управления VM

    Hyper-V Security или безопасность Hyper-V Часть 2 | Denis Abramenko: Blog

    Рисунок 10 Делегирование управления VM

    Для разграничения прав на операции с виртуальными машинами можно использовать приложение Authorization Manager, которое входит в состав ОС Windows 2008 Server.

    Authorization Manager — это инструмент, который позволяет разграничивать права доступа на основе ролей, основанных на предоставлении необходимого функционала для каждой роли. Authorization Manager позволяет разместить информацию в файле или Active Directory ,или в базе данных. Поддерживает как 64 битные, так и 32 битные системы. По умолчанию Authorization Manager хранит свои данные в текстовом файле в формате xml на локальном сервере.

    Рассмотрим, какие компоненты существуют в Authorization Manager:

    • Operation – Операция.
    Минимальное действие, которое можно совершить над объектом является операцией. Например: Создание, включение, остановка виртуально машины, изменение конфигурации.

    Task — Задача.
    Операции группируются в задачи. Таким образом, получается группа операций, которые можно делегировать пользователю. В Authorization Manager уже есть сформированные задачи практически на все действия с виртуальными машинами, дополнительно существует возможность формировать свои задачи, если это необходимо.

    Роль – Role.
    Определяет круг задач для учетной записи. Например, учетная запись может иметь право выполнять все операции и задачи связанные с конфигурацией виртуальной сети. При необходимости такую роль можно создать и делегировать пользователю.

    Область – Scope.
    Параметр, который позволяет Вам указать какими виртуальными машинами может управлять определенная роль пользователя. По умолчанию при создании виртуальных машин они помещаются в область по умолчанию Default Scope. Если вы хотите предоставить административный доступ к определенным виртуальным машинам, Вам потребуется создать область, в которую необходимо поместить эти виртуальные машины, после чего применить настройки к данной области. Это можно реализовать специальным скриптом. Пользователь, которому делегирована некая область управления, будет видеть только свои виртуальные машины, и не будет видеть и иметь доступ к другим виртуальным машинам.

    Если в вашей организации более трех узлов Hyper-V, рекомендуется опубликовать хранилище Authorization Manager в Active Directory.

    Использование System Center Virtual Machine Manager 2008 R2:

    Для крупной инфраструктуры, управление виртуальными машинами, делегирование прав на виртуальные машины и хост системы рекомендуется использовать System Center Virtual Machine Manager.

    Ключевое достоинство System Center Virtual Machine Manager – тесная интеграция с другими решениями Microsoft для управления инфраструктурой Windows-серверов семейства System Center. System Center Virtual Machine Manager позволяет создать гибкую виртуальную инфраструктуру на основе платформы Hyper-V и упростить развертывание виртуальных систем из центральной библиотеки шаблонов. Основные возможности System Center Virtual Machine Manager включают в себя:

    System Center Virtual Machine Manager позволяет использовать базу данных Operations Manager 2007, в которой собраны данные о производительности физических серверов, и определить наиболее подходящие для виртуализации серверы.

    System Center Virtual Machine Manager имеет встроенные средства миграции (ранее для этих целей использовался Virtual Server Migration Toolkit), использующие службы теневого копирования тома для преобразования физических серверов в виртуальных, без их остановки. Кроме того, System Center Virtual Machine Manager позволяет преобразовать виртуальные машины VMware в формат Hyper-V.

    System Center Virtual Machine Manager обладает возможностью  автоматически перемещать виртуальные серверы на физических компьютерах, используя данные об их рабочих нагрузках.

    System Center Virtual Machine Manager позволяет централизовать управление вашими ресурсами, управление гипервизорами Hyper-V, Virtual Server, VMware ESX и др. Позволяет увеличить доступность виртуальных машин, с точки зрения переноса виртуальных машин, в случае проблем с оборудованием, в случае большой нагрузки на оборудовании, путем перемещения виртуальной машины на другой узел. Позволяет управлять ресурсами хост сервера и ресурсами виртуальных машин.

    Одной из наиболее важных особенностей является возможность создавать группы физических серверов Hyper-V и делегировать управление ими.

    System Center Virtual Machine Manager позволяет создавать библиотеки которые могут быть использованы для хранения виртуальных машин, образов и шаблонов.

    System Center Virtual Machine Manager предоставляет портал самообслуживания, который представляет собой Web-приложение для самостоятельного развертывания виртуальных машин пользователями. Администратор определяет политики самообслуживания, которые включают в себя правила создания, развертывания и использования виртуальных систем. Взаимодействие портала с управляющим сервером производится по модели сервисно-ориентированных систем WCF (Windows Communication Foundation).

    System Center Virtual Machine Manager позволяет создать пользовательские роли, делегировать разрешения для групп хост серверов, виртуальных машин, и серверов библиотек.

    Серверы Hyper-V могут быть объединены в группы, которые могут быть организованы по некоторым логическим категориям (например, «Тестовые машины», «Веб-порталы» и т.п.). Довольно удобно организовать группы хостов в соответствии со структурой Active Directory. Естественно, System Center Virtual Machine Manager полностью поддерживает службу каталога Active Directory.

    Использование групп хостов позволяет упростить управление виртуальными серверами и облегчить их мониторинг. Кроме того, группы хостов используются для назначения им определенных политик и свойств. Компания Microsoft рекомендует привязывать каждую группу хостов к одной библиотеке шаблонов, которую используют серверы этой группы.

    Обеспечение безопасности виртуальных машин:

    Виртуальная машина, по сути, состоит из нескольких файлов, которые определяют конфигурацию и данные виртуальной машины .При работе виртуальных машин, в определенных ситуациях, используются файлы для сохранения данных памяти на диск и приложения, которые работают на виртуальной машине, и которые не сохраняют важные данные на жесткий диск (например пароли), но при этом эти данные содержаться в оперативной памяти. Таким образом, в момент выключения и сохранения состояния памяти виртуальной машины на диск хост сервера, создается реальная угроза безопасности. Таким образом, важным элементом безопасности является обеспечение безопасности файлов данных и файлов конфигурации виртуальной машины. Защитите системные файлы, используйте шифрование для хранилищ данных, включите аудит событий.

    Следует защитить виртуальные машины, выполняющиеся на сервере виртуализации, в соответствии с процедурами защиты этого вида сервера или нагрузки. Не существует никаких специальных или особых мер для защиты виртуальной машины только потому, что это виртуальная машина. Например, если для политик или процедур требуется выполнение антивирусной программы, просто запустите ее на виртуальной машине. Если имеется требование политики о назначении физического сервера определенному сегменту сети,  то виртуальным машинам размещенным на этом сервере  необходимо так же следовать этой политике.

    Обеспечение безопасности операционной системы виртуальной машины, по сути, ничем не отличаются от обеспечения безопасности операционной системы, размещенной на физических серверах. Все требования касательно ОС физических серверов применимы к ОС виртуальных машин.

    Виртуальные машины следует развертывать на серверах виртуализации, имеющих такие же требования безопасности. Например, предположим, что производится классификация уровня риска и усилий по защите серверов на три категории: «защищенный», «более защищенный» и «наиболее защищенный». Для наиболее защищенных серверов потребуется приложить больше усилий по обеспечению соответствия и необходимо больше процедур управления, чем для защищенных серверов. Это справедливо, независимо от того, является сервер физическим или выполняется в виртуальной машине. При развертывании  защищенных, и наиболее защищенных виртуальных машин в управляющей операционной системе, для сервера виртуализации необходимо установить уровень защиты как для «наиболее защищенного» сервера. Развертывание виртуальных машин с одинаковым уровнем безопасности на сервере виртуализации может облегчить управление и перемещение виртуальных машин.

    На каждой виртуальной машине рекомендуется использовать:

    Рекомендуется размещать серверы Hyper-V в соответствующих организационных единицах Active Directory и применять к ним групповые политики, которые настраивают базовые значения параметров безопасности.

    Защита файловой системы:

    Для защиты файловой системы необходимо использовать стандартные средства, access control lists (ACLs), для определения доступа к файлам виртуальных машин. Такой подход предотвратит ситуацию, когда злоумышленник попытается получить несанкционированный доступ к файлам виртуальной машины для того, чтобы скопировать файлы на съемный носитель или предотвратит попытку замены файлов виртуальной машины, сценариев довольно много :-).

    Тем не менее, использование access control lists (ACLs) не позволит Вам защитить саму виртуальную машину от несанкционированного доступа.

    На сервере Hyper-V каждая виртуальная машина работает в контексте безопасности процесса vmwp.exe, который выполняется от имени NETWORK SERVICE и, который имеет доступ к файлам виртуальной машины. Это необходимо для использования консоли Hyper-V manager для управления виртуальными машинами пользователями, обладающими определенными правами в системе.

    Шаги по обеспечению безопасности Hyper-V включают в себя как использование access control lists (ACLs), так и использование инструментов управления и обеспечения безопасности таких как System Center Virtual Machine Manager 2008 или Authorization Manager, которые используются для разграничения прав на виртуальные машины.

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

    Это позволит каждому администратору в полной мере управлять виртуальной машиной и файлами данных, не нарушая при этом границ безопасности.

    Для таких целей рекомендуется создавать некоторую структуру папок для более удобного управления и делегирования разрешений.

    Пример:

    W:Virtualization ResourcesProject AVirtual Machines

    W:Virtualization ResourcesProject AVirtual Hard Disks

    W:Virtualization ResourcesProject AVirtual Floppy Disks

    W:Virtualization ResourcesProject AISO files

    W:Virtualization ResourcesProject BVirtual Machines

    W:Virtualization ResourcesProject BVirtual Hard Disks

    W:Virtualization ResourcesProject BVirtual Floppy Disks

    W:Virtualization ResourcesProject BISO files

    W:Virtualization ResourcesProject CVirtual Machines

    W:Virtualization ResourcesProject CVirtual Hard Disks

    W:Virtualization ResourcesProject CVirtual Floppy Disks

    W:Virtualization ResourcesProject CISO files

    Шифрование файловой системы:

    Использование шифрования BitLocker:

    Используйте шифрование диска BitLocker для защиты ресурсов Hyper-V. Шифрование диска BitLocker использует компоненты оборудования и  микропрограмму сервера для обеспечения безопасной загрузки операционной системы и шифрования диска, даже если на сервер не подается электропитание. Это позволяет защитить данные, если диск будет украден и смонтирован на другой компьютер для интеллектуального анализа данных. Шифрование диска BitLocker также помогает защитить данные, если злоумышленник использует другую операционную систему или пытается получить несанкционированный доступ к диску.

    Потеря физического диска представляет наибольшую угрозу в сценариях для небольших и средних предприятий, а также для удаленных офисов, где физическая защита сервера может быть не такой строгой, как в производственных центрах данных. Однако использовать шифрование диска BitLocker имеет смысл для всех компьютеров. Шифрование диска BitLocker должно также использоваться на всех томах, на которых хранятся файлы виртуальной машины. К ним относятся виртуальные жесткие диски, файлы конфигурации, моментальные снимки и любые ресурсы виртуальной машины, такие как образы ISO и виртуальные гибкие диски.

    Аудит событий доступа к объектам:

    Функции обеспечения безопасности на файловой системе могут предотвратить несанкционированный доступ к критически важным объектам виртуальных машин, например таких как файлы VHD. Использование аудита доступа к объектам позволит выявлять попытки несанкционированного доступа. Включите аудит доступа к объектам на сервере Hyper-V. Активируйте события на Успех и Отказ. После включения данной опции будут регистрироваться все события доступа к файлам пользователями. Если по каким-либо причинам целостность файлов будет нарушена, то в журнале событий будет отражена каждая попытка пользователя на доступ к файлам. Таким образом, вы в большинстве случаев сможете определить ответственное лицо.

    Параметры аудита по умолчанию не включены. Для включения параметров аудита используйте средство командной строки auditpol.exe, с помощью которого можно изменять политики аудита на локальном компьютере. Это средство можно использовать для включения и отключения различных категорий и подкатегорий событий, и последующего просмотра этих событий в оснастке “Просмотр событий”.

    Рекомендуется включать аудит событий для файлов VHD для каждого пользователя и группы, которые имеют права на открытие, копирование ,изменение и удаление файлов.

    Например: Администратор, настроенный против компании, осуществляет несанкционированное копирование файла критически важной виртуальной машины, система зарегистрирует событие в системных журналах и таким образом можно отследить все попытки несанкционированного доступа и нарушения регламентов безопасности, а с использованием System Center Operation Manager можно настроить уведомления сотруднику отдела безопасности.

    Часто бывает, что на виртуальных машинах требуется разместить конфиденциальную информацию. В таких случаях необходимо обеспечить более высокий уровень защиты виртуальной машины. Одним из преимуществ виртуальных машин является возможность быстрого перевода виртуальных машин в автономный режим и возврата к работе с помощью функции приостановки работы (suspend) Hyper-V. Корневой сервер сертификатов, например, содержит данные такой важности, что, вероятно, вы захотите, чтобы доступ к нему был возможен только в моменты выполнения определенных операций.

    Для защиты таких важных виртуальных машин можно разместить их на съемных жестких дисках. Завершив операции с такой виртуальной машиной, можно отключить диск и убрать его в надежное место. Если у вас есть виртуальные машины, которые большую часть времени остаются отключенными, убедитесь, что они периодически (раз в месяц) включаются для установки последних обновлений.

    Для предотвращения несанкционированного запуска виртуальных машин,содержащих важную информацию, можно установить пароль на запуск виртуальных машин. Одним из способов запрета запуска виртуальных машин Windows является задание системного пароля для операционной системы.

    Обслуживание виртуальных машин:

    Подход хранения большого количества ВМ на сервере и использования их по мере необходимости, удобен для администраторов, но несет в себе угрозу уровню информационной безопасности предприятия, ведь на выключенных машинах не обновляется антивирус, не устанавливаются исправления безопасности ОС и приложений. Включая такую виртуальную машину, вы рискуете подвергнуть ее атаке, потерять данные или даже контроль над ней.

    В настоящее время принятой практикой является плановое включение виртуальных машин, обновление их антивирусов и ОС, а затем возвращение в выключенное состояние.

    Для автоматизации процесса используйте Offline Virtual Machine Servicing Tool — это типичный Solution Accelerator, позволяющий автоматизировать данный процесс.

    Offline Virtual Machine Servicing Tool работает совместно с SCVMM 2008 и системой обновления ОС — System Center Configuration Manager (SCCM) 2007 R2 или Windows Server Update Services (WSUS) 3.0.

    Для выполнения своих задач Offline Virtual Machine Servicing Tool использует задачи на обслуживание (service jobs), получая от SCVMM список виртуальных машин и задавая команды PowerShell для работы с ВМ. Для каждой виртуальной машины выполняются три шага:

    виртуальная машина включается (активируется на сервере, имеющем достаточно свободных ресурсов — даже если она всего лишь лежала в библиотеке);

    принудительно запускается цикл обновления (SCCM 2007 или WSUS 3.0);

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

    Для планирования расписания выполнения таких процессов используется стандартный планировщик задач (инструмент Scheduled Tasks).

    Контрольный список безопасности VM:

    Контрольный список для виртуальных машин:

    При написании этой статьи использовалась информация полученная из общедоступных источников :

    Планирование безопасности Hyper-V
    http://technet.microsoft.com/ru-ru/library/dd283088(WS.10).aspx

    Портал Microsoft Virtualization
    http://www.hyper-v.ru/On.aspx

    Блог Russian Windows Virtualization Discussion
    http://blogs.technet.com/vm/default.aspx

    Блог Андрея Бешкова
    http://blogs.technet.com/abeshkov/

    Более детальную информацию можно получить из следующих источников:

    Windows Server 2008 Security Compliance Management Toolkit
    http://technet.microsoft.com/en-us/library/cc514539.aspx

    Hyper-V Security Guide
    http://technet.microsoft.com/en-us/library/dd569113.aspx

    С первой частью данной статьи вы можете ознакомится  по следующей ссылке Hyper-V Security или безопасность Hyper-V Часть 1

    Архивирование acronis

    Без архивирования вся проделанная работа ничего не стоит. Первый блин это Acronis Advanced Backup. Варианта тут два:

    1. Агент архивирования ставится на HVS;
    2. Агент архивирования ставится внутрь каждой виртуалки.

    Разница в количестве лицензий, поэтому выбираю вариант 1. А на AH в этом случае ставится хранилище и менеджмент.

    Полностью ознакомиться с документом можно на сайте Acronis’а, либо скачав с моего Google Drive.

    Установка – адская пляска с бубном, то Acronis не может, то он не видит, то он не хочет… И есть большой недостаток – практически все компоненты, включая акронисовского агента Hyper-V – 32-разрядные. Непонятно. Значит не получится удалить компоненту WoW64 и сделать HVS полностью бронебойным.

    Плюс то, что архивирование на уровне гипервизора дает различные схемы по архивированию.

    Порядок установки такой – сначала все необходимые компоненты устанавливаются на AH:

    Затем через Удаленную установку на HVS заливается Агент Hyper-V, который состоит из двух частей – Агента Core и непосредственно Агента Hyper-V.

    Потом на Узле хранения создается Хранилище – у меня это локальная папка и наконец План резервного копирования для виртуалок.

    Есть много путей как настроить архивирование, это 1 из вариантов, не самый лучший.

    Делегирование прав на hyper-v | для системного администратора

    По умолчанию Hyper-V разрешает создание и управление виртуальными машинами только администраторам. Сегодня мы поговорим о том, как делегировать эти права пользователям, не обладающими правами администратора сервера.

    Hyper-V используют новую модель авторизации пользователей — Authorization Management Framework, которая позволяет гибко настроить права пользователей на виртуальные машины. Модель очень хорошо продумана и имеет ряд интересных моментов, которые я обязательно как-нибудь затрону. Сейчас же мне придется сообщить некую вводную информацию про эту модель, чтобы затем показать настройки делегирования. Итак, термины:

    Операция (Operation)

    Основной кирпичик модели авторизации — представляет собой действие, которое пользователь может произвести. Примерами операций модели являются op_Create_VM, позволяющая создать виртуальную машину и op_Start_VM, соответственно, запускающая виртуальную машину.

    Задача (Task)

    Задача — это группа операций, требуемых для выполнения некоторых действий. По умолчанию мы не создаем никаких заданий, но если бы мы могли создать задачу control_VM, то нам бы потребовалось добавить в эту группу операции по запуску (op_Start_VM), остановке (op_Stop_VM), приостановке (op_Pause_VM) и перезапуску (op_Restart_VM) для выполнения необходимых в задаче действий.

    Роль (Role)

    Роль определяет должность, круг задач или зону ответственности для пользователя. Например, может потребоваться роль Virtual_Network_Admin. Эта роль будет иметь права на все операции и задачи, связанные с виртуальными сетями. При необходимости эту роль можно будет назначать пользователям.

    Область (Scope)

    Область позволяет вам указать, какие объекты управляются конкретными ролями. Если у вас есть система, и вы хотели бы быть дать пользователю административный доступ к некому набору виртуальных машин в ней, вам потребуется создать область, содержащую эти конкретные виртуальные машины, а затем применить ваши настройки к данной области.

    Область по умолчанию (Default Scope)

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

    Hyper-V может хранить настройки модели авторизации в Active Directory или в локальном файле в формате XML. По умолчанию после установки роли Hyper-V настройки хранятся в файле, который находится по адресу: %programdata%MicrosoftWindowsHyper-VInitialStore.xml. Для того, чтобы изменить настройки, вам потребуется:

    • Запустить приложение MMC. (Для этого выберите пункт Run в Start Menu или нажмите комбинацию клавиш ‘Windows Key R’, затем выполните mmc.exe).
    • В меню File выбрать Add/Remove Snap-in.
    • Добавить Authorization Manager.
    • В дереве консоли (левой панели ) выбрать Authorization Manager, затем в меню Action выбрать пункт Open Authorization Store.
    • Выбрать XML file в предлагаемом диалоге Select the authorization store type: и открыть файл по указанному выше пути. (Папка programdata является скрытой, так что проще будет скопировать путь целиком).
    • Выберите InitialStore.xml, затем Microsoft Hyper-V services, далее Role Assignments и в конце концов Administrator.
    • В меню Action выберите Assign Users and Groups, затем From Windows and Active Directory, далее выберите пользователя, которому хотите делегировать права на управления Hyper-V. Нажмите OK и закройте окно MMC. (При этом можно сохранить или отменить настройки MMC. Это не повлияет на изменения, внесенные вами в модель авторизации).

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

    Автор:Алексей Кибкало

    Настройка hyper-v

    Устанавливаем на AH компоненту для удаленного управления Hyper-V, если AH с серверной ОС:

    и RSAT, если AH с десктопной ОС.

    Запускаем – Server Manager -> Hyper-V -> Диспетчер Hyper-V. В общих настройках сервера меняем параметры хранения виртуальных жестких дисков и файлов конфигурации для виртуальных машин, а также, если нужно, включаем режим расширенной сессии.

    Далее создаем внешний виртуальный коммутатор, включаем на нем SR-IOV. Опция доступна только если есть поддержка со стороны железа. Выключить эту опцию потом нельзя, только через удаление существующего и создание нового виртуального коммутатора.

    После этого создаем виртуальные машины. Если нет конкретных противопоказаний, то рекомендую создавать виртуалки как машины 2 поколения – сами ОС знают, что они синтетические, моментальная установка, быстрое и адекватное поведение.

    Для машин 2 поколения Hyper-V поддерживаются ОС:

    • Windows 8/10;
    • Windows 2022/2022 R2;
    • Windows 2022;
    • Ubuntu: 14.04 и выше;
    • Debian: точно работает 8.8 (Jessie), если в свойствах машины выключить Безопасную загрузку, с другими версиями не сталкивался;
    • CentOS: 7 работает, версии ниже уже неинтересны.

    Полную информацию можно посмотреть здесь (прокрутить страницу вниз до Содержание раздела и там выбрать нужную ветку).

    Настройка виртуальных машин

    Сколько и каких выделять ресурсов каждой виртуальной машине – решаете сами.

    Доступные логические процессоры для VMs – это физические ядра, плюс потоки Hyper-Threading.

    Хочу только обратить внимание на раздел Управление, подраздел Службы интеграции, пункты Автоматическое действие при включении (и при выключении) и Синхронизация времени. Если на шаге начальной настройки было настроено обновление времени HVS через интернет, то можно спокойно передавать на виртуалки через Синхронизацию времени – время будет точным.

    А вот если контроллером домена является одна из виртуалок, Синхронизацию времени с ней нужно выключить.

    Автоматический старт виртуалок при включении хоста (небольшие разные задержки для разных виртуалок) и завершение при выключении – именно завершение работы гостевой ОС, а не сохранение – редко, но метко сохраненные состояния оказываются неработоспособными при включении, что требует ручного вмешательства.

    Завершение работы гостевой ОС гораздо дольше, зато надёжнее. За исключением, может быть, VMs на Linux, тут зависит от конкретного дистрибутива и особенностей работы Служб интеграции для Linux (LIS) в этом дистрибутиве. В некоторых случаях при установленных LIS актуальной версии Hyper-V не может погасить Linux машину при перезагрузке самого HVS и всё это дружно висит и ждёт ручного вмешательства.

    Включаем SR-IOV в свойствах синтетической сетевой, если есть поддержка со стороны железа. Возможно придётся поставить специализированные драйвера.

    Пробрасывание внутрь виртуальных машин USB-устройств (у меня это ключи 1С) осуществляется с помощью программы USB Over Network.

    Проверка

    При работе в RSAT на Windows 10 Pro и HVS 2022 – проблем нет, кроме того, что не открывается Управление дисками с сообщением “нет доступа”. Не придал значения, так как непринципиально.

    Затем настроил подключение в RSAT на Windows 10 Pro и HVS 2022 R2. Дополнительно к Управление дисками оснастка Hyper-V тоже пишет “нет доступа”. Стал уже разбираться. Помог скрипт hvremote.wsf, довольно старый, но всё ещё боевой. На странице чётко указано: Windows 10 и 2022 не поддерживаются.

    There are no plans add support for Windows 10/Windows Server 2022 - there are too many changes in Windows 10 to take this on in a simple manner right now given other things I'm working on. Sorry.

    Но работа возможна с добавлением параметра /override.

    Итак, запускаю проверку со своего домашнего компьютера:

    J:>cscript hvremote.wsf /show /override /target:hv-srv

    В выводе скрипта вижу ошибку и солюшен:

    WARN: ANONYMOUS LOGON does not have remote accessThis setting is required when the client is in a workgroup, or the server is in an untrusted domain from the client.Use hvremote /mode:client /anondcom:grant to turn on

    Выполняю: 

    J:>cscript hvremote.wsf /override /mode:client /anondcom:grant

    Оснастка Hyper-V сразу нормально начинает функционировать, а Управление дисками пишет “Сервер RPC недоступен”. Эта ситуация уже была и описана в разделе HVS и AH в одной подсети, в одной рабочей группе. Выключил файрвол на домашнем компьютере, да, Управление дисками работает. Но выключать/включать каждый раз не хочется, полностью выключать тоже не хочется.

    Удаленное подключение и управление hyper-v server 2022

    Подключаемся по rdp к серверу, чтобы было удобно копировать и вставлять длинные команды в командную строку. В консоли cmd переходим в powershell, просто введя команду:

    powershell

    Вводим команды для настройки разрешений на фаерволе для удаленного управления: 

    Set-NetFirewallRule -DisplayGroup 'Windows Management Instrumentation (WMI)' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Event Log Management' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru

    Теперь переходим на клиентскую систему. Напоминаю, что в моем случае это Windows 10 Корпоративная. Заходить на нее нужно под учетной записью с теми же параметрами, что создана на гипервизоре. Добавьте такого же пользователя и работайте под ним. Это обязательное условие для подключения к управлению непосредственно сервером, его службам, дисковой подсистемой и т.д.

    Первым делом создадим запись в файле hosts с именем сервера hyperv. В моем случае эта запись выглядит так:

    192.168.1.100 hyperv2022

    Убедитесь, что с клиентской машины вы пингуете гипервизор по имени. Теперь нам нужно проверить, чтобы в настройках сетевого адаптера текущее сетевое подключение было указано, как подключенное к частной сети. Это нужно для того, чтобы было включено сетевое обнаружение устройств. Речь вот о чем:

    По-умолчанию этот параметр включен для частных сетей и выключен для общедоступных. Можете либо включить его и для общедоступных, либо поменять параметр сетевого соединения на частную сеть. Сделать это можно в соседнем разделе панели управления:

    Я не сразу смог найти, где это сделать, поэтому подсказываю вам. Продолжаем настройку хоста для подключения к hyper-v server 2022. Запускаем cmd от администратора и переходим в powershell. Выполняем команду:

    winrm quickconfig

    Обязательно жмите Y и продолжайте. Вводим следующую команду, которая разрешает управление удаленными системами:

    winrm set winrm/config/client '@{TrustedHosts="hyperv2022"}'

    В данном примере, hyperv2022 – имя моего гипервизора.

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

    Теперь нам нужно изменить еще один параметр. Запускаем оснастку dcomcnfg.exe, выполнив эту команду в cmd. Открывается оснастка управления службой компонентов.

    Выполняем последовательность действий, указанных на картинке. Дальше надо установить стандартную оснастку для управления hyperv. Для этого идем в Панель управления -> Программы -> Включение или отключение компонентов Windows. Выбираем там Средства управления Hyper-V и устанавливаем их. Дожидаемся окончания установки и пробуем подключиться к удаленному серверу:

    Если все сделали правильно, вы подключитесь к серверу и у вас появится возможность им управлять.

    Расскажу еще об одном нюансе. Вы можете подключиться к удаленному hyper-v серверу, даже если работаете не под той учетной записью, что имеет административные права на гипервизоре. При подключении есть возможность ввести параметры другого пользователя.

    Но чтобы эта возможность заработала, необходимо выполнить ряд действий как на сервере, так и на клиенте. Для начала надо изменить один параметр в локальной политике компьютера. Для этого выполняем в cmd команду gpedit. Откроется оснастка управления локальными политиками компьютера. Идем по пути:

    wsman/hyperv2022

    Далее выполняем команды в powershell. Не забудьте запустить консоль от имени администратора: 

    Set-Item WSMan:localhostClientTrustedHosts -Value "hyperv2022"
Enable-WSManCredSSP -Role client -DelegateComputer "hyperv2022"

    Теперь надо внести некоторые изменения на самом гипервизоре. Подключаемся к нему по rdp, переходим в cmd, запускаем powershell и выполняем команды:

    Enable-PSRemoting
Enable-WSManCredSSP -Role server

    После этого можете работать под привычным пользователем компьютера, но при этом подключаться к hyper-v server 2022 под другой учетной записью и управлять им.

    Самое трудное сделали. Теперь мы можем свободно подключаться и управлять гипервизором. Забыл упомянуть о том, как подключиться к управлению самим сервером, то есть как посмотреть список дисков, службы, почитать логи и т.д. Делается это очень просто. Заходите на компьютер под той же учетной записью, что является администратором на гипервизоре.

    Пишите имя сервера и подключаетесь к нему. Вам доступны все разделы управления компьютером, кроме диспетчера устройств. К нему почему-то не получается подключиться, возникает ошибка. Я подробно не разбирался в чем дело и как ее исправить.

    Заключение

    Постарался рассмотреть все наиболее значимые аспекты в работе с бесплатным гипервизором от Microsoft. Сам еще не проверял его в работе и особо не интересовался нововведениями, пока не было времени. Смотрел на него только в тестовых стендах. Можете сравнить его с бесплатным гипервизором на kvm – proxmox, который я рассматривал в своей статье установка и настройка proxmox.

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

    В hyper-v удобно, что все системы его поддерживают без проблем. На kvm, к примеру, в proxmox, после установки windows систем в качестве гостевых машин, нужно будет устанавливать драйвера с отдельного диска, либо использовать готовые образы, где они будут уже интегрированы. Мелочь, но все равно не так удобно.

    Буду рад любым замечаниям по статье, подсказкам или указаниям на ошибки. Так же было бы любопытно узнать, какой гипервизор вы предпочитаете использовать и по какой причине. Какие преимущества по сравнению с остальными гипервизорами вы видите в своем выборе.

    Добавить комментарий

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

    ➤