Virtualizace je technologie umožnující provozovat více nezávislých virtuálních strojů na jednom fyzickém stroji. Potřeba virtuálních strojů vznikla jako odpověď na problematiku vývoje a debuggingu OS, která je v případě fyzického stroje obtížně řešitelná. V dnešní době se však objevují další důvody, proč provozovat virtuální systém - bezpečnostní a ekonomické.
Bezpečnostní důvody zahrnují především problematiku izolace procesů. Částečně je tento problém vyřešen technologií cgroups a jmennými prostory, ani jedna z těchto technologií ovšem není dostatečně vyvinutá a absolutně spolehlivá. Mission critical aplikace jsou tudíž provozovány na samostatných strojích, kde je garance, že při případném selhání bezpečnostních mechanismů izolace procesu nedojde k získání oprávnění zasahovat do dalších procesů podobné důležitosti.
Ekonomické důvody jsou úzce spojeny s důvody bezpečnostními, je-li potřeba vlastnit jeden fyzický stroj na každou aplikaci (při horizontálně škálovaných aplikacích pro každou instanci), rostou náklady na nákup a provoz HW. Jejich růst je také ovlivněn potřebou pokrýt maximální možné zatížení aplikace, kde při vysokých výkyvech v jejím používání je nutno vlastnit HW schopný zpracovat zatížení nejvyšší, zatímco práve tento HW je při nižším zatížení nepoužitý.
Virtualizovat lze několika způsoby, lišícími se od sebe výkonem, složitostí řešení a požadavky na HW. Nejméně výkonná ale bez speciálních požadavků je plná virtualizace. V rámci plné virtualizace (emulace) se snažíme na hostitelském systému vytvořit prostředí, které se pro virtuální zdroj tváří jako nějaký kus HW a stejně tak se i chová, ovšem zpracování požadavků vůči tomuto HW je realizováno hostitelským prostředím, často pouze procesorem.
Paravirtualizace je pokročilé řešení vyžadující podporu na úrovni HW (Intel VT-x), které dovoluje paravirtuálním zařízením přistupovat k fyzickému HW jen s minimální režií navíc. To se nejvíce projevuje na výkonu, který je oproti plně virtualizovanému řešení vyšší o jednotky až desítky procent. Je důležité zmínit, že paravirtualizovaná může být např. jen část virtuálního zdroje, konkrétně jenom některé zařízení. Bez ohledu na rozsah paravirtualizace je potřeba i podpora z virtualizovaného OS, u kterého se očekává přítomnost ovladačů pro paravirtualizovaná zařízení (u KVM virtio).
Samotná zařízení mohou být ještě hlouběji integrována s HW hostitelského zdroje pomocí tzv. passthrough. Je to technologicky nejnáročnější metoda, která kromě VT-x vyžaduje i VT-d (příp. AMD-Vi) podporu u CPU a chipsetu. U této metody dochází při startu virtuálního stroje k unbindu driverů pro dané zařízení na hostitelském stroji a jejich připojení k VFIO driveru, který je skrze IOMMU schopen fyzické zařízení propagovat přímo. Takové zařízení je výkonnostně pouze cca o 2-5 % níže než bez VFIO, což je oproti virtualizovaným nebo paravirtualizovaným řešením nejvyšší výkon. Tato metoda se používá převážně pro síťové karty (SR-IOV) a GPU, kde je dosažení takového výkonu jinak nemožné ale zárověň vyžadované nebo např. hostitelský systém nemá dostatečnou podporu pro zařízení (případ GPU v Linuxu).
Použití virtuálních strojů v kombinaci se síťovým úložišťěm pro jejich disky (NFS, iSCSI, GlusterFS) přináší zajímavou funkcionalitu unikátní pro virtualizované prostředí: možnost migrování strojů. Virtuální stroj je v takovém prostředí na svůj hostitelský stroj vázán prakticky pouze příznaky hostitelského CPU, a je tedy reálné aby takové stroje své hostitele měnili, jsou li virtuální CPU příznaky podmnožinou CPU příznaků cílového hosta. Je-li tato podmínka splněna, je stroj vhodný k migraci. Migrovat lze offline i za běhu, tzv. live. Offline migrace probíha pouze zastavením činnosti virtualizovaného stroje a jeho opětovným spuštěním na cílovém hostovi. Live migrace probíha za běhu VM, a jejím hlavním cílem je přenést RAM VM na cílového hosta. V první řadě musíme logovat příznak stránek, přenést celou RAM a poté stránky s příznakem - pokud jsou značeny dostatečně pomalu, aby byli přenášeny po sítí, může se migrace finalizovat - VM zničit na zdrojovém hostovi a spustit na cílovém.
Pro administraci KVM/QEMU stacku můžeme použít několik nástrojů - libvirt, virt-manager, oVirt, Proxmox aj. Nejnižším a často jinými nástroji využívaným nástrojem je libvirt, což je knihovna a prostředek k ovládání QEMU, nabízející CLI i rozhraní pro mnohé programovací jazyky (C, C++, Python, Java aj.). Libvirt je postaven na XML, kdy jednomu VM (doméně) odpovídájí dvě XML definice - XML pro tvorbu a XML existující domény. VM skrze libvirt je tedy definován skrze XML soubor, který můžeme pomocí CLI prostředku virsh spustit (virsh start $NAME.xml), čímž vzniká virtuální stroj ($NAME.xml). Definiční soubory jsou uchovány v /etc/libvirt/qemu/, zatímco soubory běžících VM ve /var/run/libvirt/qemu. Doména se ukončuje příkazem virsh destroy, a příp. další funkcionalitu zjistíme příkazem virsh help.
Kontejnerizace je pokus o virtualizaci za použití menšího množství systémových zdrojů. Jedná se např. o technologií LXC, která pomocí cgroups a namespaces vytváří kontejner, který má vlastní pohled na strom procesů, id uživatelů, síť apod. Tímto je dosaženo určité izolace vůči ostatním procesům bez nutnosti provozovat celý operační systém pouze kvůli jedinému procesu. Docker je systém využívající LXC jako backend a přidává standardizovaný formát kontejnerů a jasně daný proces jejich správy a nasazení. Jeho výhody jsou kratší start kontejneru v porovnání s VM a výkon velmi blízko k výkonu samotného hosta.
Docker využívá tzv. union FS pro tvorbu kontejnerů - kontejner je tak tvořen ro obrazem a rw vrstvou, kam probíhá zápis diferencí. Docker samozřejmě nabízí prostředky, jak z tohoto kontejneru vytvořit nový obraz včetně všech diferencí a to dokonce za použití systému git. Každá diference vůči obrazu lze příkazem docker commit přidat k samotnému obrazu, čímž vzniká obraz nový. Ten lze příkazem docker tag tzv. otagovat - pojmenovat a nastavit jeho cílové registry. Poté zbývá docker push, což je nahrání obrazu do docker registry a tudíž jeho zpřístupnění ostatním strojům.
Vytváření a spouštění (nebo obecněji lifecycle) obrazu je v Dockeru realizován příkazy docker run, docker start, docker stop, docker rm(i)...
Vzhledem k faktu, že Docker je poměrně mladý projekt, vzniká mnoho nástrojů pro jeho správu (především orchestraci) různých stupňů kvality. Za zmínku stojí orchestrátory Project Atomic a Kubernetes, trochu jiný cíl má geard - integrace Dockeru do systemd a tedy možnost provozovat kontejnery jako služby. Lze také využívat samotné LXC (např. skrz libvirt), kde je ovšem obsluha řádově složitější.