QEMU (bloková zařízení)

Z DCEwiki
Verze z 16. 12. 2015, 10:35, kterou vytvořil Keny (diskuse | příspěvky) (→‎Formáty virtuálních disků)
(rozdíl) ← Starší verze | zobrazit aktuální verzi (rozdíl) | Novější verze → (rozdíl)
Skočit na navigaci Skočit na vyhledávání

Blokové zařízení lze u QEMU do virtuálu přidat několika způsoby. Původně se to dělalo takto:

Poznámka
-hda /dev/sda1

Tímto způsobem se používaly soubory s virtuálními disky v dřevních dobách virtualizace. A dá se využít i dnes, pokud chceme jen tak narychlo otestovat nějaké LiveCD. Bohužel to má své omezení:

  • pro virtuální disky lze použít pouze ide rozhraní - ve virtuálu je pak disk vidět jako /dev/hda (hda,hdb,hdc,..); pro CD mechaniku je parametr -cdrom
  • QEMU používá při propagování souboru (nebo zařízení) do virtuálu pouze výchozí parametry

drive

Aby bylo možné nastavit další parametry (typ sběrnice, použití kešování, atp.), byla do QEMU přidaná volba -drive. I když se původně používala jak k nastavení parametrů pro backend i frontend, v současné době se používá výhradně pro nastavení backendových parametrů - tj. parametrů, které ovlivňují nastavení blokového zařízení na straně hostitele virtuálu.

Poznámka
-drive file=/dev/sda1,if=ide,cache=writeback,aio=threads

device

Konfigurace všech parametrů blokového zařízení prostřednictvím jedné volby se časem ukázala nedostatečná. Proto došlo k rozdělení voleb do dvou skupin. Parametry backendové, tj. ty, které týkají nastavení mimo virtualizační prostředí. A frontendové, které mají vliv na to, jak se zařízení tváří uvnitř virtuálního stroje. Pro tuto skupinu parametrů byla zavedena nová volba -device s identifikátorem drive, kterým obsahuje identifikátor id blokového zařízení nastaveného volbou -drive.

V následujícím ukázkovém příkladu konfigurace je identifikátorem ide0-hd0 a výsledný efekt je stejný jako u toho nejjednoduššího připojení virtuálního disku, jak bylo demonstrováno hned v úvodu.

Poznámka
-drive file=/dev/sda1,id=ide0-hd0,if=none,cache=writeback,aio=threads \
-device ide-drive,bus=ide.0,drive=ide0-hd0

Lokální bloková zařízení virtualizačního stroje

qemu block device.svg

Protunelování lokálních blokových zařízení se dnes, v době velkokapacitních disků, moc nepoužívá. Čistě teoreticky bychom mohli tímto způsobe spustit ve virtuálním prostředí systém z jiného diskového oddílu, nebo nějaký obstarožní systém ze staršího HDD. Ovšem i v takovém případě je lepší nejprve z disku udělat pomocí dd obraz disku (image) a systém spustit z něj.

Jako lokální blokové zařízení může být do virtuálního stroje připojeno..

  • lokální raid pole - zařízení typu md
  • Master DRBD (síťové pole typu RAID1) - zařízení typu drbd
  • diskový oddíl vytvořený v rámci LVM skupiny - zařízení typu dm
  • soubor připojený přes loop - zařízení typu loop
  • blokové zařízení vypublikované z jiného stroje přes NBD server - zařízení typu nbd

NBD

Řeší koncept připojení blokového zařízení ze vzdáleného stroje po síti. Více viz samostatný manuál k NBD.

qemu block nbd simple.svg
qemu block nbd complicate.svg

QEMU má integrované NBD API, takže umí vzdálené blokové zařízení publikované přes NBD server zpropagovat do virtuálu jako blokové zařízení přímo - viz schéma nalevo.

Jenže NBD je v zásadě velmi jednoduchý protokol, který neřeší ověření vzdáleného serveru. Ani si nehlídá stav připojení. U NBD se totiž předpokládá, že tohle ohlídá klient, který v případě, že se připojení ke vzdálenému serveru přeruší udělá reconnect, jenže tohle QEMU neumí.

Situaci může do určité míry vyřešit zpropagováním několika NBD disků a vytvořením RAID pole uvnitř virtuálu. Má to několik výhod a zcela zásadní nevýhodu. Výhodné je, že se nic nestane, když některé ze zařízení odpadne - virtuál to neshodí. Pokud odpadnou všechny naráz, tak se taky nic neděje. Jsou mnohem rychlejší I/O operace v prostředí virtuálu, protože jsou paralelizovány mezi na více fyzických strojů (NBD serverů). Ovšem to zas na druhou stranu žere výkon virtuálního procesoru a také virtuální paměť.

Kardinální nevýhoda pro sestavení RAID pole z NBD zařízení přímo ve virtuálu je daná tím, QEMU zařízení které odpadlo, znovu připojí až při úplném restartu stroje - nestačí k tomu pouze interní reboot virtuálního systému. Ten by stačil pouze v případě, že by to byl disklessový stroj, který by si NBD server připojoval interně sám na své vlastní NBD zařízení. Navíc - zařízení, které skončilo ve stavu fail je třeba znovu přidat a resynchronizovat - ať již manuálně nebo skriptem - uvnitř v prostředí virtuálu.

qemu block nbd raid.svg

Lepší je přistupovat na vzdálený NBD server přes NBD zařízení virtualizačního prostředí. Pro QEMU je to pak blokové zařízení jako každé jiné. Ještě lepší je obzvláště z hlediska I/O výkonu sestavit z NBD zařízení RAID pole.

Takové řešení bylo ze všech testovaných absolutně nejvýkonější. A bylo schopné nabídnout nepřetržitý provoz virtuálního stroje, ovšem pouze za předpokladu, že byla odstávka (nebo výpadek) některého z NBD serveru včas ošetřena.

Tímto způsobem bylo možné vytvořit relativně stabilní a výkonné virtualizační prostředí nad nestabilním hardware.

Upozornění Zásadním problémem RAID polí nad NBD je ale skutečnost, že je třeba dávat velký pozor při řešení situace kdy odpadne připojení NBD serveru k NBD zařízení, které je zařazené do RAID pole. Představuje to velmi choulostivý proces s velkou pravděpodobností výskytu fatální chyby, která může vést ke ztrátě dat. Stačí k tomu jeden malý překlep. Viz popis fatální havárie stroje support ze dne 21. července 2012 na stránce Peanuts
Poznámka Nevýhodou je, že s blokovým zařízením, se kterým pracuje virtuálu již nemůže pracovat nikdo jiný, pokud to neumožňuje jeho souborový systém - podobně je tomu i u iSCSI (internet Small Computer System Interface - síťová verze SCSI), nebo AoE (ATA over Ethernet technologie.)

Virtuální disky

qemu block image.svg

Qemu umí zpropagovat do prostředí virtuálu nejenom skutečné blokové zařízení, ale skrze různá api také obsah souboru který se pak tváří jako virtuální disk.

Formáty virtuálních disků

Qemu umí pracovat s virtuální disky různých formátů, které ještě ke všemu nemusí být ve formě běžného souboru. Proto má k dispozici nástroj qemu-img, který lze kromě konverze virtuálních disků používat i k identifikaci použitého formátu a jeho parametrů

Poznámka Identifikace virtuálního disku uloženého jako běžný soubor. Stejným způsobem lze zjistit parametry virtuálního disku i přímo na stroji, který je jedním z bricků GlusterFS svazku, kde je uložen:
root@stroj~# qemu-img info /path_to_file/soubor.img

Pro identifikaci virtuálního disku přes API GlusterFS je ovšem třeba použít stejné nastavení, jaké se používá pro připojení virtuálního disku z GlusterFS svazku do virtuálu. Tímto způsobem lze provést identifikaci z libovolného stroje, na kterém je nainstalován GlusterFS klient:

root@stroj~# qemu-img info gluster+tcp://192.168.0.2/volume_name/soubor.img

Identifikaci virtuálního disku uloženého ve VDI Sheepdogu, lze provést pouze skrze jeho API:

root@stroj~# qemu-img info sheepdog:192.168.0.2:8000:vdi_name

U virtuálního disku vypublikovaného přes NBD server je třeba věnovat zvýšenou pozornost tomu zda-li je dotazován správný server na správném čísle portu, protože NBD nepoužívá žádný jiný identifikátor, ani ověřovací mechanismus, který by vyloučil záměnu s jiným virtuálním diskem:

root@stroj~# qemu-img info nbd:192.168.0.2:8000
192.168.0.2
IP adresa nodu ze kterého se virtuální zařízení připojuje. V případě, že se příkaz qemu-img info spouští na tomto nodu, lze použít místo IP adresy localhost
8000
Číslo portu na kterém naslouchá démon, nebo server. Sheepdog používá výchozí port 7000, ale může být provozovován i na jiném portu, pokud by hrozila kolize s jinou aplikací. NBD server, pokud je exportováno více zařízení může naslouchat na různých portech.
raw
je v podstatě obyčejný soubor s daty ve stejné podobě, jako by byly na blokovém zařízení. Soubor o velikosti 5G zabere toto místo bez ohledu na to, jestli obsahuje nějaká užitečná data, nebo prázdné místo.
qcow
se od raw formátu liší v tom, že může být přírůstkový, takže postupně narůstá - to je výhodné u souborových systémů, které nepodporují "díry" jak např. FAT32. Tento formát také umožňuje vůči jednomu základní disku vytvářet samostatné přírůstkové kopie. Použití takové "šablony" šetří místo na disku i čas. Kromě toho má podporu AES šifrování a zlib komprese. Nevýhodou je, že takový soubor nelze namountovat rovnou přes loop zařízení, tak jako raw disky. Musí se k tomu využít utilita qemu-nbd, která ho vyexportuje jako síťové blokové zařízení, které pak lze připojit přes NBD zařízení.
qcow2
je aktualizovaná verze qcow formátu. Nejzásadnější rozdílem je v tom, že podporuje snapshoty. Jinak se v zásadě neliší. Lze se ovšem setkat i s formátem qcow2, který se interně hlásí jako QCOW verze 3. Ve skutečnosti jde pouze o modifikovaný formát qcow2, který obsahuje navíc parametr lazy_refcounts, který se opět týká snapshotů. Jelikož jde pouze o nastavení jednoho bitu, má qemu-img od verze 1.7 k dispozici volbu "amend" která ho umožňuje měnit. Starší verze qemu-img tuhle volbu nemají. POkud tedy potřebujeme změnit verzi formátu, je nutné virtuální disk překonvertovat do nového souboru, kterému se nastaví během konverze parametr compat v případě snížení verze místo "1.1" "0.10". Použití volby "amend" je výhodné v tom, že není kvůli takové drobné změně nutné hrabat na data.
qemu-img create -f qcow2 -o compat=1.1 test.qcow2 8G

http://blog.wikichoon.com/2014/12/virt-manager-10-creates-qcow2-images.html

qed
je formát virtuálního disku, který z hlediska výkonu zatěžuje hostitele nejméně. Nepoužívá žádnou kompresi. Je to přírůstkový COW formát, který pro adresaci bloků dat (clusterů) používá dvě paralelní tabulky. Bohužel se mu dlouhodbě žádný vývojář nevěnuje, takže jeho použití sebou nese některé problémy, které ještě budou zmíněny.
vdi
formát virtuálních disků, který používá virtualizační řešení fy. Oracle Virtualbox
vmdk
formát virtuálních disků, který používají produkty firmy VMware. Jde rovněž o formát, který dovoluje aby soubor postupně narůstal. Má však oproti qcow2 a qed formátům jednu velkou výhodu, které lze využít u diskless řešení, nebo u síťově distribuovaných souborových systémů. A to, že dovoluje mít soubor virtuálního disku rozdělený na menší soubory o maximální velikosti 2GB. Je to pozůstatek z dob, kdy na souborový systém nebylo možné uložit větší soubor než 2GB. Výhoda spočívá v tom, že pokud je takový virtuální disk replikován po síti, přenášejí se menší objemy dat a synchronizace tak proběhne mnohem rychleji (např. u GlusterFS). U disklessového řešení se zase využívá toho, že se pro jednotlivé soubory při snapshotu ukládají pouze malé rozdílové soubory.
vhdx
formát virtuálních disků, které používá virtualizační řešení Hyper-V firmy Microsoft
vpc
formát virtuálních souborů staršího virtualizačního řešení firmy Microsoft - VirtualPC
Přírůstkový Šifrování Komprese Prealokace Šablony Díry Dělený image Interní snapshoty Kontrola konzistence Poznámka
raw ne ne ne ano ne ne ne ne ne Lze mountovat rovnou přes loop
file ano ne ne volitelná ne ne ne ne ne Je-li nad Btrfs, umožňuje vypnout copy-on-write.
qcow ano ano ano ne ano ano ne ne ne
qcow2 ano ano ano volitelná ano ano ne ano ano
qed ano ne ne ne ano ne ne ne ano
vmdk ano ne ne volitelná ano ano? ano ne ne
vdi ano ne ne volitelná (static) ne ne ne ne ano
vhdx ano ne ne volitelná (fixed) ne ano[1] ne ne ne
vpc ano ne ne volitelná (fixed) ne ne ne ne ne
  1. Díry lze mít pouze u prealokovaného souboru (fixed)

Použitelná API

Mezi podporovanými formáty qemu-img jsou také "formáty", které ve skutečnosti zastupují API, přes které lze k těmto souborům či blokovým zařízením přistupovat vzdáleně.

nfs
soubor virtuálního disku je do QEMU připojen přes NFS protokol
iscsi
komunikace s blokovým zařízením probíhá přes iSCSI protokol. U něj nemůže jedno zařízení současně používat více než jeden klient.
nbd
přístup přes NBD protokol je velmi rychlý. Je to díky tomu že je velmi jednoduchý. To je výhodou, ovšem současně i nevýhodou. Výhodné je to proto, že z jednoho NBD serveru může jet více klientů, pokud využívají připojení přes lokální xnbd-server. Protože ale nemá žádné zabezpečení, ani ověřovací mechanismy, snadno se může stát že se omylem klient připojí na jiné vypublikované virtuální zařízení než by měl, které - pokud na ně zapíše - může poškodit.
ssh
připojení na vzdálený server je realizováno přes sshfs
gluster
využívá pro přístup k souboru virtuálního disku API souborového systému GlusterFS. Ten, pokud je soubor součástí replikovaného, nebo distribuovaného svazku zajišťuje distribuci ukládaných dat mezi ostatní nody. Díky tomu je schopen takový virtuální disk ustát i výpadek několika nodů.
sheepdog
je rovněž distribuovaný souborový systém s podporou replikace. Na rozdíl od GlusterFS není virtuální disk přes API přístupný jako soubor, ale jako blokové zařízení. To je výhodné z hlediska výkonu, ale nevýhodné, pokud jej potřebujeme z prostředí sheepdogu dostat ven.
paralles

Virtuální disky ze síťového úložiště

Výhodou blokových zařízení umístěných mimo virtualizační stroj je především to, že jsou pak imunní vůči výpadku virtualizačního stroje.

Umožňují také zajistit vysokou dostupnost a také dostatečnou kapacitu vzdáleného úložiště.

Využití NFS

qemu block nfs.svg

Sheepdog
Od Qemu verze 1.7 podporuje síťový reconnect

qemu block sheepdog.svg

GlusterFS

qemu block glusterfs.svg

Virtuály bez blokových zařízení

Bez blokových zařízení lze provozovat pouze operační systémy, které umí běžet z NFS, případně ze systému zpropagovaného do virtuálu přes Plan9