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

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

• Adăugarea caracteristicii abonament Azure: Utilizând caracteristica Adăugați un abonament Azure din setul de actualizări 6, administratorii Virtual Machine Manager pot adăuga Microsoft Azure abonamente la VMM și pot efectua acțiuni de bază asupra instanțelor Azure din aceste abonamente. Caracteristica este inclusă în Virtual Machine Manager în setul de actualizări 6 pentru System Center 2012 R2. Pentru fiecare abonament Azure pe care îl adăugați, puteți utiliza o consolă pentru a vedea toate instanțele de rol din toate grupurile de implementare din acel abonament.
  
  Ce puteți face cu această caracteristică
  
  Dacă gestionați deja mașinile virtuale locale în Virtual Machine Manager, puteți utiliza această caracteristică pentru a efectua câteva acțiuni de bază în instanțele Azure, fără a ieși din consola VMM. De exemplu, puteți face următoarele:
  

  • Adăugați sau eliminați unul sau mai multe abonamente Azure utilizând consola VMM.

  • Vedeți o vizualizare listă a detaliilor și stărilor tuturor instanțelor de rol din toate implementările din acel abonament.

  • Actualizați manual lista de instanțe.

  • Efectuați următoarele acțiuni de bază pentru instanțe:
    

    • Start

    • Opreşte-te

    • Shutdown

    • Reporniţi

    • Conectare prin RDP

  Pentru mai multe informații, consultați Adăugarea unui abonament Azure în VMM în System Center 2012 R2 cu setul de actualizări 6.

• Scenariu de protecție ASR E2A îmbunătățit: Având setul de actualizări 6 în mediul Virtual Machine Manager, este mai ușor să descoperiți și să corectați o problemă care apare uneori atunci când configurați protecția Azure Site Recovery (ASR). Această problemă apare atunci când doriți să adăugați protecție ASR pentru mașinile virtuale locale și aveți următoarele proprietăți de mașină virtuală:
  

  • Nicio versiune specificată a sistemului de operare

  • Nicio indicație privind discul care conține sistemul de operare al mașinii virtuale

  Aceste proprietăți trebuie specificate, deoarece sunt solicitate de Azure Site Recovery. În Setul de actualizări 6, un set mai clar de mesaje de eroare se afișează în VMM în panoul Activități dacă încercați să configurați o mașină virtuală care nu îndeplinește cerințele.
  
  Pentru informații despre cerințele ASR, consultați Îmbunătățirea scenariului de protecție ASR E2A.

• Opțiunea de a utiliza mașini virtuale de generația 2 în Servicii și VMRoles: În setul de actualizări 6, VMM oferă acum suport pentru mașini virtuale de generația 2 pentru servicii și roluri VM. Utilizând această caracteristică, puteți să implementați servicii cu mai multe niveluri și să alegeți generația mașinii virtuale pentru niveluri individuale. Utilizatorii pot servi aceste instanțe de serviciu prin servicii convenționale și bazate pe imagini.
  
  Pentru mai multe informații, consultați Înțelegerea Mașini virtuale generației 1 și a generației 2 în VMM.

• Total reguli de expunere de utilizare în rețea în Pachetul de gestionare: Această modificare introduce două reguli care vizează gazdele Hyper-V:
  

  • Total regulă de colectare trafic rețea VNic de intrare

  • Regulă totală de colectare trafic rețea VNic de ieșire

  Aceste reguli măsoară traficul total de intrare și total de ieșire în kilo byți pe VNic pe mașină virtuală, în următoarea metodă:
  
  Pentru fiecare mașină virtuală:
  

  1. Activați contorizarea Hyper-V dacă nu este activată.

  2. Rulați Measure-VM.

  3. Colectați date de măsurare pentru fiecare adresă la distanță de "0.0.0.0/0" sau "::/0" per VNic.

  În mod implicit, aceste reguli rulează în fiecare oră. Utilizatorii pot opta să înlocuiască această setare prin înlocuirea proprietății IntervalSeconds. Aceste reguli nu trebuie rulate mai frecvent decât la fiecare cinci minute (300 de secunde).
  
  Comportamentul în versiunile anterioare: VMM nu a măsurat consumul de date. Acesta a măsurat doar debitul.

• Opțiunea de a suprascrie capacitatea Cloud și Host Group pentru mașini virtuale replicare: System Center 2012 R2 Virtual Machine Manager vă permite să amplasați mașinile virtuale de reproducere într-un cloud preconfigurat sau într-un grup gazdă preconfigurat, dacă acestea se încadrează în setările de capacitate. Până acum, VMM a presupus că toate resursele care au fost alocate mașinilor virtuale de reproducere erau în uz. Prin urmare, VMM nu v-a permis să amplasați nicio mașină virtuală de reproducere pe un cloud sau un grup gazdă dacă acest lucru ar ridica sarcina agregată a tuturor mașinilor virtuale de reproducere dincolo de capacitatea de grup de cloud sau gazdă.
  
  Deși acest comportament a asigurat că toate mașinile virtuale de reproducere pot porni simultan, aceasta ar putea provoca o utilizare neoptimă a norilor de reproducere și a grupurilor gazdă. Acest lucru se întâmplă dacă (o întreprindere sau hoster) ați încercat să amplasați mașini virtuale suplimentare într-un cloud sau într-un grup gazdă. Aceasta dacă ați supracommis mediul cloud de reproducere sau grupul gazdă. În Setul de actualizări 6, puteți să depășiți mediile cloud și grupurile gazdă din mediul VMM configurând următoarea cheie de registry pe serverul VMM:
  

  Locație registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\Placement
  Nume DWORD: IgnoreMemoryForStoppedReplicaVM
  Valoare DWORD: 1
  Notă Dacă subcheia Plasare nu există, creați-o.
  
  Pentru mai multe informații, consultați Opțiunea de a supracommite cloud și HG pentru mașini virtuale de reproducere.

• Suport pentru scenarii de bază VMWare VCenter 5.5.
  
  Setul de actualizări 6 prezintă următoarele scenarii de asistență:
  

  • Adăugați VCenter 5.5 la VMM 2012 R2 MANAGEMENT UR6

  • Adăugați O gazdă ESX cu versiunea 5.5 și aduceți-o sub gestionare

  • Crearea șablonului VMWare VM și implementarea mașinilor virtuale cu șablonul

  • Creați șabloane cu rețele de bază (printre care se numără scenarii de asociere la domeniu) și implementați mașini virtuale

  • Efectuați diverse operațiuni cu ciclul de viață VM (de exemplu, pornire, oprire, închidere, reparare, reîmprospătare și punct de verificare pe o mașină virtuală).

  • Conectare la o mașină virtuală utilizând consola și verificând accesibilitatea

  • Anularea accesului la mașini virtuale

  • Creați un rezervor de resurse și aduceți rezervorul de resurse sub Gestionare VMM

  Acestea sunt scenarii limitate. Cu toate acestea, ele reprezintă primul și cel mai important pas spre sprijinirea versiunilor mai noi de VCenter. Vom continua să construim pe baza matricei noastre de suport pentru VMWare VCenter și vom furniza actualizări pentru a remedia acest lucru în pachetele de seturi viitoare.

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

• Problema 1
  
  Apare o eroare 801 atunci când obiectele VMM sunt eliminate. VMM întâmpină uneori o problemă în care un obiect VMM, cum ar fi o mașină virtuală, nu poate fi eliminat din interfața de utilizator sau Windows Powershell, deoarece unele dintre obiectele sale fiu lipsesc din baza de date. Acest lucru determină frecvent utilizatorii să caute scripturi de remediere pentru a elimina obiectele afectate. În Setul de actualizări 6, VMM a îmbunătățit trei cmdleturi Powershell pentru a minimiza erorile legate de 801. Aceste cmdleturi sunt Remove-SCServiceTemplate, Remove-SCLibraryServer și Remove-SCLibraryShare. Utilizatorii nu trebuie să utilizeze semnalizarea -Force împreună cu aceste cmdleturi pentru a evita erorile 801. Cmdleturile oferă capacitatea de a rezolva dependențele care duc la erori 801.
  

• Problema 2
  
  Serviciul VMM se defectează și generează o eroare de încălcare a accesului în System.Xml atunci când răspunde la un eveniment de servicii de integrare.
  

• Problema 3
  
  Excepție critică în rutina de tratare a erorilor WCF - ObjectDisposedException -- Microsoft.VirtualManager.Engine.Remoting.ClientConnection.HandleError. Atunci când VMM închide gazda serviciului WCF, apelează Abort, ceea ce poate face ca toate mesajele neprocesate să fie terminate pe neașteptate, iar acest lucru poate duce la apariția ObjectDisposedExceptions. Rutina de tratare a erorilor WCF de nivel superior din VMM vede aceste excepții înainte de terminarea procesului și le raportează ca excepții critice. Deci, aici VMM raportează erori inofensive ca erori critice, eventual, adăugarea la confuzia utilizatorului.
  

• Problema 4
  
  Opțiunea pentru Mac Address estompată în interfața utilizator atunci când vnic nu este conectat. Acest lucru împiedică utilizatorii să marcheze nic ca static. După ce faceți upgrade la VMM în System Center 2012 R2, clientul nu poate alege opțiunea Adresă Static Mac în șabloanele VM pe care le creează, dacă mașina virtuală nu este conectată la o rețea. Opțiunile Adresă MAC și IP sunt estompate atunci când mașina virtuală este "neconectată". Prin urmare, nu poate atribui o adresă MAC statică mașinii virtuale înainte de implementare.
  

• Problema 5
  
  Particularizarea mașinii Vvirtual poate să nu reușească și să genereze o excepție critică atunci când Hyper-V nu returnează un obiect de unitate de dischetă. În timpul particularizării unei mașini virtuale, există posibilitatea ca Hyper-V să returneze obiectul Floppy Drive ca nul și VMM va încerca să adauge o unitate. Totuși, adăugarea unității de dischetă nu este implementată la Hyper-V. Aceasta generează o excepție care cauzează nereușita activității și lasă mașina virtuală în starea de creare nereușită. Utilizatorul poate repara mașina virtuală pentru a fi funcțională. Acest lucru poate apărea dacă configurarea unității de dischetă (pe partajarea la distanță) nu este disponibilă pentru Hyper-V sau dacă Hyper-V este ocupat sau stresat.
  

• Problema 6
  
  Imposibil de implementat mașini virtuale cu IP static atunci când sunt configurate mai multe fonduri comune IP pentru o subrețea VM. Clientul încearcă să creeze o mașină virtuală utilizând un șablon care are setări IP statice. Dacă există mai multe fonduri comune IP într-o subrețea și clientul furnizează o adresă IP de la un rezervor diferit de cel implicit (mai exact, rezervorul populat automat afișat în interfața de utilizator), atunci Expertul VM se termină fără erori, dar crearea mașinii virtuale nu reușește și returnează o eroare "Adresă IP în afara intervalului".
  

• Problema 7
  
  Căderea VmmService are loc în timpul gestionării subrețelelor mașinii virtuale eliminate în evenimentele de modificare IP trimise de Hyper-v. Într-o configurare NVGRE, dacă există un eveniment trimis de Hyper-V pentru modificare IP, dar subrețea VM nu mai există în VMM, provoacă o cădere de serviciu VMM.
  

• Problema 8
  
  VMS sunt raportate lipsă, deoarece VmMovedRefresherEvent nu este primit. Atunci când are loc un eveniment de mutare a unei mașini virtuale atunci când o gazdă nu este în modul Eveniment, iar mașina virtuală este în starea de migrare și atunci când se conectează programul de reîmprospătare a evenimentului, poate exista o fereastră în care nimeni să nu asculte, iar operațiunea de actualizare chiar înainte de modul de ascultare nu primește modificarea. Prin urmare, VMM nu va primi aceste modificări până la următoarea Reîmprospătare completă, care poate fi de până la 24 de ore.
  
  Pentru a vă asigura că astfel de evenimente pierdute sunt sincronizate prin programul de reîmprospătare a mașinii virtuale ușoare atunci când sunteți în modul Eveniment, puteți să creați și să configurați următoarea cheie de registry pentru a rula programul de reîmprospătare a mașinii virtuale ușoare la intervale regulate. Această reîmprospătare va rula în plus față de toate reîmprospătările bazate pe evenimente.
  

  Locație registry:HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings
  Cheie de registry:
  VMPropertiesEventAssitedUpdateInterval
  
  Tip de registry: DWORD
  
  Valoare minimă: 0 secunde
  
  Valoare maximă: 20 de zile

  Valorile trebuie specificate în secunde.
  Nume DWORD: VMPropertiesEventAssitedUpdateInterval
  
  Valoare DWORD:value_in_seconds
  
  Notă Substituentul value_in_seconds poate fi o valoare de la 0 secunde la 20 de zile (de asemenea, în secunde).
  

• Problema 9
  
  Solicitați semnalizări explicite pentru a indica faptul că lipsește o mașină virtuală sau o mașină virtuală de serviciu în timpul Remove-Host utilizatorului. În prezent, VMM nu verifică existența mașinilor virtuale pe gazdă în timp ce elimină gazda din VMM. O gazdă poate conține mașini virtuale de serviciu, mașini virtuale care sunt implementate în cloud, mașini virtuale care au proprietăți particularizate definite pentru acestea. Dacă un utilizator elimină din greșeală o astfel de gazdă, toate aceste asocieri sunt întrerupte. Această remediere evită astfel de scenarii solicitând utilizatorilor un mesaj de confirmare înainte ca gazdele respective să fie eliminate de fapt din VMM.
  

• Problema 10
  
  Dacă aveți o rețea logică care are mai multe site-uri de rețea și site-urile de rețea sunt vizibile pentru adaptorul de rețea gazdă, se vor aloca PA-uri de la acele site-uri de rețea diferite, iar informațiile de rutare trebuie setate, de asemenea. (Site-urile de rețea sunt denumite uneori "definiții logice de rețea".) Într-un scenariu gazdă multiplu cu VM1 pe Host1 conectat la PA1, există un caz în care un VM2 este conectat la un hnv LN și are o PA1 pentru NetwkSite1 și apoi este deconectat și reconectat mai târziu și are o PA2 pentru NetwkSite2 (aleator sau din cauza epuizării PA), apoi pentru un timp, este posibil să nu populăm informațiile de rutare PA între NetwkSite1 și NetwkSite2. Acest lucru se întâmplă din cauza modului în care reprezentarea rutei interne este tastată pentru inserarea într-un tabel hash.
  

• Problema 11
  
  Atunci când o gazdă este reîmprospătată, stabilește o conexiune de rețea WinRM (la fiecare gazdă reîmprospătată) care redă în mod constant în flux date.
  

• Problema 12
  
  Atunci când sunt create mai multe adaptoare de rețea virtuală gazdă, se observă erori aleatoare. Atunci când clienții creează mai multe adaptoare de rețea virtuală într-o singură fotografie ca parte a unui comutator logic, una sau mai multe configurații IP pentru adaptorul de rețea virtual pot să nu reușească.
  

• Problema 13
  
  Utilizatorul accesează o inserție de cheie dublată în HostWSManGetter.UpdateRASDCache atunci când efectuează o actualizare de gazdă.
  

• Problema 14
  
  Atunci când utilizatorul încearcă să cloneze o mașină virtuală cu puncte de control, după finalizarea operațiunii de clonare, VMM recunoaște incorect mașina virtuală clonă nou creată ca mașină virtuală originală și deduce incorect că mașina virtuală a migrat. Apoi încearcă să gestioneze această schimbare. Prin urmare, se creează o mașină virtuală suplimentară pe o altă gazdă cu starea "absentă". VMM crede că mașina virtuală utilizează o altă gazdă, iar această mașină virtuală nu este vizibilă pentru TFS până la următoarea actualizare a mașinii virtuale.
  

• Problema 15
  
  Atunci când furnizorului VSEM i se face upgrade, capacitatea furnizorului de a primi notificări nu este indicată motorului de notificare.
  

• Problema 16
  
  Plasarea în rețea se blochează în timpul optimizării dinamice a gazdei. Unele operațiuni de plasare trebuiau să ruleze ca activitate. Atunci când este executat în activitatea de reîmprospătare, contextul este nul. Acest lucru cauzează o cădere de plasare.
  

• Problema 17
  
  Atunci când administratorii delegați pornesc consola VMM, durează 4+ minute pentru a deschide consola VMM. În medii mari, pornirea consolei VMM este întârziată pentru administratorii delegați atunci când este comparată cu administratorii.
  

• Problema 18
  
  Stocare actualizarea furnizorului nu reușește după înlocuirea discului pe sofs.
  

• Problema 19
  
  VMM nu poate actualiza reproducerea/mașina virtuală principală fără ASR, de asemenea, migrarea mașinii virtuale de recuperare în stare de așteptare IR nu efectuează migrarea în direct.
  

• Problema 20
  
  Atunci când o mașină virtuală este ștearsă, punctele de verificare sunt îmbinate înainte de a fi șterse. Atunci când utilizatorul încearcă să șteargă o mașină virtuală care are puncte de verificare, ștergerea durează mult timp (până la o oră) pentru a se termina.
  

• Problema 21
  
  O operațiune Run DO primește uneori o excepție critică: DBCorruptionException.
  

• Problema 22
  
  Unii utilizatori utilizează seturi mari de adrese VIPAddress în loc de intervale IP, pentru a simplifica adăugarea/eliminarea ip-urilor individuale. Schema pachetului de gestionare VMM limitează în prezent acest câmp la 256 caractere (implicit). Totuși, utilizatorii pot avea valori de ~500 de caractere lungime. Și, prin urmare, Discovery a fost de rupere VMM-OM integrarea din cauza unei excepții neașteptate de la SCOM.
  

• Problema 23
  
  RG țintă și LUN-urile țintă nu sunt asociate după activitatea enableRG dacă RG/LUN sunt precreate.
  

• Problema 24
  
  Trebuie să actualizați intrările de adresă MAC pentru un dispozitiv F5 Gateway atunci când acesta nu reușește și este înlocuit. Dacă un dispozitiv F5 este RMA'd și înlocuit cu un dispozitiv nou cu o nouă adresă MAC, VMM nu are o modalitate de a actualiza adresa MAC pentru noul dispozitiv.
  

• Problema 25
  
  Permiteți utilizatorului să se ștampileze pe o mașină virtuală de reproducere, pentru a vă permite să marcați identitatea utilizatorului. Utilizatorii trebuie să actualizeze atributele UserRole și Owner pe replicaVMs, dar în prezent orice operațiune de pe mașina virtuală de reproducere este blocată. Prin urmare, nu pot actualiza acești doi parametri pe mașini virtuale de reproducere.
  

• Problema 26
  
  Partajarea SMB înregistrată nu se afișează ca opțiune de cale țintă atunci când implementați o nouă mașină virtuală HA într-un cluster.
  

• Problema 27
  
  Excepție critică în Stocare Reîmprospătați atunci când descoperiți serviciul de reproducere -- ArgumentNullException -- SetCustomOptions.
  

• Problema 28
  
  În timpul host refresher VMM interogări echipa information (comuta echipa sau LBFO echipa). Întrucât interogarea echipelor de comutare VMM accesează excepția WSMan, care face ca vswitch să dispară de pe consolă.
  

• Problema 29
  
  Protocolul HTTPS nu este acceptat în Probe, apoi VMM nu poate crea regula de monitorizare pentru a monitoriza site-ul HTTPS. VMM acceptă HTTP și HTTP în secțiunea de configurare a portului LB, dar HTTPS nu este acceptat în secțiunea de protocol a sondei LB.
  

• Problema 30
  
  Proprietarul resursei (Utilizator SSU) nu este autorizat să acceseze lista "GrantedTo" a unei resurse și, prin urmare, nu poate vedea cine are toți asi la resursă. Atunci când utilizatorul care acordă acces este, de asemenea, un utilizator cu autoservire, atunci nu poate vedea modificările pe care le-a făcut până când nu repornește consola. Un utilizator administrator poate vedea modificarea, dar, pentru un utilizator cu autoservire, GrantedToList continuă să returneze rezultatele memorate în cache, până când repornește consola.
  

• Problema 31
  
  Imposibil de mutat discurile părinte care au procesul de migrare încorporat VMM. Utilizatorul are mai multe sute de mașini virtuale, cu toate discurile diff indicând spre un singur părinte. Mutarea tuturor acestor mașini virtuale la o soluție de stocare nouă este blocată de VMM. Pentru discuri diff, dacă orice disc strămoș din ierarhie (relația părinte/fiu) este partajat de alt disc diff, migrarea spațiului de stocare al discului diff este blocată de VMM. Cu toate acestea, este activat prin Hyper-V Manager.
  

• Problema 32
  
  Field expectedDSColumn generează o excepție critică în timp ce urmărește mesajul pentru nepotrivirea coloanelor, provocând căderea serverului atunci când rulează get-scvmhost. După ce baza de date server este actualizată la Prag, serverul R2 nu poate lucra cu aceasta în anumite cazuri. Această cărare de cod este utilizată de unele obiecte de rețea și obiecte ADHC.
  

• Problema 33
  
  Atunci când scalați un șablon de serviciu existent, mașinile virtuale Hyper-V dublate care au același nume sunt create pe VMM în System Center 2012 R2 Update Rollup 5.
  

• Problema 34
  
  Dacă mașinile virtuale invitat au Windows actualizare de securitate 3035131 sau 3031432 instalată, agentul invitat VMM nu rulează scripturi generice de execuție a comenzilor (GCE) care sunt solicitate de VMM ca parte a implementării VM. Acest lucru poate provoca erori în mai multe scenarii în care utilizați scripturi GCE pentru implementare și service. De exemplu, atunci când încercați să utilizați un șablon de serviciu VMM prin scripturi GCE, se returnează codul de eroare 22029.
  
  Notă După ce instalați setul de actualizări 6 (sau seturile de actualizări mai recente) pentru System Center Virtual Machine Manger 2012 R2, acum trebuie să acordați log on ca lucrare pe loturi contului specificat Executare ca. Fără aceste drepturi, agentul invitat nu poate rula scripturile GCE printr-un cont Run As.
  

• Problema 35
  
  Migrarea în direct a mașinii virtuale nu reușește atunci când utilizați spațiu de stocare în clustere ca CSV, iar spațiul de stocare al mașinii virtuale se află pe CSV. Migrarea în direct a clusterului Hyper-V nu funcționează după VMM în System Center 2012 R2 Setul de actualizări 5.
  

• Problema 36
  
  Amplasarea discului de bază ar trebui să se rotească între partajările de plasare valide.
  

• Problema 37
  
  Consola VMM poate utiliza un șir de lansare existent în timpul copiei șablonului de serviciu. Uneori, utilizatorii nu pot copia un șablon de serviciu utilizând comanda "Copiere" pentru un șablon de serviciu. Motivul este că consola Administrator generează un șir deja existent pentru lansare.
  

• Problema 38
  
  Dala Prezentare generală a capacității lipsește din VMM în System Center 2012 R2. În VMM în System Center 2012 SP1, sub panoul mașini virtuale și servicii, atunci când selectați o gazdă și apoi faceți clic pe Prezentare generală în meniul din partea de sus, consola oferă informații rezumat și capacitate despre gazda selectată. Detaliile despre nucleele procesorului, memorie (GB) și Stocare (GB) au devenit indisponibile în System Center 2012 R2.
  

• Problema 39
  
  VMM Service Crashing because of duplicate VSID. În cazuri rare (sincronizare/condiție de cursă și coliziunea numărului aleator), diferite subrețele ale mașinii virtuale HNV pot obține același VMSubnetIdentifier (adică VSID). Acest lucru duce la un comportament neașteptat atunci când utilizați aceste subrețele ale mașinii virtuale HNV. De exemplu, pentru mașinile virtuale conectate la această subrețea, este posibil ca mașinile virtuale să nu obțină conectivitatea așteptată și să nu poată discuta cu mașinile virtuale de pe aceeași subrețea. Sau, atunci când se modifică adresa IP, aceasta va provoca căderea serviciului VMM.
  

• Problema 40
  
  Implementarea unei mașini virtuale în spatele unui sistem de echilibrare a încărcării provoacă o Excepție critică la plasare:
  

  Microsoft.VirtualManager.Engine.Placement.Conversion.HostConversionHelper.GetLoadBalancerAddressPoolResources

• Problema 41
  
  Pagina de pornire care a fost introdusă în setul de actualizări 5 este eliminată din setul de actualizări 6.
  

• Problema 42
  
  O mașină virtuală nu este asociată cu un grup de reproduceri și nu se poate muta într-o locație protejată de grupul de reproduceri.
  

• Problema 43
  
  IP-ul invitat din rețeaua HNV nu este marcat ca Dynamic/DedicatedGuestIP, chiar dacă setările sunt activate pentru aceasta. Reluări în caz de nereușită CA întrerupte. Pentru orice adresă IP adăugată/mutată într-o mașină virtuală conectată la rețeaua NVGRE (scenariul HNV Guest Cluster/Guest IP Failover), adresa IP este *not* marcată ca dinamică (tip = DedicatedGuestIP în VMM), chiar dacă mașina virtuală are setările EnableGuestIPNetworkVirtualizationUpdates=true. Atunci când prima dată când adresa IP este adăugată/mutată, aceasta va funcționa, dar reluările ulterioare în caz de nereușită ale IP-ului (care trec de la o mașină virtuală la alta) nu vor fi detectate automat. Prin urmare, adresa IP nu va fi accesibilă și VM va pierde conexiunea.
  

• Problema 44
  
  Furnizorul de stocare încorporat mai vechi din integrarea Hitachi s-a defectat cu UR5. Imposibil de reîmprospătat furnizorul de stocare. Acest lucru împiedică gestionarea furnizorului.
  

• Problema 45
  
  Clientul VMM se defectează atunci când setați intervalul de timp pentru optimizarea alimentării.
  

• Problema 46
  
  O condiție de cursă există la dispoziția WnvEventEntrySubscriptionObserver atunci când conexiunea gazdei nu reușește.
  

• Problema 47
  
  CentOS 7 și Red Hat Enterprise Linux 7 nu reușească să seteze configurația interfeței de rețea atunci când se utilizează DHCP.
  
  Acest lucru se aplică tuturor mașinilor virtuale CentOS 7 și Red Hat Enterprise Linux (RHEL) 7 care sunt configurate să utilizeze DHCP de către System Center Virtual Machine Manager. Serverele CentOS 7 și RHEL 7 care au utilizat DHCP vor întâmpina date de configurare a rețelei absente pentru fiecare interfață ethernet utilizată de serverul Linux. Această problemă apare deoarece CentOS 7 și RHEL 7 nu au instrumentul Linux ifconfig instalat în mod implicit, spre deosebire de iterațiile anterioare. Scripturile de configurare pentru rețele DHCP au fost actualizate pentru a utiliza instrumentul IP în loc de ifconfig dacă este instalat instrumentul IP.

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