2 заметки с тегом

Hyper-V

Виртуализация FreeBSD на Hyper-V

6 июля 2015, 12:29

Решил побаловаться с SCVMM 2012 R2, посмотреть, что это такое и с чем его едят. Развернул два хоста с Hyper-V Server 2012 R2, и один хост с Win2012 R2 под общее хранилище кластера виртуализации.

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

Суть косяка в том, что фря видит ДВА диска там, где по факту он всего один. На этапе установки это выглядит так:

Я выбрал при установке da0, и поставил систему туда, и всё отлично заработало. Но решил разобраться, в чём тут дело. Первое предположение было, что фря видит два диска из-за проблем в драйвере. И ada0 — это эмулируемый дисковый контроллер, а da0 — синтетический. Гуглинг ничего не показал, кроме указаний на статью в MSDN. Но там никакого внимания этой проблеме не уделено, просто скриншот (это как раз он выше) представлен, и всё. И пользователь в комментариях задаёт вопрос, типа, «why attached virtual disk to guest is visible twice? It's visiblle as ada0 and da0». Или, иными словами, а почему диск виден дважды под разными именами? Но ответа на этот вопрос не последовало.

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

В общем, по итогам общения выяснилось, что действительно, два диска представляют по сути один диск, но видимый через разные дисковые контроллеры. ada0 — это эмулируемый контроллер, da0 — синтетический. Разработчики рекомендовали использовать da0, так как будет выше производительность и ниже нагрузка на процессор. И можно слегка поправить исходники соответствующего модуля, чтобы система перестала видеть диск ada0 вообще, и остался только da0. Для этого нужно сделать следующее: в файле /usr/src/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c необходимо найти функцию v_ata_pci_probe(), и заменить в ней возвращаемое значение (return value) с BUS_PROBE_DEFAULT на BUS_PROBE_VENDOR. После этого пересобрать и установить ядро. Я проделал это, и проблема исчезла.

Также был затронут вопрос про KVP daemon. Это процесс, который умеет из гостевой фри общаться с гипервизором, и принимать/передавать туда-сюда key-values pairs. Т. е. какие-то параметры конфигурации. В частности, он используется для того, чтобы в Hyper-V manager можно было видеть IP-адрес, который имеет гостевая фря. И, по слухам, также может получать статические IP из пула, назначаемого из SCVMM, и прописывать его в гостевую систему. Но это я ещё не проверял, поэтому не знаю.

В общем, с KVP (процесс hv_kvp_daemon) тоже проблемка — он стартует только один раз после установки системы, а потом отказывается. Я порылся, и выяснил, что при запуске hv_kvp_daemon пытается создавать директорию /var/db/hyperv/pool. И если эта директория уже существует, (и следовательно, создать её не удаётся), то hv_kvp_daemon не запускается. Налицо просто некорректная обработка ошибки при попытке создания каталога. Т. е. вместо проверки на существование каталога делается попытка создания, и если она неудачная, то fail. Удаление каталога руками проблему решает — hv_kvp_daemon запускается. Непонятно, почему в системе нет стартового скрипта для этого демона, и его нужно запускать ручками. Возможно, считается, что демон ещё не доведён до ума, поэтому и стартового скрипта нет. В принципе, эту проблему с создание каталога можно обойти в стартовом скрипте — удалять каталог после остановки демона, и проверять каталог на существование при старте, и если он есть — опять таки, удаляем, hv_kvp_daemon его создаст себе сам.

Мораль: фрю вполне можно использовать в качестве гостевой ОС внутри Hyper-V. Я вижу в коммитах фрёвых исходников, что какая-то работа потихоньку, поддержка Hyper-V во фре допиливается, медленно, но верно. Остаётся дождаться только работы динамической памяти в гостевой фре, и можно совершенно смело гостевать фрю на Hyper-V. Сейчас оно всё работает — сетка и диски видны из коробки (на фре 10.1), крутится довольно стабильно. Правда, я нагрузки большой не давал, но в рамках той нагрузки, что есть, всё работает.

FreeBSD   Hyper-V   Troubleshooting

Управление Hyper-V из-под обычного пользователя

13 января 2012, 17:12
Локальное управление

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

Hyper-V может хранить настройки модели авторизации в Active Directory или в локальном файле в формате XML. По умолчанию после установки роли Hyper-V настройки хранятся в файле, который находится по адресу: %programdata%\Microsoft\Windows\Hyper-V\InitialStore.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 управляется локально. Для того, чтобы подключаться к нему удалённо, нужно проделать ещё ряд мероприятий:

Описанные в этой статье шаги применимы к версии RC0 гипервизора Hyper-V и RC0 версии клиентской утилиты управления Hyper-V Manager для Vista SP1 (x86 и x64).

Итак, на сервере следует выполнить следующие шаги:

Разрешить в Windows Firewall правило «Windows Management Instrumentation (WMI)» следующей командой:
netsh advfirewall firewall set rule group=«windows management instrumentation (wmi)» new enable=yes

Внимание: в различных локализованных ОС встроенные правила брандмауэера могут назваться по-разному. Необходимо указать название правила именно так, как оно выглядит в инструментах управления Windows Firewall. Например, в русской версии Windows Server 2008 приведенная выше строка будет выглядеть так:

netsh advfirewall firewall set rule group=«Инструментарий управления Windows (WMI — входящий трафик)» new enable=yes

Предоставить пользователю права на удаленный запуск (remote launch and activation) в DCOM. Это можно сделать как для конкретного пользователя или группы, так и для всех AUTHENTICATED USERS.
Нажмите Start, выберите Run, запустите dcomcnfg.exe.
В Component Services раскройте Computers, правой кнопкой нажмите на My Computer и выберите в меню пункт Properties.
В My Computer Properties раскройте COM Security.
В Launch and Activation Permissions выберите Edit Limits.
В случае, если пользователь не указан в списке Groups of user names в окне Launch Permission, добавьте его кнопкой Add.
В Launch Permission выберите пользователя или группу и в колонке Allow в Permissions for user укажите Remote Launch и Remote Activation. Нажмите OK.
Предоставить пользователю права на удаленное управление (remote enable) в пространстве имен (namespace) **root\CIMv2 и root\virtualization. Это можно сделать как для конкретного пользователя или группы, или для AUTHENTICATED USERS.
В Control Panel зайдите в Administrative Tools и запустите Computer Management.
В Computer Management раскройте Services and Applications, правой кнопкой выберите WMI Control и нажмите Properties.
В закладке Security выберите Advanced.
В случае, если пользователь не указан в списке Permission в окне Advanced Security Settings, добавьте его кнопкой Add.
В Advanced Security Settings выберите имя пользователя и нажмите Edit.
В выпадающем меню Apply To окна Permission Entry выберите This namespace and subnamespaces и укажите Remote Enable в колонке Allow. Нажмите OK.
Предоставьте пользователю права на Hyper-V. Эта процедура описана выше.
Перезагрузите сервер. (Если вы хотите избежать перезагрузки сервера, достаточно перезапустить следующие сервисы: winmgmt, vmms, vhdsvc & nvspwmi).
Внимание: если сервер с установленной ролью Hyper-V, которым вы хотите управлять удаленно, используя локальную запись с правами администратора, не входит в домен, и при этом на сервере включен User Account Control (UAC), то имейте в виду следующее. По умолчанию к локальным учетным записям при неинтерактивном (в том числе сетевом) доступе применяется UAC Filtering. То есть, даже если вы являетесь администратором сервера, при попытке удалённого подключения UAC предоставит вам права стандартного пользователя. Поэтому в таком случае вам потребуется напрямую предоставить пользователю права на Hyper-V способом, описанным в предыдущей статье.

Итак, сервер мы настроили. Теперь ряд настроек потребуется выполнить и на клиентском ПК с Vista SP1.

Разрешить на Windows Firewall правило «Windows Management Instrumentation (WMI)» командой
netsh advfirewall firewall set rule group=«windows management instrumentation (wmi)» new enable=yes

В русской версии Windows Vista эта же команда выглядит следующим образом:

netsh advfirewall firewall set rule group=«Инструментарий управления Windows (WMI — входящий трафик)» new enable=yes

А на системах с ОС, предшествующими Windows Vista (Windows XP / 2003), для этого служит команда

netsh firewall set service RemoteAdmin enable

На системах с ОС, предшествующих Vista (Windows XP / 2003), следует также добавить исключение для исполняемого файла Unsecapp.exe:
netsh firewall add allowedprogram program=%windir%\system32\wbem\unsecapp.exe name=UNSECAPP

Добавить в Windows Firewall исключение для исполняемого фалйла mmc.exe:
netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name=«Microsoft Management Console»

Если клиент или сервер находятся в рабочей группе или они находятся в разных доменах, между которыми нет доверительных отношений, то соединение от сервера до клиента, устанавливаемое для доставки результирующей информации, происходит анонимно. Анонимное соединение завершается неудачно с кодом ошибки 0x80070005 или 0x8007000e до тех пор, пока анонимному соединнеию не будет дано право Remote Access на DCOM клиента. Дать это право можно, выполнив следующие шаги:
Нажмите Start, выберите Run, запустите dcomcnfg.exe.
В Component Services раскройте Computers, правой кнопкой выберите My Computer и укажите Properties.
В My Computer Properties раскройте COM Security.
В Launch and Activation Permissions выберите Edit Limits.
В окне Access Permissions выберите ANONYMOUS LOGON в списке Group or user names. В колонке Allow в Permissions for User укажите Remote Access и нажмите OK.
После выполнения всех описанных действий вы, наконец, получите возможность удаленно подключаться к серверу и управлять ролью Hyper-V.