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

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

• Suport pentru SQL Server 2014 SP1 ca bază de date
  VMM Cu setul de actualizări 8 pentru SC VMM 2012 R2, acum puteți avea Microsoft SQL Server 2014 SP1 ca bază de date VMM. Această asistență nu include implementarea șabloanelor de serviciu utilizând tipul de profil SQL ca SQL Server 2014 SP1. Pentru cele mai recente informații despre cerințele SQL Server pentru System Center 2012 R2, consultați referința aici.
  
  

• Suport pentru scenariile
  de gestionare VMWare vCenter 6.0 Cu setul de actualizări 7, am anunțat suport pentru scenariile de gestionare pentru vCenter 5.5. Pornind de la planul nostru principal pentru integrarea și suportabilitatea vCenter și VMM, suntem încântați acum să anunțăm suportul pentru VMWare vCenter 6.0 în setul de actualizări 8. Pentru o listă completă a scenariilor acceptate, faceți clic aici.
  
  

• Capacitatea de a seta cote pentru adrese
  IP externe Cu setul de actualizări 7, am anunțat suport pentru mai multe adrese IP externe pentru fiecare rețea virtuală, dar povestea a fost incompletă, deoarece nu a existat nicio opțiune de a seta cote pentru numărul de conexiuni NAT. Cu UR8, suntem bucuroși să anunțăm suportul final pentru această funcționalitate, deoarece acum puteți seta cote pentru numărul de adrese IP externe permise pentru fiecare rol de utilizator. De asemenea, puteți gestiona acest lucru utilizând Windows Azure Pack (WAP).
  
  Cum utilizez această funcționalitate?
  
  Cmdleturi PowerShell:
  
  

  Pentru a seta cota pentru un rol de utilizator: Set-UserRole – UserRoleObject –NATConnectionMaximum MaxNumber Pentru a elimina cota pentru un rol de utilizator: Set-UserRole - UserRoleObject UserRoleObject – Cmdleturi eșantion RemoveNATConnectionMaximum : Set-UserRole –UserRole $UserRoleObject –NATConnectionMaximum 25 Set-UserRole –UserRole $UserRoleObject –RemoveNATConnectionMaximum

  
  
  

• Suport pentru cote pentru puncte de
  verificare Înainte de UR8, atunci când creați un punct de verificare prin WAP, VMM nu verifică dacă crearea punctului de verificare va depăși limita cotei de stocare a entității găzduite. Înainte de UR8, entitățile găzduite pot crea punctul de verificare chiar dacă limita cotei de stocare va fi depășită.
  
  Exemplu de scenariu pentru a explica problema de dinainte de UR8
  
  Luați în considerare un caz în care un administrator de entitate găzduită are o limită de cotă de stocare de 150 GB. Apoi, urmează acești pași:

  1. Ea creează două mașini virtuale de dimensiune VHD de 30 GB fiecare (spațiu de stocare disponibil înainte de creare: 150 GB, după creare: 90 GB).

  2. Ea creează un punct de verificare pentru una dintre mașinile virtuale (spațiu de stocare disponibil înainte de creare: 90 GB, după creare: 60 GB).

  3. Ea creează un nou VM de dimensiune VHD 50 GB (spațiu de stocare disponibil înainte de creare: 60 GB, post-creare: 10 GB).

  4. Ea creează un punct de verificare al celei de-a treia mașini virtuale (spațiu de stocare disponibil înainte de creare: 10 GB).

  
  
  Deoarece administratorul entității găzduite nu mai are cotă de stocare suficientă, VMM ar trebui, în mod ideal, să blocheze crearea acestui punct de verificare (pasul 4). Dar, înainte de UR8, VMM permite administratorilor de entități găzduite să creeze punctul de verificare și să depășească limita.
  
  Cu setul de actualizări 8, acum puteți fi sigur că VMM va gestiona verificarea limitelor cotelor de stocare ale entității găzduite înainte de a crea un punct de verificare.
  
  

• Capacitatea de a configura adresa MAC a adaptorului de rețea statică în timpul implementării
  sistemului de operare Cu setul de actualizări 8, oferim acum funcționalitatea de configurare a adreselor MAC ale adaptorului de rețea statică în timpul implementării sistemului de operare. Dacă ați făcut vreodată bare Metal asigurarea accesului de gazde și a ajuns să aibă mai multe gazde cu aceleași adrese MAC (din cauza atribuirii dinamice a adreselor IP pentru adaptoarele de rețea), acest lucru ar putea fi un adevărat salvator pentru dvs.
  
  Cum utilizez această funcționalitate?
  
  Cmdlet PowerShell:
  
  

  New-SCPhysicalComputerNetworkAdapterConfig -UseStaticIPForIPConfiguration -SetAsGenericNIC -SetAsVirtualNetworkAdapter -IPv4Subnet Șir -LogicalSwitch Logical_Switch -VMNetwork VM_Network -MACAddress MAC_Address

  
  Pentru a configura o adresă MAC statică, puteți specifica parametrul MACAddress în cmdletul PowerShell anterior. Dacă nu este specificat niciun parametru de adresă MAC, VMM îl configurează ca dinamic (VMM alocă Hyper-V pentru a atribui adresa MAC).). Pentru a alege MAC din rezervorul de adrese VMM MAC implicit, puteți specifica adresa MAC ca 00:00:00:00:00:00., ca în următoarea captură de ecran:
  
  
  
  

• Capacitatea de a implementa ACL-uri
  de port Hyper-V extinse cu setul de actualizări 8 pentru VMM, acum puteți:

  • Definirea ACL-urilor și a regulilor lor

  • Atașarea ACL-urilor create la o rețea VM, la subrețele VM sau la adaptoare de rețea virtuală

  • Atașați ACL la setările globale care o aplică la toate adaptoarele de rețea virtuale

  • Vizualizați și actualizați regulile ACL configurate pe adaptorul de rețea virtuală în VMM

  • Ștergerea ACL-urilor de port și a regulilor ACL

  
  
  Pentru mai multe informații, consultați articolul din Baza de cunoștințe 3101161.
  
  

• Suport pentru partajarea spațiului de stocare în VMM
  Cu setul de actualizări 8, VMM vă oferă acum funcționalitatea de a crea partajări de fișiere cu niveluri (SSD/HDD).
  
  Pentru mai multe informații, consultați articolul din Baza de cunoștințe 3101159.

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

• Problema 1
  Crearea mașinilor virtuale de generația 2 nu reușește, cu următoarea eroare:
  
  

  Eroare (13206)
  Managerul de mașini virtuale nu poate găsi bootarea sau volumul sistemului pe mașina virtuală <numele mașinii virtuale>. Este posibil ca mașina virtuală rezultată să nu pornească sau să nu funcționeze corect.

  
  
  

• Problema 2
  VMM nu vă permite să setați proprietarul unui profil hardware cu un nume de proprietar care conține simbolul "$".
  
  

• Problema 3
  HA VMs cu VLAN configurat pe site-urile de rețea ale unei rețele logice nu poate fi migrat de la o gazdă la alta. Se afișează următoarea eroare atunci când încercați să migrați VM:
  
  

  Eroare (26857)
  ID-ul VLAN (xxx) nu este valid, deoarece rețeaua VM (xxx) nu include ID-ul VLAN într-un site de rețea accesibil de gazdă.

  
  
  

• Problema 4
  Modificările efectuate de un administrator de entitate găzduită (cu permisiuni de implementare într-un cloud) la setările Memorie și CPU ale unei mașini virtuale din cloud prin consola VMM nu se lipesc. Pentru a rezolva această problemă, modificați aceste setări utilizând PowerShell.
  
  

• Problema 5
  Atunci când o mașină virtuală este implementată și amplasată pe o partajare de fișiere SMB3 găzduită pe NetApp filer 8.2.3 sau o versiune mai recentă, procesul de implementare a mașinii virtuale lasă o sesiune învechită deschisă pentru fiecare mașină virtuală implementată în partajare. Atunci când multe mașini virtuale sunt implementate utilizând acest proces, implementarea VM începe să nu reușească, deoarece este atinsă limita maximă a sesiunii SMB permise pe programul de completare NetApp.
  
  

• Problema 6
  VMM se blochează din cauza SQL Server probleme de performanță atunci când efectuați operațiuni de zi cu zi VMM. Această problemă apare din cauza intrărilor învechite din tabelul tbl_PCMT_PerfHistory_Raw. Cu UR8, noile intrări învechite nu sunt create în tabelul tbl_PCMT_PerfHistory_Raw. Cu toate acestea, intrările care au existat înainte de instalarea UR8 vor continua să existe. Pentru a șterge intrările învechite existente din tabelele SQL Server, utilizați următorul script de SQL:
  
  

  DELETE FROM tbl_PCMT_PerfHistory_Raw unde TieredPerfCounterID NOT IN (SELECT DISTINCT tieredPerfCounterID FROM dbo.tbl_PCMT_TieredPerfCounter);
  
  DELETE FROM tbl_PCMT_PerfHistory_Hourly unde TieredPerfCounterID NOT IN (SELECT DISTINCT tieredPerfCounterID FROM dbo.tbl_PCMT_TieredPerfCounter);
  
  DELETE FROM tbl_PCMT_PerfHistory_Daily unde TieredPerfCounterID NOT IN (SELECT DISTINCT tieredPerfCounterID FROM dbo.tbl_PCMT_TieredPerfCounter);
  
  

• Problema 7
  
  Într-o implementare cu adaptoare virtualizate de canal de fibră, VMM nu actualizează furnizorul de stocare SMI-S și generează următoarea excepție:
  
  

  Nume: Citește descrierea furnizorului
  Stocare : Citește progresul furnizorului
  Stocare : 0 %
  Status : CmdletName nereușit
  : Read-SCStorageProvider
  ErrorInfo : FailedtoAcquireLock (2606)

  
  
  Acest lucru se întâmplă deoarece VMM obține mai întâi blocarea la scriere pentru un obiect, apoi încearcă mai târziu să obțină blocarea Delete pentru același obiect.
  
  

• Problema 8
  Pentru mașinile virtuale cu VHD-uri care sunt puse pe un server de fișiere scalare (SOFS) prin SMB, contorul de performanță VM cu viteză de citire a discului afișează incorect zero în consola de Admin VMM. Acest lucru împiedică o întreprindere să monitorizeze principalii consumatori IOPS.
  
  

• Problema 9
  Optimizarea dinamică nu reușește, pierde o tranzacție și împiedică executarea altor lucrări. Este blocat pe computerul SQL Server până când SCVMM este reciclat sau SPID ofensa în SQL este ucis.
  
  

• Conversia problemei 10
  V2V nu reușește atunci când încercați să migrați mașini virtuale de la gazda ESX la gazda Hyper-V dacă dimensiunea hard diskului mașinii virtuale de pe gazda ESX este foarte mare. S-a produs următoarea eroare menționată:
  
  

  Eroare (2901)
  Operațiunea nu s-a terminat cu succes din cauza unui parametru sau a unei secvențe de apel nevalide. (Parametrul este incorect (0x80070057))

  
  
  

• Problema 11
  Migrarea live a mașinilor virtuale într-o rețea HNV durează mai mult decât era de așteptat. De asemenea, este posibil să găsiți că ping-urile la mașinile virtuale care migrează sunt pierdute. Acest lucru se întâmplă deoarece, în timpul migrării în direct, este transferat tabelul de politică WNV (în loc de delta). Prin urmare, dacă tabelul politică WNV este prea lung, transferul este întârziat și poate cauza ca mașinile virtuale să piardă conectivitatea la noua gazdă.
  
  

• Problema 12
  VMM obține o adresă MAC greșită în timp ce generează politica HNV în implementările în care sunt utilizate echilibrarea încărcării F5.
  
  

• Problema 13
  Pentru dispozitivele IBM SVC, activarea reproducerii nu reușește în VMM, deoarece există o limitare în SVC, în care numele grupului de consistență ar trebui să înceapă cu un caracter alfabetic (cod de eroare: 36900). Această problemă apare deoarece, în timpul activării reproducerii, VMM generează șiruri aleatoare pentru denumirea "grupurilor de consistență" și "relație" între sursă și țintă, iar acestea conțin caractere alfanumerice. Prin urmare, primul caracter generat de VMM poate fi un număr, iar acest lucru încalcă cerința ibm SVC.
  
  

• Problema 14
  În setul de actualizări 6, am inclus o modificare care le permite clienților să aibă o adresă MAC statică, chiar dacă adaptorul de rețea nu este conectat. Această remediere nu a acoperit toate scenariile corect și declanșează o excepție atunci când există un șablon cu un adaptor de rețea conectat, apoi încercați mai târziu să editați adresa statică pentru a deconecta adaptorul de rețea.
  
  

• Problema 15
  de după setul de actualizări 6, imediat ce o gazdă intră în modul moștenit, nu revine la eveniment timp de 20 de zile. Prin urmare, proprietățile mașinii virtuale nu sunt reîmprospătate și nu se primesc evenimente de la HyperV timp de 20 de zile.
  
  Această problemă apare din cauza unei modificări incluse în UR6 care setează expirarea ca 20 de zile atât pentru modul de evenimente, cât și pentru modul moștenit. Programul de reîmprospătare moștenit, care ar trebui să ruleze în mod ideal după 2 minute, rulează acum după 20 de zile; și până atunci, evenimentul este dezactivat.
  
  Soluție:
  Pentru a rezolva această problemă, rulați manual reîmprospătarea moștenită reîmprospătând proprietățile mașinii virtuale.
  
  

• Problema 16
  post-UR7, ștergerea unei rețele virtuale nu curăță corect resursele clusterului pentru Gateway-ul de virtualizare a rețelei. Acest lucru face ca rolul cluster (grupul de clustere) să intre într-o stare nereușită atunci când are loc o reluare în caz de nereușită a rolului de cluster de gateway HNV. Acest lucru cauzează o stare de eroare la gateway, ca în următoarea captură de ecran:
  
  

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