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

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

• Az Windows 10 ügyféloldali operációs rendszer
  
  támogatása A frissítés telepítése után kiépítheti és testre szabhatja Windows 10 ügyféloldali Virtual Machines (VM-eket). Ez a támogatás nem tartalmazza Virtual Machine Manager-konzol telepítését Windows 10 operációsrendszer-ügyfelekre.
  
  

• Új Linux operációs rendszerek
  
  támogatása A frissítés telepítése után vendég operációs rendszerként kiépítheti és testre szabhatja a Debian 8 Linuxot.
  
  

• VMWare vCenter 5.5 felügyeleti forgatókönyvek
  
  támogatása A 6. kumulatív frissítésselbejelentettük a vCenter 5.5 alapszintű felügyeleti forgatókönyveinek támogatását. A vCenter és a VMM integrációjára és támogathatóságára vonatkozó terveink alapján bejelentünk egy szélesebb körű támogatási mátrixot a vCenter-példányok VMM-konzolon való kezeléséhez.
  
  A támogatott forgatókönyvek teljes listájáért kattintson ide.
  
  

• Több külső IP-cím támogatása Virtual Network
  
  Mostantól több külső IP-cím is hozzárendelhető egyetlen Virtual Network, ha a VMM-környezetben telepítve van a 7. kumulatív frissítés vagy egy újabb verzió.
  
  A 7. kumulatív frissítés lehetővé teszi több IP-cím beállítását a NAT-hoz a VMM-ben a PowerShell használatával. Ez a frissítés magasabb szintre emeli a képességet a veremben azáltal, hogy támogatja a VMM-et a hálórendszergazda számára.
  
  Hogyan használni ezt a funkciót?
  
  

  $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"
  Miután alaposan megvizsgálta a verem összes elemét, felismertük, hogy egy hatékony és megbízható megoldás megvalósítása további munkát igényel, és nem illeszkedik egyetlen URL-kiadásba. Ezért lehetővé tesszük több IP-cím beállítását virtuális hálózatonként egy HNV NAT-átjáró használatával, szakaszosan.
  
  A VMM jövőbeli kumulatív frissítése a teljes veremen keresztül vizsgálja meg a tulajdonságokat, és a következő funkciókat biztosítja egészen Windows Azure Pack (WAP) csomagon keresztül.
  
  

  • Új NAT-szabály hozzáadásakor a bérlő használhat egy meglévő külső címet, vagy megadhat egy újat.

  • Engedélyezheti a WAP-rendszergazda számára, hogy kvótákat állítson be a felhőben felhasználói szerepkörenként engedélyezett külső IP-címekhez.

  Tisztában vagyunk vele, hogy a kapott ügyfélvisszajelzések mennyisége alapján nagy a kereslet a funkció iránt. Azt tervezzük, hogy teljes körű támogatást nyújtunk ehhez a funkcióhoz.

• Lehetőség az árva virtuális gépek szolgáltatás- vagy virtuálisgép-szerepkörökhöz
  
  való újratársítására Ha valaha is el kellett távolítania egy olyan gazdagépet, amely üzemeltetett szolgáltatás- vagy virtuálisgép-szerepkörű virtuális gépeket, és egy varázspálca hullámát kívánta átcsoportosítani a virtuális gép szolgáltatásához vagy virtuálisgép-szerepköréhez, miután a gazdagépet újból hozzárendelte a VMM-hez, a 7. kumulatív frissítés tartalmazza a megoldást.
  
  Mostantól újra társíthat egy árva virtuális gépet a szolgáltatásához vagy a virtuálisgép-szerepköréhez, miután a gazdakiszolgálót újra hozzárendelte a VMM-hez.
  
  További információért kattintson ide.
  
  

• A VMM DHCP-bővítmény PXE-/TFP-továbbítási
  
  rendszergazdáinak támogatása, akik a PXE-től függenek a virtuális gépek vagy gazdagépek beállításához, mostantól közvetlenül a VMM DHCP-bővítményeinek használatával végezhetnek PXE-rendszerindítást.

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

• Több mint 50 gazdagép méretarányában a VMM szolgáltatás időnként összeomlik vagy leáll, és nem jelez használható kivételt.
  
  

• Hyper-V-hálózatvirtualizálás (HNV) házirendek eloszlását a rendszer nem küldi el időnként egy gazdagépnek. Ennek az az oka, hogy az adott gazdagépen aktív virtuális gépek nem tudnak hálózati forgalmat küldeni vagy fogadni a virtuálisgép-hálózaton belüli vagy azon kívüli virtuális gépekre.
  
  

• Ha egy gazdagépnek sok virtuális kapcsolója van (például 15 vagy több), a gazdagép frissítése több mint egy órát vesz igénybe.
  
  Az iteratív WSMan GET hívások mostantól optimalizálva vannak a jobb hálózati hatékonyság érdekében.
  
  

• A több átmenő lemezzel rendelkező virtuális gép frissítése a gazdagép újraindításakor meghiúsul. Újraindításkor a gazdagép időnként felcseréli a csatlakoztatott lemezeket, és a VMM néha nem kezeli a módosítást. Ez olyan helyzetet okoz, amelyben a virtuális gép használhatatlanná válik.
  
  

• A PortProfile maximális sávszélességének nullára állítása a gazdagépen nem jelenik meg a virtuális gépeken. Ennek az az oka, hogy a virtuális gépek maximális és minimális sávszélességének alapértelmezett értéke null. Emiatt kihagyja a módosításokat.
  
  

• Egy Self-Service felhasználó esetében a Feladatok panelen lévő feladatok nevei hiányoznak. A SC-GetJob parancs üres neveket eredményez.
  
  

• A szolgáltatás horizontális felskálázása nem teszi lehetővé a virtuális gép nevének újbóli felhasználását. Ha a gazdagépen üzembe helyezett szolgáltatást skálázza fel, ha megszakítja a varázslót, majd újra próbálkozik ugyanazokkal a lépésekkel ahelyett, hogy véglegesítenie kell a kibővített varázsló utolsó szakaszában, a varázsló nem engedélyezi ugyanazon gépnév újbóli használatát.
  
  

• Ha egy üres forrásfelhőt próbál eltávolítani a VMM-konzolon keresztül, az valójában nem törli a felhőt. Ebben az esetben a feladat befejeződik. A felhő azonban továbbra is látható a konzolon.
  
  

• Ha egy HNV-környezetben található szolgáltatás egy vendégfürtön, a külső világ egy virtuálisgép-hálózati átjárón keresztül csatlakozik a szolgáltatáshoz. Ha azonban a vendégfürt feladatátvétele történik (például a CA IP-feladatátvétele), a szolgáltatás már nem érhető el. A rendszer egy hibaüzenetet naplóz a VMM-feladatelőzményekben, és azt állítja, hogy az átjáró hálózati házirendjének frissítése sikertelen volt.
  
  Ennek az az oka, hogy a keresési rekordok a hitelesítésszolgáltató feladatátvételekor frissülnek a gazdagépen (amelyen a vendégfürt fut). A rekordok azonban nem frissülnek az átjárón. Ezért a HNV környezetben a belső kommunikáció működik, de a szolgáltatással folytatott külső kommunikáció nem válaszol.
  
  

• A ZH-HK nyelvi területi beállítás (hongkongi kínai) helytelen sztringként való megjelenítése CHH-ként (ZHH helyett) a VMM monitorozási csomagban. Ez a VMM felügyeleti csomagok importálása után nem területi (angol) sztringek megjelenítését okozza az Operations Manager ZH-HK területi konzolon.
  
  

• A virtuális gép nem távolítható el a szolgáltatáspéldányból. Amikor megpróbálja eltávolítani a virtuális gépet, a következő hibaüzenet jelenik meg:
  
  

  Remove-SCVirtualMachine: A VMM nem tudja eltávolítani a virtuális gépet, mert nem támogatott fürtkonfigurációs állapotban van. (Hibaazonosító: 809, részletes hiba:)
  
  Módosítsa a virtuális gép állapotát, majd próbálkozzon újra a művelettel.
  
  A feladat újraindításához futtassa a következő parancsot:
  PS> Restart-Job -Job (Get-VMMServer qpg3-vmm001 | Get-Job | ahol { $_.ID -eq "{04de37e5-d61a-4385-8860-2cac72d44d63}"})
  At line:1 char:1
  + Remove-SCVirtualMachine -VM $T 01SQL0 -force
  + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  + CategoryInfo: ReadError: (:) [Remove-SCVirtualMachine], CarmineException
  + FullyQualifiedErrorId: 809,Microsoft.SystemCenter.VirtualMachineManager.Cmdlets.RemoveVMCmdlet

  
  
  

• Ha a párhuzamos feladatátvételi teszt (TFO) fut, a VMM zárolási problémákat tapasztalhat a replikációs csoportban (RG). Ebben az esetben, ha egy másik RG megpróbál zárolni, a művelet sikertelen lesz.
  
  

• A rendszer ismétlődő számítógépneveket hoz létre a virtuális gépekhez, ha a virtuálisgép-sablonban a <név###> mintát használja. Ebben az esetben a virtuális gép üzembe helyezése meghiúsul a virtuális gép létrehozásakor.
  
  

• A tárolószolgáltató frissítése sikertelen, és nem angol nyelvű környezetben "Helytelen formátum" kivételt hoz létre, ha a szolgáltató kezeli a replikációt, és a szállító támogatja a helyreállítási időkorlát (RPO) értékeit. A tárolószolgáltató nem frissíthető. Ez megakadályozza a szolgáltató kezelését.
  
  

• A VMM-konzol véletlenszerűen összeomlik, és System.NullReferenceException kivételt ad vissza. Az előző megoldás a VMM újraindítása volt.
  
  

• Az Azure Site Recovery (ASR) használatával védett fürt virtuális gépén nem lehet dinamikus optimalizálást (DO) végrehajtani. Ez hatással van a fürt terheléselosztására.
  
  Emellett a do meghívásakor a következő hibaüzenet jelenik meg:
  
  
  
  Ez a probléma akkor fordul elő, ha bármely virtuális gép ASR-rel van védve, mert a virtuális gépen számos felhőattribútum (például RPO és felhő) van beállítva. A felhőben lévő gazdagépek azonban nem kapnak felhőhöz kapcsolódó attribútumokat. A DO során az elsődleges virtuális gép migrálása közben a gazdagépek felhőattribútumainak elhelyezését igényli, és mivel a szükséges attribútumok hiányoznak, nem talál megfelelő gazdagépet.
  
  

• A dinamikus optimalizálás (DO) nem hagyja figyelmen kívül a helyreállítási felhő leállított replika virtuális gépeit, miközben kiszámítja az új virtuális gépek kapacitáskorlátait. Ha egy gazdagépen le vannak állítva a replika virtuális gépek, a DO nem helyez át további virtuális gépeket a gazdagépre. Ez hatással lehet a fürt terheléselosztására.
  
  Ez a probléma azért fordul elő, mert az "IgnoreMemoryForStoppedReplicaVM" beállításkulcs több virtuális gép elhelyezésére szolgál, ha bármely gazdagép replika virtuális gépei leállított állapotban vannak. A DO-forgatókönyvek nem tartják be ezt a jelzőt.
  
  

• A fürtcsomópont nem helyezhető karbantartási módba, ha rendelkezik ASR-védelem alatt álló virtuális gépekkel. Ebben az esetben a következő hibaüzenet jelenik meg.
  
  
  
  

• A VMM az alábbi figyelmeztetést jeleníti meg, ha egy ASR-védelem alatt álló virtuális gép élő áttelepítése történik a fürtön belül.
  
  
  
  Bár ez az ellenőrzés csak egy puha blokk, és nem blokkolja a tényleges migrálási forgatókönyvet, a gazdagép elhelyezés alapján továbbra is nulla minősítést kap. Ez blokkolja a dinamikus optimalizálási (DO) műveletet, és végül megakadályozza a virtuális gép élő áttelepítését.
  
  

• A Trönk VLAN hálózati típusként való engedélyezésének lehetősége a VMM hálózati szolgáltatásban nem érhető el. Ha a hálózattípust VLAN-ként jelöli meg, a VMM felülírja a sávon kívül beállított trunk VLAN-beállítást.

A javítási folyamat fejlesztései

• A 7. kumulatív frissítés előtt a VMM-konzol időnként a következő hibaüzenetet jeleníti meg:
  
  

  A felügyelt kód bővítményfolyamata a következő hiba miatt nem frissíthető:
  
  A szükséges "C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\bin\AddInPipeline\HostSideAdapters" szükséges mappa nem létezik.

  
  

• Az 5. kumulatív frissítés eltávolítása nem visszaállítja a következő bináris fájlt a korábbi verzióra:
  
  

  Microsoft.SystemCenter.VirtualMachineManager.resources.dll
  
  

• Ha egy korábbi kumulatív frissítést nem emelt szintű módban telepít, az IndigoTCPport beállításjegyzékbeli értéke alaphelyzetbe áll. Ehhez a felhasználóknak manuálisan kell módosítaniuk az értéket 8100-ra. Emellett a következő hibaüzenet jelenik meg:
  
  

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Administrator Console\Settings\IndigoTCPport értéke helytelen

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