:::: MENU ::::

HYPERCON 2.0 se blíží

Již za dva dny začíná konáním v Novém Jičíně pokračování mé konference HYPERCON zaměřené na Hyper-V a související technologie. Na konci ledna hned navážeme pražským termínem. Můžete se opět těšit na maximum zajímavých informací a praktických ukázek. Pokud jste se ještě nezaregistrovali, tak neváhejte – počet volných míst velice rychle klesá. Registraci na pražšké konání otevřeme již brzy.

Přípravy jsou samozřejmě již v plném proudu, vlastně již téměr v cíli 🙂 Laby jsou připravené a prezentace vyladěné. Tento rok se na vás chystáme i s hardwarem, na kterém všechny ukázky budou probíhat. Tento ročník (do Prahy) máme také dva hosty a to ze společnosti DELL (CZ) a Orange Networks (DE).

Těším se na Vás!

Více informací na http://www.hypercon.cz

 


Hledám posilu do System Center teamu

Je to už nějaká chvilka, co jsem se přesunul do spol. KPCS a mám na starost implementace System Center a souvisejících technologií. Jelikož máme práce víc než dost, tak hledám posilu do svého System Center teamu! Pokud máte zkušenost s nasazením a správou především SCCM, SCOM, SCSM a SCDPM, tak jste možná ten/ta, koho/kterou hledáme. Více informací najdete na webu KPCS zde.


Sledování využití CPU uvnitř Hyper-V VM

Skoro na každém školení nebo přednášce se zmíním o tom, jak Task Manager lže nebo o tom, že nemáte sledovat využití prostředků performance countery uvnitř VM.

Proč lže task manager?

Témeř v každé verzi Windows Serveru nebo Windows klienta byl nějaký problém se zobrazováním dat v task manageru. Od 2008 do 2012 R2 vám bude uvnitř VM ukazovat vždy maximální hodnotu paměti jakou VM nafoukne během svého celého běhu. To samozřejmě mluvím o Dynamic Memory.

Hyper-V 2016 se dokonce chystá i možnost snížení statické paměti za běhu VM. V tom případě opět task manager uvnitř VM zas nesníží paměť, kterou zobrazuje v horní části. Podobných příkladů bych našel ještě více.

A proč nemáte monitorovat VM „zevnitř“, ale použít Hyper-V performance countery?

Nejdříve trochu k architektuře. Hypervisor nad sebou spravuje dva typy partitions – root partition a child partitions. Root je specifická v tom, že spravuje fyzické zařízení, řídí podřízené child partitions, zajišťuje endpoint pro správu atd., prostě se stará o vše kromě procesorového času a přidělování paměti. To má na starost samotný hypervisor, který běží níže na ringu -1.
Child Partition reprezentuje VM. Tedy prostředí, kde běží virtuální počítač.

Root ani child partitions nekontrolují APIC (programovatelný kontroler přerušení), Power Management Timer, správu adres, atd., což znamená, že nemají žádnou reálnou představu o čase, který je jim tedy dodáván virtuálně. Ano, i root partition (tedy hlavní řídící OS nedostává skutečný čas z HW). Tomu navíc nepřidává ani to, že virtuální procesory využívají fyzické procesory přepínaným přístupem.

Teď k samotným performance counterům. Co se týče procesoru, tak asi nejvíce známý je % Processor Time. Ten detailně ukazuje celkové množství CPU využité procesem. Nepočítá čas, kdy CPU nic nedělá (je idle).

Když teda např. mrkneme uvnitř totálně zatížené VM na tenhle counter, tak uvidíme využití CPU na 100%.

Pokud se ale v tu samou chvíli podíváme na „hezčí“ counter na úrovni root partition – Hyper-V Hypervisor Guest Run Time – tak tam uvidíme číslo menší (cca 80%)!!!

Jak to? Který tedy ukazuje správnou hodnotu? Z pohledu architektury oba. Z pohledu skutečného využití prostředků vůči fyzickému hardware má pravdu ten Hyper-V counter. Proč?

Counter uvnitř VM říká toto – systém konzumuje 100% procesorového času, který mu hypervisor dal, tedy pokaždé, když hypervisor přidělil čas, tak ho systém všechen využil. To je pravda přece, ne? VM opravdu žere 100% dodaného času do virtuálního procesoru.

Jelikož ale hypervisor má ještě v rezervě nějaký čas, který tráví přepínáním a který má k dispozici i pro jiné VM, tak ukazuje číslo nižší.

Podobně zvláštně se to bude chovat i s counterem % Processor Time na úrovni root partition. Opět nebude říkat úplně správná čísla, jelikož jeho pojem o čase je také zkreslený. Je proto tedy nutné sledovat Hyper-V Hypervisor Logical Processor. Logický procesor odpovídá jednomu vláknu (pokud máte fyzické CPU s podporou HT (hyperthreading)), které zatežuje jádro.

Závěrem dodám, že pokud bychom se bavili o sledování prostředků např. Microsoft SQL Server uvnitř VM, tak nemáte jinou možnost než použít SQL performance countery uvnitř VM. Komplexní obrázek využití prostředků základních komponent (paměť, procesor, disk a síť) dostanete vždy ale jen z root partition.

 


Sítě v Hyper-V Clusteru

Jinými slovy, sítě potřebné pro Windows Failover Cluster (WFC) sloužící k provozu vysoce dostupných VM.

V dnešním článku se zaměřím právě na sítě, které potřebujete k provozu stabilního Hyper-V clusteru. Sítě clusteru se v základu dělí na 3 typy:

  1. Síť využitá pouze pro cluster komunikaci.
  2. Síť využitá jak pro cluster komunikaci, tak připojení vnějších zařízení (klientů).
  3. Síť, na které je cluster komunikace zakázána.

Zvolení vhodného typu sítě lze provést přímo přes Failover Cluster Manager (dále jen FCM) nebo za použití PowerShellu (property Role na objektu Cluster Network, Get-ClusterNetwork).

Aby bylo jasné toto rozdělení, uveďme si pár příkladů.

  1. Cluster Heartbeat
  2. Cluster Management
  3. iSCSI konektivita

V rámci jednotlivých nodů clusteru je každý Hyper-V host připojen do těchto cluster sítí pomocí virtuálních adapterů WFC. Tyto koncové endpointy jsou interpretovány NetFT (Network Fault-Tolerant) adapterem (v Device Manageru ho najdete pod skrytým zařízením „Microsoft Failover Cluster Virtual Network Adapter“). Ten byl zaveden od Windows Server 2008 v rámci naprosto přepsaných funkcionalit WFC a jsou pomocí něj zajištěny klíčové funkce.

MAC toto adapteru je vytvořena z MAC fyzického adapteru. Ovladačem je Cluster Virtual Miniport Driver (netft.sys), který běží v kernel modu (ring 0) a běží vždy současně s cluster službou.

Když prozkoumáte IP konfigurace tohoto síťové rozhraní, tak najdete na IPv4 nastavenou APIPA a na IPv6 Link-Local adresu. Není potřeba tyto adresy jakkoli měnit (ani to není obecně dobrý nápad dělat), jelikož veškerá tato komunikace je tunelována přes odpovídající validní síťové rozhraní.

Co se týče „tvrdých“ požadavků na sítě v Hyper-V clusteru, tak existuje jen jediný: mít dostupné minimálně dvě sítě pro cluster komunikaci.

Díky tomu je NetFT spolu s dalším komponentami (Topology Manager, FTI, Interface Manager) schopen například postavit celou routovací strukturu, aby byla zajištěna maximální míra vysoké dostupnosti.

Není samozřejmě nejvhodnější konfigurace postavit cluster pouza na dvou sítích, protože je pak např. nedostatečně zajištěna potřebná šířka pásma pro jednotlivé typy komunikace a tím hrozí snížení vysoké dostupnosti.

Typy samotných komunikací v rámci clusteru lze rozdělit takto:

  1. Cluster komunikace
  2. Komunikace pro správu clusteru
  • Komunikace VM
  1. Live Migration
  2. Komunikace na úložiště
  3. Komunikace Hyper-V Replica

Nejdůležitějším požadavkem pro následné samotné rozdělení na logické sítě je existence odlišných dedikovaných sítí. Nelze v rámci WFC definovat sítě pro rozdílné typy komunikace na identických subnetech.

Pro oddělení cluster komunikace se používá již zmíněné nastavení na začátku článku. V rámci této sítě “tečou” i jedny z nejdůležitějších komunikací clusteru – cluster heartbeat (HB). Ty jsou malé, ale velice citlivé na latenci. Pokud neprojde HB z jednoho nodu na druhý, může být tato situace interpretována jako výpadek nodu. Je tedy také ještě velmi vhodné nastavit pomocí QoS prioritu (802.1p PCP hodnota) na komunikaci na portu, který HB používá (unicast UDP 3343) pomocí PowerShellu (New-NetQoSPolicy –IPDstPort 3343 –Piority 6)

Pro zvolení sítě pro správu je vhodné ještě toto nastavení kombinovat s určitou formou zabezpečení komunikace (které možná stejně je požadáno), čímž jste následně schopni tuto komunikaci rozpoznat.

Komunikace VM není v rámci clusteru nutné žádným způsoben definovat, jelikož se jedná o data tekoucí přes rozhraní, které nemá vůbec aktivní TCP/IP stack (externí Hyper-V switch) a proto není clusterem jakkoli využívané.

Live Migration (LM) je v rámci funkcionalit Hyper-V samotného možné nastavit na TCP (výchozí stav je s komprimací) nebo SMB (s využitím SMB Direct v případě použití síťových karet podporujících RDMA). Oddělení komunikace je nastaveno přímo v FCM, kde se checkboxy volí požadované sítě pro LM, nebo pomocí PowerShellu, kde se naopak nastavuje parametr sítí, které nemají být použity pro LM (Set-ClusterParameter –Name MigrationExcludeNetwork).

Komunikace s úložištěm může být částěčně dána přenosovým médiem a protokolem (např. v případě FC tedy není opět nutné nic oddělovat, jelikož se nejedná o síť s TCP/IP). Pokud se jedná o blokový přístup (např. iSCSI), tak je vhodné na těchto sítích zakázat cluster komunikaci (opět viz. začátek článku). Pokud se jedná o SMB úložiště, tak je tok dat řízen pomocí SMB Multichannel, kde pomocí PowerShellu opět vymezíme dedikované sítě (New-SMBMultichannelConstraint).

K omezení komunikace Hyper-V replikace lze použít jedině trvalé statické routy (route add –p).

Trochu ošemetnou otázkou ještě zůstává, co dělat s metadaty a případným redirected přístupem u Cluster Shared Volume (CSV). Důležitou částí odpovědi je fakt, že od Windows Server 2012 používá CSV vždy pro metadata SMB protokol, tedy konkrétně SMB Multichannel. Tím je zajištěn maximální možný výkon v případě redirected accesu (tedy funkci, která se používá, když některý z nodů clusteru ztratí přímý přístup k úložišti). Jelikož SMB Multichannel je použit i pro metadata, použije se síť, které má povolenou SMB MC komunikaci. Pokud není dostupná žádná síť s SMB MC, tak je zpětně komunikace přepnuta na NetFT. V tom případě se použije cluster síť s nejnižší metrikou. Metriky si ve výchozím stavu řídí cluster sám automaticky, ale je možné je nastavit na vlastní hodnotu (Get-Cluster Network). Vhodné je také nastavit opět QoS obecně pro SMB (New-NetQoSPolicy –SMB –MinimumBandwidthWeightAction).

Závěrem bych ještě rád upozornil na to, že vaše Hyper-V servery mohou (a v mnoha případech by měly) mít další typy komunikace, které bude nutné/vhodné izolovat v rámci clusteru (např. backup). Nezapomínejte také na závislosti jendotlivých používaných funkcí, které celkově značně ovlivňují síťovou architekturu WFC (např. NIC Teaming vs. SMB Multichannel, FCoE, HNV apod.)


Kolik dat upraví sysprep?

Dělal jsem teď měření, kolik dat se změní v OS, když projde sysprepem. Budu průbežně info aktualizovat, jak se dostanu k dalšímu OS.

  • Windows Server 2016 TP4 („Core“ edition) = 1 118 208 kB

Není to úplně málo, co říkáte? Je asi jasné, že to dost záleží například i na hardware, který musí OS detekovat. Naměřené hodnoty jsou z VM na Hyper-V.


Jak vzdáleně povolit PowerShell Remoting

Anglicky by ten titulek zněl ještě líp – How to remotely enable PowerShell Remoting 🙂

Samozřejmě to nejlépe uděláte přes GPO například. Pokud to ale potřebujete ihned, tak můžete použít PSEXEC (ať žije Mark! :))

A pak už to valí a můžete třeba přes Enter-PSSession jít na CLIENTPC1 a powershellit.


OneDrive připojený jako síťový disk

Od Windows 10 máme „skvělý“ nový engine OneDrivu, který neumí on-demand stáhnout soubor z cloudu a musíte si tedy navolit, které složky chcete synchronizovat. Problém je v tom, že složky/soubory, které nesynchronizujete, neuvidíte na disku vůbec. Škoda, tuhle funkci jsem měl v předchozí verzi rád.

Já si teda ještě mapuji svůj OneDrive jako network drive. Jak na to?

  1. Přihlašte se přes onedrive.com na svůj onedrive.
  2. Klikněte vlevo v navigaci na Soubory (Files)
  3. Nyní by URL měla vypadat nějak takto: https://onedrive.live.com/?id=root&cid=00AAB3D7DDF12AF7
  4. Vykopírujte si z URL to poslední ID. V mém příkladu tedy 00AAB3D7DDF12AF7
  5. Teď klasicky ve File Exploreru namapujte nový disk svými OneDrive credentials pomocí cesty: https://d.docs.live.net/00AAB3D7DDF12AF

A je to. Enjoy!


Povolení Isolated User Modu ve WS 2016 TP4

Isolated User Mode je funkce, která zajišťuje, aby určitá security related data (např. NT Hash, kterou drží v paměti proces LSASS.EXE) byla managována izolovanými procesy pomocí Virtual Secure Modu. VSM je paměťově kompletně oddělený prostor OS a funguje pomocí HW virtualizace stejně jako Hyper-V.

IUM povolíte třeba PowerShellem takto:


Jak vytvořit Nano Server VM ve Windows Server 2016 TP4

Co potřebujete?

  • Instalačku Windows Server 2016 TP4 (ISO)
  • Lokální disk s adresáři (třeba D:\ a D:\Hyper-V)

Jak vytvořit VHDčko pro Nano Server VM?

  1. Mountněte ISO WS 2016 TP4. Řekněme, že se připojí jako disk E:.
  2. Spusťte PowerShell konzoli a použijte příkazy:
    1. cd E:\NanoServer
    2. Import-Module  .\NanoServerImageGenerator.psm1
    3. New-NanoServerImage -MediaPath E:\ -BasePath .\Base -TargetPath D:\Hyper-V\nano1\nano1.vhd -ComputerName nano1 -GuestDrivers
      • MediaPath ukazuje na písmenko jednotky, která reprezentuje ISO WS 2016 TP4
      • BasePath je pracovní dočasný adresář, kde se bude vyrábět VHDčko
      • TargetPath je adresář, kam to vyhodí výsledné VHDčko
      • ComputerName je vnitřní název OS virtuálky
      • GuestDrivers je přepínač, proto tam není žádná hodnota, který říká, aby se injectly ovladače potřebné pro běh Nano Serveru ve virtuálce
  3. Výsledkem bude v TargetPath VHDčko (opravdu je to VHD a ne VHDX) o velikosti cca 450 MB.
  4. Teď už můžete jednoduše vyrobit VM s použitím tohoto VHD. Dejte pozor, že to musí být Generation 1 VM. Stačí jí naprosto 512 MB paměti.

Jak nastavit Nano Server VM?

Hodně věcí se dá udělat rovnou s použitím autounattend.xml souboru, který injectnete do VHD během jeho vytváření. Pokud si ale chcete pohrát, můžete použít PowerShell Direct.

Nano Server má téměř nulové GUI. Tady je pár screenshotů:

Zapněte tedy Nano Server VM a na hostiteli použijte následující PowerShell příkazy:

  1. Enter-PSSession -VMName Nano1
  2. Do okna zadejte credentials pro připojení – tedy Administrator a heslo, které jste zadali v cmdletu New-NanoServerImage
  3. Get-NetIPAddress vám ukáže aktuální IP adresaci
  4. New-NetIPAddress -InterfaceAlias ‚Ethernet‘ -IPAddress 192.168.88.55 -PrefixLength 24 vám nastaví statickou IP adresu
  5. Set-DnsClientServerAddress -InterfaceAlias ‚Ethernet‘ -ServerAddresses 192.168.88.11 vám nastaví DNS server

Pro přidání do domény nemůžete použít Add-Computer cmdlet, jelikož v Nano Serveru není potřebný modul. Musíte ted provést offline domain join:

  1. Na nějaké stanici v doméně si vyrobíte BLOB objekt: djoin.exe /provision /domain domain.local /machine nano1 /savefile .\odjblob
  2. Výsledný blob po síti nebo přes Copy-VMFile přenesete do VM a v ní spustíte: djoin /requestodj /loadfile c:\Temp\odjblob /windowspath c:\windows /localos
  3. Uděláte restart třeba přes shutdown -r -t 0
  4. Nakonec zavřete session Exit-PSSession

Pokud byste opravdu chtěli použít Copy-VMFile, tak postup je následující:

  1. Musíte si povolit Guest Services a to buď v Hyper-V konzoli na Nano VM v Integration Services a nebo PowerShellem Enable-VMIntegrationService -VM (Get-VM nano1) -Name ‚Guest Service Interface‘
  2. Zkopírujete si BLOB pomocí Copy-VMFile -Name ‚nano1‘ -SourcePath D:\odjblob -DestinationPath C:\ -FileSource Host

Další nastavování už je buď klasický PowerShell nebo si jen v Nano povolíte na firewallu remote management a použijete vzdáleně konzole.


Co je nového ve Windows Server 2016 TP4 (Hyper-V)

Už v listopadu 2015 byl uvolněn Technical Preview 4 pro Windows Server 2016. Další zlomový okamžik pro všechny, co se těší na příští verzi Windows Serveru. Co je v TP4 nového kolem Hyper-V?

  1. Nano Server
    • Vylepšení oproti TP3
    • Podpora kontejnerů
    • Podpora nested virtualizace (Hyper-V v Hyper-V)
    • Pro ty, co neví co to je – ultra ořezaný OS, který nemá žádné GUI (ani příkazovku) a tak jeho režie je cca 120 MB paměti a 450 MB dat na disku.
    • Pro ty, co se toho bojí ještě víc než se teď bojí Core Edice, mám skvělou zprávu – bude to preferovaný typ OS pro Hyper-V hostitele. Takže co teď? Hybaj se naučit PowerShell!
  2. Podpora režimu Connected Standby
    • Surface 4 a podobné devices používají nový AOAC režim. Hyper-V tak nemá problém běžet ani na nich.
  3. Discrete Device Assignment
    • Možnost „protáhnout“ z fyzického hostitele PCIe zařízení do VM. Především se teď jedná o NVMe a GPUčka.
    • Tato funkce nemá nic společného s Processor Affinity nebo podobně, které používají konkureční platformy.
  4. Hot Add paměti a síťovky
    • Lze měnit velikost přidělené virtuální paměti (VM Static Memory) za běhu. A to jak přidávat, tak odebírat. Task Manager ve VM z toho dost blázní.
    • Lze přidávat a odebírat virtuální síťovky (VM Network Adapter) za běhu. VM přitom nejde do pauzy.
  5. Vylepšená Hyper-V konzole
    • Podpora WS-MAN protokolu (konečně!)
    • Podpora alternativního přihlašování. Moc se hodí pro konzultanty, jako jsem já.
    • Podpora správy starších verzí Hyper-V, ale jen do Hyper-V 2012 (Windows 8/Windows Server 2012). Jestli máte ještě starší Hyper-V, tak už je opravdu čas udělat upgrade.
  6. Instalace Integration Services
    • Už to nejde přes Hyper-V konzoli. Hyper-V hostitel už ani nemá v System32 adresáři náš oblíbený soubor vmguest.iso.
    • Bude se instalovat klasicky přes Windows Update
  7. Secure Boot pro Linuxy
    • Do teď byl podporávan pro Secure Boot jen WS 2012+ a Windows 8 x64+
  8. Samotná nested virtualization
    • Na tuhle funkci čekám od existence Hyper-V. Když si totiž potřebujete postavit Hyper-V lab, tak máte jen 2 možnosti – mít hoodně fyzického železa nebo použít VMware Workstation. Teď už ale rozjedete v Hyper-V virtuálku a v ní můžete nainstalovat Hyper-V a v něm vytvořenou virtuálku zapnout. Podporovány jsou i krásy jako NVGRE, Live Migration atd. atd. Má to ale několik limitů – ta virtuálka, co simuluje Hyper-V hostitele nemůže používat Dynamic Memory, CheckPointy, Saved State apod. To ale nevadí – už teď mám na svém domácím serveru postavený díky tomu Hyper-V lab se Scale-out File Serverem.
  9. Síťová vylepšení
    • SET. Zní to jak nějaká ultra vědecká funkce, ale je to jen podpora teamingu přímo na úrovni Hyper-V switche. Dnes je možné použít pro Hyper-V switch taky teamované adaptery, ale musí se nejdříve udělat team pomocí NIC Teaming funkce.
    • RDMA podpora pro síťovky připojené k Hyper-V switchi.
    • Rozšířené možnosti nastavování QoS pro různé typy komunikací (aneb SDN, neboli Software Defined Networking, v SDDC, neboli Software Defined Data Center).
  10. Production CheckPoints
    • Nejdříve je potřeba si říct, že aktuální CheckPointy nejsou na některých workloadech nepodporované a hlavně obecně nedoporučované (viz tady). Naše známé CheckPointy se budou ve WS 2016 jmenovat Standard (buďte rádi, čekal jsem, že je pojmenují Legacy nebo Deprecated nebo tak, aby je nikdo už nikdy nechtěl použít) a budou fungovat pořád tak, jako dnes. Nové Production CheckPointy jsou ale samozřejmě lepší a jsou nastavené by default. Fungují obdobně jako Standard, akorát že pro konzistentní propis dat používají ještě navíc VSS (takže klasicky přes IS do VM volají request).
  11. Rolling Cluster Upgrade
    • Strašně se mi ten název líbí! Je to vylepšení procesu upgradu Hyper-V clusteru zaživa, jako jsme už viděli při migraci 2012 na 2012 R2. Tam šla Live Migration ale udělat je jedním směrem – verzí nahoru. Teď můžete VM migrovat tam i zpět, ale po tu dobu nemůžete používat krásné nové 2016 funkce. Celé je zařízeno přes verzi VM (pozor VERZI! ne generaci!), která nás doteď moc nezajímala, protože Hyper-V dělalo auto upgrade verze při importu VM, a taky přes Cluster Functional Level (což je něco jako DFL/FFL v ADčku, resp. má to podobné dopady).
  12. Shielded VM
    • Dřív byl nejsilnější ITík ten, kdo měl v AD Enterprise Admina. S virtualizací už je ale nejsilnější ten, kdo má admina na Hyper-V hostech, jelikož může třeba vykopírovat VHDčka DCček a dělat pak offline útoky na AD databázi nebo se může připojovat adminům (kteří jsou hloupí) přes VMConnect do virtuálek apod. Shielded VM je kombinace několika security funkcí – virtuálního TPM chipu (novinka ve 2016) (čímž tedy můžete BitLockerovat data uvnitř VM), Host Resource Protection (taky novinka) a Secure Bootu. Díky tomu už Hyper-V admin nemá plnou kontrolu nad VM…. Rozlučte se tedy ale s klasickým troubleshootingem takových VM, protože jsou to pak super blackboxy.
  13. Storage QoS na SOFSu
    • Teď nastavíte Storage QoS na virtuálním disku. Má to mraky nedostatků: co když chci nastavit limit per VM/private cloud/oddělení/zákazníka, co když chci nastavit limit per logický (no asi trochu zavádějící, ale lépe to popsat nejde) disk? Nelze. Microsoft sice nepřišel s tím, že jde nastavit Storage QoS na úrovni CSV disku (to si asi nechává do další verze), ale aspoň to budete moci nastavit na úrovni Scale-Out File Serveru. Problém je, že v ČR SOFS nikdo moc nepoužívá…
  14. Formát konfig souboru VM
    • Ještě když Hyper-V nebylo úplně Hyper-V a celé to bylo moc podobné VirtualPC, které MS koupil s celým Connectixem, tak byla celá konfigurace VM v souboru VMC. Pak se ale řeklo, že to je blbost, že přeci vše má MS v XML, tak i VM musí mít XML. Teď se ale přišlo na to, že se v tom XML admini vrtaj a že je to vlastně celé k ničemu a že bude lepší udělat zbrusu nový převratní binární formát konfig souboru, který bude mít koncovku (světě div se) VMCX. Taky se mění VSV a BIN stavové soubory na VMRS (RS = Runtime State).
  15. PowerShell Direct
    • Pro admina nejlepší funkce ze všech. Vezmete cmdlet Invoke-Command třeba a pustíte ho z hostitele s parametrem VMName. Tím zavoláte daný ScriptBlock přímo ve VM. A v ní NEmusíte mít povolený PowerShell Remoting!!! Cool, co? A víte, na co je to také řešení? Na ten zpropadený Nano Server, který nejde nijak moc nastavovat.

Průbežně sem přihazuji další features, tak si klidně post někam uložte a mrkněte za měsíc nebo tak znovu.

A jestli vás to zajímá více, tak přijďte na HYPERCON!!!


Stránky:1234567...23