Virtualizace

Virtualizační metody používané v rámci DCE

VMware, původně vznikl jako virtualizační nástroj, který měl usnadnit práci vývojářům. Jako takový tedy běžel vždy v rámci jiného OS, skrz který bylo možné se dostat na jeho administrační konzoli. Teprve později (s VMware GSX serverem) se objevila administrační konzole založená na přístupu klient-server. Jelikož se fa. VMware snažila o zachovávat platformní neutralitu, založila své řešení pro přístup k virtualizovaným strojům na VNC protokolu. Využila tak s výhodou již existujícího řešení s řadou klientů pro nejrůznější platformy.

Xen, je virtualizační nástroj, který měl být původně open source variantou komerčního VMware ESX serveru. Jeho hypervizor byl - stejně jako hypervizor pro VMware ESX server - odvozen z linuxového jádra a navíc vyžadoval od virtualizovaného stroje podporu v jádře jeho OS. Proto se Xen, jehož první použitelná verze byla uvolněna v r.2003, využívá především pro virtualizaci linuxových strojů s upraveným jádrem.

Jelikož Xen neřešil nic jiného než vlastní virtualizaci a sám o sobě neobsahoval žádnou konzoli pro vzdálený přístup, nebyl nepovažován firmou VMware za konkurenci. To se však změnilo v okamžiku, kdy firmu XenSource ( která hypervizor vyvíjí ) odkoupila fa. CITRIX (22. října 2007). Hlavní parketou Citrixu byl do té doby byl aplikační server, který umožňoval sdílený přístup k aplikacím, spouštěným v rámci OS Microsoft Windows Server. Na rozdíl od nativního RDP protokolu jejich klient používá ke komunikaci patentově chráněný ICA protokol.

Citrix byl svými produkty vždy úzce spjat s Microsoftem, takže je otázkou v čí hlavě se zrodil nápad využít kapitál skrytý v možnostech ICA protokolu a vytvořit tak konkurenci vůči VMware.

Microsoft přišel v roce 2008 s vlastním virtualizačním řešením Hyper-V, postaveným na platformě Windows Server 2008. To však mělo stejný problém jako Xen, ovšem v obráceném gardu. Plnou virtualizaci bylo možné použít pouze u systémů s upraveným jádrem, zatím co při virtualizaci jiných OS se použila paravirtualizace, která pochopitelně degraduje výkon. Navíc RDP protokol používaný pro vzdálený přístup má daleko k optimalizovanému ICA protokolu.

Citrix ponechal vývoj samotného hypervizoru pod GPL licencí, ale z pochopitelných důvodů neměl zájem na vývoji otevřeného protokolu pro vzdálený přístup. Že se kují nekalé pikle, které mají za cíl z trhu vyšachovat VMware začalo být jasné když v září 2008 většinový podíl v Citrixu v tichosti získala fa. Microsoft.

KVM je zkratkou z anglického názvu této virtualizační metody Kernel-based Virtual Machine, neboli česky: "Virtualizační stroj založený na [linuxovém] kernelu". Jeho vývoj iniciovali vývojáři z fy. Red Hat prakticky ihned poté, co se ukázalo, že vývojáři Xenu nejsou příliš ochotni začlenit kód hypervizoru přímo do linuxového jádra. Red Hat, který z velké části vývoj linuxového jádra financuje, tím pádem neměl do budoucna zajištěno, že nemůže dojít k uzavření kódu hypervizoru Xenu. Tato hrozba se stala reálnou zvláště po odkoupení fy. XenSource Citrixem.

Když začal Microsoftu usilovat o rozhodující podíl v Citrixu, Red Hat - pro který byla tato akvizice přímým ohrožením ochodních zájmů - odkoupil 4. července 2008 za 107 miliónů dolarů firmu Qumramnet, která těsně předtím oznámila vývoj protokolu SPICE, který by se měl stát open source alternativou ICA protokolu. Tímto krokem Red Hat do budoucna zabránil ev. uzavření jeho vývoje.

V praxi jde o stejný virtualizační princip jako používá VMware ESX server či Xen, kdy mezi fyzickým hardware a virtuálními stroji běží tzv. hypervizor, který se stará o rozdělování fyzických prostředků hostitele mezi jednotlivé virtuály.

Na rozdíl VMware ESX serveru či Xenu, KVM nepoužívá paravirtualizaci proto procesor hostitele musí mít hardwarovou podporou virtualizace. Tuto podmínku splňují všechny 64-bitové procesory fy. AMD (včetně mobilních), ovšem u procesorů fy. INTEL to až tak jednoznačné není. Také je třeba dávat pozor na nastavení biosu, ve kterém lze podporu virtualizace vypnout (AMD), nebo naopak zapnout (INTEL)

Přístup na virtualizované stroje

Na virtualizované stroje lze přistupovat několika způsoby

1. Nativně, prostřednictvím standardních nástrojů pro vzdálenou správu (rdp, vnc) resp. poskytovaných serverových služeb (web, ftp, ssh, atd.)
2. Prostřednictvím administrační konsole na hostiteli (VMware, Xen console, Qemu console)
3. Pomocí řešení klient-server (VMware console, Citrix, Spice, VNC,...)

Nativní přístup k virtuálu

Podmínkou pro nativní přístup je funkční síťový přístup z virtuálního stroje do vnější internetové sítě.

Administrační konsole

V případě že dojde k nějakému problému s nastavením sítě, síťového zařízení, nebo služby, která zajišťuje vzdálený přístup, je takový stroj nedostupný. Pokud taková situace nastane, pak lze využít administrační konsole buď přímo na hostiteli. V případě že se problém s připojením týká i hostitele, je přístup přes lokální konzoli jediným možným.

Přístup klient - server

Aby bylo možné přistupovat k virtualizovaným strojům vzdáleně, bez ohledu na to zda samy o sobě podporují vzdálený přístup, využívají všechny virtualizační metody také (kromě přístupu přes lokální konzoli) řešení klient - server, kdy na hostiteli běží nějaká služba (démon), na kterou se lze připojit prostřednitvím klientské aplikace z jiného stroje.

Administrace virtuálních strojů

Administrace virtuálních strojů

Virtuální stroj

Virtuální stroj lze získat buď instalací z instalačního média, nebo naklonováním již existujícího virtuálního stroje.

Bloková zařízení virtuálních strojů

Virtuální stroje mohou používat:

• fyzická zařízení (HDD, CDROM,USB disk,..)
• síťová zařízení (NFS, iSCSI,..)
• virtuální bloková zařízení

Virtuální disky

Nejjednodušším formátem virtuálních blokových zařízení, který by mělo jít použít bez nutnosti konverze s jakýmkoliv virtualizačním nástrojem, je raw. Může to být bud soubor (tzv. image neboli "obraz" disku), který je bitovou kopií fyzického zařízení vytvořenou např. pomocí utility dd. Nebo "prázdný" soubor potřebné velikosti, do kterého se teprve virtualizovaný stroj nainstaluje.

Virtuální disk v raw formátu, v rámci souborového systému, rovnou obsadí veškerý prostor daný jeho velikostí. Z toho tedy plyne, že raw formát neumožňuje vytvořit tzv. "děravý" (sparse) disk, který by mohl později "narůstat", podle toho jak by do něj budou přibývat data.

Raw kopie HDD mají většinou příponu .img nebo .bin (U obrazů disků z Mac OS X můžete narazit na příponu .dmg).

Narůstající (growable) disky

Existuje několik formátů virtuálních disků, které mohou "růst". Virtualizační stroje však většinou vyžadují konverzi do nativního formátu, neboť na něj je navázána většinou např. možnost "snapshotování" aj.

Výhody rostoucího disku:

• Tím že diskový prostor není předem obsazen, lze na jeden fyzický diskový prostor umístit hned několik strojů, jejichž skutečná celková disková kapacita může daleko přesahovat kapacitu fyzického prostoru.
• Velikost celého virtuálního stroje je z hlediska hostitele mnohonásobně menší, takže lze takový stroj rychleji odzálohovat.

Nevýhody rostoucího disku:

• Tím, že se data při ukládání do virtuálního disku neustále přerovnávají, klesá efektivita IO operací virtuálního stroje. Více viz Vliv IO operací na výkon virtualizovaného stroje
• Čas od času je nutné na nabobtnalý disk pustit nějakou utilitu, která ho přerovná a zajistí aby "splasknul", což ovšem většinou nelze provést za chodu. Jde o náročnou operaci (zvláště u objemných disků) nejenom na čas, ale i výkon fyzických disků při zpracování IO operací. Někdy to může vést i k "tuhnutí" ostatních spuštěných virtuálních strojů.

Obrazy CD a DVD disků

Obrazy CD a DVD, které jsou pořízeny z datových médií většinou mají příponu .iso', ale lze se setkat i s jinými příponami, neboť některé vypalovací nástroje používají svoje vlastní specifické formáty, které je pro potřeby virtualizace nutné převést pomocí některé z utilit na surové "raw" iso. Pro konverzi lze použít buď samostatné utility (jako např. nrg2iso), nebo komplexní nástroje jako je isomaster nebo acetoneiso. Přehled těch nejběžnějších formátů s nimiž se můžete setkat:

• Vypalovací software Nero používá příponu .nrg.
• Aplikace MagicISO používá příponu .uif (Universal Image Format)
• Aplikace PowerISO používá příponu .daa (Direct-Access-Archive)
• Komprimované iso má příponu .isz
• Formát klonovací aplikace Daemon Tools s příponou .mdx (Media Data eXtended)
• Formát klonovací aplikace Alcohol 120% s příponou .mds

VMware

VMware používá pro disky svých virtuálních strojů nativně formát vmdk s příponou .vmdk. Žádný jiný formát nepodporuje, ale pro konverzi z jiných formátů má utilitu vmware-vdiskmanager.

Pro namountování virtuálního disku ve formátu vmdk lze použít utilitu vmware-mount Bohužel však tento nástroj není mezi verzemi konzistentní, a tak některé úkony paradoxně s jeho novější verzí nelze provést (např. namountování snapshotu "za živa", aj.)

VirtualBox

VirtualBox používá pro disky svých virtuálních strojů nativně formát vdi s příponou .vdi. Umí však přidat také disk ve formátu vmdk (nativní formát VMware), vhd (nativní formát Microsoftích virtualizačních nástrojů Virtual PC a Hyper-V) a hdd (formát disků virtualizačních nástrojů fy. Parallels

Pro práci s virtuálními disky a virtuálním strojem vůbec, se používá administrační nástroj VBoxManage, který umožňuje také virtuální disky překonvertovat.

Xen

Xen nemá řádný speciální nativní formát virtuálních disků a také nepodporuje žádný z "rostoucích" virtuálních formátů, pouze raw disky. V podstatě to však není ani třeba, neboť virtuálnímu stroji lze "předhodit" z DomO buď přímo zařízení, nebo logický diskový oddíl vytvořený v rámci LVM svazku.

KVM & QEMU

KVM, stejně jako Xen zajišťuje pouze virtualizaci na úrovni jádra. A samo o sobě, stejně jako Xen žádný nativní formát virtuálního disku nemá. Využívá však k tomu QEMU, které nejenom že má svůj nativní formát virtuálních disků qcow2, ale umí používat i jiné formáty virtuálních disků - vmdk, vdi, vdh, aj.

QEMU má pro práci s virtuálními disky nástroj qemu-img, který umožňuje virtuální disky konvertovat mezi různými formáty.