- Įdėtinė virtualizacija leidžia hipervizoriams ir virtualioms kompiuteriams veikti kitų virtualių mašinų viduje, maksimaliai išnaudojant aparatinę įrangą ir palengvinant sudėtingus laboratorinius darbus bei testus.
- Prieš įjungiant įdėjimą, būtina, kad pagrindiniame kompiuteryje būtų įdiegti suderinami procesoriai („Intel VT-x“ arba „AMD-V/SEV“), atnaujintos „Windows“ versijos ir „Hyper-V“.
- Tinklo ir MAC adresų klastojimas turi būti kruopščiai sukonfigūruotas, kad būtų užtikrintas stabilus įdėtųjų virtualių mašinų ryšys, ypač „IoT Edge“ aplinkose ir scenarijuose su „VMware ESXi“ arba „Azure“.
- Daugiasluoksnės atsarginės kopijos ir išteklių stebėjimas yra labai svarbūs norint palaikyti saugias, atkuriamas ir kontroliuojamo našumo įdėtąsias aplinkas.
Įdėtinė virtualizacija šiuolaikinėje įrangoje tapo beveik nepakeičiama priemone IT komandoms, kūrėjams ir instruktoriams, kuriems reikia sukurti sudėtingas laboratorijas, testavimo aplinkas ar saugumo scenarijus neužpildant duomenų centro fiziniais serveriais. Paprastai tariant, tai leidžia paleisti virtualias mašinas kitų virtualių mašinų viduje, išlaikant priimtiną našumą ir tiksliai valdant išteklius.
Be įprasto „vienos virtualios mašinos įdėjimo į kitą“, įdėtoji virtualizacija atveria duris lanksčioms „DevOps“ sistemoms, realistiškoms mokymo aplinkoms, izoliuotam saugumo testavimui ir „IoT Edge“ diegimui įvairiose platformose – nuo vietinės „Hyper-V“ iki virtualių mašinų „Azure“ ar „VMware ESXi“. Tačiau norint, kad viskas veiktų taip, kaip tikėtasi, aparatinės įrangos ir hipervizoriaus konfigūracija turi atitikti labai specifinius reikalavimus.
Kas tiksliai yra įdėtoji virtualizacija ir kodėl ji svarbi?
Įdėtinė virtualizacija reiškia virtualios mašinos gebėjimą veikti kaip virtualizacijos mazgas kitoms vidinėms virtualioms mašinoms. Kitaip tariant, fizinėje įrangoje yra aukščiausio lygio hipervizorius (pvz., „Hyper-V“ sistemoje „Windows Server“ arba „Azure Local“), o vienoje iš jos virtualių mašinų įdiegiame „Hyper-V“ arba kitą suderinamą hipervizorių, kad sukurtume daugiau virtualių mašinų.
„Hyper-V“ atveju įdėtoji virtualizacija leidžia įdiegti „Hyper-V“ vaidmenį svečio virtualioje mašinoje , kuri savo ruožtu veikia fiziniame pagrindiniame kompiuteryje su „Hyper-V“. Ši „tarpinė“ virtualioji mašina procesoriaus virtualizacijos plėtinius pateikia vidinėms virtualioms kompiuteriams, kurie elgiasi taip, tarsi būtų arčiau aparatinės įrangos, nors iš tikrųjų po jais yra keli sluoksniai.
Ši funkcija iš pradžių pasirodė „Windows Server 2016“ ir „Windows 10“, skirtose „Intel“ procesoriams , o vėliau palaikymas išplėstas iki naujesnių „Windows Server“, „Windows 11“ ir AMD procesorių versijų. Šiandien tai brandi funkcija, kurią „Microsoft“ integruoja į savo oficialią dokumentaciją ir kurią taip pat naudoja trečiųjų šalių sprendimai.
Praktinė vertė akivaizdi: naudodami įdėtąją virtualizaciją galime atkartoti gamybos aplinkas, kurti ištisus klasterius, testuoti rizikingas konfigūracijas arba imituoti daugiasluoksnius tinklus neinvestuodami į naujas lentynas ar rezervuodami duomenų centro vietos. Daugeliui įmonių sutaupytos išlaidos ir lankstumas su kaupu kompensuoja nedidelę našumo žalą.
Įprasti įdėtosios virtualizacijos naudojimo atvejai
Vienas populiariausių scenarijų – sudėtingų bandymų laboratorijų steigimas . Kūrimo ir kokybės užtikrinimo komandos gali kurti daugiapakopius programų paketus (duomenų bazes, tarpines paslaugas, sąsajas) vienoje pagrindinėje virtualioje mašinoje, o toje pačioje mašinoje talpinti visas vidines virtualias mašinas, reikalingas gamybinei aplinkai atkartoti.
Tai taip pat labai naudinga techninio mokymo ir kūrimo aplinkoje . Dėstytojai gali nustatyti pagrindinę virtualiąją mašiną (VM), kurioje kiekvienas studentas kuria savo svečių virtualias mašinas, konfigūruoja tinklus, testuoja serverio vaidmenis arba diegia konteinerius, niekada neprisiliesdamas prie įmonės „tikrosios“ infrastruktūros. Viskas yra lengvai sunaikinamoje „smėlio dėžėje“.
Kitas tipiškas panaudojimo būdas – naujų programinės įrangos versijų vertinimas ir testavimas . Užuot keisdami jautrias konfigūracijas tiesiogiai fiziniame kompiuteryje, administratoriai gali atkartoti scenarijų įdėtoje virtualizuotoje VM ir prieš diegdami gamybinėje aplinkoje patikrinti pataisas, naujus leidimus ar saugos pakeitimus.
Įdėtinė virtualizacija taip pat atlieka svarbų vaidmenį įgalinant pažangias saugumo funkcijas, tokias kaip virtualizacijos pagrindu veikiantis saugumas (VBS) arba specifinės izoliacijos, kurios remiasi hipervizoriaus funkcijomis skirtinguose lygiuose. Tai leidžia sustiprinti tam tikras aplinkas nereikalaujant papildomos aparatinės įrangos.
Daiktų interneto srityje įdėtoji virtualizacija yra labai svarbi „Azure IoT Edge“, skirta „Linux“ ir „Windows“ scenarijams , kai reikia derinti „Windows“, „Linux“ konteinerius ir hipervizoriaus galimybes skirtinguose virtualizacijos sluoksniuose, tiek lokaliai, tiek trečiųjų šalių platformose, tokiose kaip „VMware ESXi“ arba virtualiose mašinose „Azure“.
Įdėtinės virtualizacijos aparatinės ir programinės įrangos reikalavimai
Kad visa tai veiktų tinkamai, pirmasis filtras yra suderinama aparatinė įranga ir minimalios operacinės sistemos versijos . Pavyzdžiui, „Azure On-premises“ aplinkose reikalinga 2411.3 arba naujesnė versija, taip pat virtualios mašinos, kurių konfigūracijos versija yra 10.0 arba naujesnė, taip užtikrinant reikiamų virtualizacijos plėtinių palaikymą.
Procesoriaus lygmeniu, jei dirbate su „Intel“, labai svarbu, kad BIOS / UEFI būtų įjungta „Intel VT-x“ virtualizacijos technologija . AMD architektūroms reikalingas AMD-V palaikymas, o sudėtingesniais atvejais turi būti įjungta saugios šifruotos virtualizacijos (SEV) technologija, kuri prideda šifravimą VM ir pagerina izoliaciją bei žemo lygio saugumą.
Pagrindinė operacinė sistema turi būti moderni „Windows Server“ arba „Windows 10/11“ versija , tinkamai atnaujinta su naujausiais pataisymais. Prieš bandant įjungti įdėjimą, fiziniame kompiuteryje turi būti įdiegta „Hyper-V“; tai nėra funkcija, kuri tampa standartine vien tik turint suderinamą procesorių.
Kitas svarbus dalykas yra virtualių mašinų būsena. Norint keisti procesoriaus parametrus ir atskleisti virtualizacijos plėtinius, VM, veikianti kaip įdėtasis pagrindinis kompiuteris, turi būti visiškai išjungta , nepristabdyta ar išsaugotoje būsenoje. Tik tada „Hyper-V“ leidžia keisti išplėstines virtualaus procesoriaus parinktis.
Galiausiai, tinklo ryšys turi būti kruopščiai suplanuotas. Įdėtosioms virtualioms kompiuteriams gali reikėti išorinės prieigos arba prieigos prie kitų lygių, todėl patartina iš pat pradžių apibrėžti, ar bus naudojami vidiniai komutatoriai, NAT, MAC adreso klastojimas ar kiti virtualaus tinklo metodai, siekiant išvengti ryšio ir filtravimo problemų.
Įjunkite įdėtąją virtualizaciją „Hyper-V“ sistemoje naudodami „PowerShell“
Tiesioginis ir detaliausias būdas įjungti įdėtąją virtualizaciją „Hyper-V“ sistemoje yra naudoti „PowerShell“ cmdlet . Šis metodas veikia tiek „Windows Server“, tiek suderinamuose kliento leidimuose ir leidžia nuosekliai automatizuoti konfigūraciją keliuose pagrindiniuose kompiuteriuose arba virtualiose mašinose.
Pirmas žingsnis – įsitikinti, kad virtuali mašina, kurioje norime įdiegti „Hyper-V“ kaip svečias, yra išjungtas iš „Hyper-V Manager“ (Išjungimo parinktis) arba naudojant atitinkamą komandą „PowerShell“, pavyzdžiui Stop-VM -Name 'NombreVM'Jei jis lieka sustabdytas arba išsaugotos būsenos, procesoriaus pakeitimai nebus pritaikyti teisingai.
Kai VM sustabdyta, turite pateikti procesoriaus virtualizacijos plėtinius svečio operacinei sistemai naudodami „ Set-VMProcessor“ cmdlet , nustatydami parinktį „ExposeVirtualizationExtensions“ į reikšmę „true“. Šis nustatymas leidžia sistemai iš VM matyti funkcijas, reikalingas hipervizoriaus vaidmenims įdiegti.
Norėdami patikrinti, ar operacija buvo pritaikyta teisingai, lauke „ExposeVirtualizationExtensions“ galime naudoti „Get-VMProcessor“ kartu su „Select“ . Tai patikrina, ar tikslinės VM virtualiojo procesoriaus konfigūracijoje reikšmė nustatyta kaip „true“, ir neleidžia paleisti iš dalies sukonfigūruotos aplinkos.
Jei bet kuriuo metu prireiktų atkurti konfigūraciją, pavyzdžiui, atliekant diagnostikos užduotį arba dėl to, kad nebereikalingos įdėtosios virtualios mašinos, tiesiog pakartokite tą pačią procesoriaus cmdlet , bet pakeiskite reikšmę į „false“, o tai vėl išjungs virtualizacijos plėtinių prieigą svečio virtualioje mašinoje.
Kai virtualus procesorius sukonfigūruotas, įrenginys įjungiamas naudojant „Start-VM“ arba iš „Hyper-V Manager“ . Svečio operacinėje sistemoje visas „Hyper-V“ vaidmuo įdiegiamas įprastais metodais: serverio tvarkytuvu (pridėti vaidmenis ir funkcijas), DISM, „PowerShell“ ir kt. Nuo to momento VM administratoriaus požiūriu veikia kaip papildomas „Hyper-V“ pagrindinis kompiuteris.
Tinklo konfigūracija ir MAC adreso klastojimas įdėtosiose aplinkose
Baigus procesoriaus dalį, kitas žingsnis yra įdėtųjų virtualių mašinų tinklo prijungimas . Jei norime, kad vidinės virtualios mašinos galėtų bendrauti su kitais tinklais, internetu arba aukštesnio lygio kompiuteriais, būtina pakoreguoti tam tikrus tarpinės virtualios mašinos virtualaus adapterio parametrus.
„Hyper-V“ sistemoje įprasta įjungti MAC adreso klastojimą VM, veikiančio kaip įdėtasis mazgas, tinklo adapteryje. Ši funkcija leidžia vidinėms VM siųsti srautą naudojant savo MAC adresus per tą patį adapterį, apeinant blokavimą ar filtravimą fizinio mazgo virtualiame komutatoriuje.
Šį koregavimą galima atlikti naudojant „PowerShell“ komandą „Set-VMNetworkAdapter“, kurios „MacAddressSpoofing“ parametras nustatytas kaip „Įjungta“, ir pritaikytas atitinkamam VM tinklo adapteriui. Tai užtikrina, kad aukščiausio lygio hipervizorius neprarastų srauto iš gilesnių VM.
Sudėtingesnėms konfigūracijoms patartina iš anksto sukurti virtualių komutatorių ir NAT instancijų topologiją kiekviename sluoksnyje. Pavyzdžiui, galime derinti vidinius komutatorius, kad izoliuotume laboratorijas, maršruto parinkimo taisykles ar ugniasienes tarp sluoksnių, ir NAT tarpiniame pagrindiniame kompiuteryje, kad suteiktume prieigą prie interneto kelioms įdėtoms virtualioms mašinoms jų tiesiogiai neatskleidžiant.
Dirbant su keliais virtualizacijos sluoksniais, ryšio problemos dažnai susijusios su išjungtu MAC adresų klastojimu, netinkamai sujungtomis NAT taisyklėmis arba pernelyg ribojančiomis užkardomis . Peržiūrėjus šiuos punktus ir iš naujo paleidus tinklo adapterius ar paslaugas kiekviename sluoksnyje, dauguma ryšio problemų įdėtosiose aplinkose paprastai išsprendžiamos.
Grafinės sąsajos naudojimas susijusioms užduotims
Nors griežtas įdėtosios virtualizacijos aktyvinimas yra visiškai kontroliuojamas iš „PowerShell“, praktiškai daugelį susijusių užduočių patogiau atlikti naudojant „Hyper-V Manager“ grafinę sąsają , ypač jei valdome kelis pagrindinius kompiuterius arba norime vizualiai peržiūrėti konfigūraciją.
Įprastas darbo procesas apima „Hyper-V Manager“ atidarymą, tikslinės virtualios mašinos paiešką ir jos išjungimo užtikrinimą naudojant išjungimo parinktį. Tai papildo „PowerShell“ naudojimą ir apsaugo nuo atsitiktinio virtualios mašinos, kurios parametrai dar nėra tinkamai sukonfigūruoti, paleidimo.
Kai bus įvykdytos reikiamos cmdlet, skirtos virtualizacijos plėtiniams atskleisti, galėsime grįžti į grafinę aplinką ir atidaryti VM konfigūracijos langą . Iš ten lengva peržiūrėti ir modifikuoti tinklo adapterio ypatybes, priskirtų virtualių procesorių skaičių arba įdėtajai pagrindinei VM prieinamą atmintį.
MAC adreso klastojimo įjungimo parinktis yra tinklo adapterio išplėstiniuose nustatymuose . Ją įjungti per grafinę sąsają yra greita ir aišku administratoriams, kurie renkasi vizualinį požiūrį arba kurie neįsiminė visų cmdlet parametrų.
Kai ši konfigūracija bus baigta, kasdienį aplinkos valdymą galima atlikti pakaitomis iš „Hyper-V“ konsolės fiziniame kompiuteryje arba įdėtojoje virtualioje mašinoje , naudojant standartinius įrankius naujoms virtualioms mašinoms kurti, komutatoriams konfigūruoti, vaidmenims pridėti arba momentinėms kopijoms daryti pagal kiekvienos laboratorijos poreikius.
Įdėtoji virtualizacija „Azure On-Preme“ ir „IoT Edge“ scenarijuose
„Azure On-Premise“ aplinkose įdėtoji virtualizacija remiasi tais pačiais principais, tačiau prideda konkrečius versijos reikalavimus ir palaiko pažangias funkcijas, tokias kaip AMD SEV arba saugos plėtinius . Reikalinga minimali sistemos versija (2411.3 arba naujesnė), o virtualios mašinos turi naudoti suderinamą konfigūracijos versiją (10.0 arba naujesnę).
Dirbant su „Azure IoT Edge for Linux“ sistemoje „Windows“, yra trys palaikomos įdėtosios virtualizacijos diegimo parinktys . Kiekviena iš jų atitinka skirtingus infrastruktūros poreikius ir organizacijos pageidaujamą kontrolės lygį pagrindinėje aplinkoje ir hipervizoriuje.
Pirmasis variantas apima „IoT Edge“ diegimą „Windows“ virtualioje mašinoje vietiniame pagrindiniame kompiuteryje naudojant „Hyper-V“ . Tai paprasčiausias būdas: toje „Windows“ virtualioje mašinoje įjungiama įdėtoji virtualizacija, o tada „Azure IoT Edge for Linux“ įdiegiama ir konfigūruojama sistemoje „Windows“ pagal konkrečią „Microsoft“ dokumentaciją.
Šiuo atveju labai svarbu užtikrinti, kad „ Hyper-V“ vaidmuo būtų teisingai įdiegtas vietiniame pagrindiniame kompiuteryje („Windows Server“ arba „Azure Local“) . Jei pagrindiniame kompiuteryje nebus aktyvus „Hyper-V“, svečio virtualioji mašina negalės veikti kaip įdėtasis hipervizorius arba papildomame sluoksnyje atskleisti „IoT Edge“ reikalingas funkcijas.
Šio tipo diegimai yra labai naudingi, kai reikia integruoti daiktų interneto įrenginius, „Linux“ konteinerius ir „Azure“ paslaugas į esamą „Windows“ infrastruktūrą, išlaikant pagrįstą pusiausvyrą tarp lankstumo, našumo ir paprasto valdymo.
Įdėtinė virtualizacija naudojant „VMware ESXi“ ir „Azure IoT Edge“
Kitas įdomus scenarijus iškyla, kai norime paleisti „Azure IoT Edge for Linux“ sistemoje „Windows“ virtualioje mašinoje, talpinamoje „VMware ESXi“ . Šiame kontekste įdėtoji virtualizacija remiasi „VMware“ hipervizoriaus, o ne tiesiogiai aparatinėje įrangoje esančio „Hyper-V“, galimybėmis.
„VMware ESXi“ 6.7 ir 7.0 versijose yra aiškiai numatytas aparatinės įrangos virtualizacijos palaikymas svečių sistemose , leidžiantis atlikti įdėjimą, reikalingą „Windows“ virtualiai mašinai tapti „Hyper-V“ pagrindiniu kompiuteriu. „VMware“ dokumentuoja šią funkciją savo žinių bazėje, išsamiai aprašydama reikalavimus ir galimus našumo aspektus.
Bendroji procedūra pirmiausia apima „Windows“ virtualios mašinos sukūrimą „ESXi“ pagrindiniame kompiuteryje , laikantis standartinių „VMware“ rekomendacijų dėl procesorių, atminties, saugyklos ir tinklo adapterių. Sukūrus virtualią mašiną, ji išjungiama, kad būtų galima modifikuoti jos išplėstinius procesoriaus nustatymus.
„ESXi“ arba „vSphere Client“ sąsajoje pasirinkite „Windows VM“, eikite į „Redaguoti nustatymus “ ir skiltyje „CPU nustatymai“ raskite skyrių „Aparatinės įrangos virtualizavimas“. Ten įjunkite parinktį „Atskleisti aparatinės įrangos virtualizavimą svečio operacinei sistemai“ , kuri leis „Windows“ matyti VT-x/AMD-V plėtinius, net jei sistema veikia „ESXi“ viduje.
Išsaugoję pakeitimus ir paleidę VM iš naujo, tęskite „Hyper-V“ hipervizoriaus diegimą sistemoje „Windows“ – kliento versijoje („Windows 10/11“) arba „Windows Server“, įtraukdami valdymo įrankius ir visus papildomus komponentus, reikalingus konteineriams ar paslaugoms, kurios bus naudojamos su „IoT Edge“.
Įdėtoji virtualizacija „Azure“ virtualiose mašinose
Kai scenarijų perkeliame į aukštesnį lygį ir dirbame tiesiogiai su virtualiomis mašinomis „Azure“ platformoje kaip įdėtajame virtualizacijos serveryje , atsiranda platformos ypatumai, ypač susiję su virtualiais komutatoriais ir numatytuoju tinklu, kurį naudoja „Azure“ virtualios mašinos.
„Azure IoT Edge“, skirta „Linux“ sistemoje „Windows“, nelaikoma iš esmės palaikoma jokioje „Azure“ virtualioje mašinoje, kurioje veikia serverio SKU, nebent būtų paleistas specialus scenarijus , leidžiantis įjungti tinkamą virtualų jungiklį. Šis scenarijus atidaro numatytąjį jungiklį, kuris leidžia „IoT Edge“ aplinkai tinkamai veikti su papildomu virtualizacijos sluoksniu.
Oficialioje „Microsoft“ dokumentacijoje aprašomi veiksmai, kaip sukurti ir konfigūruoti virtualų komutatorių, skirtą „Linux“ sistemai „Windows“ sistemoje „Azure“ kontekste, taip suderinant konteinerių ir „Edge“ paslaugų tinklo reikalavimus su debesies tinklo infrastruktūros charakteristikomis.
Šio tipo diegimuose ypač svarbu peržiūrėti VM SKU, saugyklos tipą ir procesoriaus bei RAM kvotas , nes įdėtoji virtualizacija prideda savo pridėtines išlaidas, o vidinės VM gali intensyviai naudoti išteklius, jei visas rinkinys nėra tinkamo dydžio.
Nepaisant šių sudėtingumų, nauda yra didelė: „Azure“ virtualioji mašina gali būti naudojama kaip „IoT Edge“ sprendimų testavimo, kūrimo ar ikigamybinė platforma tomis pačiomis sąlygomis, kurios vėliau bus atkartotos fiziniuose periferiniuose įrenginiuose arba pramoniniuose šliuzuose, dislokuotuose lauke.
Įdėtųjų „Hyper-V“ virtualių mašinų atsarginių kopijų kūrimas naudojant specializuotus sprendimus
Kuriant įdėtąsias virtualizacijos aplinkas, vienas aspektas, kuris dažnai pamirštamas, yra atsarginių kopijų kūrimo ir atkūrimo po avarijų strategija . Čia praverčia įmonės lygio atsarginių kopijų kūrimo sprendimai, galintys tinkamai valdyti „Hyper-V“ aplinkas su keliais virtualizacijos sluoksniais ir keliomis lygiagrečiai veikiančiomis platformomis.
Tarp šių sprendimų yra tokie įrankiai kaip „Vinchin Backup & Recovery “, palaikanti daugiau nei penkiolika skirtingų virtualizacijos platformų, įskaitant „VMware“, „Proxmox“, „oVirt“, „OLVM“, „RHV“, „XCP-ng“, „XenServer“, „OpenStack“, „ZStack“ ir, žinoma, „Hyper-V“. Šio tipo programinė įranga skirta heterogeninėms infrastruktūroms, kuriose kartu egzistuoja įvairių gamintojų hipervizoriai.
Tokios funkcijos kaip nuolatinis papildomas atsarginių kopijų kūrimas, duomenų deduplikavimas ir glaudinimas bei detalus atkūrimas žymiai sumažina saugyklos sunaudojimą ir laiką, reikalingą atskiriems kompiuteriams, konkretiems failams ar net konkretiems objektams atkurti iš svarbių programų.
Be to, suplanuotos atsarginių kopijų kūrimo politikos ir archyvavimo juostose arba debesyje parinktys padeda pritaikyti atsarginių kopijų kūrimo strategiją prie kiekvienos organizacijos norminių ar vidinių reikalavimų, išlaikant ilgus saugojimo laikotarpius nepadidinant saugojimo išlaidų našiuose masyvuose.
Žiniatinklio pagrindu veikianti valdymo konsolė labai supaprastina „Hyper-V“ aplinkų su įdėtosiomis virtualiomis mašinomis apsaugą: pasirenkate virtualias mašinas, kurias norite apsaugoti, pasirenkate atsarginių kopijų saugyklą, apibrėžiate vykdymo strategiją (laiko intervalus, atsarginių kopijų tipą, saugojimą) ir paleidžiate užduotį. Daugelis šių sprendimų siūlo išsamius kelių savaičių trukmės bandomuosius laikotarpius, kad būtų galima įvertinti jų našumą ir integraciją su esama infrastruktūra.
Įdėtųjų aplinkų apribojimai ir geriausia praktika
Nors įdėtinės virtualizacijos galimybės yra plačios, egzistuoja ir techniniai apribojimai, kuriuos lemia pačių hipervizorių dizainas , kuriuos reikėtų suprasti nuo pat pradžių, kad būtų išvengta netikėtumų gamyboje ar didelio prieinamumo scenarijuose.
Aiškus pavyzdys yra virtualių mašinų tiesioginė migracija naudojant įdėtąją virtualizaciją . Šiuo metu neįmanoma atlikti pagrindinio pagrindinio kompiuterio tiesioginės migracijos, kai jo virtualiose mašinose yra svečių serverių, kurie priklauso nuo aktyvaus įdėjimo. „Microsoft“ dokumentuoja šį apribojimą, ir bendra rekomendacija yra planuoti atnaujinimus ar pagrindinių kompiuterių perkėlimą su kontroliuojamais išjungimais šiose aplinkose.
Išteklių suvartojimo stebėjimas keliuose sluoksniuose reikalauja kombinuotos strategijos. Patartina naudoti „Hyper-V Manager“, našumo skaitiklius ir cmdlet, pvz., „Get-VM“ , aukščiausio lygio pagrindiniame kompiuteryje ir tuo pačiu metu naudoti panašius įrankius įdėtajame pagrindiniame kompiuteryje, kad būtų aiškus vaizdas, kaip apkrova paskirstoma procesoriui, atminčiai, tinklui ir saugyklai.
Kai vidinė VM staiga praranda tinklo ryšį, tai paprastai rodo, kad viename iš susijusių adapterių yra išjungti užkardos taisyklių pakeitimai, NAT problemos arba MAC adreso klastojimo nustatymai . Visų lygių patikrinimas, konfigūracijos patvirtinimas ir paveiktų tinklo paslaugų paleidimas iš naujo paprastai išsprendžia daugumą šių sutrikimų.
Prieš diegiant įdėtąją virtualizaciją, geriausia praktika yra aiškiai apibrėžti aplinkos tikslą, sluoksnių skaičių, vykdomų darbo krūvių tipus ir atsarginių kopijų kūrimo politiką. Šis pradinis projektas nulems, ar laboratorinė arba bandymų aplinka bus tvari ilguoju laikotarpiu ir netaps painiava, kurią sunku prižiūrėti.
Trumpai tariant, įdėtinė „Hyper-V“ ir kitų platformų virtualizacija leidžia gauti daug daugiau naudos iš esamos įrangos ir lanksčiai nustatyti laboratorinius, testavimo, saugumo ar „IoT Edge“ scenarijus, jei tik atsižvelgiama į procesoriaus reikalavimus, sistemos versiją ir tinklo konfigūraciją, o visa tai lydi gera stebėjimo ir atsarginių kopijų kūrimo strategija.
