Set de actualizări 7 pentru System Center 2012 R2 Virtual Machine Manager

Caracteristici adăugate în acest set de actualizări

• Asistență pentru sistemul
  
  de operare client Windows 10 După ce instalați această actualizare, puteți să furnizați și să particularizați Windows 10 client Mașini virtuale (VMs). Acest suport nu include instalarea consolei Virtual Machine Manager pe clienții sistemului de operare Windows 10.
  
  

• Suport pentru noi sisteme
  
  de operare Linux După ce instalați această actualizare, puteți să furnizați și să particularizați Debian 8 Linux ca sistem de operare Invitat.
  
  

• Suport pentru scenariile
  
  de gestionare VMWare vCenter 5.5 Cu setul de actualizări 6, am anunțat suport pentru scenariile de gestionare de bază pentru vCenter 5.5. Pe baza planurilor noastre pentru integrarea și suportabilitatea vCenter și VMM, anunțăm o matrice de suport mai largă pentru a gestiona instanțele vCenter în consola VMM.
  
  Pentru o listă completă de scenarii acceptate, faceți clic aici.
  
  

• Suport pentru mai multe adrese IP externe per Rețea virtuală
  
  Acum puteți avea mai multe adrese IP externe atribuite unui singur Rețea virtuală dacă aveți setul de actualizări 7 sau o versiune mai recentă instalată în mediul dvs. VMM.
  
  Setul de actualizări 7 include capacitatea de a seta mai multe adrese IP pentru NAT în VMM utilizând PowerShell. Această actualizare ridică capacitatea la un nivel mai mare în stivă, având suport în VMM pentru Administrator Fabric.
  
  Cum utilizez această funcționalitate?
  
  

  $natConnection = Add-SCNATConnection - numele "NAT_Connection1_NatConnection" -VMNetworkGateway $VmNetworkGateway -ExternalIPPool $externalIpPoolVar -ExternalIPAddress "30.30.30.50"
  
  $natConnection = Add-SCNATConnection NAT_Connection1_NatConnection -Name "NAT_Connection2_NatConnection" -VMNetworkGateway $VmNetworkGateway -ExternalIPPool $externalIpPoolVar -ExternalIPAddress "30.30.30.51"
  După examinarea profundă a tuturor pieselor din stivă, ne-am dat seama că livrarea unei soluții eficiente și fiabile necesită nu se încadrează într-o singură eliberare UR. Prin urmare, oferim capacitatea de a seta mai multe adrese IP pentru fiecare rețea virtuală, utilizând un gateway NAT HNV într-o manieră pe etape.
  
  Un set viitor de actualizări pentru VMM va explora proprietățile prin stiva completă și va furniza următoarele funcționalități până Windows Azure Pack (WAP).
  
  

  • Atunci când adăugați o regulă NAT nouă, o entitate găzduită poate acum să utilizeze o adresă externă existentă sau să specifice una nouă.

  • Puteți permite administratorului WAP să seteze cote pentru adresele IP externe care sunt activate pentru fiecare rol de utilizator din cloud.

  Înțelegem că există o cerere foarte mare în jurul acestei caracteristici, pe baza volumului de feedback de la clienți pe care l-am primit. Avem în plan să oferim asistență end-to-end pentru această caracteristică.

• Opțiunea de a reasocia mașinile virtuale orfane la rolul
  
  de serviciu sau VM Dacă a trebuit vreodată să eliminați o gazdă care a găzduit mașini virtuale cu rol de serviciu sau VM și ați dorit să fluturați o baghetă magică pentru a reasocia o mașină virtuală la serviciul său sau la rolul VM după ce gazda este recommisă la VMM, avem soluția pentru dvs. în setul de actualizări 7.
  
  Acum puteți reasocia o mașină virtuală orfană la serviciul său sau la rolul VM după ce serverul gazdă este recommis la VMM.
  
  Pentru mai multe informații, faceți clic aici.
  
  

• Asistența pentru administratorii de redirecționare
  
  VMM DHCP extensie PXE/TFP care depind de PXE pentru a configura mașini virtuale sau gazde pot efectua acum o bootare PXE, profitând direct de extensiile VMM DHCP.

Probleme care sunt remediate în acest set de actualizări

• La o scară mai mare de 50 de gazde, serviciul VMM se defectează sau nu mai răspunde intermitent, fără a genera o excepție utilizabilă.
  
  

• Distribuția politicii hyper-V Network Virtualization (HNV) nu este trimisă intermitent unei gazde. Efectul este că mașinile virtuale active în acea gazdă nu vor putea să trimită sau să primească trafic de rețea către alte mașini virtuale din interiorul sau din afara rețelei VM.
  
  

• Atunci când o gazdă are mai multe argumente virtuale (de exemplu, 15 sau mai multe), finalizarea reîmprospătării gazdei durează mai mult de o oră.
  
  Apelurile Iterative WSMan GET au fost optimizate acum pentru a oferi o eficiență mai bună a rețelei.
  
  

• VM Reîmprospătarea unei mașini virtuale care are mai multe discuri directe nu reușește la o repornire a gazdei. La repornire, gazda interschimbează intermitent discurile atașate, iar VMM uneori nu gestionează modificarea. Acest lucru cauzează o situație în care mașina virtuală devine inutilizabilă.
  
  

• Resetarea lățimii de bandă maxime PortProfile la zero în gazdă nu se reflectă în mașinile virtuale. Acest lucru se întâmplă deoarece valoarea implicită a lățimii de bandă maxime și minime dintr-o mașină virtuală este nulă. Acest lucru face ca modificările să fie ignorate.
  
  

• Pentru un utilizator Self-Service, numele lucrărilor din panoul Lucrări lipsesc. Comanda SC-GetJob are ca rezultat nume goale.
  
  

• Scalarea unui serviciu nu vă permite să reutilizați numele mașinii virtuale. Când scalați un serviciu implementat pe gazdă, dacă anulați expertul și reîncercați aceiași pași din nou în loc să comiteți în ultima etapă a expertului scalare, expertul nu vă permite să reutilizați același nume de computer.
  
  

• Dacă încercați să eliminați un nor sursă gol prin consola VMM, acest lucru nu șterge de fapt mediul cloud. În această situație, locul de muncă se termină. Cu toate acestea, mediul cloud este încă vizibil în consolă.
  
  

• Atunci când există un serviciu pe un cluster de invitați într-un mediu HNV, lumea externă se conectează la serviciu printr-un VM Network Gateway. Cu toate acestea, atunci când are loc o nereușită a clusterului invitat (cum ar fi o reluare în caz de nereușită CA IP), serviciul nu mai este accesibil. Un mesaj de eroare este înregistrat în istoricul activităților VMM și afirmă că actualizarea la politica de rețea din Gateway nu a reușit.
  
  Acest lucru se întâmplă deoarece înregistrările de căutare sunt actualizate în gazdă (pe care este găzduit clusterul de invitat) atunci când are loc o reluare ca în caz de nereușită. Totuși, înregistrările nu sunt actualizate în gateway. Prin urmare, comunicarea internă în cadrul mediului HNV funcționează, dar comunicarea externă la serviciu nu răspunde.
  
  

• Reprezentare incorectă a șirului de setări regionale ZH-HK (chineză Hong Kong) ca CHH (în loc de ZHH) în pachetul de monitorizare VMM. Acest lucru determină afișarea șirurilor care nu sunt locale (în limba engleză) în consola regională Operations Manager ZH-HK după importul pachetelor de gestionare VMM.
  
  

• Imposibil de eliminat mașina virtuală din instanța serviciului. Atunci când încercați să eliminați mașina virtuală, primiți următorul mesaj de eroare:
  
  

  Remove-SCVirtualMachine: VMM nu poate elimina mașina virtuală, deoarece se află în starea De configurare cluster neacceptată. (ID eroare: 809, Eroare detaliată:)
  
  Modificați starea mașinii virtuale, apoi încercați din nou operațiunea.
  
  Pentru a reporni activitatea, rulați următoarea comandă:
  PS> Restart-Job -Job (Get-VMMServer qpg3-vmm001 | Get-Job | unde { $_.ID -eq "{04de37e5-d61a-4385-8860-2cac72d44d63}"})
  La linia:1 char:1
  + Remove-SCVirtualMachine -VM $T 01SQL0 -force
  + ~~~~~~~~~~~~~~~~~
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CategoryInfo : ReadError: (:) [Remove-SCVirtualMachine], CarmineException
  + FullyQualifiedErrorId: 809,Microsoft.SystemCenter.VirtualMachineManager.Cmdlets.RemoveVMCmdlet

  
  
  

• Atunci când rulează reluarea în caz de nereușită a testului paralel (TFO), VMM poate întâmpina probleme de blocare pe Grupul de replicare (RG). În această situație, dacă un alt RG încearcă să pună un lacăt, operațiunea nu reușește.
  
  

• Numele de computer dublate sunt create pentru mașinile virtuale atunci când utilizați modelul de nume <###> într-un șablon VM. În acest caz, implementarea mașinii virtuale nu reușește atunci când creați o mașină virtuală.
  
  

• Reîmprospătarea furnizorului de stocare nu reușește și generează o excepție "Format incorect" într-un mediu care nu este în limba engleză dacă furnizorul gestionează replicarea și furnizorul acceptă valorile obiective ale punctelor de recuperare (RPO). Imposibil de reîmprospătat furnizorul de stocare. Acest lucru împiedică gestionarea furnizorului.
  
  

• Consola VMM se blochează aleator și returnează System.NullReferenceException. Atenuarea anterioară a fost repornirea VMM.
  
  

• Nu puteți efectua Optimizare dinamică (DO) pe o mașină virtuală de cluster care este protejată utilizând Azure Site Recovery (ASR). Acest lucru afectează echilibrarea încărcării clusterului.
  
  În plus, primiți următorul mesaj de eroare atunci când este invocat DO:
  
  
  
  Această problemă apare dacă o mașină virtuală este protejată utilizând ASR, deoarece mai multe atribute cloud (cum ar fi RPO și cloud) sunt setate pe mașina virtuală. Dar gazdele din acel cloud nu primesc atribute legate de cloud. În timpul DO, în timp ce este migrată o mașină virtuală principală, solicitările de plasare pentru atributele cloud ale gazdelor și pentru că atributele necesare lipsesc, nu găsește o gazdă potrivită.
  
  

• Optimizarea dinamică (DO) nu ignoră mașinile virtuale oprite din mediul cloud de recuperare în timp ce calculează restricțiile de capacitate pentru mașinile virtuale noi. Dacă există opriți replicare VM pe o gazdă, NU se mută mașini virtuale suplimentare la gazdă. Acest lucru poate afecta echilibrarea încărcării clusterului.
  
  Această problemă apare deoarece cheia de registry "IgnoreMemoryForStoppedReplicaVM" este utilizată pentru a include mai multe mașini virtuale dacă orice gazdă are mașini virtuale de reproducere într-o stare de oprire. Scenariile DO nu onorează această semnalizare.
  
  

• Un nod de cluster nu poate fi pus în modul de întreținere dacă are mașini virtuale protejate prin ASR. În această situație, primiți următorul mesaj de eroare.
  
  
  
  

• Următorul avertisment este afișat de VMM atunci când o mașină virtuală care este protejată prin ASR este migrată în direct în cluster.
  
  
  
  Deși această verificare este doar o blocare soft și nu blochează scenariul de migrare propriu-zis, gazdei i se atribuie în continuare o evaluare zero prin plasare. Acest lucru blochează operațiunea de Optimizare dinamică (DO) și, în cele din urmă, împiedică migrarea în direct a mașinii virtuale.
  
  

• Opțiunea de a activa Trunk VLAN ca tip de rețea în serviciul de rețea VMM nu este disponibilă. Dacă marcați tipul de rețea ca VLAN, acest lucru face ca VMM să suprascrie setarea VLAN trunchi care a fost setată în afara benzii.

Îmbunătățiri ale procesului de corecție

• Înainte de setul de actualizări 7, atunci când ați instalat setul de actualizări VM, consola VMM afișează intermitent următorul mesaj de eroare:
  
  

  Imposibil de actualizat canalul programului de completare de cod gestionat din cauza următoarei erori:
  
  Folderul necesar "C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\bin\AddInPipeline\HostSideAdapters" nu există.

  
  

• Eliminarea setului de actualizări 5 nu readuce următorul binar la versiunea anterioară:
  
  

  Microsoft.SystemCenter.VirtualMachineManager.resources.dll
  
  

• Dacă instalați un set de actualizări mai vechi în modul ne elevat, acest lucru face ca valoarea de registry IndigoTCPport să fie resetată. Acest lucru necesită ca utilizatorii să modifice manual valoarea la 8100. În plus, primiți următorul mesaj de eroare:
  
  

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Administrator Console\Settings\IndigoTCPport valoare este incorectă

Cum se obține și se instalează setul de actualizări 7 pentru System Center 2012 R2 Virtual Machine Manager