Dotaz: KVM konfigurace pro Win

[bob]

Ahoj, potřeboval bych na linuxovém serveru zprovoznit komerční program (síťová služba), který běží jen pod Windows 10. Jako nejjednodušší se mi jeví nainstalovat Windows 10 jako guest OS do KVM (není k tomu nutný restart).

Chtěl bych poprosit o radu, jaký virtuální HW a jaké ovladače do guest OS mám vybrat, aby mi z guest OS fungoval co nejrychleji přístup k síti a k diskům.

Program potřebuje několik pevných portů otevřených do internetu. Mám použít bridge s pevnou IP pro guest OS viditelnou do internetu?

Odpovědi

[Karlosek]

NIC a HDD na virtio, při instalaci doporučuji 2x cdrom a do jedné hned dát drivery kvůli hdd. Grafiku na QXL, dle potřeby zvýšit vram (já dávám 64M, lze editovat přes virsh edit...) Zbytek pak doinstalovat už z os. Návod třeba zde https://dennisnotes.com/note/20180614-ubuntu-18.04-qemu-setup/ IP bych dal pevnou lokální, nebo lépe použít DMZ a nastavit přesměrování portů na fw. Záleží na FS hostitele, ale jako HDD bych dal RAW - ale to je možné konvertovat a otestovat, co vyhovuje.

[bob]

Děkuji za reakci.

Napadlo mě použít přímo logical volume (/dev/VolGrp/LogVol) hostu jako storage (hdd) pro guest místo souboru (v raw formátu). Ale nevím, zda to může reálně zvýšit výkon (a zda to lze zkombinovat s virtio)?

[Karlosek]

Virtio se nastaví v každém případě, to je sběrnice. Pak jestli je to img nebo vol, nebo img na vol, to je potřeba vyzkoušet. Záleží na železe, jestli hdd/ssd, typ raidu, fs, velikost paměti... A taky nastavení vyrovnávací paměti - ztráta dat při výpadku/rychlost... Raw se dá na vol převést jednoduše dd, takže otestovat. Někdo používá qcow2 kvůli funkcím a ani nepozoruje zpomalení, někdy dokonce naopak.

[alkoholik]

Nema ten server nahodou sitovku, ktera umi SR-IOV?

[bob]

SR-IOV síťová karta asi podporuje, v hostu je Mellanox ConnectX-4 Lx.

[trekker.dk]

"Asi" to s jistotou poznáte podle sysfs - v /sys/class/net/ethX/device budou soubory sriov_. Pokud tam jsou a pokud do nich půjde zapisovat (na serverech, co používáme, se to musí extra povolit v biosu), karta SR-IOV podporuje. Pak můžete místo virtio síťovky do toho virtuálního serveru přímo dát ten "fyzický" hardware. (Klíčová slova pro hledání jsou vfio passthrough)

Výhoda - ty Windows budou na stejné fyzické síti bez další práce. Nevýhody - ten virtuální server bude muset zamknout (memlock) svoji paměť do fyzické, tj. nemůžete použít KSM (deduplikace paměti) a taky budete muset sehnat ovladač té fyzické karty do Windows - a to ne přímo té karty, ale její virtuální funkce.

[zigi]

Ahoj, vše zde zmíněné je OK až na ty Windows 10. Osobně si myslím, že provozem síťové služby ("Program potřebuje několik pevných portů otevřených do internetu") budeš porušovat M$ licenci. Windows 10 je uživatelský systém a ne serverový - na provoz síťových služeb a aplikací/programů dostupných po síti tu je aktuálně Windows Server 2019. Pokud se jedná o komerční použití, tak bych si to raději ověřil spolu s licencováním na počet hypervizorů (jejich CPU - slotů a corů).

[bob]

Aha, to jsem si neuvědomil. Díky za upozornění. Když jsem psal "internet", tak jsem měl ve skutečnosti na mysli lokální síť. Ale i tak si raději pečlivě prostuduji licenční podmínky Win.

[Max]

Windows 10 umožňují přístup pro 20 zařízení, vztahuje se to pro fce Windows. Pokud na Windows provozuješ aplikací třetí strany, která nevyužívá žádné služby z Windows, tak se tě ten limit netýká a vše bude ok.
Tzn., že pokud si na Windows 10 nainstaluješ např. Apache+php+mysql a vystavíš ven do netu, tak to bude ok.
Zdar Max

[Max]

Pro jednu VM na jednom stroji je nejjednodušší asi použít virsh, viz výcuc z mé dokumentace (VM, kde je instalovaný Oracle Enterprise Linux / OEL5, tzn. něco jako CentOS 5, takže si změň type a os varianta na příslušnou verzi Windows) :

# vytvoříme si virtuální disk :
qemu-img create -f qcow2 ./MyServer.qcow2 20G

# vytvoříme si VM :
virt-install --name MyServer --ram 16384 \
--os-type=linux \
--os-variant=ol5.11 \
--disk path=/vm/MyServer_01.qcow2,format=qcow2,bus=virtio,size=60 \
-c /mnt/iso/Oracle/OEL/OEL-5U11-V47133-01.iso \
--network bridge=br0-lan,model=virtio,mac=RANDOM \
--graphics vnc,password=heslo,listen=0.0.0.0,port=5900 --noautoconsole \
-v --vcpus=12 \
--boot cdrom,hd

A pak jednoduchý mgmt:

# seznam VM :
virsh list --all

# start/stop :
virsh shutdown guest1 --mode acpi
virsh start
virsh shutdown
virsh suspend
virsh reset
virsh reboot
virsh console

# zobrazit nastavení :
virsh dumpxml MyServer

# zmazat vm :
virsh undefine MyServer

# připojit cd :
virsh attach-disk MyServer /mnt/iso/Oracle/OEL/OEL-5U11-V47133-01.iso hdc --type cdrom --mode readonly

# zobrazit info o img :
qemu-img info MyServer_01.qcow

# zobrazit seznam podporovaných os variant:
virt-install --os-variant list

Zdar Max

[OldFrog {Ondra Nemecek}]

Díky, na tohle používám virt-manager, ale virsh bude asi leckdy praktičtější - a tady to máš vše hezky pokupě :)

[bob]

Díky všem za užitečné informace. Ještě sem přidám pár základních odkazů.

https://www.linux-kvm.org/page/Tuning_KVM

https://www.linux-kvm.org/page/Networking

https://www.linux-kvm.org/page/10G_NIC_performance:_VFIO_vs_virtio

[LarryL]

Ty odkazy znám, ale info na těch stránkách je už dost staré. Zdá se mi, že to není aktualizováno. Když se dívám na ten první odkaz, tak je tam cpu "qemu64", ale když si dám příkaz: qemu-system-x86_64 -device ? | grep qemu64 tak mi to ukazuje:

name "qemu64-v1-x86_64-cpu"
name "qemu64-x86_64-cpu"

V nějaké verzi Qemu zřejmě vznikla druhá verze virtuálního procesoru qemu64.

Nebo v sekci Storage používají

-drive if=virtio,...

ale dnes by se mělo používat:

-drive if=none,...
-device virtio-blk-pci,...

nebo ještě modernější:

-drive if=none,...
-device virtio-scsi-pci,...

No vlastně místo -drive by se nově mělo používat -blockdev

Podobně je to u Network:

-netdev ...
-device virtio-net-pci ...

Zajímalo by mne jestli je ještě pořád aktuální věta o BTRFS:

Don't use the linux filesystem btrfs on the host for the image files. It will result in low IO performance. The kvm guest may even freeze when high IO traffic is done on the guest.

Pokud bys chtěl optimalizovat ještě víc, tak někdo používá "cpu pinning", ale to na serveru asi nevyužiješ, ale je vhodné použít HyperV parametry (HyperV požívat nemusíš) pro CPU nějak takto:

-cpu host,kvm=off,hv_synic,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,...

ale taky už možná nejsou úplně aktuální - zkus pogooglit. Těmi příznaky "řekneš" virtuálce Windowsu, že běží ve virtuálce a Win by tak měl fungovat trochu optimálněji.

Pro vytunění RAMky někdo používá huge pages, ale považuji to za zbytečné, přesněji řečeno jsem nikdy nenarazil na nějaký test, který by prokazoval zásadní benefit.

Jinak co se týká výkonu souborů *.qcow2 vs *.raw, tak ano uvádí se, že raw je rychlejší, ale abys to poznal tak bys musel ve VM provozovat DB, nebo nějaké diskově náročné operace. Každopádně pohrát si u -drive s parametrem cache=... smysl dává. Z vlastní zkušenosti vím, že se u některého nastavení prodloužil boot Windowsu ve VM na dvojnásobek. U cache=writeback se mi zase začal sekat kurzor myši na hostiteli (Linuxu) když jsem ve VM prováděl kopírování velkého souboru. Pokud se VM přiděluje celý svazek nebo partition (což zřejmě plánuješ ty), tak se většinou používá cache=none. U kombinace ZFS a NVMe někdo zkoušel "vhost_scsi", takže kdyby to byla zrovna tvoje HW kombinace na serveru, tak můžeš zkusit.

Někdo volí raději -machine typu q35 namísto zastaralého, ale stále výchozího i440fx. Taky to může mít vliv na výkon.

Možností pro optimalizace je dost, takže jde o to jak moc jsou dané optimalizace nutné pro danou aplikaci, kterou chceš ve VM Windows provozovat. Pokud ta aplikace nebude zásadně vytěžovat server, tak přehnané optimalizace nedávají smysl.

[alkoholik]

Hugepages maji dva benefity: mapovani stranek zere min pameti a nemas zdaleka tak casto TLB miss. Rozhodne je doporucuju pouzivat.

[trekker.dk]

Zkoušel jste, jaký vliv to má na KSM? Tak nějak se mi nezdá, že když se na serveru najde N stejných 4kB stránek, že se tam taky najde N/512 stejných 2MB stránek

[alkoholik]

Deduplikaci neresim a pouzivam 1GB stranky.

[LarryL]

zere min pameti

Dá se to vyjádřit nějak číselně? Když přiřadím VM 8GB RAM, tak kolik GB/MB paměti ušetřím když zapnu hugepages?

nemas zdaleka tak casto TLB miss

Tak asi nějaký vliv to má, ale jde o to jestli se tím získá navíc výkon, který je vůbec měřitelný.

[alkoholik]

PTE jsou 4B pro kazdou 4kB stranku. Nasobit a delit umis, ne?
Mimo virtualizaci (qemu je jenom jeden proces) si musis vysledek jeste vynasobit poctem procesu, ktere stejne stranky sdileji.
Samozrejme vliv maji. V databazich jsou poznat pomerne hodne.
Ja si virtualizuju herni VM a chci naprosto minimalni latenci, takze za me rozhodne pouzivat.

[alkoholik]

Jo sorry za nepresnost, 4B plati pro 32-bit systemy. x86-64 muze mit 4-5 urovni a pocita se to trosku hur.

[LarryL]

PTE jsou 4B pro kazdou 4kB stranku. Nasobit a delit umis, ne?

Jestli to u 8GB znamená pár získaných pár MB, tak to je celkem zanedbatelné ušetření RAM. Nějak do detailu hugepages neznám, ale asi větší benefit je, že se menší velikost snáze vejde do cache CPU a tím se sníží latence a věřím, že u DB to význam může mít.

Ja si virtualizuju herni VM

Taktéž, a když jsem měřil výkon v 3DMarku s/bez hugepages tak jsem žádný rozdíl neviděl a jelikož bych musel hugepages alokovat při startu VM a uvolnit při vypnutí VM (aby mi hugepages zbytečně nezabíraly RAM), tak jsem se na to vykašlal. Ve tvém prvním odkazu se moc nevyznám. Vidím, že je z roku 2010 a uvádí se tam jednotky nanosekund. Hádám, že u hraní hry by ta latence mohla být max 0.5ms (ale spíše výrazně méně) a jelikož doma nemáme žádného profihráče, tak to neřeším.

[alkoholik]

Treba u oracle db to byva dost dulezite. Pustis si malou 100GB instanci (pro zjednoduseni budeme pocitat 100MB per proces) s 1000 serverovych procesu a bez HP uz jenom ziras, kam se podela veskera pamet..
Jeste jedna drobnost. Mam Threadripper, takze NUMA system. S HP muzu VM rict, aby si alokovala pamet ze spravneho node.

[LarryL]

bez HP uz jenom ziras, kam se podela veskera pamet.

U spotřebované paměti RAM přece musí platit přímá úměra. Tzn. když přidělím VM 8GB RAM, tak bez HP si PTE navíc vezme (dejme tomu) 16MB RAM. Se zapnutými HP by si PTE vzaly z RAM jen 32kB. A když VM přidělím 10x více RAM (80GB) (např. pro Oracle DB), tak by si 10x více paměti měly vzít i PTE. Takže nějak nechápu kam by se měla záhadně spotřebovávat veškerá paměť, tak jak popisuješ.

[alkoholik]

Vsak plati.
Oracle umi na x86-64 pracovat jenom se 2MB strankami (18 ani 19 jsem jeste nezkoumal). V uvedenem pripade by se tak jenom na mapovani bez HP spotrebovalo 100GB RAM, s 2MB HP jenom 200MB.
Ja psal, ze u VM to tolik nepali, protoze stranky vetsinou nesdili.

[alkoholik]

Kua, 2MB HP to dela 50MB, ne 200.

[LarryL]

Nechci být otravný, ale pořád to nějak nechápu.

"jenom na mapovani"

Konkrétní čísla co jsem uvedl jsem vzal z linux-kvm.org (6. stránka Cache effect). Při 16GB z RAM se "na mapování" používá 32MB (bez HP) nebo 64KB (s HP). Takže pokud by Oracle měl "jenom na mapování" bez HP použít 100GB, tak by musel Oracle používat 50TB RAM. Pokud Oracle tolik TB RAM nepoužívá, tak si do těch 100GB musí ukládat ještě nějakou vlastní Oracle režii, tzn. že HP nepouužívá jen na mapování virtuální paměti do fyzické paměti, ale funguje to jako nějaká např. DB cache.

[alkoholik]

Tobe unika jenom problem s poctem procesu.
Kdyz zustamene u Tveho prikladu

Při 16GB z RAM se "na mapování" používá 32MB (bez HP) nebo 64KB (s HP).

a pustime databazovou instanci s tisicem procesu, kde si kazdy proces musi namapovat tech 16GB, protoze je sdili, najednou nebudes potrebovat jenomna mapovani 32MB resp. 64KB, ale celkem 32GB resp. 64MB.
Ta pamet je z hlediska procesu samotneho jinak nepouzitelna. A samozrejme lita sem a tam mezi pameti a TLB.

[LarryL]

Aha, tak už rozumím. Vídím, že jsi o vynásobení na počet procesů před tím psal, ale nějak mi to nedošlo . Myslel jsem, že je jen jedna překladová tabulka pro celý OS.

[trekker.dk]

Zajímalo by mne jestli je ještě pořád aktuální věta o BTRFS

Jenom tipuju, takže bez záruky, ale obával bych se, že je to dáno architekturou - BTRFS je Copy-On-Write filesystém a image ve formátu qcow je podle jména totéž. Takže když se do toho souboru něco napíše, tak se tam taky musí zapsat metadata (blok je teď umístěn někde), což jsou dva zápisy, načež Btrfs musí udělat totéž jak pro data, tak pro metadata, což už jsou čtyři zápisy.

Což by ovšem znamenalo, že když máte SSD, tak si toho varování nejspíš nemusíte moc všímat.

U cache=writeback se mi zase začal sekat kurzor myši na hostiteli

Na hraní je to dobré, jinak si ale IIRC koledujete o ztrátu dat. Zatímco host si myslí, že data jsou již uložena na disku, Qemu v tomhle režimu považuje zápis za dokončený, už když se dostane do té cache (tj. k zápisu na disk nikdy nemusí dojít, když např. vypadne proud.)

[LarryL]

BTRFS je Copy-On-Write filesystém a image ve formátu qcow

Na redditu píší, že to souvisí s COW na BTRFS a při každé změně image VM dochází k velké fragmentaci na disku. Jestli je image VM v qcow2 nebo v raw asi už nezáleží. Vypnutí COW pro adresář ve kterém jsou image VM se zdá jako rozumné řešení.

Na hraní je to dobré, jinak si ale IIRC koledujete o ztrátu dat.

Ano, máš pravdu. Je to na zvážení podle důležitosti dat se kterými se pracuje ve VM. Pokud třeba edituješ fotky ve VM a neuložíš si rozdělanou práci a spadne VM nebo hostitel, tak o tu rozdělanou práci (data) stejně přijdeš nehledě na nastavení cache. Je i nastavení cache=unsafe u kterého jsem pozoroval největší rychlost při bootování VM. Pro desktop je hodnota writeback nebo unsafe v pohodě a u serveru se zase předpokládá záložní zdroj, takže tam je to riziko taky malé.

[pavele]

U serveru se nemůžeš spoléhat na záložní zdroj, ale na co nejbezpečnější a nejjednodušší, pokud možno defaultní konfiguraci/nastavení i v případě mírného dopadu na výkon.

Stačí se podívat na net, kolik i velkých firem přišlo o data, protože spoléhali na záložní zdroj + diselagregát + máme přece zálohy...

I já jsem se chvíli radoval při výpadku sítě, že mám vše jištěné záložním zdrojem, než jsem zjistil, že baterky byly KO a hlásili mi to do emailu ráno před výpadkem.

[Petr Fiedler]

I já jsem se chvíli radoval při výpadku sítě, že mám vše jištěné záložním zdrojem, než jsem zjistil, že baterky byly KO a hlásili mi to do emailu ráno před výpadkem.

Tak to je moc.