среда, 30 декабря 2009 г.

Ограничения при управлении хостами ESX из SCVMM

Microsoft позиционирует System Center Virtual Machine Manager 2008 R2 как продукт для централизованного управления инфраструктурой виртуальных машин. Одной из особенностей SCVMM 2008 R2 является возможность работы с хостами VMware ESX. Однако, существует ряд ограничений, о которых должны знать администраторы перед тем, как решиться на подобную интеграцию.

1) Для управления хостами ESX/ESXi вам потребуется VMware vCenter. SCVMM не управляет хостами напрямую, а использует для этого функционал, схожий с тем, который vCenter предоставляет через Web Access.

2) SCVMM поддерживает ESX 3.0/ESXi 3.5 и выше, в том числе ESX/ESXi 4.0 U1, однако все новые функции vSphere - Fault Tolerance, Host Profiles, VMDirect Path, Distributed Switches, Thin Disks, vShield Zones не поддерживаются.

3) Через консоль SCVMM вы не можете создавать и настраивать Resource Pools и кластеры VMware HA и DRS, создавать и настраивать сетевые подключения для Service Console и VMKernel, изменять настройки DPM, настраивать iSCSI, Fibre Channel или NFS, добавлять, расширять и просматривать хранилища.

4) Перед использованием шаблонов машин VMware, вам потребуется импортировать их в библиотеку SCVMM. Customization Specification не поддерживается. Аналогично, для подключения ISO образов требуется также перенести их в библиотеку.

5) При создании новой виртуальной машины из SCVMM, она автоматически создается с Virtual Machine version 7; вы не можете указать/изменить тип сетевой карты и SCSI контроллера. Кроме того, требуется принудительно поменять тип подключения диска с IDE на SCSI, даже если вы используете ESX 4.0.

6) SCVMM имеет собственный журнал событий/операций, с помощью SCVMM вы не можете просматривать Alerts от ESX/vCenter и настраивать задания по расписанию.

7) При переводе хоста ESX в Maintenance Mode с помощью vCenter, в консоли SCVMM информация о состоянии хоста не изменится, однако, ни запустить, ни изменить свойства виртуальных машин вы не сможете.

8) Встроенный Physical Server Convert не позволяет делать P2V миграцию на узлы ESX.

9) Многие функции по управлению VI/vSphere реализуются через плагины к VIC/vSphere Client, поэтому консоль SCVMM их не поддерживает.

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

четверг, 17 декабря 2009 г.

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть II)

Сегодня продолжим наши эксперименты с Hyper-V из командной строки. В предыдущей части я рассказал о настройках на узле Hyper-V. На очереди самое интересное - создание кластера.


Настройка кластера
Для создания кластера введите:
cluster /cluster:<ИМЯ_КЛАСТЕРА> /create /node:<ИМЯ_УЗЛА> /ipaddress:<АДРЕС_КЛАСТЕРА>
, где <ИМЯ_КЛАСТЕРА> - имя, по которому можно будет обращаться к кластеру;
<ИМЯ_УЗЛА> - имя узла, входящего в кластер
<АДРЕС_КЛАСТЕРА> - IP адрес и маска подсети для кластера в полном или сокращенном формате (например 192.168.10.13/24 или 192.168.10.13/255.255.255.0)

Теперь можно полюбоваться на кластер, набрав:
cluster /list

и посмотреть список доступных ресурсов:
cluster res

Как видите в списке отсутствуют дисковые ресурсы, поэтому придется добавлять их вручную. При создании кластера Windows Server 2008 настраивает две группы для размещения ресурсов: Cluster Group и Available Storage. Увидеть доступные группы можно с помощью команды:
cluster group
По-умолчанию, все дисковые ресурсы размещаются в группе Available Storage. Исключение составляет только диск, предназначенный для кворума - он будет помещен в группу Cluster Group. Создадим новый дисковый ресурс:
cluster res "<ИМЯ_РЕСУРСА>" /create /group:"Cluster Group" /type:"Physical Disk"
, где <ИМЯ_РЕСУРСА> - произвольное имя
После создания дискового ресурса требуется сопоставить его с физическим диском. В Windows Server 2003 у ресурса physical disk был параметр Drive, соответствующей букве физического диска. В Windows Server 2008 синтаксис команды изменился, и теперь вместо Drive используется параметр DiskSignature. Для определения DiskSignature нам потребуется воспользоваться Diskpart.

После запуска Diskpart выберите нужный диск и выполните:
detail disk
В свойствах найдете нужный параметр Disk ID, представляющее собой шестнадцатиразрядное число. Для дальнейшего использования требуется перевести
это число в десятичный формат и затем выполнить команду, подставив в качестве значения параметра DiskSignature:
cluster res "<ИМЯ_РЕСУРСА>" /priv DiskSignature=<ID_ДИСКА>
Кстати о конвертировании - в Powershell есть встроенный преобразователь типов:
[Convert]::ToInt32("<16-РАЗРЯДНОЕ_ЧИСЛО>", 16)
Теперь переведем ресурс в активное состояние.
cluster res "<ИМЯ_РЕСУРСА>" /on
Проделаем аналогичные операции для второго диска:
Теперь требуется указать кластеру, где размещать кворум (в качестве примера, кластер будет работать в режиме Node and Disk Majority):
cluster /quorum:"<ИМЯ_РЕСУРСА>"
Настройка Cluster Shared Volume
Как и в случае с работой из GUI, перед преобразованием диска в CSV, вам потребуется включить поддержку CSV на кластере:
cluster /prop EnableSharedVolumes=1
Запустите Powershell. Добавьте модуль для поддержки работы с кластером:
Import-Module FailoverClusters
Добавление CSV выполняется командой:
Add-ClusterSharedVolume "<ИМЯ_РЕСУРСА>"
Добавление второго узла в кластер
Остались последние штрихи - добавить еще один узел в кластер Hyper-V. Все настройки на втором узле - конфигурация IP, ввод в домен, iSCSI Initiator выполняются аналогичным образом, поэтому я не буду заострять на них внимание.

Когда второй узел будет готов, добавьте его в кластер командой:
На этом настройка кластера завершена. Вам осталось развернуть или скопировать виртуальные машины и запустить их.

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

Материалы
При подготовке статьи использовались следующие материалы:
  1. Q. How can I change a Windows Server 2008 cluster quorum from the command line?

вторник, 8 декабря 2009 г.

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть I)

Готовясь к сертификации по Windows Server 2008, я решил более обстоятельно поработать с SCVMM 2008 R2 и Hyper-V R2. Среди прочих задач захотелось поднять двухузловой отказоустойчивый кластер. Вот только его настройка из оболочки sconfig и оснасток MMC показалась мне довольно тривиальной, поэтому решил выполнить аналогичные операции, используя только лишь командную строку.

Схему организации кластера выбрал самую простую:

Один контроллер домена (W2K8-DCS01), один сервер, выполняющий роль iSCSI Target (W2K8-STR01), два узла Hyper-V Server R2 (W2K8-HYP01 и W2K8-HYP02) с двумя сетевыми адаптерами: один - для доступа к узлам, работы с виртуальными машинами, а также подключения к iSCSI Target'ам, второй - для передачи heartbeat. Кворум предполагается размещать на одном LUN'е (Quorum), презентованном по iSCSI, раздел для хранения виртуальных машин - на втором (Storage).


Первоначальная настройка
Перед тем, как начать собирать кластер, потребуется выполнить настройку сети на сервере Hyper-V.

Закрываем неприглядное окно sconfig'а, на передний план выходит cmd.

Сначала включим несколько дополнительных компонентов (службы кластера, PowerShell и Framework для него):
dism /online /enable-feature /featurename:FailoverCluster-Core
dism /online /enable-feature /featurename:NetFx2-ServerCore
dism /online /enable-feature /featurename:MicrosoftWindowsPowerShell


Они понадобятся нам на более поздних этапах настройки.

Кстати, получить список доступных (активных/неактивных) компонентов можно с помощью команды:
dism /online /get-features


С помощью netsh настроим сетевые подключения. Сначала узнаем имена, которые система назначила сетевым адаптерам:
netsh interface show interface

В моем случае адаптер "Local Area Network" подключен к общей сети, адаптер "Local Area Network 3" к частной (heartbeat). Исходя из первоначального плана, назначаем адреса, маски, DNS, Default Gateway:
netsh interface ipv4 set address "Local Area Connection" static 192.168.10.11 255.255.255.0 192.168.10.254
netsh interface ipv4 set dnsserver "Local Area Connection" static 192.168.10.1 primary
netsh interface ipv4 set address "Local Area Connection 3" static 10.0.0.1 255.255.255.252


Без RDP может быть скучно, поэтому включим и его:
Cscript.exe "C:\Windows\System32\Scregedit.wsf" /AR 0

И разрешим подсоединятся старым RDP клиентам:
Cscript.exe "C:\Windows\System32\Scregedit.wsf" /CS 0

Хотя, мне больше нравится удаленно управлять сервером с помощью WinRM.

Перед присоединением сервера к домену, изменим его имя на что-то более благозвучное:
netdom renamecomputer %computername% /newname <НОВОЕ_ИМЯ_СЕРВЕРА>

Перезагрузим сервер:
shutdown -r -t 00

Добавим сервер в домен:
netdom join %computername% /domain:<ИМЯ_ДОМЕНА> /userd:<УЧЕТНАЯ_ЗАПИСЬ> /passwordd:<ПАРОЛЬ>

и снова перезагрузим сервер.

Подключение дисков
Перед созданием кластера нам понадобится настроить iSCSI Initiator чтобы получить доступ к презентованным дискам. Сделать это можно в несколько щелчков мыши, запустив графическую настройку iscsicpl.exe.

Однако, мы не ищем легких путей, поэтому будем настраивать все из командной строки. :)

По-умолчанию служба iSCSI Initiator выключена, поэтому для начала запустим ее:
net start msiscsi

А чтобы не повторять эту операцию каждый раз при загрузке сервера вручную настроим ее на автоматический старт:
sc config msiscsi start= auto

На очереди сама консольная утилита - iscsicli. С ее помощью и настроим iSCSI Initiator на узле. Подключимся к iSCSI Target серверу:
iscsicli qaddtargetportal <ИМЯ_СЕРВЕРА>
, где <ИМЯ_СЕРВЕРА> - имя или IP адрес iSCSI хранилища.

Посмотрим на список доступных целей:
iscsicli listtargets

Подключимся к обоим целям:
iscsicli qlogintarget <IQN>
, где <IQN> - IQN целей, к которым требуется подключиться

а также сделаем так, чтобы они автоматически подключались после перезагрузки сервера:
iscsicli persistentlogintarget <IQN> t * * * * * * * * * * * * * * * 0


Разбиение дисков
Теперь потребуется создать отформатировать разделы на подключенных дисках. Сделать это можно с помощью консольной утилиты Diskpart.

Запустим Diskpart и посмотрим на подключенные диски:
list disk
Выберем первый диск, создадим и отформатируем на нем раздел под кворум:
select disk 1
create partition primary
format fs=ntfs label="Quorum" quick


аналогичные операции выполним для второго диска под хранилище виртуальных машин:
select disk 2
create partition primary
format fs=ntfs label="Storage" quick


Заключение
На этом первая часть завершена. В следующий раз я опишу процесс настройки самого кластера и подключения второго узла. До встречи!

Материалы
При подготовке статьи использовались следующие материалы:
  1. Сделай сам: стенд с решениями для виртуализации — настройка узлов кластера для использования общего хранилища

вторник, 1 декабря 2009 г.

Домашний сервер All-In-1 в качестве тестового полигона

Сегодняшнее повествование будет несколько отличаться от привычных вам статей на VM Press. Не будет в нем примеров настройки или описания какой-либо технологии или продукта. Вместо этого я расскажу о своем домашнем виртуальном сервере.


Помню, как год назад был рад, когда, наконец, задушил свою жабу и собрал отдельный тестовый полигон. Потому как бы не был хорош мой настольный компьютер с VMware Workstation 6.5, но душа желала чего-то большого и производительного. Этим чем-то стал самосборный сервер:

  • четырехъядерный процессор Intel Core 2 Quad Q6600;
  • мат.плата Asus P5BV-E (с двумя гигабитными сетевыми адаптерами Broadcom BCM 5721 и интегрированным SATA контроллером ICH7R);
  • память 8 Gb DDR-II 800Mhz;
  • дискретный 8-канальный SATA/SAS Raid-контроллер Intel SRCSASRB с 256Mb кэш памяти;
  • три жестких диска SATA - WD 1001FALS 7200RPM 32Mb.
Все это было собрано в хорошем корпусе с качественным БП, довольно тихим куллером и вентиляторами.

Неплохая, как мне тогда показалась конфигурация, ибо раскошеливаться на S771 процессор/FBDIMM память/и соответствующую мат.плату было выше моих финансовых возможностей, радовала меня первые полгода. :)

На сервер был поставлен ESXi 3.5 U3. Подбирались комплектующие как раз исходя из требований совместимости (спасибо Tim'у Jacobs'у за его статью). Другие решения виртуализации я также рассматривал (VMware Server 2.0, Windows Server 2008 + Hyper-V/Hyper-V Server R1, Citrix Xen Server 5.0), но все они по тем или иным причинам не подошли. Решающими для меня стала поддержка Memory Overcommit и наиболее удобная, на мой взгляд, работа с шаблонами виртуальных машин через vCenter. На ESXi были подняты две служебные машины - Windows Server 2003 в качестве контроллера домена и сервера VMware vCenter 2.5 U3 и Windows Server 2008 - файловый сервер.

Сами виртуальные машины (служебные, а потом и тестовые) ютились на одном единственном 640Гб жестком диске. Три терабайтных жестких диска были объединены в массив RAID 5 силами Intel SRCSASRB, затем разбиты на два LUN'а по терабайту (условно для software и media) и проброшены внутрь ВМ при помощи RDM. Не то, чтобы я не доверял файловой системе VMFS, но при возникновении какой-либо внештатной ситуации мне хотелось быстро и просто получить доступ к моим данным. Да, и я очень удивился скорости записи контроллера на диски в режиме Write Through (~14 Mb/sec), так, что пару раз хотел заехать молотком по несчастной железке, благо, режим Write Back, оказалось, можно включить без батарейки (которая позже все же была куплена, во избежание). И еще эта диагностика контроллером всех дисков в случае простоя, которая вымораживала меня на протяжении двух недель, пока не удосужился прочитать инструкцию и отключить.

Кроме того, на виртуальном сервере был настроен NFS и для ESXi расшарена папка с ISO образами для подключения через консоль Infrastructure Client.

При такой организации, служебные виртуальные машины и сам ESXi отъедали 1.5-2Гб от оперативной памяти и совсем немного мегагерц от процессора, оставляя для экспериментов достаточные вычислительные ресурсы. Однако, как я уже сказал, доволен я был этим сервером полгода.

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

Во-вторых, примерно в это же время я начал задумываться о том, что с Windows Server 2003 в тестовой среде пора закругляться, и пора начинать плотнее общаться с 2008 сервером. И если Windows Server 2003 места на диске много не занимала и памяти виртуальным машинам можно было поменьше отводить, то с 2008 все было намного печальнее.

В-третьих, возник вопрос об удаленном доступе к серверу и виртуальным машинам. Долгое время я ограничивался простой публикацией RDP на одной из виртуальных машин с установленной консолью Infrastructure Client. Надо сказать, что работать так с виртуальными машинами - удовольствие сомнительное, консоль ощутимо притормаживала, что при открытии в RDP сессии, что при более изощренном доступе через TS Remote Apps, что при TS Gateway. Чуть позже начал использовать возможность подключения к виртуальной машине по протоколу VNC - даже внутри RDP сессии управление стало намного приятнее. Один недостаток - приходилось вручную править .vmx файл настроек и запоминать порты для подключения.

И все это происходило на фоне моей постоянной и неуемной страсти к покупке новых железок. Я всерьез начал прикидывать во что мне обойдется апгрейд на платформу Intel S1366 с Xeon E5520 и 16 Гб памяти. Останавливало меня от этого шага только отсутствие вменяемых корпусов, в которых бы разместилась полноразмерная серверная E-ATX плата. Короче, голос разума победил.

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

Поэтому в ожидании подарков от Деда Мороза решил обновиться до ESXi 4.0. 640 Гб диск был заменен на 1 Тб, а сам ESXi был установлен на flash накопитель (что чертовски удобно). Все виртуальные машины переставлены заново.

Из-за требований vCenter 4.0 не может быть установлен на контроллере домена. Поэтому пришлось установить его на Windows 2008 Server R2. И вот тут возникла одна неприятная особенность - при установке драйвера для виртуальной видеокарты из комплекта VMware Tools машина начинала периодически зависать. Поиск в Google быстро решил проблему.

А через несколько дней стал доступен Update 1, который позволил нормально создавать машины Windows Server 2008 R2 и Windows 7 из шаблона и подготавливать их с помощью Customization Specification. Надо ли говорить, что благодаря поддержке Thin Provisioning из GUI я смог легко уменьшить место занимаемое виртуальными машинами, не мучаясь теперь с командной строкой и ssh. Стоит отметить и негативную сторону данного события - я начал забывать параметры команды vmkfstools. :)

Что касается рациональности потраченных средств - я знаю, что можно было собрать сервер подешевле и с raid контроллером явно вышел перебор; с другой стороны, наверное, я достиг того возраста, когда меня интересуют такие вот игрушки.

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

среда, 18 ноября 2009 г.

Удаленная работа с виртуальными машинами ESX/ESXi

Иногда возникает необходимость предоставить пользователю доступ к виртуальной машине, расположенной на сервере ESX/ESXi. Хотя консоль VMware Infrastructure/vSphere Client и справляется с данной задачей, но является достаточно громоздкой. В качестве альтернативных методов выступают VNC и Remote Console.

Для включения VNC клиента, отредактируйте файл .vmx виртуальной машины, добавив туда следующие строчки:
remotedisplay.vnc.enabled=”true”
remotedisplay.vnc.password = “<ПАРОЛЬ>
remotedisplay.vnc.port=”<ПОРТ>

, где <ПАРОЛЬ> - любой подходящий пароль, <ПОРТ> - порт, используемый для подключения.


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

Теперь вы сможете подключаться с помощью VNC клиента (например, UltraVNC).


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

В качестве альтернативного варианта вы можете воспользоваться VMware Remote Console, входящей в состав VMware Player. Просто запустите из командной строки:
vmplayer -h <АДРЕС_ESX> <ПУТЬ_К_VMX>

Например так:
Обратите внимание на формат пути к .VMX файлу (после квадратных скобок должен быть пробел).

При подключении у вас запросят имя пользователя и пароль учетной записи ESX, у которой есть права на подключение:
 

Одно замечание - при попытке подключиться к ESXi 3.5 U4 с помощью Remote Console от Vmplayer 3.0, консоль закрывается без объяснения причин. В качестве решения, вы можете скачать модифицированную версию Remote Console от компании Minicom. С ESX 4.0 такой проблемы не наблюдается.

Update: если вы планируете подключаться с помощью Remote Console к ESX/ESXi версии 4.1 и выше, то вам требуется вручную создать на хосте учетную запись из-под которой производится подключение, так как доменная авторизация при интеграции с Active Directory не работает.

вторник, 10 ноября 2009 г.

Настройка WinRM на Windows Server 2008

Бывают случаи, когда требуется выполнить какую-либо команду на сервере локально (например, сконфигурировать iSCSI Initiator). Подключаться для этого через Remote Desktop и запускать cmd - неудобно, использовать Telnet - небезопасно, ставить на сервер демона ssh - не... хочется...

Специально для таких запущенных случаев, Microsoft, начиная с Windows Server 2003 R2, снабдила администраторов новым средством управления - Windows Remote Management (WinRM), позволяющим удаленно выполнять команды, используя стандартные средства ОС, и обеспечивая при этом должный уровень безопасности.

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


Настройка WinRM
В качестве примера я рассмотрю процесс настройки WinRM на Windows Server 2008. Эта процедура никак не отличается от настройки WinRM, например, на Windows Vista или Hyper-V Server.

Проще всего WinRM настроить можно, используя режим быстрой конфигурации, набрав в CMD:
winrm quickconfig
и ответив утвердительно ('y') на вопрос о создании нового объекта-listener'а, прослушающего порт TCP 80, и использующего протокол HTTP для коммуникаций между клиентом и сервером.

И все, сервером можно управлять удаленно, используя команду:
winrs -r:<ИМЯ_СЕРВЕРА> <КОМАНДА>
,где <ИМЯ_СЕРВЕРА> - имя или IP адрес сервера, к которому осуществляется подключение;
<КОМАНДА> - удаленная команда, которую требуется выполнить.

Если клиент и сервер не являются членами одного домена, вам потребуется дополнительно указать имя пользователя из-под которого будет запускаться команда и его пароль:
winrs -r:<ИМЯ_СЕРВЕРА> -u:<ИМЯ_ПОЛЬЗОВАТЕЛЯ> -p:<ПАРОЛЬ> <КОМАНДА>
, а заодно, как советует появившееся сообщение, добавить сервер в список доверенных узлов, либо использовать более надежный протокол для коммуникации (HTTPS).

Для добавления узла в список надежных, выполните на клиенте, с которого планируете подключаться:
winrm set winrm/config/client @{TrustedHosts="<ИМЯ_УЗЛА1>[,<ИМЯ_УЗЛА2>]"}

После настройки вы можете получить информацию о существующих listener'ах с помощью команды:
winrm enumerate winrm/config/listener

Удалить существующий listener можно следующим образом:
winrm delete winrm/config/listener?Address=*+Transport=HTTPS

Настройка WinRM с использованием HTTPS
В ряде случаев вам может потребоваться создать надежный канал для безопасной пересылки команд между клиентом и сервером. Для этого можно использовать HTTPS.

Однако, для создания listener'а с поддержкой HTTPS вам потребуется цифровой сертификат, который можно запросить у доверенного Центра Сертификации, либо воспользоваться различными утилитами по созданию самоподписанных (самозаверенных) сертификатов, например, Makecert, входящей в состав Windows SDK. Скачать Makecert отдельно можно отсюда.

Для создания самоподписанного серитификата выполните следующую команду:
makecert -a sha1 -r -pe -n "CN=<ИМЯ_СЕРВЕРА>" -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -m 12 <ФАЙЛ_СЕРТИФИКАТА>
, где <ИМЯ_СЕРВЕРА> соответствует имени, которое будет использовать клиент при подключении к серверу;
<ФАЙЛ_СЕРТИФИКАТА> - путь к файлу, куда будет сохранен сертификат с открытым ключем.

Сертификат с закрытым ключем будет создан и помещен в хранилище сертификатов локального компьютера. Добавьте его к доверенным корневым сертификатам:
certutil -addstore root cert.cer

Теперь просмотрите хранилище сертификатов, найдите там требуемый сертификат и запишите его Thumbprint (Cert Hash):
certutil -store my

Наконец, можно приступать к созданию HTTPS listener. Введите команду:
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<ИМЯ_УЗЛА>";CertificateThumbprint="<ХЭШ_СЕРТИФИКАТА>";Port="<ПОРТ>"}
,где <ИМЯ_УЗЛА> - имя, которое указывается при обращении к серверу
<ХЭШ_СЕРТИФИКАТА> - Thumbprint, который вы узнали на предыдущем шаге (без пробелов).
<ПОРТ> - порт, на который будет подключаться клиент (TCP 443 по-умолчанию).

Если на сервере включен брандмауэр Windows, не забудьте добавить правило:
netsh advfirewall firewall add rule name="allow WinRM on 4443" protocol=TCP dir=in localport=4443 action=allow

При использовании самоподписанных сертификатов, вам придется добавить его к доверенным корневым сертификатам на клиенте.

После выполнения всех шагов, вы, наконец, получите возможность удаленного выполнения команд:

Обратите внимание, что в случае использования нестандартного порта, вам потребуется специально его указать. Чтобы не делать этого каждый раз, вы можете изменить стандартный порт, который клиент использует при подключении по HTTPS, с помощью команды:
winrm set winrm/config/client/DefaultPorts @{HTTPS="4443"}

Заключение
Как видите, настройка Windows Remote Management достаточно проста в классических ситуациях (с использованием единого домена и CA), однако, при небольшом отклонении от данного шаблона могут обнаружиться несколько подводных камней. К WinRM привыкнуть можно достаточно быстро, особенно, если вы частенько пользуетесь консолью для настройки системы.

При подготовке статьи использовались следующие материалы:
  1. How to enable Windows Remote Shell
  2. Средство создания сертификатов (Makecert.exe)
  3. How to use makecert.exe to create a self-signed test certificate that can be used with IIS for SSL

четверг, 15 октября 2009 г.

Загрузка Microsoft Hyper-V Server R2 с flash накопителя

Многим специалистам в области виртуализации известно о возможности загрузки и работы гипервизора VMware ESXi напрямую с flash накопителя.

Незадолго до релиза Hyper-V Server R2, Microsoft заявила о предоставлении аналогичной возможности своим OEM партнерам. До этого момента все попытки создания чего-то подобного пресекались одним неприятным фактом - установщик просто не видел никаких устройств со сменными носителями на этапе выбора места установки ОС.

Что же поменялось с выходом R2?

Да практически ничего. Установщик все также слеп. Однако, Microsoft добавила поддержку виртуальных дисков (в формате .vhd) на которых можно создавать разделы и устанавливать ОС, как если бы это были отдельные физические диски. Единственное требование - наличие еще одного системного раздела на физическом накопителе с записанным туда загрузчиком (bootmgr), который бы мог монтировать витуальный диск и запускать ОС.

Суть метода заключается в первоначальной установки ОС на поддерживаемый носитель (физический и виртуальный диски) с последующим переносом всех необходимых файлов, загрузочных секторов и загрузчика на flash накопитель. Для тестовых целей я устанавливал Hyper-V, используя VMware Workstation 6.5, т.к. он умеет презентовать usb устройства с хоста виртуальной машине. В качестве объекта эксперимента выступала моя новая 16Гб флешка, хотя должно хватить и 8Гб.

Установка ОС на виртуальный диск
Загрузитесь с установочного диска Microsoft Hyper-V Server R2.

Выберите язык установщика и языковые настройки. Запустите командную консоль cmd.exe, нажав комбинацию клавиш Shift + F10, либо в окне Install now выбрав Repair computer -> use recovery tools... -> Command Prompt.

В командной консоли запустите Diskpart и создайте новый раздел на диске:
select disk <НОМЕР_ДИСКА>
create partition primary
select partition 1
assign
format fs=ntfs label="Boot Partition"

Номер диска можно посмотреть при помощи команды list disk. Также можете выполнить detail partition, чтобы узнать букву, присвоенную разделу.

Создайте виртуальный диск на новом разделе и смонтируйте его:
create vdisk file=<ПУТЬ_К_ФАЙЛУ> maximum=<РАЗМЕР_ДИСКА> type=fixed
select vdisk file=<ПУТЬ_К_ФАЙЛУ>
attach vdisk

Закройте командную консоль и продолжите установку Hyper-V. На экране выбора расположения ОС укажите созданный виртуальный диск. Установщик выведет предупреждение о том, что Windows не может быть установлена на данный диск. Можете его проигнорировать.
После завершения процесса установки загрузитесь в ОС и обновите/добавьте драйверы для устройств.

Если вы планируете использовать создаваемый образ для загрузки нескольких серверов или на сервере с другой аппаратной конфигурацией, то перед копированием выполните:
sysprep /generalize /shutdown

Sysprep при следующей загрузке системы (с флешки) выполнит генерацию нового SID компьютера, обновит список устройств, очистит журнал событий и удалит профили пользователей.

Копирование образа на flash накопитель
После выполнения Sysprep, загрузите систему с установочного диска Hyper-V Server R2 и зайдите в консоль.

Подключите flash накопитель. Запустите Diskpart.exe и при необходимости создайте и отформатируйте на флешке новый раздел:
select disk <НОМЕР_FLASH_НАКОПИТЕЛЯ>
clean
create partition primary
select partition 1
assign
format fs=ntfs label="Boot Flash"


Пометьте созданный раздел как активный:
active

Подмонтируйте виртуальный диск и назначьте ему букву.
select vdisk file=<ПУТЬ_К_ФАЙЛУ>
attach vdisk
assign


Выйдите из Diskpart. Запишите на flash накопитель загрузочный сектор:
bootsect /nt60 <БУКВА_FLASH_НАКОПИТЕЛЯ>

Скопируйте загрузчик с виртуального диска на флешку:
bcdboot <БУКВА_ВИРТУАЛЬНОГО_ДИСКА>\Windows /s <БУКВА_FLASH_НАКОПИТЕЛЯ>
Запустите Diskpart еще раз и отмонтируйте виртуальный диск
select vdisk file=<ПУТЬ_К_ФАЙЛУ>
detach vdisk


Скопируйте все содержимое физического диска на флешку (включая файл виртуального диска .vhd):
robocopy /copyall <БУКВА_РАЗДЕЛА_ДИСКА> <БУКВА_FLASH_НАКОПИТЕЛЯ>

Теперь можете выключить компьютер и вынуть из него жесткий диск. Зайдите в bios, и в качестве первичного загрузочного устройства выберите flash накопитель, а также проверьте, что включены Intel VT-x/AMD-V и DEP, затем перезагрузитесь, и вуаля!

Хочу отметить, что несмотря на низкую латентность flash накопителей, время загрузки гипервизора существенно увеличивается по сравнению с обычным (sata) жестким диском. Однако, если вас это не пугает, а также в наличии флешка с большой емкостью, можете и Windows 7/Windows Server 2008 R2 на нее установить.

Альтернативный вариант установки Hyper-V Server R2 с использованием утилит из Microsoft WAIK вы можете найти в данной статье.