Зведене оновлення 7 для System Center 2012 R2 Virtual Machine Manager

Функції, додані в цьому зведеному оновленні

• Підтримка операційної системи
  
  клієнта Windows 10 Після інсталяції цього оновлення можна підготувати та настроїти віртуальні машини клієнта Windows 10. Ця підтримка не включає інсталяцію консолі Диспетчера віртуальних машин на клієнтах операційної системи Windows 10.
  
  

• Підтримка нових операційних систем
  
  Linux Після інсталяції цього оновлення ви можете підготувати та налаштувати 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 = $natConnection Add-SCNATConnection -Name "NAT_Connection2_NatConnection" -VMNetworkGateway $VmNetworkGateway -ExternalIPPool $externalIpPoolVar -ExternalIPAddress "30.30.30.51"
  Вивчивши глибоко всі частини стосу, ми зрозуміли, що доставка ефективного та надійного рішення потребує додаткової роботи та не вписується в один випуск UR. Таким чином, ми забезпечуємо можливість установлювати кілька IP-адрес для кожної віртуальної мережі за допомогою шлюзу HNV NAT поетапно.
  
  У майбутньому зведене оновлення для VMM вивчить властивості через повний стек і забезпечить наведені нижче функції до кінця Windows Azure Pack (WAP).
  
  

  • Коли ви додаєте нове правило NAT, клієнт тепер може використовувати наявну зовнішню адресу або вказувати нову.

  • Адміністратор WAP може встановити квоти для зовнішніх IP-адрес, які ввімкнуто для кожної ролі користувача в хмарі.

  Ми розуміємо, що навколо цієї функції є великий попит на основі обсягу відгуків клієнтів, які ми отримали. Ми плануємо забезпечити підтримку цієї функції.

• Можливість повторно пов'язати загублені віртуальні машини з роллю
  
  служби або віртуальної машини Якщо вам коли-небудь доводилося видаляти хост, на яких розміщено віртуальні машини з роллю служби або віртуальної машини, і ви хотіли б помахати чарівною паличкою, щоб повторно пов'язати віртуальну машину зі своєю службою або роллю ВМ після того, як хост буде переміщено до VMM, у нас є рішення для вас у зведеному оновленні 7.
  
  Тепер ви можете повторно пов'язати загублену віртуальну машину зі службою або роллю віртуальної машини після того, як хост-сервер буде реактивовано до VMM.
  
  Щоб отримати додаткові відомості, клацніть тут.
  
  

• Підтримка для адміністраторів переспрямування
  
  VMM DHCP PXE/TFP, які залежать від PXE для налаштування віртуальних машин або хостів, тепер можуть виконувати завантаження PXE, безпосередньо скориставшись розширеннями VMM DHCP.

Проблеми, які усуваються в цьому зведеному оновленні

• У масштабі більше 50 хостів служба VMM аварійно завершує роботу або періодично припиняє реагувати, не кидаючи виняток, придатний для використання.
  
  

• Розподіл політики віртуалізації мережі Hyper-V (HNV) періодично не надсилається на хост. Це полягає в тому, що віртуальні машини, активні на цьому хості, не зможуть надсилати або отримувати мережевий трафік до інших віртуальних машин у мережі віртуальних машин або за її межами.
  
  

• Якщо хост має багато віртуальних перемикачів (наприклад, 15 або більше), оновлення хоста займає більше години.
  
  Ітераційні виклики WSMan GET тепер оптимізовано для підвищення ефективності мережі.
  
  

• Не вдається оновити віртуальну машину віртуальної машини, яка має кілька наскрізних дисків під час перезавантаження хоста. Під час перезавантаження хост перемикає підключені диски періодично, а VMM іноді не обробляє зміни. Це призводить до ситуації, коли віртуальна машина стає непридатним для використання.
  
  

• Скидання максимальної смуги пропускання PortProfile до нуля на хості не відображається на віртуальних машинах. Це відбувається тому, що значення за промовчанням максимальної та мінімальної смуги пропускання на віртуальній машині має null-значення. Це призводить до пропуску змін.
  
  

• Для користувача Self-Service відсутні імена завдань в області Завдання. Команда SC-GetJob призводить до пустих імен.
  
  

• Масштабування служби не дає змогу повторно використовувати ім'я віртуальної машини. Якщо масштабувати службу, розгорнуту на хості, якщо скасувати роботу майстра, а потім повторити ті самі кроки, а не виконати їх на завершальній стадії майстра масштабування, майстер не дає змогу повторно використовувати те саме ім'я комп'ютера.
  
  

• Якщо ви намагаєтеся видалити пусту вихідну хмару через консоль VMM, це фактично не видаляє хмару. У цій ситуації завдання завершується. Однак хмара все ще відображається на консолі.
  
  

• Коли є служба в гостьовому кластері в середовищі HNV, зовнішній світ підключається до служби через віртуальну машину мережевого шлюзу. Однак, коли гостьовий кластер відновлення після відмови відбувається (наприклад, CA IP відновлення після відмови), служба більше не доступна. Повідомлення про помилку реєструється в журналі завдань VMM і вказує, що не вдалося оновити мережеву політику шлюзу.
  
  Це пов'язано з тим, що записи підстановки оновлюються на хості (на якому розміщено гостьовий кластер), коли відбувається відновлення після відмови центру сертифікації. Однак записи не оновлюються в шлюзі. Тому внутрішня комунікація в середовищі HNV працює, але зовнішній зв'язок зі службою не відповідає.
  
  

• Неправильне представлення рядка мови ZH-HK мови (Гонконґська китайська) як CHH (замість ZHH) у VMM Monitoring Pack. Це призводить до відображення не локалізації (англійська) рядків у консолі локалізації Operations Manager ZH-HK після імпорту VMM management Packs.
  
  

• Не вдалося видалити віртуальну машину з екземпляра служби. Під час спроби видалити віртуальну машину, з'являється таке повідомлення про помилку:
  
  

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

  
  
  

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

• Повторювані імена комп'ютерів створюються для віртуальних машин під час використання шаблону <name###> у шаблоні віртуальної машини. У цьому випадку віртуальної машини розгортання не під вільний час створення віртуальної машини.
  
  

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

• Консоль VMM аварійно завершує роботу випадковим чином і повертає System.NullReferenceException. Попереднє зниження ризику полягало в перезапуску VMM.
  
  

• Не можна виконати динамічну оптимізацію (DO) на віртуальній машині кластера, захищеній за допомогою Azure Site Recovery (ASR). Це впливає на розподілення навантаження кластера.
  
  Крім того, під час виклику DO з'являється таке повідомлення про помилку:
  
  
  
  Ця проблема виникає, якщо будь-яка віртуальна машина захищена за допомогою ASR, оскільки на віртуальній машині настроєно кілька атрибутів хмари (наприклад, RPO та хмара). Але хости в цій хмарі не отримують жодних атрибутів, пов'язаних із хмарою. Під час DO під час перенесення основної віртуальної машини вимоги до розміщення для атрибутів хмари на хостах, а також тому, що необхідні атрибути відсутні, він не може знайти відповідний хост.
  
  

• Динамічна оптимізація (DO) не ігнорує зупинені віртуальні машини реплік у хмарі відновлення, поки вона обчислює обмеження ємності для нових віртуальних машин. Якщо на хості зупинено репліки віртуальних машин, DO не переміщує додаткові віртуальні машини на хост. Це може вплинути на розподілення навантаження кластера.
  
  Ця проблема виникає тому, що розділ реєстру IgnoreMemoryForStoppedReplicaVM використовується для розміщення більшої кількості віртуальних машин, якщо будь-який хост має репліки віртуальних машин у зупиненому стані. DO сценарії не шанують цю позначку.
  
  

• Вузол кластера не можна перемістити в режим обслуговування, якщо він має будь-які віртуальні машини, захищені за допомогою ASR. У цій ситуації з'являється таке повідомлення про помилку.
  
  
  
  

• Наведене нижче попередження відображається VMM, коли віртуальна машина, захищена за допомогою ASR, переносяться в кластері в реальному часі.
  
  
  
  Хоча ця перевірка є лише м'яким блоком і не блокує фактичний сценарій перенесення, хосту все ще призначається нульова оцінка за розміщенням. Це блокує операцію динамічної оптимізації (DO) і в кінцевому підсумку запобігає динамічному переносити віртуальну машину.
  
  

• Параметр увімкнення каналу VLAN як мережевого типу в мережевій службі VMM недоступний. Якщо ви позначите тип мережі як VLAN, це призводить до того, що VMM перезапише параметр Trunk VLAN, який було налаштовано поза смугами.

Удосконалення процесу виправлення

• До зведеного оновлення 7, під час інсталяції VM оновлення зведення, консоль VMM періодично відображає таке повідомлення про помилку:
  
  

  Не вдалося оновити керований канал надбудов коду через таку помилку:
  
  потрібна папка "C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\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 Virtual Machine Manager