6. kumulatív frissítés a System Center 2012 R2 Virtual Machine Manager

A kumulatív frissítésben hozzáadott szolgáltatások

• Azure-előfizetés hozzáadása funkció: A 6. kumulatív frissítés Azure-előfizetés hozzáadása funkciójával a Virtual Machine Manager rendszergazdái Microsoft Azure előfizetéseket adhatnak hozzá a VMM-hez, és alapszintű műveleteket hajthatnak végre ezekben az előfizetésekben található Azure-példányokon. A funkció Virtual Machine Manager része a 2012 R2 System Center 6. kumulatív frissítésében. Minden hozzáadott Azure-előfizetéshez használhat egy konzolt az előfizetésben lévő összes üzembehelyezési csoport összes szerepkörpéldányának megtekintéséhez.
  
  A funkcióval elvégezhető műveletek
  
  Ha már felügyeli a helyszíni virtuális gépeket a Virtual Machine Manager-ban, ezzel a funkcióval nagyon alapvető műveleteket hajthat végre az Azure-példányokon a VMM-konzol elhagyása nélkül. Például a következőket teheti:
  

  • Egy vagy több Azure-előfizetés hozzáadása vagy eltávolítása a VMM-konzol használatával.

  • Az előfizetés összes üzemelő példányában található összes szerepkörpéldány részleteinek és állapotának listanézete.

  • A példányok listájának manuális frissítése.

  • Hajtsa végre a következő alapvető műveleteket a példányokon:
    

    • Start

    • Állj

    • Shutdown

    • Indítsa újra

    • CSATLAKOZÁS RDP-n keresztül

  További információ: Azure-előfizetés hozzáadása a VMM-ben a System Center 2012 R2-ben a 6. kumulatív frissítéssel.

• Továbbfejlesztett E2A ASR-védelmi forgatókönyv: A 6. kumulatív frissítés Virtual Machine Manager környezetben való használatával könnyebben felderíthetők és kijavíthatók azok a problémák, amelyek az Azure Site Recovery (ASR) védelmének konfigurálásakor fordulnak elő. Ez a probléma akkor fordul elő, ha ASR-védelmet szeretne hozzáadni a helyszíni virtuális gépekhez, és a következő virtuálisgép-tulajdonságokkal rendelkezik:
  

  • Nincs megadva operációsrendszer-verzió

  • Nincs jele annak, hogy melyik lemez tartalmazza a virtuális gép operációs rendszerét

  Ezeket a tulajdonságokat meg kell adni, mert az Azure Site Recovery megköveteli őket. A 6. kumulatív frissítésben a VMM-ben tisztább hibaüzenetek jelennek meg a Feladatok panelen, ha olyan virtuális gépet próbál konfigurálni, amely nem felel meg a követelményeknek.
  
  Az ASR-követelményekkel kapcsolatos információkért lásd az ASR E2A védelmi forgatókönyvének fejlesztése című témakört.

• Lehetőség a 2. generációs virtuális gépek használatára a Szolgáltatások és a VMRoles szolgáltatásban: A 6. kumulatív frissítésben a VMM mostantól támogatja a 2. generációs virtuális gépeket a szolgáltatásokhoz és a virtuálisgép-szerepkörökhöz. Ezzel a funkcióval többrétegű szolgáltatásokat helyezhet üzembe, és kiválaszthatja a virtuális gépek generációját az egyes szintekhez. A felhasználók hagyományos és rendszerképalapú karbantartással is kiszolgálhatják ezeket a szolgáltatáspéldányokat.
  
  További információ: Az 1. és a 2. generációs Virtual Machines ismertetése a VMM-ben.

• Teljes hálózathasználati expozíciós szabályok a felügyeleti csomagban: Ez a módosítás két olyan szabályt vezet be, amelyek a Hyper-V-gazdagépeket célják:
  

  • Bejövő virtuális hálózati adapterek teljes forgalomgyűjtési szabálya

  • Kimenő virtuális hálózati adapterek teljes forgalomgyűjtési szabálya

  Ezek a szabályok virtuális gépenként megmérik a virtuális gépenkénti teljes bejövő és kimenő forgalmat kilobájtban:
  
  Minden virtuális gép esetében:
  

  1. Ha nincs engedélyezve, engedélyezze a Hyper-V mérést .

  2. Futtassa a Measure-VM parancsot.

  3. Gyűjtsön mérési adatokat a "0.0.0.0/0" vagy a ":/0" minden távoli címéhez virtuális hálózati adapterenként.

  Ezek a szabályok alapértelmezés szerint óránként futnak. A felhasználók dönthetnek úgy, hogy felülbírálják ezt a beállítást az IntervalSeconds tulajdonság felülbírálásával. Ezek a szabályok nem futtathatók gyakrabban, mint öt percenként (300 másodperc).
  
  Viselkedés a korábbi verziókban: A VMM nem mérte az adatfelhasználást. Csak az átviteli sebességet mérte.

• A replika virtuális gépek felhő- és gazdagépcsoport-kapacitásának túllépése: System Center 2012 R2 Virtual Machine Manager lehetővé teszi, hogy a replika virtuális gépeket előre konfigurált felhőbe vagy gazdagépcsoportba helyezze, ha azok megfelelnek a kapacitásbeállításoknak. Eddig a VMM azt feltételezte, hogy a replika virtuális gépekhez lefoglalt összes erőforrás használatban van. Ezért a VMM nem tette lehetővé replika virtuális gépek felhőbe vagy gazdagépcsoportba helyezését, ha ez az összes replika virtuális gép összesített terhelését a felhőn vagy a gazdagépcsoport kapacitásán túlra növelné.
  
  Bár ez a viselkedés gondoskodott arról, hogy az összes replika virtuális gép egyidejűleg elinduljon, a replikafelhők és a gazdagépcsoportok nem optimális használatát okozhatja. Ez akkor fordul elő, ha Ön (egy vállalat vagy egy gazdagép) további virtuális gépeket próbált elhelyezni egy felhőben vagy egy gazdagépcsoportban. Vagyis ha túllépte a replikafelhőt vagy -gazdagépcsoportot. A 6. kumulatív frissítésben a VMM-környezetben a következő beállításkulcs konfigurálásával lehet túllépni a felhőket és a gazdagépcsoportokat a VMM-környezetben:
  

  Beállításjegyzék helye:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\Placement
  DWORD neve: IgnoreMemoryForStoppedReplicaVM
  Duplaszó értéke: 1
  Megjegyzés: Ha az Elhelyezés alkulcs nem létezik, hozza létre.
  
  További információ: A felhő és a HG túlvállalása replika virtuális gépekhez.

• A VMWare VCenter 5.5 alapszintű forgatókönyveinek támogatása.
  
  A 6. kumulatív frissítés a következő támogatási forgatókönyveket mutatja be:
  

  • VCenter 5.5 hozzáadása a VMM 2012 R2 UR6 felügyeletéhez

  • 5.5-ös verziójú ESX-gazdagép hozzáadása és felügyelet alá helyezése

  • VMWare virtuálisgép-sablon létrehozása és virtuális gépek üzembe helyezése a sablonnal

  • Sablonok létrehozása alapszintű hálózatkezeléssel (ezek közé tartoznak a tartományhoz csatlakoztatott forgatókönyvek), és virtuális gépek üzembe helyezése

  • Különböző virtuálisgép-életciklus-műveleteket hajthat végre (például indítás, leállítás, leállítás, javítás, frissítés és ellenőrzőpont a virtuális gépeken).

  • Csatlakozás a virtuális gépre a konzol használatával, és ellenőrizze az akadálymentességet

  • Virtuális gépek megszüntetése

  • Hozzon létre egy erőforráskészletet, és hozza az erőforráskészletet a VMM felügyelete alá

  Ezek korlátozott forgatókönyvek. Ezek azonban a VCenter újabb verzióinak támogatása felé megtett első és legfontosabb lépést jelentik. Továbbra is a VMWare VCenter támogatási mátrixára fogunk épülni, és a jövőbeli összesítő csomagokban frissíteni fogjuk a probléma megoldását.

A kumulatív frissítésben kijavított problémák

• 1
  
  . probléma VMM-objektumok eltávolításakor 801-es hiba lép fel. A VMM néha olyan problémát tapasztal, amely miatt egy VMM-objektum, például egy virtuális gép nem távolítható el sem a felhasználói felületről, sem a PowerShell-Windows, mert a gyermekobjektumok némelyike hiányzik az adatbázisban. Ez gyakran azt eredményezi, hogy a felhasználók szervizelési szkripteket keresnek az érintett objektumok eltávolításához. A 6. kumulatív frissítésben a VMM három PowerShell-parancsmagot javított a 801-es hibák minimalizálása érdekében. Ezek a parancsmagok a Következők: Remove-SCServiceTemplate, Remove-SCLibraryServer és Remove-SCLibraryShare. A felhasználóknak nem kell a –Force jelzőt használniuk ezekkel a parancsmagokkal együtt, hogy elkerüljék a 801-et. A parancsmagok lehetővé teszik a 801-hez vezető függőségek feloldását.
  

• 2
  
  . probléma A VMM szolgáltatás összeomlik, és hozzáférés-megsértési hibát okoz System.Xml, amikor integrációs szolgáltatási eseményre válaszol.
  

• 3.
  
  probléma Kritikus kivétel a WCF hibakezelőben -- ObjectDisposedException -- Microsoft.VirtualManager.Engine.Remoting.ClientConnection.HandleError. Amikor a VMM leállítja a WCF-szolgáltatás gazdagépét, megszakítja a hívást, ami miatt a feldolgozatlan üzenetek nem biztonságosan leállhatnak, és ez ObjectDisposedExceptions kivételeket eredményezhet. A VMM legfelső szintű WCF-hibakezelője ezeket a kivételeket a folyamat leállítása előtt látja, és kritikus kivételként jelenti őket. Ezért itt a VMM ártalmatlan hibákat jelent, mivel kritikus hibák is okozhatják a felhasználók zavarát.
  

• 4
  
  . probléma A MAC-cím beállítás szürkén látható a felhasználói felületen, ha a virtuális hálózati adapter nincs csatlakoztatva. Ez megakadályozza, hogy a felhasználók statikusként jelölik meg a hálózati adaptert. Miután System Center 2012 R2-ben frissített a VMM-re, az ügyfél nem választhatja a Statikus Mac-cím lehetőséget az általa létrehozott virtuálisgép-sablonokban, ha a virtuális gép nincs hálózathoz csatlakoztatva. A MAC-cím és az IP-cím beállításai szürkítve jelennek meg, ha a virtuális gép "nincs csatlakoztatva". Ezért nem tud statikus MAC-címet hozzárendelni a virtuális géphez az üzembe helyezés előtt.
  

• 5
  
  . probléma A virtuális gépek testreszabása meghiúsulhat, és kritikus kivételt eredményezhet, ha a Hyper-V nem ad vissza hajlékonylemez-meghajtó objektumot. A virtuális gépek testreszabása során előfordulhat, hogy a Hyper-V null értékként adja vissza a Hajlékonylemez-meghajtó objektumot, és a VMM megpróbál hozzáadni egy meghajtót. A hajlékonylemez-meghajtó hozzáadása azonban nem történik meg a Hyper-V-ben. Ez kivételt eredményez, amely a feladat meghiúsulását okozza, és a virtuális gép létrehozási meghiúsult állapotában marad. A felhasználó kijavíthatja a virtuális gépet, hogy működőképes legyen. Ez akkor fordulhat elő, ha a hajlékonylemez-meghajtó konfigurációja (a távoli megosztáson) nem érhető el a Hyper-V számára, vagy ha a Hyper-V foglalt vagy stresszes.
  

• 6
  
  . probléma Nem lehet statikus IP-címmel rendelkező virtuális gépeket üzembe helyezni, ha egy virtuálisgép-alhálózathoz több IP-készlet van konfigurálva. Az ügyfél statikus IP-beállításokkal rendelkező sablonnal próbál virtuális gépet létrehozni. Ha egy alhálózatban több IP-készlet található, és az ügyfél az alapértelmezetttől eltérő készletből biztosít IP-címet (azaz a felhasználói felületen megjelenő automatikusan feltöltött készletből), akkor a virtuális gép varázslója hiba nélkül befejeződik, de a virtuális gép létrehozása meghiúsul, és "Az IP-cím kívül esik a tartományon" hibaüzenetet adja vissza.
  

• 7
  
  . probléma A VmmService összeomlik a Hyper-v által küldött IP-változási események eltávolított virtuálisgép-alhálózatainak kezelése során. Ha egy NVGRE-telepítésben a Hyper-V által az IP-módosításhoz küldött eseményt, de a virtuálisgép-alhálózat már nem létezik a VMM-ben, az a VMM szolgáltatás összeomlását okozza.
  

• 8
  
  . probléma A VMS hiányzik, mivel a VmMovedRefresherEvent nem érkezett meg. Ha egy virtuális gép áthelyezési eseménye akkor következik be, amikor egy gazdagép nincs Esemény módban, és a virtuális gép migrálási állapotban van, és amikor az eseményfrissítő csatlakozik, előfordulhat, hogy egy olyan ablak van, ahol senki sem figyel, és a frissítési művelet közvetlenül a figyelési mód előtt nem kapja meg a módosítást. Ezért a VMM nem kapja meg ezeket a módosításokat a következő teljes frissítésig, amely akár 24 óra is lehet.
  
  Az alábbi beállításkulcs létrehozásával és konfigurálásával biztosíthatja, hogy az ilyen kihagyott események szinkronizálva legyenek a könnyű virtuális gép frissítőjén keresztül esemény módban. Ehhez hozza létre és konfigurálja a következő beállításkulcsot, hogy rendszeres időközönként fusson a könnyű virtuális gép frissítője. Ez a frissítő az eseményalapú frissítők mellett fog futni.
  

  Beállításjegyzék helye:HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings
  Beállításkulcs:
  VMPropertiesEventAssitedUpdateInterval
  
  Beállításjegyzék típusa: DWORD
  
  Minimális érték: 0 másodperc
  
  Maximális érték: 20 nap

  Az értékeket másodpercekben kell megadni.
  DWORD neve: VMPropertiesEventAssitedUpdateInterval
  
  DWORD érték:value_in_seconds
  
  Megjegyzés: A value_in_seconds helyőrző értéke 0 és 20 nap között lehet (szintén másodpercben).
  

• 9
  
  . probléma Explicit jelzők megkövetelése hiányzó virtuális gép vagy szolgáltatás virtuális gép eltávolításának jelzéséhez a felhasználó Remove-Host során. A VMM jelenleg nem ellenőrzi, hogy léteznek-e virtuális gépek a gazdagépen, miközben eltávolítja a gazdagépet a VMM-ből. A gazdagépek tartalmazhatnak szolgáltatás virtuális gépeket, felhőben üzembe helyezett virtuális gépeket, valamint olyan virtuális gépeket, amelyekhez egyéni tulajdonságok vannak definiálva. Ha egy felhasználó véletlenül eltávolít egy ilyen gazdagépet, az összes társítás megszakad. Ez a javítás elkerüli az ilyen eseteket, ha megerősítést kérő üzenetet kér a felhasználóktól, mielőtt az ilyen gazdagépeket ténylegesen eltávolítanák a VMM-ből.
  

• 10. probléma
  
  Ha olyan logikai hálózattal rendelkezik, amely több hálózati hellyel rendelkezik, és a hálózati helyek láthatók a gazdagép hálózati adaptere számára, a rendszer lefoglalja a különböző hálózati helyekről származó szolgáltatói fiókokat, és meg kell adnia az útválasztási információkat is. (A hálózati helyeket néha "logikai hálózati definícióknak" is nevezik.) Több gazdagépes forgatókönyvben, amelyben a gazdagép1 virtuális gépe pa1-hez csatlakozik, akkor előfordulhat, hogy egy VM2 csatlakozik egy hnv LN-hez, és rendelkezik EGY PA1-gyel a NetwkSite1-hez, majd leválasztja, majd később újracsatlakozik, és rendelkezik egy PA2-vel a NetwkSite2-höz (véletlenszerűen vagy a PA kimerülése miatt), majd egy ideig, Előfordulhat, hogy nem töltjük fel a PA útválasztási adatait a NetwkSite1 és a NetwkSite2 között. Ez azért fordul elő, mert a belső útvonal ábrázolása kulcsként van beszúrva egy kivonattáblába.
  

• 11
  
  . probléma A gazdagép frissítésekor létrehoz egy WinRM hálózati kapcsolatot (minden egyes frissített gazdagéphez), amely folyamatosan streameli az adatokat.
  

• 12. probléma
  
  Több gazdagép virtuális hálózati adapterének létrehozásakor véletlenszerű hibák figyelhetők meg. Ha az ügyfelek több virtuális hálózati adaptert hoznak létre egy logikai kapcsoló részeként, egy vagy több virtuális hálózati adapter IP-konfigurációja meghiúsulhat.
  

• 13. probléma
  
  A felhasználó ismétlődő kulcsbeszúrást talál a HostWSManGetter.UpdateRASDCache fájlban a gazdagép frissítésekor.
  

• 14
  
  . probléma Amikor a felhasználó ellenőrzőpontokkal próbál klónozni egy virtuális gépet, a klónozási művelet befejezése után a VMM helytelenül ismeri fel az újonnan létrehozott klónozott virtuális gépet eredeti virtuális gépként, és helytelenül arra következtet, hogy a virtuális gép át lett telepítve. Ezután megpróbálja kezelni ezt a módosítást. Ezért létrejön egy további virtuális gép egy másik, hiányzó állapotú gazdagépen. A VMM úgy véli, hogy a virtuális gép más gazdagépet használ, és ez a virtuális gép a következő virtuális gép frissítéséig nem látható a TFS számára.
  

• 15
  
  . probléma A VSEM-szolgáltató frissítésekor a szolgáltató értesítések fogadására való képessége nincs jelezve az értesítési motor számára.
  

• 16- os probléma
  
  A hálózati elhelyezés összeomlik a dinamikus gazdagép-optimalizálás során. Egyes elhelyezési műveleteket feladatként kellett volna futtatni. Ha egy frissítő tevékenységben hajtja végre, a környezet null értékű. Ez az elhelyezés összeomlását okozza.
  

• 17
  
  . probléma Amikor a meghatalmazott rendszergazdák elindítják a VMM-konzolt, a VMM-konzol megnyitása több mint 4 percet vesz igénybe. Nagy környezetekben a VMM-konzol indítása késleltetve van a delegált rendszergazdák számára, amikor a rendszergazdákhoz van összehasonlítása.
  

• A 18
  
  Storage szolgáltató frissítése a lemez sofs-ra cserélése után meghiúsul.
  

• 19
  
  . probléma A VMM nem tudja frissíteni a replikát/elsődleges virtuális gépet ASR nélkül, a függőben lévő integrációs modul állapotú helyreállítási virtuális gép migrálása szintén nem hajt végre élő migrálást.
  

• 20. probléma
  
  Egy virtuális gép törlésekor az ellenőrzőpontok egyesítve lesznek a törlés előtt. Amikor a felhasználó ellenőrzőpontokkal rendelkező virtuális gépet próbál törölni, a törlés hosszú időt (akár egy órát) vesz igénybe.
  

• 21
  
  . probléma A Do futtatása művelet néha kritikus kivételt kap: DBCorruptionException.
  

• 22
  
  . probléma Egyes felhasználók ip-címtartományok helyett nagyméretű VIPAddress-készleteket használnak, hogy megkönnyítse az egyes IP-címek hozzáadását/eltávolítását. A VMM felügyeleti csomag sémája jelenleg 256 karakterre korlátozza ezt a mezőt (alapértelmezés). A felhasználók azonban ~500 karakter hosszúak lehetnek. Ezért a Discovery megszakította a VMM-OM integrációját az SCOM váratlan kivétele miatt.
  

• 23. probléma
  
  A cél RG és a cél LUN nem lesz társítva az enableRG feladat után, ha az RG/LUN-k előre lettek hozva.
  

• 24
  
  . probléma Ha az F5-átjáróeszköz meghibásodik és lecserélődik, frissítenie kell a MAC-címbejegyzéseket. Ha egy F5-eszköz RMA-t használ, és egy új MAC-címmel rendelkező új eszközre cseréli, a VMM nem tudja frissíteni az új eszköz MAC-címét.
  

• 25
  
  . probléma Lehetővé teszi, hogy a felhasználó a replika virtuális gépen bélyegezze a felhasználói identitást. A felhasználóknak frissíteniük kell a UserRole és a Owner attribútumokat a ReplicaVM-eken, de a replika virtuális gépen jelenleg minden művelet le van tiltva. Ezért nem tudják frissíteni ezt a két paramétert a replika virtuális gépeken.
  

• 26- os
  
  probléma A regisztrált SMB-megosztás nem jelenik meg célútvonal-beállításként, amikor új ha virtuális gépet helyez üzembe egy fürtön.
  

• 27
  
  . probléma Kritikus kivétel a Storage Frissítőben a replikációs szolgáltatás felderítésekor – ArgumentNullException –– SetCustomOptions.
  

• 28
  
  . probléma A Gazdagépfrissítő során a VMM lekérdezi a csapat adatait (csapatváltás vagy LBFO-csapat). Míg a csapatok lekérdezése során a VMM eléri a WSMan kivételt, ami miatt a vswitch eltűnik a konzolról.
  

• 29
  
  . probléma A MINTAVÉTEL nem támogatja a HTTPS protokollt, így a VMM nem tud figyelőszabályt létrehozni a HTTPS-hely figyeléséhez. A VMM támogatja a HTTP- és HTTP-protokollokat az LB-port konfigurációs szakaszában, de a HTTPS nem támogatott az LB mintavételi protokoll szakaszában.
  

• 30. probléma
  
  Az erőforrás tulajdonosa (SSU-felhasználó) nem jogosult hozzáférni egy erőforrás "GrantedTo" listájához, ezért nem tudja megtekinteni, hogy ki rendelkezik az erőforrással. Ha a hozzáférést biztosító felhasználó egyben önkiszolgáló felhasználó is, akkor a konzol újraindításáig nem láthatja az általuk végrehajtott módosításokat. A rendszergazdai felhasználók láthatják a módosítást, de az önkiszolgáló felhasználók esetében a GrantedToList továbbra is gyorsítótárazott eredményeket ad vissza, amíg újra nem indítják a konzolt.
  

• 31
  
  . probléma Nem lehet áthelyezni a VMM beépített migrálási folyamatával rendelkező szülőlemezeket. A felhasználó több száz virtuális géppel rendelkezik, és az összes lemez egyetlen szülőre mutat. Ezeket a virtuális gépeket egy új tárolási megoldásba a VMM blokkolja. Diff lemezek esetén, ha a hierarchia bármely elődlemezét (szülő-gyermek reláció) egy másik lemez megosztja, a lemez tárolási áttelepítését a VMM blokkolja. A Hyper-V kezelőjével azonban engedélyezve van.
  

• 32
  
  . probléma A field expectedDSColumn kritikus kivételt jelez az oszlopok eltérésére vonatkozó üzenet nyomon követése során, ami a kiszolgáló összeomlását okozza a get-scvmhost futtatásakor. Miután a kiszolgáló adatbázisa küszöbértékre frissült, az R2-kiszolgáló bizonyos esetekben nem tud vele dolgozni. Ezt a kódútvonalat egyes hálózati objektumok és ADHC-objektumok használják.
  

• 33. probléma
  
  Meglévő szolgáltatássablon felskálázásakor az azonos nevű Hyper-V virtuális gépek a VMM-en jönnek létre a System Center 2012 R2 5. kumulatív frissítésében.
  

• 34.probléma
  
  Ha a vendég virtuális gépeken Windows biztonsági frissítés 3035131 vagy 3031432 telepítve van, a VMM vendégügynöke nem futtat általános parancsvégrehajtási (GCE) parancsfájlokat, amelyeket a VMM a virtuális gépek üzembe helyezésének részeként kér. Ez több olyan forgatókönyvben is hibát okozhat, amelyben GCE-szkripteket használ az üzembe helyezéshez és a karbantartáshoz. Ha például egy VMM-szolgáltatássablont GCE-szkriptekkel próbál kiszolgálni, a rendszer a 22029-es hibakódot adja vissza.
  
  Megjegyzés: Miután telepítette System Center Virtual Machine Manger 2012 R2 6. kumulatív frissítését (vagy újabb kumulatív frissítéseit), a megadott futtató fiókhoz kötegelt feladatként kell megadnia a bejelentkezéshez szükséges jogosultságokat. E jogosultságok nélkül a vendégügynök nem tudja futtatni a GCE-szkripteket futtató fiókon keresztül.
  

• 35-ös
  
  probléma A virtuális gép élő áttelepítése meghiúsul, ha fürtözött tárolóhelyet használ CSV-ként, és a virtuális gép tárolója a CSV-n található. A Hyper-V fürt élő áttelepítése nem működik a VMM után az System Center 2012 R2 5. kumulatív frissítésében.
  

• 36-os
  
  probléma Az alaplemez elhelyezésének el kell forgnia az érvényes elhelyezési megosztások között.
  

• 37
  
  . probléma A VMM-konzol egy meglévő kiadási sztringet használhat a szolgáltatássablon másolása során. Előfordulhat, hogy a felhasználók nem tudnak szolgáltatássablont másolni egy szolgáltatássablon "Másolás" parancsával. Ennek oka, hogy a rendszergazdai konzol létrehoz egy már meglévő sztringet a kiadáshoz.
  

• 38
  
  . probléma A kapacitásáttekintő csempe hiányzik a VMM-ben a System Center 2012 R2-ben. A VMM-ben a System Center 2012 SP1-ben, a Virtuális gépek és szolgáltatások panel alatt, amikor kiválaszt egy gazdagépet, majd a felső menü áttekintésére kattint, a konzol összegző és kapacitásadatokat biztosít a kiválasztott gazdagépről. A processzormagok, a memória (GB) és a Storage (GB) részletei a 2012 R2 System Center-ben elérhetetlenné váltak.
  

• 39
  
  . probléma A VMM szolgáltatás duplikált VSID miatt összeomlik. Ritka esetekben (szinkronizálás/versenyhelyzet és véletlen számütközés) a különböző HNV virtuálisgép-alhálózatok ugyanazt a VMSubnetIdentifier-t (más néven VSID-t) kaphatják meg. Ez váratlan viselkedéshez vezet, amikor ezeket a HNV virtuálisgép-alhálózatokat használja. Az alhálózathoz csatlakoztatott virtuális gépek esetében például előfordulhat, hogy a virtuális gépek nem szerezik be a várt kapcsolatot, és nem tudnak majd ugyanazon az alhálózaton lévő virtuális gépekkel beszélni. Vagy ha az IP-címük megváltozik, az a VMM szolgáltatás összeomlását okozza.
  

• 40-ik probléma
  
  Ha egy virtuális gépet egy Load Balancer mögött helyez üzembe, az kritikus problémát okoz az elhelyezéskor:
  

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

• A 41
  
  Start menü 5. kumulatív frissítésben bevezetett lap el lesz távolítva a 6. kumulatív frissítésből.
  

• 42.probléma
  
  A virtuális gép nincs replikációs csoporthoz társítva, és nem helyezhető át replikációs csoport által védett helyre.
  

• 43- os probléma
  
  A HNV-hálózaton lévő vendég IP-cím akkor sem lesz dinamikus/dedikáltguestIP-ként megjelölve, ha a beállítások engedélyezve vannak hozzá. A hitelesítésszolgáltató feladatátvétele megszakadt. Az NVGRE-hálózathoz (HNV vendégfürt/vendég IP-feladatátvételi forgatókönyv) csatlakoztatott virtuális gépen hozzáadott/áthelyezett IP-címek esetén az IP-cím *nem* dinamikusként van megjelölve (típus = DedicatedGuestIP a VMM-ben), még akkor is, ha a virtuális gép az EnableGuestIPNetworkVirtualizationUpdates=true beállításokkal rendelkezik. Az IP-cím első hozzáadásakor/áthelyezésekor az működni fog, de az IP-cím későbbi feladatátvételei (az egyik virtuális gépről a másikra való áthelyezés) nem lesznek automatikusan észlelve. Ezért az IP-cím nem érhető el, és a virtuális gép elveszíti a kapcsolatot.
  

• 44-ik probléma
  
  A Hitachi régebbi beágyazott tárolószolgáltatója az UR5-el megszakadt. A tárolószolgáltató nem frissíthető. Ez megakadályozza a szolgáltató kezelését.
  

• 45-ös
  
  probléma Az energiaoptimalizálás időtartományának beállításakor a VMM-ügyfél összeomlik.
  

• 46-os probléma
  
  Versenyállapot áll fenn a WnvEventEntrySubscriptionObserver elidegenítésekor, ha a gazdagép kapcsolata meghiúsul.
  

• 47.probléma
  
  A CentOS 7 és a Red Hat Enterprise Linux 7 nem tudta beállítani a hálózati adapter konfigurációját DHCP használata esetén.
  
  Ez az összes Olyan CentOS 7 és Red Hat Enterprise Linux (RHEL) 7 virtuális gépre vonatkozik, amely a DHCP használatára van konfigurálva System Center Virtual Machine Manager. A DHCP-t használó CentOS 7 és RHEL 7 kiszolgálók hiányzó hálózati konfigurációs adatokkal találkoznak a Linux-kiszolgáló által használt összes Ethernet-adapterhez. Ez a probléma azért fordul elő, mert a CentOS 7 és az RHEL 7 nem rendelkezik a Linux-eszköz ifconfig telepítésével alapértelmezés szerint, a korábbi iterációkkal ellentétben. A DHCP-hálózatkezelés konfigurációs szkriptjei úgy frissültek, hogy az IP-eszköz telepítése esetén az IP-eszköz helyett az IP-eszközt használják.

A 6. kumulatív frissítés beszerzése és telepítése System Center 2012 R2 Virtual Machine Manager