April, 2011

Sandy Bridge и Advanced Vector Extensions (AVX).

С течением времени мы становимся свидетелями эволюции архитектуры микропроцессоров, а также системы их команд. Новые поколения процессоров приносят новые инструкции, изменение количества ядер, размера кэша. Раз в пару лет появляются существенные изменения, фундаментальные наборы инструкций. Последними примерами таких фундаментальных наборов являются SSE 4.1 и SSE 4.2. В своё время в заметке «Работа процессора в Hyper-V» я рассказывал о том, что такое функциональная спецификация гипервизора, и какие инструкции доступны хосту и виртуальным машинам. В феврале 2011 года Intel представил второе поколение процессоров Core iX, поколения Sandy Bridge. Кроме изменений с оптимизацией, частотами и производительностью, в Sandy Bridge появился новый фундаментальный набор инструкций Advanced Vector Extensions (AVX). Впервые предложенная разработчикам в 2008 году, идея AVX нашла свою реализацию в процессорах Intel лишь в начале 2011 года. Также, этот набор лицензирован компанией AMD, их появление планируется в процессорах Bulldozer. В текущих процессорах Xeon Westmere, вышедших даже позднее Sandy Bridge, этого набора нет. Ждём скорого обновления в линейке Xeon?

В операционной системе Windows Server 2008 и даже в Windows Server 2008 R2 поддержки этому набору инструкций нет. К сожалению, это означает, что гипервизор не понимает фундаментального набора инструкций и из соображений безопасности не запускает виртуальные машины. При попытке запуска вы получаете сообщение типа «An error occurred while attempting to start the selected virtual machine(s). <virtual machine name> could not initialize» и событие 3040 в Журнале Событий от Hyper-V-Worker в разделе Applications and Services Logs: «<virtual machine name> Failed to set/change partition property».

Поддержка набора инструкций AVX добавлена в Windows Server 2008 R2 Service Pack 1. Установив первый пакет обновлений, вы решите проблему на новых серверах. Если по каким-то причинам не можете установить Service Pack 1 (например, ваша система сертифицирована на оригинальную версию ОС), для вас доступно обновление 2517374. Обновление предназначено только для оригинальной версии Windows Server 2008 R2, оно уже включено в пакет обновлений.

Для Windows Server 2008 пока что не поступало запросов на поддержку Sandy Bridge. Видимо, мало кто из обладателей нового поколения Core i7 устанавливает серверную ОС Microsoft прошлого поколения для задач виртуализации. Если у вас как раз такой случай, и вы имеете контракт Премьер Поддержки, попробуйте обратиться, может быть соберут обновление и для Windows Server 2008.

После установки Service Pack 1 или обновления 2517374 набор инструкций AVX понятен гипервизору и даже транслируется виртуальным машинам. Внутри виртуальных машин также доступны эти инструкции. Очевидно, что если вы добавляете новые серверы с AVX в существующий кластер, вам будет необходимо помнить о работе режима совместимости процессора, нормализующем список инструкций, доступных для виртуальных машин.  Я подробно описывал этот режим в отдельной заметке и кое-что дополнял в статье  «Работа процессора в Hyper-V»

Sandy Bridge, Westmere и большие объёмы памяти.

Те, кто читали мою заметку об обновлениях, появляющихся после выхода Windows Server 2008 R2 Service Pack 1, помнят, что я описывал там обновление 2517329, которое исправляет ошибку работы с большими объёмами памяти на серверах с Sandy Bridge и Westmere. Так вот, обновление 2517329 кумулятивно по отношению к 2517374, и доступно к установке на Windows Server 2008 R2 без Service Pack 1. Его я рекомендую установить всем, кто имеет систему с Sandy Bridge или Westmere, вне зависимости от того, установили ли вы уже пакет обновлений или нет.

На днях на TechNet стала доступна в качественном формате видеозапись трёхдневного курса «Microsoft Virtualization for VMware Professionals». 15 часов технического тренинга, рассчитанного на людей которые в целом понимают, что такое виртуализация, знакомы с технологией конкурента, но пока что не работали с виртуализацией Microsoft. Это не маркетинговая драма, а технический курс. 13 модулей, каждый занимает около часа (модуль о внедрении и установке из-за объёма информации получился двойным) условно сегментированы на три части: «Платформа», «Управление» и «Виртуализация рабочих станций».

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

• Virtualization Jump Start (01): Virtualization Overview
• Virtualization Jump Start (02): Differentiating Microsoft & VMware
• Virtualization Jump Start (03a): Hyper-V Deployment Options & Architecture | Part 1
• Virtualization Jump Start (03b): Hyper-V Deployment Options & Architecture | Part 2
• Virtualization Jump Start (04): High-Availability & Clustering
• Virtualization Jump Start (05): System Center Suite Overview with focus on DPM
• Virtualization Jump Start (06): Automation with Opalis, Service Manager & PowerShell
• Virtualization Jump Start (07): System Center Virtual Machine Manager 2012
• Virtualization Jump Start (08): Private Cloud Solutions, Architecture & VMM Self-Service Portal 2.0
• Virtualization Jump Start (09): Virtual Desktop Infrastructure (VDI) Architecture | Part 1
• Virtualization Jump Start (10): Virtual Desktop Infrastructure (VDI) Architecture | Part 2
• Virtualization Jump Start (11): v-Alliance Solution Overview
• Virtualization Jump Start (12): Application Delivery for VDI

Прочитать краткую аннотацию к каждому из модулей можно на основной странице Jump Start курса.

Загрузить материалы курса в виде PDF можно с сайта Born to Learn. Если у вас мало времени на просмотр видео, просмотрите материалы. Уделите особое внимание модулям 6, 7 и 8. Даже я нашел в них для себя нечто новое.

В компонентах интеграции Hyper-V шина VMBus играет роль широкой магистрали, по которой как потоки автотранспорта снуют потоки пакетов от виртуальных машин к физическим устройствам. Как и в реальной жизни эта магистраль может быть довольно таки сильно занята, и возникают пробки. Если в обычной жизни стоянка в пробке – это удел автомобилистов, то в виртуализации сам сетевой пакет не может судить, сколько времени ему ожидать очереди на отправку. Для этого каждая виртуальная машина имеет буфер. Размер буфера по умолчанию – 1 Мб. Буфер вмещает в себя 655 пакетов (по 1600 байт каждый). В некоторых случаях, о которых мы сейчас поговорим, этого буфера бывает недостаточно. Виртуальная машина может начать терять пакеты, что сразу же сказывается на скорости работы сети. Забегая вперёд, скажу, что рекомендую увеличить размер буфера до 2 МБ, а в некоторых случаях и до 4 МБ (максимально поддерживаемый размер). Когда, как и для чего, – об этом мы сейчас и поговорим.

Гипервизор, обрабатывая запросы от виртуальных машин, делит всё своё время на интервалы – кванты, через которые он обращается к той или иной машине для обмена данными по шине VMBus. В зависимости от количества прерываний, генерируемых виртуальной машиной, и нагрузки на гипервизор, размер кванта (в теории) может достигать 10 миллисекунд. Это означает, что гипервизор раз в 10 мс будет обращаться к виртуальной машине, чтобы обслужить её очередь пакетов на VMBus. В реалии такой размер кванта возникает не часто, но мы исследуем худший сценарий. Что такое 10 миллисекунд для сервера? Физические серверы могут обслуживать до 260000 пакетов в секунду на 10Гбит интерфейсе. Для виртуальной машины при размере кванта в 10 мс за одну секунду происходит сто сеансов обслуживания. Это значит, что виртуальная машина может передать лишь 65500 пакетов с интерфейса (800 Мбит). Если виртуальная машина будет пытаться передать больше (и если по какой-то причине невысоко количество генерируемых прерываний, отвечающее за уменьшение размера кванта), то пакеты начнут теряться. Это вынудит машину пересылать их повторно, что скажется на скорости работы сети. Это не является ограничением драйверов или компонентов интеграции. Просто в данном редком случае значение размера буфера является недостаточным. Если мы увеличим его с 655 до 2600, то это будет соответствовать максимальным возможностям физического сервера и решит потенциальную проблему.

Увеличение размера буфера следует делать для каждой виртуальной машины. Под это будет выделяться реальная память сервера. Если вас не смущает выделение дополнительных пары мегабайт на каждую виртуальную машину из памяти сервера (увеличение буферов до 2МБ в 512 машинах потребует примерно 1ГБ памяти сервера), то смело вносите изменения во все машины, чтобы более не думать о буфере. Как же это сделать?

Размер буфера задаётся внутри виртуальной машины для каждого сетевого интерфейса. В ОС Windows каждый сетевой интерфейс имеет свой уникальный GUID. Увидеть GUID текущей сетевой карты можно в диспетчере устройств в свойствах драйвера сетевой карты:

В редакторе реестра на виртуальной машине следует найти ветвь HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{GUID}\{index} , соответствующую данному интерфейсу:

Внутри значения индекса следует создать два ключа типа DWORD: ReceiveBufferSize и SendBufferSize. Значения этих ключей считаются в килобайтах в шестнадцатеричном виде. 0x400 соответствует размеру буфера по умолчанию в 1МБ. Изменив значение на 0x800, вы зададите размер буфера в 2 МБ. Задав значение 0x1000, получите размер буфера 4МБ. На примере ниже задаются размеры обоих буферов по 2МБ:

Если вы хотите добиться изменения размера буфера в виртуальных машинах Linux, то перед компиляцией ядра с компонентами интеграции 2.1 вимательно посмотрите файл NETVSC.H, где явно задаются значения для NETVSC_SEND_BUFFER_SIZE и NETVSC_RECEIVE_BUFFER_SIZE. Помните, что внесение изменений в эти файлы вы делаете на свою ответственность. После внесения изменений требуется перекомпиляция ядра (или по крайней мере модулей Hyper-V). Если есть интерес к установке и настройке компонент интеграции под Linux, я могу написать статью на примере какого-нибудь неподдерживаемого дистрибутива, например, Debian. Очевидно, что с RedHat и SUSE всё проще – там компоненты интеграции сразу поставляются в комплекте.

Не ожидайте от этих изменений существенного увеличения производительности. В 99% случаев размер кванта существенно меньше 10 мс. Да и очередь пакетов на отправку не превышает 1МБ. Однако, для душевного спокойствия администраторов, для достижения стабильности и повышения доступности я бы рекомендовал увеличить размер буфера до 2 или даже до 4 мегабайт на всех промышленно используемых виртуальных машинах. Сами понимаете, что пара мегабайт памяти на одну машину не стоят ваших мыслей о том, как там работает буфер!

Я верю, что всем кто интересуется виртуализацией Hyper-V, интересна тема кластеризации для повышения доступности сервисов и виртуальных машин в частности. В то же время я часто вижу заказчиков, которые имеют какой-то подсознательный страх перед службой кластеризации, - наверное, после сложностей с кластерами на базе Windows 2000 Server или Windows Server 2003. К выходу Windows Server 2008 сама кластеризация стала существенно проще и стабильнее. Были сняты искусственные ограничения поддержки конфигураций, теперь достаточно лишь пройти мастер валидации на вашем сервере. С появлением Windows Server 2008 R2 публика воодушевлённо приняла технологию Cluster Shared Volumes, делающую возможным использование единого тома для хранения виртуальных машин, доступного одновременно на чтение и запись со всех узлов кластера.

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

Windows Server 2008 R2 Service Pack 1: Asymmetrical Storage

С выходом первого пакета обновления для Windows Server 2008 R2 и Hyper-V Server 2008 R2 у вас появилась возможность использовать общие дисковые массивы, которые доступны лишь некоторым узлам кластера. Ранее для того чтобы вы смогли добавить диск в кластер, он должен был быть доступен на чтение и запись на всех узлах кластера. Это вполне нормальное требование, если рассматривать кластер, узлы которого расположены на одной площадке. Что же делать в случае построения территориально распределённого кластера (термин «геокластер», часто используемый для этого понятия принадлежит некой компании, которая возражает против использования её трейдмарка в обозначении общей технологии)? Если я хочу помимо реплицируемого (дорогого) хранилища, доступного всем узлам, использовать в каждом сайте своё локальное хранилище для ресурсов, кластеризуемых исключительно в этом сайте? С выходом Service Pack 1 вы можете добавить в кластер общий диск, если он доступен хотя бы двум узлам кластера. Очевидно, что возможными владельцами этого диска, а также всех ресурсов, зависящих от этого диска, должны являться лишь узлы, имеющие прямой доступ к диску. Так что не удивляйтесь, если у вас, вдруг, получится добавить в кластер LUN, презентованный лишь некоторым узлам. Технологически ничего нового в этом нет. Просто для будущей версии SQL Server такая возможность кластера понадобилась, вот её и разрешили в консоли.

KB2494036: Возможность выбора, голосует ли узел за формирование большинства или нет

В кластерах Windows Server 2008 и Windows Server 2008 R2 важно понятие «большинства». «Большинство» формируется при наличии более половины узлов, которые могут общаться друг с другом. Ровно половина большинства не формирует. При чётном количестве узлов используется дополнительный голос – диск или сетевой ресурс. Рассмотрим сценарий территориально распределённого кластера: несколько узлов в основном датацентре, несколько в резервном. Очевидно, что если количество узлов не равное, то при проблемах с связью между двумя площадками, все узлы того ЦОД, где узлом меньше половины исключат себя из кластера, так как не будут иметь большинства голосов. Если количество узлов равное… то мы имеем по сути ту же ситуацию, - ни один из ЦОД не имеет большинства, при проблемах с сетью между площадками все узлы кластера остановят себя. Для такого сценария сейчас мы, как правило, используем некий сетевой ресурс, как дополнительный голос. В терминологии кластеризации этот голос называется witness. Disk witness или file share witness. В сценарии территориально распределённого кластера дисковый ресурс требует синхронной репликации, что, как правило, не осуществимо, а сетевой ресурс должен располагаться на некой третьей площадке. Большую гибкость, как раз, и даёт обновление 2494036. Что же оно приносит?

Параметр NodeWeight

После установки обновления 2494036 на сервер с Windows Server 2008 R2 Service Pack 1 или Windows Server 2008 Service Pack 2 в свойствах узлах кластера появляется новый параметр NodeWeight. Этот параметр может принимать значения 1 или 0. Значение 1 задаётся по умолчанию, и все узлы без этого обновления ведут себя, как будто, имеют NodeWeight = 1. Вы можете вручную для некого узла задать значение NodeWeight = 0 командой Cluster.exe . node <NodeName> /prop NodeWeight=0 или командой PowerShell: (Get-ClusterNode "NodeName").NodeWeight = 0

Посмотреть состояние NodeWeight для данного узла кластера можно командой PowerShell: Get-ClusterNode "NodeName" | fl *

Значение NodeWeight можно задавать и через WMI класс MSCluster_Node.

Ключ PreventQuorum (PQ)

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

Сценарии

Рассмотрим сценарий, когда это нововведение может быть полезным. Продолжим развивать идею нашего кластера на две площадки. Пусть мы имеем пять узлов в основном ЦОД и пять в резервном. Для традиционного кластера мне необходимо иметь сетевой ресурс на некой третьей площадке, который будет судить, какой из площадок иметь большинство, в случае проблемы со связью между ними. Допустим, один из ЦОД имеет доступ к этому сетевому ресурсу, он сформирует большинство, набрав 6 голосов из 11. Что произойдёт в случае перезагрузки любого из узлов в ЦОД? Верно! Останется лишь 5 узлов из 11, это не большинство, кластер остановит себя.

Очевидно, что я бы не хотел создавать резервный ЦОД, проблемы в котором могут уменьшить уровень доступности серверов в основном ЦОД. Теперь у нас есть вариант другого сценария. Вы можете для всех узлов резервного ЦОД указать параметр NodeWeight равным 0. При этом теперь вам не нужен сетевой ресурс на третьей площадке. Если резервный ЦОД будет недоступен, то это не повлияет на работу сервисов в основном ЦОД. Даже если один или два сервера в основном ЦОД будут недоступны при недоступности всего резервного ЦОД, кластер продолжит работы: ведь три узла из голосующих пяти формируют большинство!

Что делать, если основной ЦОД стал недоступен, например, в виду проблем с электропитанием? В резервном ЦОД у нас есть пять узлов, которые при недоступности основного ЦОД остановят себя. Один из узлов нужно запустить с ключом ForceQuorum. Этот ключ изначально есть в Windows Server 2008 R2, и появляется в Windows Server 2008 SP2 после установки обновления 2494036. Узел, запущенный с ForceQuorum сформирует большинство, остальные узлы присоединятся к нему, несмотря на то, что они на самом деле не имеют большинства голосов в кластере. Как теперь убедиться в стабильной работе кластера, и не бояться потери данных после нормализации работы основного ЦОД?

Если узлы основного ЦОД будут включаться, когда кластер в резервном ЦОД уже сформирован и доступен, они присоединятся к нему без проблем. Что делать, если электричество восстановлено, но пока нет связи, - в основном ЦОД мы имеем пять узлов, которые могут сформировать большинство пока кластер у нас работает в резервном ЦОД? Как предотвратить потерю данных? Узлы в основном ЦОД следует запустить с ключом PreventQuorum. Служба кластера на них стартует, но они не будут пробовать сформировать большинства, будут лишь готовы соединиться с рабочим кластером. В нашем случае, когда восстановится канал связи между площадками, они присоединятся к кластеру, образованному нами вручную в резервном ЦОД, и реплицируют на себя все изменения.

Обновление уже можно загрузить с сайта поддержки.

Надеюсь, я достаточно подробно описал два нововведения, и это добавит вам уверенности в работе с службой кластеризации в Windows Server 2008 R2 Service Pack 1.

С выходом первого пакета обновлений для Hyper-V R2 был немного расширен список поддерживаемых ОС. В список вошли новые ОС: Windows Home Server 2011, Windows Small Business Server 2011 и Windows Storage Server 2008 R2. Также была добавлена поддержка для Red Hat Enterprise Linux 5.6. Сейчас идёт активная работа с Red Hat по сертификации RHEL 6.0, о результатах я сообщу после официального анонса. Полностью список выглядит так:

Замечу, что когда в Microsoft речь идёт о «поддерживаемых» системах, заказчик может обратиться в службу поддержки Microsoft для решения проблемы с ОС. Например, при проблемах с установкой роли Active Directory в Windows Server, или при проблемах с Apache в SUSE Linux. Microsoft имеет соглашения со службами поддержки Red Hat и SUSE, и точка входа при обращении не будет меняться, - вас не будут переадресовывать на другого производителя. Именно поэтому нет поддержки CentOS, Fedora или Debian. Для данных ОС нет поддержки при установке на аппаратном сервере, команда поддержки отсутствует. Очевидно, что некие третьи конторы, производители гипервизоров, заявляют о поддержки таких ОС, или ОС типа OS/2, Windows NT4 или Windows 98. А также ОС, производитель которых заведомо не поддерживает любую стороннюю виртуализацию – например, Oracle Solaris. Понятно, что в таком случае при списке «поддерживаемых ОС» в несколько десятков элементов вся «поддержка» на деле означает «мы попробовали установить, и, вроде бы, обычно оно устанавливается. Если у вас будет проблема, мы вас перенаправим на производителя ОС, пускай разбираются они». Трезво и внимательно оценивайте списки поддерживаемых ОС, задавайте вопросы, как будет решаться инцидент при проблемах с той или иной ОС.

Отдельно обращу ваше внимание, - в рамках программы SVVP (Server Virtualization Validation Program) Microsoft сертифицирует конкретные версии сторонних гипервизоров на поддержку ОС Windows Server. Никакой речи о поддержке Windows XP или Windows 7 на сторонних гипервизорах в программе SVVP не идёт. То же самое касается и специализированных ОС: Home Server, Storage Server, HPC Server и Small Business Server. Они программой SVVP не покрываются и никак не поддерживаются на сторонних платформах виртуализации. За такую поддержку на стороннем гипервизоре вам придётся платить отдельно, заключая прямое соглашение о поддержке с Microsoft, или довольствоваться самостоятельной поддержкой со стороны производителя гипервизора.

Мы уже не раз говорили об iSCSI и даже рассматривали процесс установки и настройки Microsoft iSCSI Target. Только ранее для этого было необходимо покупать ОС Windows Storage Server, которая поставлялась лишь с OEM оборудованием. Теперь же все желающие могут загрузить iSCSI Target с сайта Microsoft.

Что же находится внутри скачиваемого файла iSCSITargetDLC.EXE?

Сам iSCSI Target поддерживается на ОС Windows Server 2008 R2 Standard/Enterprise/Datacenter, только полная инсталляция (не Server Core) может выступать таргетом. Наличие Service Pack 1 крайне рекомендуется.

Установить iSCSI Target на Windows Server 2003/2008 не удастся. Также не получится установить его на 32-битной версии Windows 7.

Таргет поддерживает кластеризацию: если у вас есть общее дисковое хранилище (DAS/NAS/SAN), презентованное двум или более серверам, вы можете создать высокодоступный iSCSI Target. Для подключения дисков можно использовать стандартный iSCSI Initiator, идущий в составе с ОС или сторонние решения. Нельзя подключать инициатором диски с самого себя (совмещать Taget и Initiator на одной ОС). Для задач виртуализации iSCSI – идеальное решение. Как для построения небольших кластеров с высокодоступными виртуальными машинами, так и для создания кластеров из виртуальных машин. Напомню, в отличии от VMware в виртуальных машинах Hyper-V поддерживается создание кластеров на базе iSCSI – без ограничений на количество узлов в кластере.

В комплекте с таргетом идут VSS Provider и VDS Provider. Тем кто еще не знает, что это такое рекомендую почитать первоисточник по ссылкам.

Более детально правила поддержки iSCSI Target изложены на соответствующей странице TechNet.

Прошу прощения у моих читателей, что исчез на месяц, - я перевёлся из Российского отделения Microsoft, а в связи, с переездом было немного не до блога. Исправлюсь!

За последний месяц произошло немало всяких анонсов, большинство которых тем или иным образом связаны с выходом первого пакета обновления для Windows Server 2008 R2 и Windows 7. Я уже писал о самом Service Pack 1 и о том, какие изменения он принёс для виртуализации. Загрузить пакет обновлений можно с сайта Microsoft. Для Windows Server 2008 R2 и для Hyper-V Server 2008 R2 требуется 64-битная версия пакета. Доступны как обновления для каждой из платформ по отдельности, так и единый образ диска 7601.17514.101119-1850_Update_Sp_Wave1-GRMSP1.1_DVD.iso включающий в себя пакет обновления для всех платформ и всех языков.

Отдельно можно загрузить и Windows Server 2008 с интегрированным пакетом обновления: общедоступна ознакомительная версия ОС, а для подписчиков MSDN/TechNet и корпоративных заказчиков, доступна полная версия.

На днях была выложена версия бесплатного Hyper-V Server 2008 R2 with Service Pack 1. Это самостоятельная ОС с ролью Hyper-V, поддержкой кластеризации виртуальных машин, динамической памяти и технологии RemoteFX. В своём цикле заметок про RemoteFX я уже упоминал, но напомню: RemoteFX есть в бесплатном Hyper-V Server 2008 R2 с Service Pack 1, но её нет в установках Windows Server 2008 R2 Core. Windows Server 2008 R2 требует установки полной версии ОС для поддержки RemoteFX. Также, RemoteFX невозможно совмещать с ролью контроллера домена.

Для управления серверами Hyper-V с персональных компьютеров под управлением Windows 7 требуется установка Remote Server Administration Tools. Для Windows 7 Service Pack 1 вышел обновлённый пакет RSAT. Загрузить пакет администрирования можно с сайта Microsoft. Пакет отличается для 32- и 64- битных версий ОС, является мульти язычным.

Задачу управления инфраструктурой виртуализации Microsoft решает System Center Virtual Machine Manager 2008 R2. Он также обновился. Вы можете загрузить VMM 2008 R2 SP1 с сайта Microsoft. Обратите внимание, это одновременно и ознакомительная версия, - для тех кто его устанавливает на новый сервер, и пакет обновления, - для тех кто устанавливает его поверх текущей инсталляции VMM 2008 R2. Если у вас стоит полная, не ознакомительная версия VMM 2008 R2, то этот пакет просто обновит её до версии SP1, принеся поддержку динамической памяти, RemoteFX, а также включая все кумулятивные обновления VMM, доступные ранее. Для подписчиков TechNet/MSDN и корпоративных заказчиков доступна к загрузке полная версия VMM. Для корректной работы VMM PRO с SP1 вам потребуется обновить ваш OpsMgr 2007 R2, установив кумулятивное обновление 4.

Порядок обновления VMM 2008 R2 до SP1:

• Установить Service Pack на сервер VMM 2008 R2
• Установить Service Pack на консоли администратора VMM
• Установить Cumulative Update 4 на OpsMgr 2007 R2
• Запустить мастер интеграции с OpsMgr с дистрибутива VMM 2008 R2 SP1 на сервере OpsMgr для обновления всех Management Packs.

На днях я расскажу об обновлениях, вышедших после сборки пакета обновления, и которые я бы рекомендовал к установке на ваши серверы виртуализации, а также о нововведениях в службе кластеризации, появившихся в SP1 и в обновлениях, вышедших после его выпуска.