KVM

From DCEwiki
Jump to: navigation, search

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.

Upozornění 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)


Samotný KVM hypervizor však řeší pouze virtualizaci na úrovni procesoru, nikoliv na úrovni zařízení. Proto bylo využito možností jiného virtualizačního nástroje - QEMU.

QEMU[edit]

QEMU bylo původně navrženo jako virtualizační nástroj, který umí emulovat nejenom hardwarové vybavení virtuálního stroje, ale také architekturu virtuálního procesoru. To je sice výhodné z hlediska vývojářů, neboť tak mají možnost vyvíjet a testovat software v izolovaném prostředí virtuálního stroje, ale velmi náročné na výkon hostitelského stroje. Oproti nativnímu prostředí hostitele je totiž zpomalení virtuálu 5 až 10 násobné. Proto původní vývojář QEMU - Fabrice Bellard - vyvíjel také jaderný modul kqemu, s nímž bylo zpomalení pouze poloviční, ovšem ten na rozdíl od QEMU nebyl open source.

Paralelně s kqemu byl po jistou dobu vyvíjen také alternativní jaderný modul qvm86, ale jeho vývoj umřel r. 2005. Oficiálně jeho vývoj skončil poté, co v lednu 2007 firma SUN uvolnila pod GPL2 licencí VirtualBox Open Source Edition (OSE). Fabrice Bellard na tuto akci reagoval tím, že v únoru 2007 uvolnil jako open source i svůj modul kqemu. Ovšem od QEMU verze 0.12.0 (uvolněné v srpnu 2009) je tento modul nepoužitelný, neboť jeho fungování je neslučitelné s možností mapování velkého množství paměti. A tak byl jeho další vývoj ukončen. V té době se však začaly začaly masově šířit stroje s podporou virtualizace přímo v procesoru.

Aby bylo možné této možnosti virtualizace využít, musel být vytvořen v linuxovém jádře tzv. hypervizor - což je vlastně jaderný modul kvm (Kernel-based Virtual Machine). Virtualizace procesoru ale sama o sobě nestačí, protože virtuální stroje se musí dělit o další fyzický hardware - bloková zařízení, síťové karty aj. A to byl okamžik, kdy se využilo možností QEMU a tak se tento nástroj od verze O.10.1 začal pozvolna měnit z pouhého emulátoru v administrační nástroj pro hypervizory. Nejprve pro hypervizor KVM a posléze (od verze 0.11.0) i pro hypervizor XEN. Využilo se takjeho rozvinutých možností řízení a monitorování virtuálního stroje, a především toho, že bylo schopné emulovat reálný hardware, který zatím nebylo možné virtualizovat na nižší úrovni. QEMU v kombinaci s KVM se pozvolna stává vážnou konkurencí vůči komerčním virtualizačním nástrojům.


Virtio ovladače[edit]

http://www.ibm.com/developerworks/linux/library/l-virtio/

Emulace hardware u QEMU nabízí mnoho možností jak vyřešit u virtualizovaných strojů problémy a kompatibilitou původního fyzického hardware. Ovšem každá emulace fyzického hardware jde na úkor výkonu, proto byl navržen paravirtualizační framework virtio, který umožil dosáhnou lepšího výkonu díky virtualizaci na úrovni hypervizoru linuxového jádra. Původně jej začal vyvíjet Rusty Russell pro své virtualizační řešení - lguest a v kernelu je od verze 2.6.25

Funguje to tak, že v rámci hypervizoru hostitele běží back-endová část ovladačů, která zajišťuje virtualizaci fyzického hardware. Disponuje-li virtuální stroj virtio ovladači, tak nemusí komunikovat přes zařízení která emuluje QEMU, ale přímo s hypervizorem.

Vlastní transport dat mezi virtuálem a hypervizorem hosta zajišťuje modul virtio_ring. Ten však "nekecá" samostatně s jednotlivými moduly, ale pouze s modulem virtio, který funguje jako virtuální sběrnice. V jádře virtualizovaného stroje se pak mohou vyskytnout následující moduly..

PCI id pro qemu/virtio zařízení[edit]

Red Hat, Inc. donates a part of its device ID range to qemu, to be used for virtual devices. The vendor ID is 1af4 (formerly Qumranet ID).

The 1000 -> 10ff device ID range is used for VirtIO devices.

The 1100 device ID is used as PCI Subsystem ID for existing hardware devices emulated by qemu.

All other device IDs are reserved.


VirtIO Device IDs

1af4:1000 network device 1af4:1001 block device 1af4:1002 balloon device 1af4:1003 console device

1af4:1004 Reserved.

  to      Contact Gerd Hoffmann <kraxel@redhat.com> to get a

1af4:10ef device ID assigned for your new virtio device.

1af4:10f0 Available for experimental usage without registration. Must get

  to      official ID when the code leaves the test lab (i.e. when seeking

1af4:10ff upstream merge or shipping a distro/product) to avoid conflicts.


virtio_blk[edit]

Zajišťuje IO operace blokových zařízení virtuálního stroje

virtio_net[edit]

Zajišťuje komunikaci virtuálních síťových rozhraní

virtio_pci[edit]

Umožňuje zpřístupnit v rámci virtuálního stroje fyzická PCI zařízení hostitele

virtio_console[edit]

virtio_balloon[edit]

Umožňuje dynamicky ze strany hostitele měnit množství dostupné paměti virtuálního stroje.

  • v jádře je tento modul od 2.6.27
  • aktivuje se volbou -balloon virtio na straně hostitele
  • deaktivace volbou -balloon none (výchozí nastavení)
  • aby bylo možné balloon použít musí být v jádře virtuálního stroje zaveden modul virtio_balloon

http://rwmj.wordpress.com/2010/07/17/virtio-balloon/

virtio_rng[edit]

Je modul který původně zajišťoval pouze protunelování zařízení /dev/random hostitele do prostředí virtuálu.

Virtuální stroje mají totiž obvykle nedostatek IO entropie, která je zapotřební u kryptovacích mechanismů, protože u nich neprobíhají standardní IO operace blokových zařízení. Později se vyřešil tento problém tak, že se potřebná data pro získání entropie tunelují do virtuálu z hosta TCP protokolem přes síťové rozhraní.

Jenže to nefunguje pokud je spojení přerušeno. Modul virtio_rng tedy jeho autor Ian Molton upravil tak, aby se nejprve pokusil toto spojení obnovit a teprve pokud se mu to nepodaří, vytvořil tunel pro /dev/random.

Modul se v jádře objevil od verze 2.6.33

http://www.mnementh.co.uk/home/projects/collabora/virtio-rng

9pnet_virtio[edit]

http://www.slideshare.net/ericvh/9p-on-kvm

Je transportní modul, který umožňuje namountovat lokální souborový systém hostitele v rámci virtuálního stroje přes souborový systém plan9.

Data lze do virtuálního stroje dostávat dvěma způsoby:

  1. prostřednictvím virtuálního blokového zařízení
  2. nebo přes síťový souborový systém

Volba na plan9 padla především pro jeho jednoduchost. Ovladač je v linuxovém jádře od verze 2.6.14, server je součástí QEMU, takže stačilo pouze dodělat tento transportní modul

Kromě tohoto modulu musí mít host zaveden také moduly 9p (ovladač pro souborový systém plan9) a 9pnet

Z hlediska výkonu je sice výkon při IO operacích ve srovnání s virtio_blk pomalejší, ale pořád lepší než kupř. při použití NFS.

Výhodou p9 je podpora pro..

  • UID/GID

Error ID Stav

  • Práva
  • Symlinky a Hardlinky
  • Soubory zařízení

Obsah manuálu[edit]

(Vpravo je uveden aktuální stav zpracování kapitoly)

KVM (kompilace QEMU)  
 
50%
KVM (hardware)  
 
00%
KVM (konfigurace sítě)  
 
80%
KVM (čas)  
 
80%
KVM (spuštění virtuálního stroje)  
 
10%
KVM (řízení přes konzole QEMU)  
 
80%
KVM (debug)  
 
20%
KVM (konfigurace CRM)  
 
00%

Doplňky

Tisková verze
Diskuze k tomuto materiálu