Накопительный пакет обновления 7 для System Center 2012 R2 диспетчер виртуальных машин

Функции, добавленные в накопительный пакет обновления

• После установки Windows 10
  
  клиентской операционной системы можно подготовить и настроить Windows 10 клиентских Виртуальные машины (VM). Эта поддержка не включает установку диспетчер виртуальных машин консоли на Windows 10 клиентах операционной системы.
  
  

• После установки этого
  
  обновления можно подготовить и настроить Debian 8 Linux в качестве гостевой операционной системы.
  
  

• Поддержка сценариев управления VMWare vCenter 5.5
  
  с накопительным пакетом обновления 6. Мы объявили о поддержке базовых сценариев управления для vCenter 5.5. В соответствии с нашими планами интеграции и поддержки vCenter и VMM мы объявляем об более широкой матрице поддержки для управления экземплярами vCenter в консоли VMM.
  
  Полный список поддерживаемых сценариев см. здесь.
  
  

• Поддержка нескольких внешних IP-адресов
  
  на виртуальная сеть У теперь может иметь несколько внешних IP-адресов, назначенных одному виртуальная сеть если в среде VMM установлен накопительный пакет обновления 7 или более поздняя версия.
  
  Накопительный пакет обновления 7 включает возможность установки нескольких IP-адресов для NAT в VMM с помощью PowerShell. Это обновление позволяет повысить уровень стека благодаря поддержке VMM для администратора Структуры.
  
  Разделы справки использовать эту функцию?
  
  

  $natConnection = Add-SCNATConnection -Name "NAT_Connection1_NatConnection" -VMNetworkGateway $VmNetworkGateway -ExternalIPPool $externalIpPoolVar -ExternalIPAddress "30.30.30.50"
  
  $natConnection = Add-SCNATConnection -Name "NAT_Connection2_NatConnection" -VMNetworkGateway $VmNetworkGateway -ExternalIPPool $externalIpPoolVar -ExternalIPAddress "30.30.30.51"
  После подробного изучения всех частей в стеке, мы поняли, что для доставки эффективного и надежного решения требуется дополнительная работа и не помещается в один выпуск UR. Таким образом, мы дополируем возможность поэтапного задания нескольких IP-адресов на виртуальную сеть с помощью шлюза NAT HNV.
  
  Будущий накопительный пакет обновления для VMM будет изучать свойства через полный стек и предоставлять следующие функциональные возможности в Windows Azure Pack (WAP).
  
  

  • При добавлении нового правила NAT клиент теперь может использовать существующий внешний адрес или указать новый.

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

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

• 
  
  Возможность повторного связывания потерянных виртуальных машин с ролью службы или виртуальной машины. Если вам когда-либо приходилось удалять виртуальные машины с ролью службы или виртуальной машины, а вы хотите переназначить виртуальную машину с ее ролью службы или виртуальной машины после повторной передачи узла в VMM, у нас есть решение для вас в накопительном пакете обновления 7.
  
  Теперь вы можете повторно связать потерянную виртуальную машину с ее ролью службы или виртуальной машины после повторного вывода сервера узла в VMM.
  
  Дополнительные сведения см. здесь.
  
  

• Поддержка администраторов PXE-пересылки
  
  расширения DHCP VMM, которые зависят от PXE для настройки виртуальных машин или узлов, теперь может выполнять загрузку PXE, напрямую используя преимущества расширений DHCP VMM.

Проблемы, исправленные в этом накопительных пакетах обновлений

• В масштабе более 50 узлов служба VMM аварийно завершает работу или перестает периодически отвечать, не выдав при этом исключение.
  
  

• виртуализация сети Hyper-V (HNV) не отправляется на хост периодически. Это означает, что виртуальные машины, активные на этом узле, не смогут отправлять или получать сетевой трафик на другие виртуальные машины внутри или за пределами сети виртуальных машин.
  
  

• Если на узле много виртуальных коммутаторов (например, 15 или более), обновление узла занимает более часа.
  
  Теперь итеративные вызовы WSMan GET оптимизированы для повышения эффективности сети.
  
  

• Обновление виртуальной машины с несколькими сквозным дисками завершается сбоем при перезапуске узла. При перезапуске хост периодически переключает подключенные диски, а VMM иногда не обрабатывает изменение. Это приводит к ситуации, когда виртуальная машина становится непригоданной для использования.
  
  

• Сброс максимальной пропускной способности PortProfile до нуля на узле не отражается на виртуальных машинах. Это происходит потому, что значение по умолчанию для максимальной и минимальной пропускной способности виртуальной машины равно NULL. Это приводит к пропуску изменений.
  
  

• Для Self-Service отсутствуют имена заданий в области заданий. Команда SC-GetJob приводит к пустым именам.
  
  

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

• При попытке удалить пустое исходное облако через консоль VMM оно фактически не удаляется. В этом случае задание завершается. Однако облако по-прежнему отображается в консоли.
  
  

• При наличии службы в гостевом кластере в среде HNV внешний мир подключается к службе через сетевой шлюз виртуальной машины. Однако при отработке отказа гостевого кластера (например, отработка отказа IP-адреса ЦС) служба больше недоступна. Сообщение об ошибке регистрируется в журнале заданий VMM и указывает, что обновление политики сети на шлюзе завершилось сбоем.
  
  Это связано с тем, что записи подстановки обновляются на узле (на котором размещен гостевой кластер) при отработке отказа ЦС. Однако записи не обновляются на шлюзе. Таким образом, внутреннее взаимодействие в среде HNV работает, но внешнее взаимодействие со службой не отвечает.
  
  

• Неправильное строковое представление языкового стандарта ZH-HK (гонконгский китайский) в виде CHH (вместо ZHH) в пакете мониторинга VMM. В результате после импорта пакетов управления VMM в консоли языкового стандарта Operations Manager ZH-HK отображаются строки, отличные от языкового стандарта (английский).
  
  

• Не удается удалить виртуальную машину из экземпляра службы. При попытке удалить виртуальную машину вы получите следующее сообщение об ошибке:
  
  

  Remove-SCVirtualMachine: VMM не может удалить виртуальную машину, так как она находится в неподдерживаемом состоянии конфигурации кластера. (Идентификатор ошибки: 809, подробная ошибка:)
  
  Измените состояние виртуальной машины и повторите операцию.
  
  Чтобы перезапустить задание, Выполните следующую команду:
  PS> Restart-Job -Job (Get-VMMServer qpg3-vmm001 | Get-Job | where { $_.ID -eq "{04de37e5-d61a-4385-8860-2cac72d44d63}"})
  В строке :1 char:1
  + Remove-SCVirtualMachine -VM $T 01SQL0 -force
  + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  + CategoryInfo: ReadError: (:) [Remove-SCVirtualMachine], CarmineException
  + FullyQualifiedErrorId: 809,Microsoft.SystemCenter.VirtualMachineManager.Cmdlets.RemoveVMCmdlet

  
  
  

• При параллельной тестовой отработке отказа (TFO) VMM может возникнуть проблема с блокировкой в группе репликации (RG). В этом случае, если другая RG пытается установить блокировку, операция завершается сбоем.
  
  

• Дублирующиеся имена компьютеров создаются для виртуальных машин при использовании шаблона <##> шаблона виртуальной машины. В этом случае развертывание виртуальной машины завершается сбоем при создании виртуальной машины.
  
  

• Обновление поставщика хранилища завершается сбоем и создает исключение "Неправильный формат" в среде, отличной от английского, если поставщик управляет репликацией и поддерживает значения целевой точки восстановления (RPO). Поставщик хранилища не может быть обновлен. Это предотвращает управление поставщиком.
  
  

• Консоль VMM аварийно завершает работу случайным образом и возвращает System.NullReferenceException. Предыдущее решение было перезапустить VMM.
  
  

• Вы не можете выполнять динамическую оптимизацию (DO) на виртуальной машине кластера, защищенной с помощью Azure Site Recovery (ASR). Это влияет на балансировку нагрузки кластера.
  
  Кроме того, при вызове DO появляется следующее сообщение об ошибке:
  
  
  
  Эта проблема возникает, если любая виртуальная машина защищена с помощью ASR, так как на виртуальной машине задано несколько облачных атрибутов (например, RPO и облако). Но узлы в этом облаке не получают атрибуты, связанные с облаком. Во время do при переносе основной виртуальной машины требования к размещению облачных атрибутов на узлах отсутствуют, и так как необходимые атрибуты отсутствуют, она не находит подходящего узла.
  
  

• Динамическая оптимизация (DO) не игнорирует остановленные реплики виртуальных машин в облаке восстановления, пока вычисляет ограничения емкости для новых виртуальных машин. Если на узле остановлены виртуальные машины-реплики, do не перемещает дополнительные виртуальные машины на этот узл. Это может повлиять на балансировку нагрузки кластера.
  
  Эта проблема возникает из-за того, что раздел реестра IgnoreMemoryForStoppedReplicaVM используется для размещения дополнительных виртуальных машин, если на любом узле есть реплики виртуальных машин в остановленном состоянии. Сценарии DO не учитывают этот флаг.
  
  

• Узел кластера нельзя перевести в режим обслуживания, если он содержит виртуальные машины, защищенные с помощью ASR. В этом случае вы получите следующее сообщение об ошибке.
  
  
  
  

• Следующее предупреждение отображается VMM при динамической миграции виртуальной машины, защищенной с помощью ASR, в кластере.
  
  
  
  хотя эта проверка является лишь обратимым блоком и не блокирует фактический сценарий миграции, узлу по-прежнему назначается нулевая оценка по размещению. Это блокирует операцию динамической оптимизации (DO) и в конечном итоге предотвращает динамическую миграцию виртуальной машины.
  
  

• Параметр включения магистральной виртуальной ЛС в качестве типа сети в сетевой службе VMM недоступен. Если пометить тип сети как виртуальную ЛС, VMM перезапишет параметр магистральной виртуальной ЛС, который был установлен вне диапазона.

Усовершенствования процесса установки исправлений

• Перед накопительным пакетом обновления 7 при установке накопительного пакета обновления виртуальной машины консоль VMM периодически отображает следующее сообщение об ошибке:
  
  

  Не удалось обновить конвейер надстроек с управляемым кодом из-за следующей ошибки:
  
  требуемая папка "C:\Program Files\Microsoft System Center 2012\диспетчер виртуальных машин\bin\AddInPipeline\HostSideAdapters" не существует.

  
  

• Удаление накопительного пакета обновления 5 не приводит к возврату следующего двоичного файла к предыдущей версии:
  
  

  Microsoft.SystemCenter.VirtualMachineManager.resources.dll
  
  

• При установке более ранних накопительных пакетов обновления в режиме без повышенных привилегий значение реестра IndigoTCPport сбрасывается. Для этого пользователи должны вручную изменить значение на 8100. Кроме того, вы получите следующее сообщение об ошибке:
  
  

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Administrator Console\Settings\IndigoTCPport неправильное значение

Как получить и установить накопительный пакет обновления 7 для System Center 2012 R2 диспетчер виртуальных машин