Host: Windows 11 Pro insider
Virtualizované stroje: Windows 10, Windows 11

Upozornění: VirtualBox vyžaduje vypnutou virtualizaci ve Windows, VMWare Workstation a Hyper-V ji naopak vyžadují
Ve všech typech virtualizace jsem se snažil studovat zdroje a nastavit optimální konfiguraci virtuálních strojů s ohledem na co nejlepší běh.

Proč používat virtualizaci

Vývojář - má připravený stroj s vývojovým prostředím. Pokud nastanou problémy na fyzickém počítači, jednoduše jej přenese na nový
Tester - testování nových aplikací, nových operačních systémů, aniž by to ovlivnilo fyzický počítač
Snapshoty - před jakoukoliv významnější akcí je možné vytvořit snapshot (snímek) virtuálního počítače a kdykoliv se k němu vrátit
Když se něco úplně podělá na virtuálním stroji - jednoduše nakopíruji soubory ze zálohy

Oracle Virtual Box

Donedávna jsem používal VirtualBox, protože rychlost virtualizovaného počítače byl lepší než u konkurence.
Problém nastal u Windows 11, kde jsem musel zůstat u starší verze VitrualBoxu. Poslední 6.5 i nejnovější 7 mají s virtualizovaným strojem (Windows 11) problémy. Ta starší verze jede, ale každou chvíli se to na pár sekund sekne. Po chvíli se zase rozběhne, ale na seriozní práci to není.

VMWare workstation/player

Workstation a Player jsou odlehčené verze eSXI. Player neumožňuje vytvářet Snashoty.
Po VirtualBoxu jsem přešel jsem na VMWare workstation a nějaký ten měsíc v nich na ostro pracoval. Virtuální stroje z VirtualBoxu jsem převedl vyexportováním a naimportováním do VMWare přes OTF. To proběhlo bez problémů. Oba stroje běžely, ale žádná hitparáda to není. Je to citelně pomalejší než ve VirtualBoxu. Výhodou je snadný přenos do dospělého VMWare, jednoduchá správa - stejně jako v dospělém VM Ware.

MS Hyper-V

Hyper-V jsem se vyhýbal, protože když jsem to kdysi v minulosti zkoušel (možná ještě v době Win7), tak se to v nějaké chvíli rozsypalo a už jsem to nebyl schopný dát dohromady. Výhodou je, že jako součást Windows Pro je zdarma - stačí si přidat součást OS.
Když jsem zkoušel Hyper-V pod Windows 11, byl jsem mile překvapený. Nainstaloval jsem testovací Win 11, všechno běželo krásně až do okamžiku, kdy jsem odstranil ISO, ze kterého jsem instaloval. V tu chvíli se virtuální stroj nerozběhl a požadoval medium s ISO, ze kterého jsem instaloval. Nechápu.

Konverze do Hyper-V
Po čase jsem se k myšlence použít Hyper-V vrátil a hledal možnost na konverzi existujících strojů. Ze strany MS v podstatě nic použitelného není. MS konvertor, který umí jen Generaci 1 (OS bez UEFI) a už několik let není podporovaný, forma Configuration manageru, který je placený a neběží na Windows 11 (pouze Win 10), PowerShell, který potřebuje nainstalovat podporu z Configuration manageru, která se na Win 11 nenainstaluje...

Pak jsem objevil StarWind V2V converter. Pokud stránky zrovna nefungují, najděte si to na nějakém software serveru. Krásná, jednoduchá utilitka, která umí konverzi buď do souboru, nebo rovnou vytvoří virtuální stroj v Hyper-V, zvládá i konverzi fyzického počítače do virtuálního. Poradí si s eSXI a Hyper-V.
Doporučuji si nechat vytvořit virtuální počítač někde v TEMPu a pak ho ve správci Hyper-V přesunout do finální složky s volbou vše v jedné složce. Výchozí nastavení Hyper-V totiž soubory virtuálních strojů rozstrká do různých složek (v jedné konfigurace, v jiné disky atd.) a znesnadňuje to zálohování.

Chování Hyper-V
Virtualizace pod Hyper-V se chová jinak než ostatní 2 systémy. Přirovnal bych to spíš k dospělému VM Ware, kde virtuální stroje běží na serveru a vy se k nim připojujete přes RDP nebo eSXI konzoli. Díky tomu jsem byl schopný rozjet virtuální na záložce v Remote Desktop manageru (devolutions.net) (náhrada mnou dříve používaného správce mRemote NG), jako jakýkoliv jiný spravovaný počítač. Nebo si spustíte konzoli přímo z Hyper-V managera.

Plusy
- Co se týká rychlosti, ta mne překvapila. Běží to plynule, téměř jako Windows na fyzickém počítači
- Správa paměti - stroje klidně můžete nechat běžet spuštěné na pozadí. Bez připojení spotřebovávají asi 1,5GB paměti a žádný procesor

Mínusy
Nepamatuje si velikost HOST okna a nastavit jdou pouze standardní velikosti
Pokud používáte rozšířenou relaci (abyste si mohli okno zvětšit dle potřeby), tak nefunguje autologon