Компы и автомобили (Posts about Администрирование)

Зависание инсталлятора VMware tools

at-hacker — Fri, 06 Nov 2015 09:51:00 GMT

Попытался сейчас на одной виртуалке с Ubuntu заапргейдить VMware tools в «non-interactive mode». Это когда оно, по идее, должно само подключиться к виртуалке, и само всё сделать. Но операция «Initiated VMware tools install or upgrade» зависла на 0%, и больше ничего нельзя было с виртуалкой сделать — ни отмонтировать диск с VMware tools, ни мигрировать виртуалку, ни отменить операцию установки. При попытке выбрать «End Install/upgrade VMware tools» выскакивала ошибка «Call „VirtualMachine.UnmountToolsInstaller“ for object „Usergate-Webfilter“ on vCenter Server „vcenter.vsphere.local“ failed», а в логах появлялось сообщение: «The operation is not allowed in the current state».

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

В итоге на просторах отыскался рецепт:

Включить SSH на том хосте, на котором работает виртуалка;
Зайти в консоль хоста и выполнить там команду vim-cmd vmsvc/getallvms. Эта команда покажет список работающих виртуалок. В левой колонке будет ID соответствующей виртуалки. Ищем в списке виртуалку, на которой завис инсталлятор VMware tools, и определяем её ID;. Эта команда покажет список работающих виртуалок. В левой колонке будет ID соответствующей виртуалки. Ищем в списке виртуалку, на которой завис инсталлятор VMware tools, и определяем её ID;
Выполняем команду vim-cmd vmsvc/tools.cancelinstall , где VM_ID — идентификатор виртуалки, определённый на шаге 2. После этого операция установки VMware tools завершается с ошибкой и освобождает виртуалку;, где VM_ID — идентификатор виртуалки, определённый на шаге 2. После этого операция установки VMware tools завершается с ошибкой и освобождает виртуалку;
Не забываем снова отключить службу SSH на хосте.

Время, вперёд!

at-hacker — Fri, 23 Oct 2015 18:31:00 GMT

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

Полезли смотреть всей толпой. Выявили, что в логах факт отработки крона логируется с указанием времени, на час опережающем текущее. Т. е. если, например, выполнить date, то получаем 17 часов, а крон в лог пишет, что запустился в 18 часов. Вспомнили, что мы этот сервак не перезагружали после обновления time zone data. Я сделал , то получаем 17 часов, а крон в лог пишет, что запустился в 18 часов. Вспомнили, что мы этот сервак не перезагружали после обновления time zone data. Я сделал service syslogd restart. Смотрю в логи — ну, вроде как факт очередного редактирования crontab записался с правильным временем . Должно задание отработать. Однако нифига :-) В логах стало вот так:. Смотрю в логи — ну, вроде как факт очередного редактирования crontab записался с правильным временем . Должно задание отработать. Однако нифига :-) В логах стало вот так:

Oct 14 17:41:13 vpn2-lesnoy crontab[63631]: (root) BEGIN EDIT (root)
Oct 14 17:41:34 vpn2 crontab[63631]: (root) REPLACE (root)
Oct 14 17:41:35 vpn2 crontab[63631]: (root) END EDIT (root)
Oct 14 17:41:46 vpn2 crontab[63646]: (root) BEGIN EDIT (root)
Oct 14 17:41:52 vpn2 crontab[63646]: (root) END EDIT (root)
Oct 14 18:42:00 vpn2 /usr/sbin/cron[992]: (root) RELOAD (tabs/root)
Oct 14 17:42:34 vpn2 crontab[63677]: (root) LIST (root)
Oct 14 18:44:00 vpn2 /usr/sbin/cron[63721]: (operator) CMD (/usr/libexec/save-entropy)
Oct 14 18:45:00 vpn2 /usr/sbin/cron[63763]: (root) CMD (/usr/libexec/atrun)

Т. е. время скачет очень внезапно :-) Перезапуск крона этот вопрос решил, и время везде синхронизировалось. Т. е. задание не отрабатывало потому, что коллега устанавливал срабатывание задания на 17 часов, а крон считал, что уже 18 часов.

Баг в файрволе pf

at-hacker — Wed, 08 Jul 2015 11:25:00 GMT

Предисловие

В конторе мы вынужденно используем FreeBSD 9.3 на BRAS'ах. Вызвано это тем, что на 10-ой фре есть какой-то косяк с mpd (у нас с его помощью PPPoE-соединения от клиентов обслуживаются). И mpd периодически виснет при значительном изменении числа подключений. Т. е. когда много клиентов одновременно подключается или отключается, mpd зависает в состоянии umtxn. Я писал по этому поводу в уже открытый PR, но движухи по нему нет.. Я писал по этому поводу в уже открытый PR, но движухи по нему нет.

О проблеме

Но речь не об этом. В общем, на фре 9.3 в файрволе pf обнаружился занятный баг. Баг относится к работе NAT на pf. Проявляется так:

Клиент шлёт через NAT запрос на какой-то сервер в интернете;
Сервер ему отвечает;
Но за время ответа у клиента этот порт, с которого он отправлял свой запрос, почему-то закрылся;
Клиент примет пакет от сервера и ответит серверу ICMP пакетом с типом port unreachable

Тут-то и проявляется баг — pf'овский NAT некорректно натит этот ответный ICMP-пакет, и в итоге с внешнего интерфейса улетает ICMP-пакет с серым SRC IP клиента и белым DST IP того сервера, куда этот пакет должен быть доставлен.

Т. е. допустим, у вас адрес NAT-интерфейса — 1.1.1.1, адрес сервера в интернете 2.2.2.2. И адрес клиента 192.168.0.1. В итоге с ВНЕШНЕГО интерфейса NAT'a улетит пакет с адреса 192.168.0.1 на адрес 2.2.2.2. Т. е. трансляции адреса клиента во внешний адрес NAT (1.1.1.1) не произойдёт.

Кровавые подробности

Если быть совсем точным, то трансляция ICMP-пакета таки происходит. Но не везде и не до конца :-)

Немного теории

ICMP-пакеты подразделяются на несколько типов. Причём в каждом типе есть ещё несколько подтипов. В данном случае клиент генерирует пакет типа 3 «destination unreachable». И подтипа тоже 3 — «port unreacable». Подробности можно почитать в man icmp, там есть табличка с типами и подтипами (подтипы называются codes, коды). В пакет типа port unreacahble клиент вкладывает заголовок того пакета, который вызвал генерацию сообщения ICMP «port unrecahable» (назовём для краткости такой пакет «пакетом-инициатором»). Ну, чтобы сервер, получивший от клиента ICMP destination unreachable понимал, на какой конкретно его пакет клиент ответил, что порт недоступен. И вот расследование показало, что как раз этот заголовок, пакета-инициатора транслируется файрволом нормально. Но сам ICMP-пакет — нет.

Суровая практическая реальность

Итак, мы приняли, что локальный IP клиента у нас 192.168.0.1, а внешний IP, в который NAT'ится клиентский трафик — 1.1.1.1. Таким образом, получается примерно такой формат ICMP-пакета от клиента обратно на сервер 2.2.2.2 (до трансляции):

Заголовок ICMP	SRC IP: 192.168.0.1	DST IP: 2.2.2.2
Заголовок пакета-инициатора	SRC IP: 2.2.2.2 port 80	DST IP: 192.168.0.1 port 12345

То есть, клиент со своего адреса 192.168.0.1 оповещает сервер 2.2.2.2, что типа, «бро, ты мне отправил пакет со своего IP 2.2.2.2 и порта 80 на мой адрес 192.168.0.1 и порт 12345. Ну так вот, довожу до твоего сведения, что этот порт у меня закрыт».

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

Заголовок ICMP	SRC IP: 1.1.1.1	DST IP: 2.2.2.2
Заголовок пакета-инициатора	SRC IP: 2.2.2.2 port 80	DST IP: 1.1.1.1 port 54321

То есть, NAT уже от своего имени проговаривает серверу 2.2.2.2: «бро, ты мне отправил пакет со своего IP 2.2.2.2 и порта 80 на мой адрес 1.1.1.1 и порт 54321. Ну так вот, довожу до твоего сведения, что этот порт у меня закрыт».

Обращаю внимание, что порт на клиентской стороне ДО и ПОСЛЕ трансляции могут отличаться. Т. е. то, что у клиента слушает на порту 12345, на NAT'е будет на порту 54321 (ну, или на любом другой, который будет свободен на момент установки соединения клиентом, и который NAT выберет для трансляции). Ну это так, для сведения, сейчас это роли не играет.

Так вот, из-за бага в pf пакет транслируется следующим образом:

Заголовок ICMP	SRC IP: 192.168.0.1	DST IP: 2.2.2.2
Заголовок пакета-инициатора	SRC IP: 2.2.2.2 port 80	DST IP: 1.1.1.1 port 54321

Т. е. NAT в pf транслирует только заголовок пакета-инициатора, идущий нагрузкой в ICMP-пакете типа «destination unreachable», но не транслирует заголовок самого ICMP-пакета.

Заключение

Написал сообщение в рассылку freebsd-net. Там товарищ Kristof Provost попросил проверить, есть ли такое же поведение в -CURRENT, и если да, то он посмотрит, в чём там проблема. Ну, соберу -CURRENT на досуге, попробую.

А, кстати, ещё один момент. pf не только некорректно натит такие пакеты, но и также не может блокировать этот трафик. Т. е. правило вида

block out quick inet proto icmp from 192.168.0.0/24 to any

тоже не работает для таких пакетов. Похоже, pf анализирует только содержащийся в нагрузке заголовок пакета-инициатора, а не самого ICMP-пакета.

UPDATE

Собрал -CURRENT, проверил. Это поведение полностью повторяется и в -CURRENT. Нарисовал багрепорт по этому поводу, авось когда-нибудь починят. На текущий момент подобный пытающийся улететь наружу трафик блокируется с помощью IPFW.

Часовой пояс во FreeBSD

at-hacker — Tue, 08 Apr 2014 14:33:00 GMT

Запилил тут на Амазоне сервер на фре, и возник вопрос — а как выставить часовой пояс? Раньше как-то на этапе установки системы в инсталляторе выставлял, и всё. И поэтому не в курсе, как это физически реализуется. Оказывается, нужно выбрать файл со своим часовым поясом в /usr/share/zoneinfo и скопировать его в /etc. То есть, для Москвы нужно выполнить команду:

# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Как рулить инсталляциями server core

at-hacker — Mon, 02 Dec 2013 13:18:00 GMT

Нашёл мега-полезную ссылку про то, как можно жить с server core. Прямо так и называется: «Сore 2012: Руководство по выживанию». Много всяких полезных штук — как настраивать сетку, как просматривать логи и так далее, через powershell. про то, как можно жить с server core. Прямо так и называется: «Сore 2012: Руководство по выживанию». Много всяких полезных штук — как настраивать сетку, как просматривать логи и так далее, через powershell.

Минимальное ядро и загрузка с ZFS

at-hacker — Fri, 22 Nov 2013 14:06:00 GMT

Попытался тут оторвать все модули и жёстко впаять необходимое в ядро. Система грузится с ZFS, а также используется AIO для самбы, ибо сильно увеличивает скорость работы самбовых шар. Проверил как-то ради шутки — без AIO гиговый файл копировался 9 минут 10 секунд, с включенным AIO — 1 минуту 45 секунд. Разница примерно 6 раз.

В общем, пока (на момент версии FreeBSD 9.2) выясняется, что zfs.ko и и opensolaris.ko в ядро не включить, можно только модулями ядра грузить. Добавил в ядро только AIO: в ядро не включить, можно только модулями ядра грузить. Добавил в ядро только AIO:

options VFS_AIO

И прописал в make.conf:

MODULES_OVERRIDE=zfs opensolaris

Собрал ядро, установил, попытался перезагрузиться и получил облом. При загрузке система стала утверждать, что не знает, откуда смонтировать root. Оказывается, нужен ещё модуль krpc.ko, отвечающий за реализацию RPC в солярке (откуда и портирована ZFS). Причём судя по обрывочным сведениям, нужен он только на 64-битной фре, на 32-битной вроде как нет. Проверять, честно говоря, влом :-), отвечающий за реализацию RPC в солярке (откуда и портирована ZFS). Причём судя по обрывочным сведениям, нужен он только на 64-битной фре, на 32-битной вроде как нет. Проверять, честно говоря, влом :-)

Правим make.conf:

MODULES_OVERRIDE=zfs opensolaris krpc

Пересобираем ядро, ставим, перезагружаемся — и всё взлетает нормально.

Удалённое выполнение команд по ssh

at-hacker — Wed, 20 Nov 2013 12:57:00 GMT

В свете полученных знаний из ссылок в предыдущем посте решил начать жить по-новому. А именно — бэкапные файлы с фри на фрю складывать не по SMB или FTP, как раньше, а по scp или ssh. Подумал, и решил, что удобнее будет через ssh — туда загоняется поток через pipe, а на удалённой стороне из pipe складывается в локальнный (для удалённого сервера-хранилища бэкапов) файл. Проверил даже скорость — в конкретной сети гиговый файл через SMB скопировался за 1 минуту 48 секунд, а то же самое, но через ssh — за 1 минуту 35 секунд. Профит налицо :-)

Запустил mcedit и начал ваять. Со скриптом бэкапа системы проблем не возникло:

# cat system_backup.sh
#!/bin/sh
backup_dir="/home/backup_operator/backups/os/buhserver-ttr"
keyfile="/home/gateway/service/keyfile.ppk"
username="backup_operator@backup-ttr"

DATE=`date +%Y.%m.%d`

dump -0 -L -u -C 32 -f — / | gzip -5 | ssh  -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_root.dump.gz"
dump -0 -L -u -C 32 -f — /usr | gzip -5 | ssh  -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_usr.dump.gz"
dump -0 -L -u -C 32 -f — /var | gzip -5 | ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_var.dump.gz"
dump -0 -L -u -C 32 -f — /home | gzip -5 | ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_home.dump."

keyfile — это private key для авторизации на удалённом сервере, backup_operator — имя пользователя на том сервере, а backup-ttr — имя самого сервера, где у нас бэкапы хранятся. Получается следующее — dump дампит раздел в stdout, откуда это перегоняется в gzip через pipe, откуда перегоняется вот в эту конструкцию:

ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_root.dump.gz" Т. е. мы подключаемся к серверу backup-ttr, и выполняем там команду "cat > {backup_dir}/${DATE}_root.dump.gz". Которая читает из stdin сжатый gzip'ом и прокинутый по сети поток и сохраняет его в файл {backup_dir}/${DATE}_root.dump.gz.". Которая читает из stdin сжатый gzip'ом и прокинутый по сети поток и сохраняет его в файл {backup_dir}/${DATE}_root.dump.gz.

В общем, тут всё просто. А вот с бэкапом почты пришлось повозиться. Было принято решение не просто каждый день сваливать полный бэкап почтовой базы и удалять старые копии, а сделать инкрементный бэкап. А для этого нужно производить определённые манипуляции на стороне хранилища бэкапов. Можно, конечно, сделать второй скрипт, и запускать его по крону на стороне хранилища. Но «Шурик, это же не наш метод!». Это придётся контролировать две точки выполнения одной операции — бэкапа почты, так как задействованы будут два скрипта, два крона, два компа и т. д.

Суть задачи такова. Допустим, у нас в день 1 выполняется полный бэкап почтовой базы. В день 2 — только то, что изменилось или добавилось со времени исполнения 1-го бэкапа, отработавшего в день 1. В день 3 — только изменения с момента бэкапа в день 2, и так далее до конца недели. Допустим, за первую неделю у нас сделано 7 архивов, с именами, соответственно, mail1.tgz, mail2.tgz, ... mail7.tgz. Где mail1.tgz — это полная копия базы, а остальные — дельты изменений. Неделя закончилась, надо как-то сделать ротацию бэкапов. То есть, куда-то деть эти 7 архивов. Можно их тупо удалить. Но как-то хочется, чтобы у нас хотя бы двухнедельная история бэкапов хранилась. Самое простое — эти архивы переименовать. Например, по схеме mail1.tgz.bak, mail2.tgz.bak и так далее. Тут-то и началось самое интересное.

Сначала решил сделать как-нибудь так:

for i in `ssh -q -i ${keyfile} ${username} "ls ${backup_dir}/*.gz"`
do
    ssh -q -i ${keyfile} ${username} "mv ${i} ${i}.bak"
done

Но это получается 1 вызов ssh для получения списка файлов, и потом ещё в цикле 7 раз запускается ssh, чтобы переименовать каждый отдельный файл. Касичок кагбэ, неоптимальненко.

Камрады в интернете посоветовали сделать как-нибудь так:

ssh -q user@remoteserver 'ls -f /path/*.tgz | while read f; do "$"» };done' Я попробовал, не прокатило. Полез искать точный синтаксис однострочного оформления циклов в shell. Нашёл несколько примеров, подставил, но ни один не прокатил. Я так понял, что приведённые примеры — в основном для линуксового bash, а у меня фрёвая /bin/sh, поэтому и не прокатывает. Потом нашёл обрывочные сведения, что циклы типа for, foreach, while — «is not single-line friendly». Но коллективный разум мне сурово возразил, что я не прав.

Копаясь дальше, я обнаружил, что реально, однострочные конструкции типа

ls | while read f;do echo ${f};done работают, будучи запущены в /bin/sh и локально. Но не работают удалённо. Потом до меня дошло, что локально-то я запустил /bin/sh, и в ней пускаю все эти конструкции. Но по дефолту у пользователя backup_operator оболочка прописана /bin/csh, и синтаксис там может отличаться.

Не вопрос, топаем на удалённый сервер и делаем там:

pw usermod backup_operator -s /bin/sh Меняем, иными словами, ему оболочку на sh вместо csh. После этого конструкция

ssh -i keyfile.ppk backup_operator@backup-ttr "ls /home/ | while read f; do echo ${f}; done;" просто обязана была заработать. Но не заработала... А написала, что f: Undefined variable.

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

The shell will expand variables in double-quotes, but not in single-quotes.

что если команду для удалённого исполнения заключать в двойные кавычки, то оболочка подставляет значение переменной вместо имени переменной. А в этой ситуации нужно, чтобы имя переменной передавалось как есть на дальнюю сторону, и значение вычислялось и использовалось уже там. Поэтому эту команду нужно заключать в ОДИНАРНЫЕ кавычки. То есть, вот так:

ssh -i keyfile.ppk backup_operator@backup-ttr 'ls /home/ | while read f; do echo ${f}; done;' Но есть и другой путь — просто ставить backslash перед символом переменной. То есть, можно сделать вот так:

ssh -i keyfile.ppk backup_operator@backup-ttr "ls /home/ | while read f; do echo \${f}; done;' Мне так пришлось сделать, потому что по итогу потребовалось, чтобы в одной команде были и локальные и удалённые переменные. Т. е. финальная рабочая конструкция выглядит вот так:

ssh -i keyfile.ppk backup_operator@backup-ttr "cd ${backup_dir}; ls ./ | while read f; do mv \${f} \${f}.bak; done"

SSH tips&tricks

at-hacker — Tue, 12 Nov 2013 19:24:00 GMT

Обнаружил тут ряд интересных статей про использование ssh и screen. Оказывается, SSH умеет сильно больше, чем я подозревал.

Про SSH:

http://habrahabr.ru/post/122445/

http://matt.might.net/articles/ssh-hacks/

Про screen:

http://rus-linux.net/kos.php?name=MyLDP/consol/screen.html

Бьётся файл при передаче по http

at-hacker — Tue, 23 Oct 2012 16:51:00 GMT

Мерял тут скорость внутри конторских VPN-каналов, путём передачи 100-мегабайтного файла по http, с Apache22 на FreeBSD. Обнаружил необъяснимое — при передаче файла на винду качается кусок файла случайного размера (от 2.5 до 18 мегабайт) и потом передача рвётся. Клиент считает, что файл скачан полностью, в логах апача никаких ошибок. При этом перед началом закачки размер файла определяется правильно.

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

[Thu Sep 27 12:31:48 2012] [info] [client 10.0.7.1] (12)Cannot allocate memory: core_output_filter: writing data to the network

Беглый поиск привёл на сайт Apache, где нашёлся такой текст:

*Invalid argument: core_output_filter: writing data to the network
Apache uses the sendfile syscall on platforms where it is available in order to speed sending of responses. Unfortunately, on some systems, Apache will detect the presence of sendfile at compile-time, even when it does not work properly. This happens most frequently when using network or other non-standard file-system.Apache uses the sendfile syscall on platforms where it is available in order to speed sending of responses. Unfortunately, on some systems, Apache will detect the presence of sendfile at compile-time, even when it does not work properly. This happens most frequently when using network or other non-standard file-system.

Symptoms of this problem include the above message in the error log and zero-length responses to non-zero-sized files. The problem generally occurs only for static files, since dynamic content usually does not make use of sendfile.Symptoms of this problem include the above message in the error log and zero-length responses to non-zero-sized files. The problem generally occurs only for static files, since dynamic content usually does not make use of sendfile.

To fix this problem, simply use the EnableSendfile directive to disable sendfile for all or part of your server. Also see the EnableMMAP, which can help with similar problems.To fix this problem, simply use the EnableSendfile directive to disable sendfile for all or part of your server. Also see the EnableMMAP, which can help with similar problems.*

Что в переводе означает, что Apache используется системный вызов sendfile на тех платформах, где он доступен, чтобы увеличить скорость ответа клиенту. К сожалению, на некоторых система апач определяет наличие этого вызова во время компиляции (т. е. сборки самого апача) даже если этот вызов в системе реально не работает надлежащим образом. Обычно это происходит при использовании сетевых или иных нестандартных файловых систем. Симптомы этой проблемы включают в себя вышеприведённый текст в логах и нулевой ответ на запрос файлов ненулевой длины. Проблема обычно возникает при передаче статических файлов, динамический контент не использует sendfile. Чтобы решить эту проблему, используйте директиву EnableSendfile, чтобы выключить использование вызова SendFile. Также почитайте про EnableMMAP, которая может помочь при сходных проблемах.

Выключил в итоге в конфиге апача EnableSendfile и EnableMMAP. Это помогло, но осадочек остался... Потому как файло лежит на обычном локальном разделе диска. Или UFS считается для апача недостаточно стандартной?

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

at-hacker — Fri, 13 Jan 2012 13:12:00 GMT

Локальное управление

В блоге Алексея Кибкало вычитал полезную штуку — как позволить простому смертному пользователю, не обладающему администраторскими правами, управлять 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% является скрытой, так что проще будет скопировать путь целиком). и открыть файл по указанному выше пути. (Папка %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. Нажмите 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.