QEMU

14.12.2021 00:48 | Přečteno: 2253× | linux | poslední úprava: 14.12.2021 01:00

Qemu je softvér na virtualizáciu a emuláciu hardvéru. Upozornenie : Autor neručí za prípadné škody použitím týchto informácii. Užívateľ je si vedomi rizik a bude používať informácie z blogu s dostatočnou opatrnosťou a vždy si preverí postup na cvičnom stroji.

Úvod

Tento blog popisuje používanie virtualizacie QEMU cez príkazový riadok. Dôvod písania tohto blogu je podelenie sa o informácie získane pri používani QEMU cez CLI.

Na jednú vec musím upozorniť a to je kombinácia fs. Neodporúčam kombináciu LVM thin pool s fs ext4 ak máme LVM s fs ext4 vo VM v spojení s qcow2. Pri inštalácii na tejto platforme trvala inštalácia mnohonásobne dlhšie. Preto odporúčam prvotnú inštaláciu systému do VM vo formate obrazu raw.

Rýchle spustenie

Podľa dokumentácie stačí na spustenie QEMU obraz disku a zadanie qemu-system-x86_64 obraz.img. Príkaz spustí virtualizáciu s základným nastavením.

Detailnejšie nastavenie

Počet cpu

Počet cpu je možne určiť pomocou parametra -smp. QEMU podporuje funkciu pridania cpu počas chodu VM. Pred spustením musí byť zadefinovaný počet cpu -smp X,maxcpus=y, ktoré je možne pridať počas chodu. Premenná X definuje počet aktuálne pripojených cpu a premenná Y maximalný počet cpu.

Ďalši krok je pridanie cpu cez QEMU monitor cez príkaz device_add driver=host-x86_64-cpu,socket-id=1,thread-id=0,core-id=0,id=cpu-1

Veľkosť RAM

Veľkosť RAM je definovaný v QEMU voľbou -m.QEMU podporuje aj pridávanie

V prípade potreby pridávania RAM počas chodu VM môžeme definovať množstvo RAM. V definícii ram -m môžme pridať definiciu počtu slotov a maximálnu veľkosť RAM, pomocou parametrov slots= maxmem=.

Ďalej je nutné definovať objekt pamäťového backendu. To môžme urobiť dvomi spôsobmi :
• ako súčasť príkazového riadku - -object memory-backend-ram,id=id,size=
• cez QEMU monitor - object_add memory-backend-ram,id=id,size=

Ako posledné musíme vytvoriť zariadenie RAM pomocou QEMU monitora device_add pc-dimm,id=dimm1,memdev=id.

Nastavnie blokových zariadení

Podľa dokumentácie QEMU poskytuje tri spôsobi definovania blokového zariadenia.

• Schéma podobná rozhraniu IDE - primary and secondary IDE¹
• definícia drive
• podrobná definicia frontendu a backendu

Schéma ide má konfiguračné voľby hda až hdd,fda,fdb a cdrom. V princípe stači definovať cieľový súbor alebo zariadenie.

Definícia drive umožňuje detailnejšie nastavenie typu zariadeni v oblasti rozhrania a typu média. V mojom prípade som použil typ rozhrania virtio. Myslím, že tým odstraním obmedzenia jednotlivých rozhrani a zariadenie bude emulované bez špecifických vlastnosti reálnych hw zariadení.

Definícia -blockdev je najdetailnejšia konfigurácia blokového zariadnia a vyžaduje aj definovanie zariadenia -device. V prípade blockdev je nutné definovať zdrojový súbor alebo zariadeni kde budú data uložené, jednoznačný identifikátor a typ blokového zariadenia. Následne je nutné definovať paramter drive v definícii -device. Ak použijeme format qcow2, tak je nutné vsunuť medzi blockdev a device, definiciu blockdev pre qcow2. V prípade, že je použita bežna definicia pre obrazy vo formate qcow2 dôjde k ohlaseniu chyby o chýbajúcom disku.

---

¹⁾hdX - používa linux na označovanie zariadení rozhrania IDE.

virtio-blk

virtio-blk je emulácia blokového zariadenia s najjednoduchším rozhraním vzhľadom na komunikáciu medzi hosťovským blokovým zariadením a VM.

Na pripojenie disk cez blokové zariadenie potrebujeme dve definície -device a -blockdev. Pre definíciu device musíme vybrať typ zariadeni virtio-blk a názov backendu ku ktorému bude dané zariadenie priradené pomocou parametra drive=. U definície blockdev musíme vybrať typ blokového zariadenia. Existujú tri druhy file,raw,qcow2. Pre typ file potrebujeme filename=,node-name=.

Ak máme obraz disku vo formate qcow2. Musíme vložiť definiciu blokového zariadenia pre qcow2.

virtio-scsi

virtio-scsi je emulácia zariadenia zbernice SCSI. Princíp komunikácie je v určitej miere pobodný reálnému SCSI. Z toho vyplýva, že mierný pokles výkonu je spôsobený komunikačným protokolom, ktorý pri virtio-blk je len základná komunikácia čítania a zápisu.

Definicia SCSI zariadenia vyžaduje radič a zariadenie alebo viacej zariadení. -device virtio-scsi,id=id a -device scsi-hd,drive=,device_id=.

Definicia zvukového zariadnia

Definovanie zvukového zariadenia je možne urobiť cez -device a -audiodev. -device definuje typ zvukového hw, ktorý má qemu emulovať. -audiodev definuje výstup smerom z QEMU do systému.

Zvuková karta

Definovať zvukovú kartu je možné pomocou -device intel-hda,id=sound. Zatial mám vyskúšanu zvukovú kartu intel-hda. Ak chceme pripojiť do zvuk do hosťovkého systému musíme pridať -device hda-output,audiodev=snd0 a -audiodev pa,id=snd0.

Sieťové karty

Bez definovania sieťovej karty

Pri spustení qemu bez konfigurácie sieťovej karty je prítomne jedno spojenie s vonkajším svetom.

Vypis z qemu monitora info network
• hub0
• hub0port1: __org.qemu.net1: index=0,type=user,net=10.0.2.0,restrict=off
• hub0port0: e1000.0: index=0,type=nic,model=e1000,macaddr=XX:XX:XX:XX:XX:XX

Spustenie s definiciou sieťovej karty

V tomto prípade potrebujeme na správnu funkcie konfiguračne voľby -device a -netdev. -device definuje typ sieťovej karty a niektoré nastavenia. Ak použijeme viace sieťových kariet je vhodné pre každú kartu definovať hw adresu mac=XX:XX:XX:XX:XX:XX a identifikátor pomocou ktorého zpárujeme použite spojenie s vonkajšim prostredím.

Parameter -netdev umožňuje definovať typ pripojenia k vonkajšiemu svetu.
• user
• socket
• vde
• bridge

user - režim NAT. Pre každú VM je samostatná sieť s NAT do vonkajšieho sveta

socket - režim umožňujúci pripojenie dvoch a viacerích VM medzi sebou. Socket poskytuje dva režimi TCP a multicast. V prípade TCP je možne vytvoriť. -netdev socket,id=net,listen=127.0.0.1:10001 a -netdev socket,id=net,connect=127.0.0.1:10001

vde - pripojenie pomocou vde zariadenia. Na úspešne pripojenie je nutné mať vytvorení vdeswitch.

bridge - pripoji zariadenie tap k zariadeniu bridge na hosťovskom systéme. Hosťovský systému musí mať vytvorené zariadenie bridge aby mohla byť spustená VM. Ak nepovolíme bridge zariadenie v /etc/qemu-bridge.conf.

V prípade prepojenia VM je nutné definovať pomocou parametra mac fyzicku adresu sieťovej karty v definícii -device.

vde_switch

Umožňuje vytvorenie virtualného switchu pre rozhrania VDE. vde_switch -s /tmp/testnet -d.

slirpvde

Vytvorí virtuálny router medzi VM a hosťovskou sieťou.slirpvde /tmp/testnet -D.

USB

Parameter -usb spustí emuláciu USB vo virtualnom stroji.

Definicia emulovaneho USB kľúča

V prípade pripojenia emulovného USB kľúča je nutné zadefinovať USB zariadenie a blokové zariadenie cez ktoré bude emulovaný USB kľúč pripojený. Definícia USB zariadenia vo VM je nutné zadefinovať cez -device. Definicia pre radič usb -device qemu-xhci,id=usb. Definicia pre USB uložisko -device usb-storage,bus=usb.0,drive=stick. Definicia samotného obsahu uložiska usb -blockdev file,filename=usbstorage.img,node-name=stick.

Ak chcem pripojiť obraz vo formate qcow2 musime zadefinovať prepojenie medzi -device a -blockdev pomocou -device usb-storage,bus=usb.0,drive=stick1, -blockdev file,filename=usbstorage.img,node-name=stick, -blockdev qcow2,node-name=stick1,file=stick.

Definicia usb seriového portu

Použitie emulovaného seriového portu potrebujeme definiciu -device usb-serial,chardev=serialtest a -chardev vc,id=serialtest.

Seriový port

Sériový port je typ rozhrania, ktoré bolo v minulosti používane primárne na komunikáciu s modemom a následne s protistranou. Počas zlepšovania techniky Internetu sa začal seriový port používať na pripojenie do internetu cez analogovú linku. Z tohto vyplýva, že seriové rozhranie PC komunikovalo s modemom a následne modem zakódoval data do signálu vhodného na prenos po analogovej linke. Neskór toto rozhranie začalo používať aj u niektorích zariadeniach na konfiguráciu.Existuje množstvo typov seriových rozhrani. RS-232,RS-442,RS-485.

Seriový port v QEMU je možné pripojiť rôznými spôsobmi.
• Štandardné IO
• Súbor
• Virtuálna konzola - -serial vc
• Pty - vytvorí pty, ktoré je v poradí a ešte neobsadené.
• Pipe
• Chardev - -serial chardev:id a -chardev vc,id=id
• TCP - -serial tcp::10000,server=on,wait=off
• UDP

Štandardné io - pripojí IO VM k terminálu kde bola spustená VM

Súbor - výstup seriového rozhrania je zapisaný do definovaného súboru

Virtuálna konzola - priame zobraznenie komunikácie seriového rozhrania.

Pty - na pripojenie k pty môžme použiť minicom -D /dev/pts/X.

Chardev - pripojá seriové rozhranie do znakového zariadenia s definovaným id. Následne je možné pomocou chardev preposlať komunikáciu rôznými spôsobmi

TCP - umožni pripojenie sa k seriovému portu pomocou sieťového pripojenia na sieťovom protokole TCP.

UDP -

QEMU monitor

QEMU monitor je nástroj virtualizačného prostredia na konfiguráciu VM a monitorovanie niektorích parametrov. Prednadstavené správanie monitora je v prípade textového režimu beh QEMU monitora v stdio a v prípade GUI v režime virtuálnej konzoly. Podobne ako pri seriovom rozhraní je možné QEMU monitor presmerovať rôznými metódami.

Záver

V tomto blogu som opísal niektoré možnosti qemu cez CLI. Vzhladom na množstvo času stráveného spisovaním blogu a testovania, ukončujem tento blog. Možno v buducnosti napíšem ďalšie blogy o QEMU.

       

Anketa

Anketa

Komentáře

[Gréta]

určitě to jako zkusim ;D

[Want]

Aneb - objevujeme kolo.

[Fms]

Jaka je pridana hodnota tohoto prekladu do cobolstiny?

[Aleš Kapica]

Jeho blog, jeho problém, ne? Nikdo tě to číst nenutí. Nebo si snad stěžuješ i když tě v krámě obslouží ženská co evidentně není z Čech?

[Mandarinka Mega C]

Presne tak, at blogu proste neda spropitne kdyz se mu nelibi :D

[Fms]

pokud mluvi cesky, nebo se aspon snazi, tak ne (ukrajinky, vietnamky, polky...)

pokud na me mluvi cobolsky, tak ano, volam vedouciho

[lhostejno]

Ty hovado. Slovenština je v ČR úřední řečí.

[Fms]

Ty jsi hovado. Já nejsem zvědavý aby na mě nějaká prodavačka mluvila cizím jazykem a ani se nesnažila naučit česky nebo anglicky.

[T.F.]

Takze ty se neches multikulturne obohacovat? Tak co vlastne chces? Postavit si vozovou hradbu a byt hodnym kalisnikem?

[Fms]

Nechci se učit barbarský jazyk z východu, jenom proto, že se je imigrant líný naučit česky.

[Miluna]

Ale to delas kolosalni chybu ze nechces!

[vlk]

Vůl volem zůstane!

Buď rád že ťa niekto v obchode obslúži, ale bola by sranda keby ten vedúci na teba prehovoril tiež "čobolsky"

[debian+]

Stale lepsie ako moje blogy.

[podlesh]

Technická: Major Haluška aka "Ťerazky" byl nejspíš Rusín a mluvil jazykem "vzdáleně připomínajícím slovenštinu".

[Aleš Kapica]

Babiš je rusín?

[xxxs]

rodina matky prišla na Slovensko po druhej svetovej vojne z Podkarpatskej Rusi.

https://www.webnoviny.sk/osobnosti/andrej-babis/

[Aleš Kapica]

Tak to leccos vysvětluje. Tenhle hajzl taky přitáhnul odtamtud.

[Slovák]

lol triggered pepík

[henk]

Díky za blog, co Intel GVT-g, podařilo se ti takto zprovoznit? Mě zatím ne.

[ewew]

Ešte som sa neodvážil použiť passthrough.

[LarryL]

Mně se to podařilo. Zkoušel jsem na Manjaru. Podle návodu na archwiki celkem v pohodě akorát bacha na to, že poslední Intely už GVT-g nemají. U nových iGPU Intelů se uvádí, že mají SR-IOV, ale co vím tak zatím neexistuje žádný SW, který by umožnil SR-IOV využít.

[GeorgeWH]

Na to potrebujes nejaky SW? Teda sr-iov u grafiky nepoznam, ale v pripade sietoviek je to len vec jadra, kedy ti v systeme pribudnu dalsie "fyzicke" sietove rozhrania.

[LarryL]

No jo, jenomže u síťovek nepotřebuješ grafický výstup. Grafický výstup byl problém i v začátcích GVT-g. Funkce GVT-g byla v ovladači Intelu, byla i v KVM, takže bylo možné z určitého počtu grafických jader vytvořit vgpu a tu následně přiřadit VM, ale po spuštění VM jsi nikde neviděl grafický výstup z dané VM, protože v Qemu nebyl ještě naprogramovaný kód - to se dodělávalo až naposledy.

Né, že bych po tom detailně pátral (nemám zatím důvod), ale nenarazil jsem na žádný návod jak právě u těch novějších iGPU (které mají SR-IOV) v Qemu nastavit, abys viděl grafický výstup z VM.

[trekker.dk]

Jo, odhadl bych, že SR-IOV je cílené na použití v datacentru, tj. k dělení výpočetního výkonu té grafiky mezi VM - ne k tomu, aby na ten obraz někdo koukal.

[LarryL]

Jak se dívám, tak Intel uvádí, že SR-IOV je v "11th Generation Intel® Core™ "G" Processors (products formerly known as Tiger Lake) or newer."

Když jsem rozklikl Tiger Lake tak jako "G" jsou označeny mobilní CPU.

Třeba podle této odpovědi to vypadá, že v procesorech podpora SR-IOV je, ale v konkrétním NUCu nebyla funkce implementovaná do Biosu.

Takže si myslím, že SR-IOV v Intelu nebude určena jen pro datacentra a je šance, že se dostane i do běžných CPU s iGPU nebo později i do mainstreamových dGPU od Intelu a pokud by i výrobci MB do Biosu funkci implementovali, tak pak už je krůček k tomu, aby se to doprogramovalo do Qemu aby bylo možné vidět grafický výstup z hosta na hostiteli.

[trekker.dk]

Hm, tak uvidíme - fakt je, že tenhle kus kódu asi nebude prioritou, protože nasazení v datacentrech přece jenom přináší větší peníze. A jestli to dobře chápu, tak v Qemu vlastně není potřeba řešit nic, se SR-IOV je to normální passthrough. Nasazení umožňující vidět výstup z hosta na hostiteli u domácích uživatelů naopak žádné peníze nepřináší a ještě bych si tipnul, že bude potřeba kromě Qemu taky podpora v ovladači hostitele. Pokud to ten hardware vůbec bude umět.

Jako zní to pěkně, ale momentálně bych spíš ocenil, kdyby remote-viewer a další podobné dokázaly odchytávat vstupy z klávesnice i v případě, že VM nemá žádný grafický výstup (protože jede čistě na passthrough grafiku.) Z toho, co jsem našel, tak to umí akorát několik let nevyvíjený klient spicec.

[LarryL]

Hm, tak uvidíme - fakt je, že tenhle kus kódu asi nebude prioritou, protože nasazení v datacentrech přece jenom přináší větší peníze.

Nasazení umožňující vidět výstup z hosta na hostiteli u domácích uživatelů naopak žádné peníze nepřináší a ještě bych si tipnul, že bude potřeba kromě Qemu taky podpora v ovladači hostitele.

To by se dalo říct i o GVT-g a taky tomu někdo věnoval čas.

A jestli to dobře chápu, tak v Qemu vlastně není potřeba řešit nic, se SR-IOV je to normální passthrough.

Tak passthrough je i GVT-g. Taky daný počet jader do VM předáš pomocí VFIO nějak takto:

-device vfio-pci,bus=pcie.0,addr=02.0,sysfsdev=/sys/bus/mdev/devices/bd3652a0-387b-3542-689e-e9b189ec5781,display=on,x-igd-opregion=on,ramfb=on,driver=vfio-pci-nohotplug,xres=1440,yres=900,romfile=./win10-gvt-g/vbios_gvt_uefi.rom

a přidání parametru -display gtk,gl=on,zoom-to-fit=off způsobí, že se zobrazí okno ve kterém půjde vidět zmiňovaný výstup z VM.

Moc nevěřím tomu, že tak jak je to naprogramované pro GVT-g to bude stačit i pro SR-IOV.

Jako zní to pěkně, ale momentálně bych spíš ocenil, kdyby remote-viewer a další podobné dokázaly odchytávat vstupy z klávesnice i v případě, že VM nemá žádný grafický výstup (protože jede čistě na passthrough grafiku.)

Já to řeším pomocí evdev, tzn. pomocí parametrů -device virtio-keyboard-pci společně s -object input-linux. Ze všech způsobů co existují se mi to osvědčilo nejlépe.

[trekker.dk]

Tak passthrough je i GVT-g.

Jo, ale tohle bylo potřeba dopsat - SR-IOV na grafice Qemu už umí, protože to pokryje normální VFIO.

a přidání parametru -display gtk,gl=on,zoom-to-fit=off způsobí,

...že Qemu spadne na segfault ve chvíli, kdy se ta GVT-g grafika nastartuje.

Já to řeším pomocí evdev, tzn. pomocí parametrů -device virtio-keyboard-pci společně s -object input-linux.

Jestli to dobře chápu, takhle si proces Qemu zabere klávesnici a vstupy z ní předává do hosta, dokud běží? To můj use-case neřeší, protože občas chci přepnout monitor do hostitelského systému, přepnout se na jiný X server a pracovat s ním.

[LarryL]

...že Qemu spadne na segfault ve chvíli, kdy se ta GVT-g grafika nastartuje.

To mně nedělalo.

Jestli to dobře chápu, takhle si proces Qemu zabere klávesnici a vstupy z ní předává do hosta, dokud běží?

Ne. Mezi hostem a hostitelem můžeš klávesnici (i myš) přehazovat stiskem L-Ctrl + R-Ctrl.

[trekker.dk]

Ne. Mezi hostem a hostitelem můžeš klávesnici (i myš) přehazovat stiskem L-Ctrl + R-Ctrl.

Poznamenal jsem si, dík. Zatím budu doufat, že ten spicec nepřestane fungovat, tohle kdyžtak může být záložní plán v případě, že přestane (hádám, že instalace v téhle konfiguraci nebude úplně triviální, když na klávesnici a myš je potřeba ovladač, ale nainstalovat ho nepůjde, protože nemám ovladač)

Ideální stav by byl wishlist bug na ten remote-viewer, ale k tomu se musím nejdřív dostat

[LarryL]

hádám, že instalace v téhle konfiguraci nebude úplně triviální, když na klávesnici a myš je potřeba ovladač, ale nainstalovat ho nepůjde, protože nemám ovladač

Já myslím, že to je celkem triviální. Jen musíš:

- přidat do Qemu parametry -object input-linux,evdev=/dev/input/by-id/<název klávesnice>,grab_all=on,repeat=on a -device virtio-keyboard-pci (Oba parametry i pro myš)

- přidat oprávnění do /etc/udev/rules.d/10-qemu-hw-users.rules

- ve VM Windows nainstalovat ovladač "virtio input" (v Linuxu netřeba instalovat, protože je součástí kernelu)

Na internetu je spousta návodů. Pak je ještě možnost použít Barrier (fork Synergy)

Ideální stav by byl wishlist bug na ten remote-viewer, ale k tomu se musím nejdřív dostat

Nepřipadá mi jako správné řešení používat remote-viewer (spicec) společně s VGA passthrough. Předpokládám, že spicec ti ukazuje černou obrazovku a používáš ho jen k předání myši a klávesnice. To je spíše hack než správné řešení. Když už by mělo být nějaké jednoduché řešení pro naklikání konfigurace předání myši a klávesnice, tak by to mělo být součástí virt-manageru, nikoliv remote-vieweru.

[LarryL]

Nepřipadá mi jako správné řešení používat remote-viewer (spicec) společně s VGA passthrough.

...i když zase na druhou stranu proč by přes spice protokol nemohly téct jen data z klávesnice a myši. To je taky pravda.

[Aleš Kapica]

Můžou. Nic ti nebrání, aby ses přepnul na konzoli. Dokonce je to v některých případech i žádoucí.

[LarryL]

No jo, ale data ze sériové konzole netečou přes Spice protokol. SPICE sice může využívat sériovou konzoli, ale SPICE a sériová konzole jsou oddělené.

SPICE byl dělaný pro přenos obrazu a zvuku a ohnout SPICE, aby přenášel jen data z klávesnice a myši je takové... no moc se mi to nezdá.

[trekker.dk]

AFAIK je SPICE lepší náhrada VNC - tedy obraz a zvuk jedním směrem, vstupy opačným směrem. Abych se přiznal, vůbec mi nedává smysl, proč všechny klientské programy pro SPICE protokol (kromě toho spiccec), na základě toho, že ve VM nenajdou grafický výstup, vypnou veškerou svoji zbývající funkcionalitu. Někdo musel úmyslně jít a přidat kód, který v takovém případě něco vypne.

[LarryL]

vůbec mi nedává smysl, proč všechny klientské programy pro SPICE protokol (kromě toho spiccec), na základě toho, že ve VM nenajdou grafický výstup, vypnou veškerou svoji zbývající funkcionalitu.

Napadá mne ten smysl, že když ve spicec nevidíš grafický výstup a přesto funguje předávání vstupů z klávesnice a myši, tak by to mohlo být docela matoucí, protože bez grafického výstupu to vypadá, že k navázání spojení nedošlo, ale přesto by docházelo k předávání vstupů z klávesnice a ty bys nevěděl a neviděl, že ovládáš vzdálený počítač ke kterému jsi přes SPICE připojený.

A jak to teda funguje na spicec při passthrough? Vidíš černou obrazovku nebo místo černé obrazovky je varování, že obraz se sice nepřenáší, ale vstupy z klávesnice ano?

[trekker.dk]

protože bez grafického výstupu to vypadá, že k navázání spojení nedošlo

Nevypadá, když k navázání spojení nedojde, vyhodí to chybovou hlášku a ukončí se to.

A jak to teda funguje na spicec při passthrough?

Černé okno, kurzor se v něm přepne na nekliknutelný (nebo jak se to jmenuje, prostě křížek). Klávesová zkratka na přepnutí do fullscreen pořád funguje. A jinak stejně jako u VNC klientů, dokud to okno má focus a kurzor myši je v něm, tak bere všechny klávesové vstupy, které může (ctrl-alt-Fx na přepnutí X konzole třeba sebrat a předat do hosta nedokáže)

[LarryL]

VNC používám jen vyjímečně, ale jak se dívám, tak ani s VNC to není tak jednoznačné. VNC sice nepotřebuje napojený fyzický displej, ale potřebuješ mít nainstalovaný X server: VNC without X server. A abys spustil Xko tak potřebuješ mít na serveru grafickou kartu (alespoň falešnou)

SPICE taky potřebuje grafickou kartu (nejčastěji je to virtuální qxl). GPU, kterou máš předanou přes passthrough SPICE nevidí.

Pokud bys dané VM nastavil 2 GPU (VGA-passthrough + qxl), tak si myslím, že by ti při správném nakonfigurování měl Remote-viewer fungovat (právě přes tu qxl grafiku). Ale připadá mi to už škrabání pravou rukou za levým uchem přidávat další GPU do VM jen kvůli předání vstupů.

[trekker.dk]

Ale houbes. Qemu umí fungovat jako VNC server a prostě na něm ukazuje to, co je na virtualizované grafice v tom VM. VNC klient pak dělá to samé jako SPICE klient, akorát přes jiný protokol. Teda v základu to samé - virtualizovaný desktop bych s tím asi používat nechtěl, ale na to vidět výstup virtualizovaného serveru a dostat do něj vstup z klávesnice to stačí.

Ale připadá mi to už škrabání pravou rukou za levým uchem přidávat další GPU do VM jen kvůli předání vstupů.

Přesně tak, proto za nejvíc přímočaré řešení považuju to, co jsem psal - aby SPICE klient ignoroval absenci displaye a vstupy předával i bez něj.

Plus ve widlích to ještě AFAIK funguje s více grafikami nějak divně, něco jako že výpočty dělá jen jedna a ostatní slouží jen jako zobrazovače - tj. když se to blbě poskládá, passthrough grafika jede s výkonem té virtuální. Dokonce mám pocit, že jsem to i zkoušel a výsledek byl nic moc.

[Aleš Kapica]

VNC je sračka. Přes spice není problém použít i aplikace s 3D akcelerací.

[LarryL]

Nevím k čemu se tvé "Ale houbes" vztahuje když vlastně nerozporuješ co jsem napsal. Možná jsme si jen nerozumněli. Ty jsi napsal:

A jinak stejně jako u VNC klientů, dokud to okno má focus a kurzor myši je v něm, tak bere všechny klávesové vstupy

Já jsem ti na to napsal, že aby ti VNC fungovalo, tak potřebuješ mít na vzdálené ploše nainstalovanou GPU (alespoň falešnou - xf86-video-dummy). Takže pokud chceš, aby SPICE fungovalo podobně jako VNC, tak i na vzdálené ploše kam se napojuješ přes SPICE musí být GPU, kterou SPICE vidí (např. qxl).

aby SPICE klient ignoroval absenci displaye a vstupy předával i bez něj.

Nevím co myslíš tím displayem. SPICE potřebuje virtuální GPU (qxl) a pak SPICE clienta (remote-viewer, spicec ...), který zobrazuje grafický výstup z qxl. Takže předpokládám, že tím displayem myslíš právě tu virtuální GPU (qxl). To je právě to na co jsem narážel výše. VNC neumí fungovat bez GPU, tak proč to chtít po SPICE?

[LarryL]

(alespoň falešnou - xf86-video-dummy)

Jen pro upřesnění: xf86-video-dummy byl příklad při napojování do fyzického serveru a netýká se to napojování VNC do Qemu. Ale u Qemu platí určitě to samé tzn. aby ses mohl pomocí VNC klienta napojit do Qemu, tak v Qemu musí být nastavená nějaká virtuální GPU.

[trekker.dk]

Já jsem ti na to napsal, že aby ti VNC fungovalo, tak potřebuješ mít na vzdálené ploše nainstalovanou GPU (alespoň falešnou - xf86-video-dummy).

A přesně na to jsem psal to "houbeles" Ale jinak po tom doplnění máte pravdu - mluvím o propojení VNC klienta pro Qemu obecně, tam žádný X server potřeba není.

Ale u Qemu platí určitě to samé tzn. aby ses mohl pomocí VNC klienta napojit do Qemu, tak v Qemu musí být nastavená nějaká virtuální GPU.

Nemusí. Nebude to nic ukazovat, ale napojit se jde. (I když co jsem teď otestoval, chová se to stejně jako moderní SPICE klienty, tj. nepředává vstupy.)

Nevím co myslíš tím displayem. SPICE potřebuje virtuální GPU (qxl) a pak SPICE clienta (remote-viewer, spicec ...), který zobrazuje grafický výstup z qxl.

Už jsme to řešili vejš. Nepotřebuje. Mám stroj, který nemá virtuální GPU, mám SPICE klienta (spicec), vstupy jsou předávány do Qemu, výstup z Qemu předáván není, protože neexistuje. Ano, ten SPICE klient pak neukazuje žádný obraz, to po něm ovšem v dané konfiguraci nikdo nechce.

[LarryL]

Ale u Qemu platí určitě to samé tzn. aby ses mohl pomocí VNC klienta napojit do Qemu, tak v Qemu musí být nastavená nějaká virtuální GPU.

Nemusí. Nebude to nic ukazovat, ale napojit se jde. (I když co jsem teď otestoval, chová se to stejně jako moderní SPICE klienty, tj. nepředává vstupy.)

Když spustím VM bez virtuální GPU, tak se i s remote-viewerem dokážu napojit, akorát, že místo grafického výstupu vypisuje nápis "Připojeno ke grafickému serveru" a jak správně píšeš nepředává to vstupy.

Takže podtrženo sečteno: SPICE klienti, ani VNC klienti nedokáží předávat vstupy z klávesnice a myši do VM když daná VM nemá nastavenu GPU. Jediná výjimka je spicec.

Když bych do toho chtěl dál štourat, tak spicec má volby:

--enable-channels <ch0, ch1...>
    Enable the specified channels. Use “all” for enabling all possible channels. Use the following names for enabling only the selected channels: “display”, “inputs”, “cursor”, “playback” and “record”. By default all channels are enabled.

--disable-channels <ch0, ch1...>
    Disable the specified channels. Use “all” for disabling all possible channels. Use the following names for enabling only the selected channels: “display”, “inputs”, “cursor”, “playback” and “record.” By default all channels are enabled. 

Remote-viewer má také volbu:

"disable-channels" (string list)
    The list of session channels to disable.
    The current SPICE channels are: main, display, inputs, cursor, playback, record, smartcard, usbredir. 

Ale když si v terminálu zobrazím nápovědu remote-viewer --help-all tak to volbu --spice-disable-channels neukazuje.

Takže jen taková spekulace: Není to třeba tak, že i remote-viewer umí fungovat podobně jako spicec, akorát že remote-viewer není zkompilovaný s patřičnou volbou?

[Aleš Kapica]

Takže jen taková spekulace: Není to třeba tak, že i remote-viewer umí fungovat podobně jako spicec, akorát že remote-viewer není zkompilovaný s patřičnou volbou?

Kdo ví? Zkus parametr --help-spice, jak to má spicy. To jsi mimochodem nezkoušel?

[LarryL]

--help-spice vypisuje jen užší výběr toho co vypisuje help-all

Volba --spice-disable-channels tam není.

[trekker.dk]

remote-viewer --debug ...
...
(remote-viewer:6602): virt-viewer-DEBUG: 23:21:34.934: FIXME: disable-channels is not supported atm

[LarryL]

PS: Myslím, že SPICE ani dnes klávesnici a myš nepřenásí. Podle mne ten trekker.dkův hack funguje proto, že při kliknutí na spicec se fokusne okno a díky tomu začne přenášet data z klávesnice a myši přes virtuální klávesnici a myš, která je standardně předdefinovaná v Qemu (nebo ve virt-manageru).

[trekker.dk]

No, spicec nemá s Qemu jiný kontakt, než přes to zadané síťové spojení, takže já bych řekl, že to musí bejt přes SPICE.

[LarryL]

Příloha:

• virtuální klávesnice-myš-tablet.png (110904 bytů)

Má jiný kontakt, a to přes virtuální klávesnici, myš a tablet o kterých jsem psal. Klávesnice a myš jsou defaultní zařízení, které si Qemu vytvoří i když je nezadáš. Podobně je tomu ve virt-manageru - viz příloha.

[LarryL]

...ale vlastně jo máš pravdu. Virtuální klávesnice, myš, tablet jsou sice definované v Qemu, ale data musí téct přes spice protokol.

[LarryL]

...nedalo mi to, tak jsem ťuknul do gůglu a vypadá to, že Intel adoptoval Looking Glass (zaznělo to i ve videu), takže grafický výstup ze SR-IOV asi tentokrát nebude součástí Qemu, ale vznikne samostatný klient, podobně jako jsou klienti pro Spice (Remote-Viewer, atd.).

[jiwopene]

Asi by stála za zmínku volba -enable-kvm.

[Want]

To byla asi ironická poznámka, že?

Před osmi lety, když jsem si ještě hrál s clustery, jsem si udělal virtuál, pouštěný pochopitelně přes čisté qemu (s využitím modulu kvm), ve kterém bylo možné spustit dalších sedm virtuálních strojů, spojených do clusteru. To celé v jednom qcow2 souboru o velikosti 1G. Původně to měl být tréningový virtuál pro pacemaker, ale pak jsem přešel na vlastní skript kvm a pacemaker poslal k šípku.

[Heron]

Díky za článek. Na cli používám virsh (libvirt). Způsob popsaný ve článku se pro něco hodí lépe.

[Heron]

Na jednú vec musím upozorniť a to je kombinácia fs. Neodporúčam kombináciu LVM thin pool s fs ext4 ak máme LVM s fs ext4 vo VM v spojení s qcow2. Pri inštalácii na tejto platforme trvala inštalácia mnohonásobne dlhšie. Preto odporúčam prvotnú inštaláciu systému do VM vo formate obrazu raw.

Jasně, protože je to v podstatě COW nad COW. Proto se pro QCOW2 moc nehodí ani BTRFS. Též je potřeba si dát pozor na FS uvnitř toho vmka, mít tam btrfs, vmko qcow2 na btrfs, to by bylo hodně pomalé.

Asi nejlepší je mít vmka nad LV v LVM, nebo jako raw soubory na fs starého typu (xfs, ext4). Nebo nad ZFS ZVOL. Atd.

[Petr Fiedler]

Zrovna to teď řeším. V pc mám NVMe rozdělené na 3 oddíly. EFI, 200 GB pro OS (LUKS, Btrfs) a 800 GB pro /data (LUKS, Btrfs). Adresář s qcow.2 mám na /data. Stačilo by oddíl /data zmenšit a za ním vytvořit nový oddíl pro qcow.2 (LUKS, ext4)?

Používám 2 VM. Mint (ext4), takže ten by pak měl být v pohodě a Windows 10. Ty Windows bych chtěl upgradovat na verzi 11. MS tool mi oznámil, že to nepůjde. Problém je v tom, že ten VM používá BIOS místo UEFI. Půjde to nějak předělat? A taky tam nemám GPU. To taky brání upgradu. Passthrough GPU zatím udělat nemůžu, protože v pc mám zatím jen jednu. To by šlo nějak hacknout? Neřešil jsi to/nevíš?

[Petr Fiedler]

Ještě koukám, že pro ext4 radíš raw. Takže by asi bylo nejlepší oba ty VM vytvořit znovu, že?

[Heron]

Jak to teď máš? QCOW2 nad BTRFS? Zkus nastavit nocow na daný adresář (viz další komentář) a ty soubory pak zkopíruj (přesunutí nepomůže) znovu. Potom to vyzkoušej. Zkus udělat tuhle změnu a potom to otestuj. Na NVMe, by to mělo být ok. (Až potom případně měnit FS na XFS.)

[Petr Fiedler]

Jak to teď máš?

Jinak, než jsem myslel. Btrfs > qcow2 > Btrfs. Takže VM není nad ext4, ale taky nad Btrfs. Pomalé mi to ale nepřipadá. Zkusil jsem rebootnout VM a reboot plocha > plocha = ~17s. NVMe má r/w 5GBps/4,4GBps. Při kopírování velkého objemu dat ta rychlost sice degraduje, ale na běžný provoz je to celkem rychlé.

Ten pokles rychlosti je jediným problémem? Někde jsem tu s LarryL(em) řešil problém qcow2 a Btrfs, ale nebyl to můj dotaz a těžko bych to teď hledal. Už si právě nepamatuji, o co tam tenkrát šlo. Každopádně když budu spokojený s rychlostí, tak to řešit nemusím?

[Heron]

Zkusil jsem rebootnout VM a reboot plocha > plocha = ~17s.

Kolik máš RAM? Na svým pecku mám boot do W10 do 15s. Na virtuálce, pokud je to celé nacachované v ram, je to skoro hned. Ale tohle měření nic neznamená. On tam detekuje HW apod. 17s je naprosto OK.

Ten pokles rychlosti

Je to složitější. COW znamená copy on write. To znamená, že každá kopie (každý zápis na stejné místo) se uloží někam jinam (copy on write doslova znamená: přečíst, změnit, uložit jinam).

je jediným problémem

On to není problém per se. COW zdvojnásobuje přepis na daném zařízení. Takže se to rychleji opotřebuje. Pokud ale vmko umístíš na nocow, tak se jednoho přepisu zbavíš.

Každopádně když budu spokojený s rychlostí, tak to řešit nemusím?

Ano. A potom to můžeš zoptimalizovat.

Co máš za HW. Nevšiml jsem si (moje chyba), že sis to koupil. Zajímá mě to, protože kdy upgrade na poslední zen3. Co máš ty?

[Petr Fiedler]

Příloha:

• sestava.html (3662 bytů)

Kolik máš RAM?

V pc 32 GB, každému VM jsem přidělil 4 GB.

Seznam hw přikládám.

[Petr Fiedler]

Koukám, že místy je z toho rozsypaný čaj, ale odkazy by měly fungovat. Případně vždy ten spodní odkaz.

[Petr Fiedler]

Zkusím to dát ještě sem:

HW konfigurace

MB
ASRock: B550 Steel Legend
Heureka: ASRock B550 Steel Legend

PSU
Corsair: RMx Series™ RM650x
Heureka: Corsair RMx Series RM650x 650W CP-9020178-EU

CPU
AMD: Ryzen™ 7 5800X Desktop Processors
Heureka: AMD Ryzen 7 5800X 100-100000063WOF

Chladič
Noctua: NH-D15S
Heureka: Noctua NH-D15S

RAM (2 ks)
Kingston: KSM26ED8/16ME
Heureka: Kingston KSM26ED8/16ME

NVMe
GIGABYTE: AORUS Gen4 SSD 1TB
Heureka: GIGABYTE AORUS Gen4 1TB, GP-AG41TB

HDD
Western Digital: WD_BLACK™ Performance Desktop Hard Drive 4TB
Heureka: WD 4TB, SATA3 6Gbps, WD4005FZBX

GPU
AMD (HP neuvádí): AMD Radeon™ Pro W5500 Graphics Card
Heureka: HP Radeon Pro W5500 8GB GDDR6 9GC16AA

Skříň
Fractal Design: Define XL R2
Heureka: Fractal Design Define XL R2 FD-CA-DEF-XL-R2-BL

Trackball
Kensington: Kabelový trackball Kensington Orbit™ s kroužkem Scroll Ring No. K72337EU
Heureka: Kensington K72337EU

Klávesnice
C-Tech: Doména je zaregistrována!
Heureka: C-Tech Scorpia V2 GKB-119

Mechanika
LG: Přehled mechanik, daný model výrobce momentálně na svém webu nemá.
Heureka: Hitachi-LG GP60N

Monitor
Philips: HDR displej 4K s technologií Ambiglow 436M6VBPAB/00
Heureka: Philips 436M6VBPAB

[Heron]

Díky. Tenhle CPU mám taky ve výběru. Líbil by se mi R9 5950X, ale asi je to overkill, stále přemýšlím mezi hodně jádry pro Blender apod. nebo menším počtem výkonnějších jader pro hraní her.

[Petr Fiedler]

Nemáš zač.

Ještě jsem se díval, bavíme se o Zen3, že oba R9 mají oproti R7 2x větší L3 cache. A i 5950X má oproti 5900X větší L1 a L2 cache. V čem se to v reálu projevuje? Možná bych se řídil i tím. Ne jen počtem jader a frekvencemi.

[Heron]

Přístup do paměti je obecně to nejpomalejší. Proto jsou tak velký cache. Potom existuje brute force řešení typu EPYC, kde je velké množství kanálů, má to hodně paměti (v TB) a je to hodně rychlý. Případně HBM což je paměť přímo nalepená na čip, dneska to umí i 1TB/s.

Ale běžný paměti v PC jsou pomalé, mají velké latence, takže rychlá velká cache se hodí.

Projevuje se to u výpočtů, kde procesor čeká na paměť.

[Petr Fiedler]

Díky za vysvětlení

Projevuje se to u výpočtů, kde procesor čeká na paměť.

A jak poznám, že CPU čeká na paměť?

[Heron]

Dle typu výpočtu. To nepoznáš*. (Resp. jedině tak, že bys zkoušel různé typy CPU a některé by byly pro daný výpočet rychlejší.) Proto to na desktopu moc nemá smysl řešit. Jak jsou napsaný programy neovlivníš a kupovat si 2x tak drahej procesor je zbytečný (pokud jej vyloženě nevyužiješ - třeba grafik pro render, nebo složitý výpočty materiálů a tak).

*) Jsou na to i nějaký sondy do jádra a tak. Místní borci by mohli poradit.

[Heron]

Proč jsi tam dal jen 32GB RAM? Cena nebo aktuálně víc nepotřebuješ? Na desce volný sloty jsou, takže to není problém doplnit. Ptám se proto, že jsem nedávno renderoval jednu scénu (oni mají všechny scény pro každý obrázek dané verze blenderu dostupné free) a 32GB už bylo málo, tak jsem potupně nastavil swap.

[Aleš Kapica]

…, tak jsem potupně nastavil swap.

Swap rozhodně není přežitek, pokud alespoň někdy pracuješ s velkými souboru, nebo když virtualizuješ stroje, co vyžadují hodně paměti.

[Heron]

To dost záleží na tom, co s nimi děláš. Velký soubor se rozhodně nemusí celý vejít do paměti, obvykle se pracuje po malých blocích.

O virtualizaci na swapu se ani bavit nebudu. Jasně, jako těžká nouzovka, pokud potřebuješ něco rozjet, tak OK, ale pro provoz ne.

[Aleš Kapica]

O virtualizaci na swapu se ani bavit nebudu. Jasně, jako těžká nouzovka, pokud potřebuješ něco rozjet, tak OK, ale pro provoz ne.

Tady nejde o to, že bys se ten swap reálně používal. Vtip je v tom, že ti dovolí ošálit virtualizovaný systém. Díky tomu umím spustit virtualizované MS Windows s 1TB virtuálním diskem a 50GB RAM na stroji co má reálně 8G RAM a 120GB SSD a dá se na nich vzdáleně pracovat přes virtualizovanou plochu připojenou před Spice.

[Heron]

Ta ramka se u toho vmka dá nastavit. Ale jo, chápu, tohle využití dává smysl.

[Petr Fiedler]

Proč jsi tam dal jen 32GB RAM? Cena nebo aktuálně víc nepotřebuješ?

Nepotřebuji. I tak už to mám docela naddimenzované.

[Petr Fiedler]

Jen pro zajímavost:

Kolik máš RAM? Na svým pecku mám boot do W10 do 15s. Na virtuálce, pokud je to celé nacachované v ram, je to skoro hned. Ale tohle měření nic neznamená. On tam detekuje HW apod. 17s je naprosto OK.

Tak jsem dal na ten bindnutý adresář qemu_kvm chattr +C a reboot plocha > plocha trvá stále ~17 s.

[Heron]

Stačilo by oddíl /data zmenšit a za ním vytvořit nový oddíl pro qcow.2 (LUKS, ext4)?

Mělo by stačit nastavit příznak nocow příkazem: chattr +C na daný (v tuto chvíli prázdný) adresář. To vypne COW v BTRFS pro daný adresář a soubory v něm. Je to rychlejší, ale na XFS to nemá. (Ale před případnou změnou FS doporučuji otestovat, na NVMe to bude rychlé a vůbec nebude potřeba měnit FS.)

Ty Windows bych chtěl upgradovat na verzi 11. MS tool mi oznámil, že to nepůjde. Problém je v tom, že ten VM používá BIOS místo UEFI.

Ano, Win11 potřebují UEFI. Převáděl jsem takto W10 (na fyzickém stroji). Ještě jsem to neupgradoval na W11 (jde to, ale snad zítra / víkend).

A taky tam nemám GPU. To taky brání upgradu. Passthrough GPU zatím udělat nemůžu, protože v pc mám zatím jen jednu. To by šlo nějak hacknout? Neřešil jsi to/nevíš?

To nevím. Na virtuálce jsem zatím na W11 neupgradoval. Kolega je má na pecku a tam to šlo hodně rychle W10-W11 asi během 40minut. Krom vzhledu žádná zásadní změna, vše mu fungovalo (dokonce si nechal otevřených asi 40 programů , vše prošlo).

[Petr Fiedler]

Díky za odkaz.

S tím převodem jsem se špatně vyjádřil. Já měl na mysli, jestli to půjde nějak přepnout v QEMU/Virt manageru? Používám i440FX BIOS.

[Petr Fiedler]

Mělo by stačit nastavit příznak nocow příkazem: chattr +C na daný (v tuto chvíli prázdný) adresář. To vypne COW v BTRFS pro daný adresář a soubory v něm.

QEMU/KVM si defaultně ukládá obrazy do /var. Já je ale mám v /data a ve fstab mám:

/data/data_giga/qemu_kvm /var/lib/libvirt/images none bind,x-gvfs-hide 0 0

Na který adresář(e) mám prosím tě chattr +C aplikovat?

[Petr Fiedler]

Já bych řekl, že jenom na ten qemu_kvm

[Petr Fiedler]

Díky za zápis.