MCP
Показаны сообщения с ярлыком hyper-v. Показать все сообщения
Показаны сообщения с ярлыком hyper-v. Показать все сообщения

вторник, 26 мая 2015 г.

Управление виртуалками для обычных пользователей в Hyper-V 2012 R2

Microsoft иногда очень оригинально относится к безопасности. Перекроет все щели так, что прорваться могут только админы. А потом начинает ныть, что же все сидят под админами. Ну, может быть, потому что кто-то ленится подумать про права?

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

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

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

Зато, после всех этих мучений, можно было весьма гранулированно раздавать права через AzMan (я, кстати, первый раз его видел, хотя, судя по всему, существовал в системе давно, с XP. Но мы-то знаем, что Microsoft не ищет лёгких путей и всегда есть по крайней мере три несовместимых технологии).

К сожалению, в 2012 R2, эта магия больше не работает. Всё сломано. Мне понадобилось достаточно длительное время, чтобы понять это, т.к. народ умудряется писать статьи о том, что всё таки работает. Не работает. Проверено. С большим скрежетом, я всё-таки нашёл, что можно с этим сделать. А сделать можно только одно: давать пользователю подключаться, к виртуальной машине. Т.е. включить он её не может, но хотя бы может работать с ней. Для того, чтобы как-то добавить права, судя по всему нужна отдельная прослойка, которая со своими жирными правами будет всё делать, уже сам раздавая права. Данной прослойкой может быть System Center Virtual Machine Manager или что-то своё самописное (можно добавить имперсонацию и рулить юзерами, действия тупо выполнять через PowerShell). Но само подключение можно реализовать чуть проще, хотя и не очень очевидно.

Собственно, для возможности подключения пользователя (не админа) к определённой виртуалке надо сделать следующее):

  1. Выдать права на виртуалку через PowerShell
    Grant-VMConnectAccess -ComputerName host_name -VMName vm_name -UserName user_name
    Есть ещё команды Get-VMConnectAccess для просмотра прав и Revoke-VMConnectAccess для отбирания
  2. В PowerShell выяснить id-нужной нам виртуалки
    Get-VM -ComputerName host_name | select id,name
  3. Установить Remote Desktop Connection Manager (стандартный не катит)
  4. В нём сделать новую группу, в группу добавить сервер, на вкладке Server Settings поставить VM Console Connect, ввести нужный Id и сохранить всё это дело


После этого можно пользоваться прямым подключением к виртуалке (возможно придётся открыть ещё порт 2179).

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



четверг, 12 июля 2012 г.

Ненависти к Hyper-V псто

Утро не предвещало ничего плохого. Приехал маленький сервер и на него нужно было взгромоздить Hyper-V (если быть точнее, то версии 2008 R2). Никаких проблем не ожидалось, всё-таки не первый раз ставлю Hyper-V, а уж винду тем более, но у сервера была маленькая особенность (что для серверов совсем не особенность). В нём радостно урча сидели 4 винчестера по 2Тб каждый.

Итак, немного покопаться в биосе, поднять RAID10, получив 4Тб радости, воткнуть флешку и пойти покурить, пока это всё ставится (а ставится Hyper-V около 10 минут, так что ещё на кофе остаётся время).

И тут возникла первая проблема. После копирования файлов и установки перед самой перезагрузкой, винда вдруг заявила: нехорошие диски у тебя, не буду я с них грузиться. Давай, до свидания! Я всё откатываю. Тут я слегка офигел, но быстро понял, ибо это достаточно известный факт: Windows не умеет грузиться с винчестеров более 2Тб. Или умеет, но при лётной погоде.

Эти грабли удалось побороть достаточно просто: хвала Ктулху, что RAID-контроллер позволил сделать 2 виртуальных массива. Что я и сделал. 50Гб для системы, 3950Гб для данных. Винда бодро установилась, я пошёл её настраивать, включать в SCVMM, ставить апдейты и прочую мишуру, которую обязательно делать с виндой. Когда всё уже было готово, я решил перенести пару тестовых виртуалок и тут меня ожидали вторые грабли: виртуальные диски отказывались создаваться под всякими разными надуманными предлогами. Не буду расписывать как я танцевал с бубном (нижний брейк в сочетании с пасодоблем), но выяснил, что Hyper-V очень не любит винчестеры с размером сектора в 4k. Моя проблема оказалось в том, что RAID решил для такого большого винчестера установить сектор в 1 килобайт (вместо стандартных 512 байт), что было явно не 4Кб, и решению по мнению операционки не поддавалось.

Тут меня посетила гениальная идея: разбить диски на 2 рейда по 2Тб и молиться Ктулху, чтобы в таком конфиге сектор получился в 512 байт (в дальнейшем эта идея оказалась верной). Но тут винда решила устроить маленькую подлость, и обозвать диск 1 диском 2, а диск 2 диском 1, или что более корректно: диск 0 диском 2, а диск 1 диском 1. Вы чего-нибудь поняли? Я тоже не очень разобрался, но в результате система поставилась на первый из двух виртуальных дисков, а очень нужный Recovery-раздел на 100 мегабайт на второй.

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

В общем, переставил ещё раз, сделал диски dynamic и создал spanned-том (аналог JBOD) на 3950Гб из двух псевдовиртуальных. Было очень радостно на душе от того, что такую хитропопую проблему так оригинально решил. Новые виртуалки создавались без проблем и ничего не предвещало беды... Но тут опять появился SCVMM, который начал утверждать, что он не может мигрировать виртуалки, потому что на сервере нет места *удар моей головы ап стену*. Расследование показало, что System Center не понимает dynamic-диски (ха! их ещё 2000 винда понимала), и из-за этого отказывается мигрировать виртуалки. Но что самое интересное, если перевести dynamic диск в basic, обновить информацию в SCVMM, перевести назад в dynamic, то всё замечательно работает. До первого рефреша о системе. Блин.
Каким местом это нужно было писать, я не знаю. Явно не руками, но и насчёт ног я тоже сомневаюсь. Во всяком случае, голова тут не использовалась.

Пришлось, в результате сделать 2 диска и при создании виртуалок помнить о том, что надо как-то следить за местом. Но ситуация выглядит абсолютно глупо.

Пойти что-ли прочитать про Hyper-V 2012, может там всё поправили и не надо так извращаться ради простейшей очевидной задачи.

пятница, 17 сентября 2010 г.

Проблемы с VMBus при миграции с Virtual PC на Hyper-V

Тут перетаскивали локальную виртуалку на Висте с Virtual PC на Hyper-V. При этом вылезла проблема с тем, что виртуалка на новом месте не видела сети (только Legacy) безумно тормозила (100% загрузки процессора и почти всё время в ядре), в списке устройств лежал неработающий VMBus (это виртуальное устройство от Hyper-V).

Естественно, это всё было после удаления гостевых служб от Virtual PC и установки соответствующих от Hyper-V, танцы с бубном не помогали.

Решение нагуглилось, но с трудом, поэтому и решил поделиться им. Для этого нужно всего-лишь:
  1. Запустить msconfig
  2. Выбрать вкладку boot (загрузка), Advanced Options (Дополнительные опции)
  3. Поставить галочку "Detect HAL" (Обнаружение HAL)
  4. Перегрузиться

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

Ещё возможно потребуется переустановить гостевые дополнения (кстати, для них рекомендуется включить Windows Update Services, иначе говорят что бывают проблемы), но это уже совсем другая история.