Dotaz: QEMU/KVM - VM Windows 10 - problém se zvukem

[Petr Fiedler]

Zdravím,
nainstaloval jsem si nejnovější verzi QEMU/KVM (libvirt) a vytvořil VM Windows 10. Před instalací jsem přidal obraz s ovladači (virtio-win-0.1.171) a pak spustil instalaci. Při ní jsem přidal ovladač pro úložiště a Windows nainstaloval. Ve Windows jsem pak nainstaloval spice-guest-tools-0.141. Pak jsem spustil správce zařízení a ze stále připojeného obrazu aktualizoval vše, co šlo. Stále však přetrvává problém se zvukem, jako u předchozí instalace. Zvuk se trhá a při každém trhnuntí se ozve slabé zapraskání. Na kartě XML nevidím u zvuku nic, co bych mohl změnit tak, aby to pomohlo. Používám ovladač HDA (ICH6). Zkusil jsem HDA (ICH9), ale nepomohlo to. Pak je tam ještě jako poslední ovladač k dispozici AC97, ale když jej použiju, tak ve Windows zvuk nejede vůbec. Ví někdo prosím co s tím?

Díky

---

---

Odpovědi

[Petr Fiedler]

Má alespoň někdo podobnou zkušenost, kterou se mu nepodařilo vyřešit? Ať neřeším neřešitelné.

[PetebLazar]

Taky jsem tomu kdysi pár hodin(dní?) věnoval a pak to nakonec vyřešil zakoupením nejlacinější USB zvukovky a jejím USB-passthrough do Win10 VM. Výstup ZK jsem připojil na sekundární vstup reproduktorů.

[Petr Fiedler]

Díky moc! Snad mi to taky pomůže. Chci to kvůli odečítači obrazovky. Orca v Linuxu není to pravé ořechové. Mám do Windows koupený docela drahý hlas (teď už to není třeba, protože tam celkem kvalitní hlas je by default) a s tím praskáním by se nedalo nic poslouchat. Pak sem napíšu, jestli to pomohlo. Ještě se zeptám. Šlo by koupit i nějakou PCI zvukovku?

[Petr Fiedler]

PCI asi ne. Už mi to docvaklo (doufám ). Tak tedy USB. Tahle by měla být lepší. Co říkáš?

[PetebLazar]

Ta by podle papírových parametrů měla být ještě lepší. Nevidím ve specifikacích důvod proč by neměla také vyhovovat, praktickou zkušenost s ní nemám.

[Petr Fiedler]

Dobře, dík. Pak dám vědě, jestli mi to pomohlo.

[Petr Fiedler]

Tak to nepomohlo. Ale alespoň jsem si díky tomu vysál za komplem, vysál jsem si i kompl a klávesnici a vyměnil teplovodivou pastu (po roce a půl).

[LarryL]

Já jsem zvuk z VM přes USB zvukovku nikdy nezkoušel, ale je divné, že by to problém nevyřešilo, protože Win10 by měl USB zvukovku přímo vidět a použít/nainstalovat pro ni ovladač. Jsi si jistý, že jsi tu USB zvukovku správně "předal" do VM? Ve virt-manageru by se to mělo udělat takto: "Přidat nový virtuální hardware" > "USB zařízení hostitele" > vybrat USB zvukovku.

[Petr Fiedler]

Nepředal jsem jí do VM. Teď jsem to tedy udělal a zvuk ve Windows se výrazně zlepšil. Problém je v tom, že se po chvilce úplně vypne. Pustím např. nějaké video na YT a zvuk krásně jede. Po chvíli se video sekne a vypne se i zvuk. Po chvíli se video opět spustí, ale už bez zvuku. A ten odečítač dělá to samé. Chvíli mluví a pak zmlkne. Zkoušel jsem v nastavení Windows různé kvality od 8 bit / 8000 Hz (telefon) až po 24 bit / 96000 Hz (studiová kvalita), ale časem zmlkne všechno. Zkusil jsem i aktualizaci ovladačů, ale nic se neaktualizovalo. Napadá mě už jen zkusit jiné (starší) ovladače. Stáhl jsem latest, ale byly tam i stable. Jinak už nevím. Nenapadá tě něco?

PS: jo a spustil jsem i poradce při potížích. Poradil mi, abych vypnul efekty, ale ty byly všechny stejně vypnuté. Takže nic.

[LarryL]

Nikdy se mi nestalo, že by USB zařízení předané do VM se po čase odpojilo nebo se vyplo. Vypadá to spíš na problém s Win10 než problém s virtualizací. Zkus pogooglit. Tady řešili trochu jiný problém, ale tazateli pomohlo přehodit z USB2.0 do USB3.0. Jiný člověk tam píše:

Funny thing is that there was sound (once) for just over a minute and then it simply went away.

Což se podobá tvému problému, bohužel na řešení nepřišel/neuvedl_ho.

Jediné co mne napadá v souvislosti s virtualizací je, že si ve VM můžeš libovolně nastavit/vytvořit virtuální řadič USB, tzn. můžeš virtuálce vytvořit jen USB2.0 (ehci1) nebo USB3.0 (qemu-xhci) nebo více řadičů zároveň... Takže pokud používáš virt-manager, tak u nastavení VM Win10 klikni na "Radič USB 0" a budeš tam zřejmě mít "USB 2". Zkus to přehodit na "USB 3".

PS: Pro virtualizaci je prý lepší použít virtuální zařízení qemu-xhci (USB3.0) než ehci1 (USB2.0), což se mi kdysi potvrdilo. Všiml jsem si, že předaná (passthrougnutá) USB myš měla plynulejší pohyb kurzoru s qemu-xhci než s ehci1.

[PetebLazar]

Nemůže jít o důsledek snahy o úsporný režim USB periférie ze strany GuestOSu/HostOSu?

Před pár dny přešel na qemu-xhci, hlavní důvodem bylo použití USB3 zařízení v GuesOSu. Dosažená rychlost přenosu cca 370MB tam/zpátky na USB3/NVME sice není maximem daného zařízení, ale stále ještě přijatelná rychlost.

[LarryL]

Zapínání úsporného režimu mě taky napadlo, ale po předání USB zařízení do VM by už HostOS do zařízení neměl zasahovat, takže se mi nezdá reálné, aby Linux té USB zvukovce zapl nějaký úsporný režim. Jedině, že by úsporný režim zapl GuestOS (Win10), ale taky mě nenapadá důvod proč by Win10 zapl úsporný režim pro USB zařízení, které je aktivně používáno.

[Petr Fiedler]

Používám USB 3.0. Už jsem to zkusil i vrátit, ale nepomohlo to. Mluvil jsem to tom se známým a říkal něco o uspávání toho zařízení ve VM, Kdysi s tím měl podobný problém. Nějaká apka ve Windows mu to vyřešila. Má mi jí poslat. Tak pak dám vědět.

Už jsem si i říkal, že bych kvůli Windows nainstaloval i VitrualBox, ale nechci closed source.

[LarryL]

Vzpomněl jsem si, že jsem v Ovládacích panelech Win10 v Možnostech napájení nastavil "Vysoký výkon". Už si nevpomínám na důvod, ale je to většinou u Windowsů ve VM doporučováno.

[Petr Fiedler]

A víš, že jsem nad tím uvažoval? Zkusím to.

[Petr Fiedler]

Nepomohlo to.

[PetebLazar]

Pozn. Samotný VirtualBox bez Extension Packu (USB2.0+, .....) je snad pod licencí GPL2, takže asi nejde označit za close source.

[Petr Fiedler]

Díky za vysvětlení.

Má smysl Windows ve VB zkoušet bez těch přídavků pro hosta?

[PetebLazar]

Pozor, přídavky pro hosta a Extension Pack je něco jiného. Ten Extension Pack je funkcemi zaměřen primárně na business sféru (min. počet licencí je snad 100). Přídavky pro hosta(Guest Additíons) jsou snad pod binary licence, stejnou jako samotný VB.

Soukromně k nekomerčnimu využití, výkouvému lze snad využít i ten Extension Pack (PUEL licence), tj. nic k nasazení do komerčního provozu.

[Petr Fiedler]

Tak jsem si o tom něco přečetl a Extension Pack pro nekomerční použití používat můžu. Otázkou ale zůstává, jestli je open source? Nikde to nemůžu najít. Nevíš?

[PetebLazar]

PUEL(licence) k Extension Packu mj. jasně zmiňuje, že je u něj zapovězena decompilace. Takže to není open source, v opačném případě by taková podmínka byla nesmyslná.

[Petr Fiedler]

Tak ta apka taky nepomohla. Pokud bude večer čas, zkusím si pohrát s tím XM: atd. Pokud ne, tak až zítra.

[LarryL]

Po chvíli se video sekne a vypne se i zvuk.

Je otázka jestli se tvůj problém opravdu týká zvuku. Když USB zvukovku natvrdo odpojíš nebo změníš nastavení v Ovládacích panelech, tak si myslím, že při ničem by se ti nemělo zaseknout video. V úvodním příspěvku jsi psal také o trhnutí zvuku + prasknutí zvuku. Problémy se zvukem, které znám a které by měly jít odstranit zde zmíněnými způsoby bych popsal spíše jako "praskání" než "trhání". Zvuk zkrátka není čistý, ale nezadrhne se třeba na sekundu. Takže je možné, že tvé "trhání" má příčinu někde jinde než ve zvuku (ovladačích zvukové karty). Možná zkus udělat video nebo aspoň záznam zvuku a hodit odkaz.

[Petr Fiedler]

Abychom si rozuměli:

Když ve VM používám defaultní zvukovku, tak se zvuk trhá a praská v něm.

Když přepnu na USB zvukovku, tak zvuk jede krásně, ale jen chvíli. Pak se vypne. Např. video na YT je chvilku ozvučeno. Pak se celé sekne, a pak se někdy spustí jen video bez zvuku, a někdy už se nespustí ani video. A nebo se to sekne při přepnutí na full screen. Když pak zavřu prohlížeč a spustím to video, tak zase zvuk jede, ale jen chvilku a celé se to opakuje. Nebo i když jen klikám na panelu na posuvník zvuku, tak se chvilku ozývá tón hlasitosti a pak taky ztichne.

Jak mám to video pořídit? Něčím ve VM? Čím?

[LarryL]

video na YT je chvilku ozvučeno. Pak se celé sekne, a pak se někdy spustí jen video bez zvuku, a někdy už se nespustí ani video.

Jak ty to děláš čoveče?

Jak mám to video pořídit? Něčím ve VM? Čím?

Nějaký Screen recorder pro Windows co ti padne pod ruku https://www.techradar.com/news/the-best-free-screen-recorder. Nebo mrkni do Microsoft Store.

Pokud vidíš grafický výstup z VM na Linux, tak použij nějaký Screen Recorder pro linux, třeba RecordMyDesktop

[Aleš Kapica]

Pro klikače je nejlepší vokoscreen.

[Petr Fiedler]

Takže:

Ve VM jsem zkoušel nahrát video, ale kvalita byla otřesná. Jeden snímek tak za 5 sekund. IMHO se není čemu divit. Nemám dedikovanou GPU a o vše se stará jen ta integrovaná.

Tak jsem to zkusil natočit na mobil. Obraz ušel (nezkoušel jsem v pc), ale ten problém se zvukem nebyl prakticky slyšet.

Tak jsem to zkusil nahrát z hostitele, ale to, co se odehrávalo ve VM nebylo pro OBS Studio v hostiteli viditelné.

Takže jsem ti pořídil alespoň zvukovou nahrávku. Pokud bys to chtěl porovnat s originálním videem, tak je to tohle.

[Aleš Kapica]

A jsme u toho. Zas. Virtualizace má své limity a pokud ji chce člověk používat, tak je musí znát a respektovat. Je jasné že ti nestíhá komp nahrávat obraz z VM, když má co dělat aby to všechno upočítal.

[MadCatX]

Mně přijde, že je to jen otázka vysoké zátěže CPU, který pak nestíhá plnit zvukový buffer. Pokud pustíš ve VM YouTubové video, pošleš tím spolehlivě do kolen skoro jakýkoliv procesor. V reálném čase dekódovat HD video a zkompozitovat grafický výstup dá dost práce. Na železe ti vždycky aspoň část z toho oddře GPU a nezdržuje režie virtualizace. Navíc zvukové systémy na železe většinou běží se zvýšenou prioritou a dalšími vychytávkami, aby minimalizovaly latenci. Ve VMku nic podobného není a pokud ti letí CPU na plné kule, na včasné plnění zvukového bufferu už prostě nemá čas. Situace by mohla být trochu lepší s QEmu 4.2. Co jsem ale zkoušel s QEmu 4.1 a novým zvukovým subsystémem, žádná sláva to nebyla.

[Petr Fiedler]

No ale jak to, že VM Linux Mint je v pohodě. Pustím YT video na 1080p a zvuk je čistý. VM Windows 10 YT video na 240p a zvuk je otřesný. Čím to?

[LarryL]

A zkoušel jsi nějaké lokální video? Jestli ten problém není náhodou v internetovém prohlížeči.

[Petr Fiedler]

Výborný nápad. Zkusil jsem to a mp3 v pohodě (USB zvukovka, integrovanou jsem nezkusil). Když jsem spustil video, tak problémy. Napřed se po chvíli vypnul zvuk a když jsem je spustil znovu, tak zvuk jel ale zlobil obraz. Takže asi QEMU/KVM má bez dedikované GPU s Windows 10 problém. A stejný problém je i při spuštění odečítače. Je slyšet praskání. A vlastně je i slyšet, když kliknu v systray na ikonu hlasitosti. Ozve se zvuk, který ukazuje nastavení hlasitosti a praská při něm. A to IMHO výpočetně náročná operace není. Tak nechápu.

Zkusím to odladit ve VirtualBoxu. Po instalaci jsem narychlo jen spustil Edge > YT > a video i audio bylo v pohodě. Nemám to ale zatím full screen. Uvidím, až nainstaluji extension pack, jak se to bude chovat. Pokud to bude OK, tak to do konce roku s VirualBoxem pro Windows vydržím. Pak si, dá-li BŮH, budu pořizovat nové pc a po hw stránce dost přitlačím. Pokud by byl se zvukem při full screen ve VB problém, tak zatím koupím nějakou GPU (slabší, nebo bazar) a budeme ladit

[Petr Fiedler]

Tak ve VirtualBoxu se Windows 10 chovají mnohem lépe. Video i audio jede dobře a celkově je systém znatelnsě svižnější. Takže pokud zprovozním USB, tak si pro Windows zatím ponechám VB.

[LarryL]

Takže asi QEMU/KVM má bez dedikované GPU s Windows 10 problém.

Běžné používám dedikovanou zprůchodněnou GPU, ale nyní jsem zkusil na cca 4-5 let starém Skylaku s QXL (tzn. také virtuální GPU co máš ty), VM jsem přiřadil 3 jádra, 4 GB ram, VM používá AC97, do VM jsem se napojil přes Spice a tvoje video s motorkama z YT mě jede naprosto plynule včetně zvuku (v okně i na FullScreen). Rozlišení VM mám FullHD. Zkusil jsem nějaké 4K video a tam už je problém. Video jede tím stylem, že jeden snímek je zobrazen cca 5 sekund a pak skočí další snímek zase na 5 sekund, tzn. framerate 1 snímek za 5 sekund . Zvuk i přesto jede naprosto plynule. Když snížím na 1440p60 tak to už jede plynule i když jde vidět, že CPU je dost vytížené. Testováno na Win10 1709 ve Firefoxu. V Qemu používám typ stroje q35. Ty máš zřejmě i440fx, ale to asi nebude problém. Podtrženo sečteno, pokud nemáš nějaký opravdu obstarožní CPU, tak ani na integrované GPU a s použitím virtuální GPU QXL, problém není. Někde máš něco blbě, ale těžko říct co.

"A vlastně je i slyšet, když kliknu v systray na ikonu hlasitosti. Ozve se zvuk, který ukazuje nastavení hlasitosti a praská při něm. A to IMHO výpočetně náročná operace není."

Ne to opravdu není náročná operace. Tohle praskání je problém číslo 1 co by měl vyřešit driver AC97 nebo možná Qemu v4 a výš. U USB zvukovky by tohle praskání být nemělo a pokud je, tak možná má jinou příčinu, ale v tomhle moc neporadím, protože USB zvukovku ve VM nepoužívám. Problém číslo 2 s USB zvukovnou, kde ti úplně vypadne zvuk a nebo se trhá video je zase jiný problém, který jsme zatím nerozklíčovali.

[Petr Fiedler]

Tak to nechápu. Mám taky Skylake. Nejlepší i5 co byl - 6600K. 4 fyzická jádra s taktem 3,5 GHz a odemčeným násobičem. Grafické jádro je Intel HD Graphics 530. Disk mám Samsung 850 EVO 500 GB ~ 540/525 MB/s. RAM 16 GB 2133 MHz. A instaloval jsem to 2x a vždy ten stejný problém. Takže možná něco v nastavení UEFI. Ale to teda nevím, co bych tam měl změnit.

BTW: VB nechci ani vidět. Udělal jsem pár snímků a v /rootfs mi došlo místo. VM nešel nahodit, abych smazal první snímek a tak jsem vlezl do /home a smazal tam jeden ručně. VM pořád nestartoval a tak jsem smazal všechny a stejně nestartoval. Když jsem pak koukl do adresáře /data/..., tak tam VHI nebyl. Tak teď nevím, jestli se věnovat QEMU/KVM, nebo dát ještě šanci VB a vše s ním související přesměrovat do /data, nebo koupit GPU, nebo to vrátit na železo? A ještě ke všemu se mi Windows odmítly aktivovat, že už můj klíč byl použit na jiném stroji. A to mám krabicovku za 6k. Už se tomu směju

[Aleš Kapica]

BTW: VB nechci ani vidět. Udělal jsem pár snímků a v /rootfs mi došlo místo. VM nešel nahodit, abych smazal první snímek a tak jsem vlezl do /home a smazal tam jeden ručně. VM pořád nestartoval a tak jsem smazal všechny a stejně nestartoval.

Jauvajs. Už toho prosím tě nech. Děsně to bolí. Nejprve si o tom něco přečti, seznam se s tím jak to funguje, vyzkoušej, otestuj. A teprve pak jdi do složitějších věcí.

Když virtualizuješ nějaký systém, tak zkrátka musíš vědět, jak se ten systém chová a co to udělá. Swapování do souboru je možná fajn, ale rozhodně ne ve virtuálu. A tuplem ne u virtuálu, který průběžně snapshotuješ. A mazat něco naprudko, jen proto že to zabírá hodně místa, které potřebuješ uvolnit, je na největší kravina jaká tě mohla napadnout. Dělá se to zkrátka jinak. Jsou na to nástroje. Jen musíš vědět co máš dělat.

Kamarádka loni dělala přesně ty samé blbosti co ty. Zavolala mi až v situaci, kdy měla všechno v prdeli. Přitom stačilo jen málo. Zvednout telefon, když na ni po tom jejím laborování vyskočilo dialogové okno "Chcete se vrátit do výchozího bodu?", a zeptat se: "Mám to odkliknout?"

Měla však štěstí, protože jsem při poslední inspekci jejího kompu udělal snapshot souborového systému. Takže přišla jen o data za poslední měsíc. Když se jí podobná situace stala podruhé – a měla stejně hloupý nápad jako ty, že uvolní místo tím že něco smaže – tak naštěstí ty soubory přesunula jen do koše. Takže už o žádná data nepřišla.

Teď už si dává pozor, ale především dodržuje pravidla co jsem jí řekl a všechno je ok. Už je poučená.

[Petr Fiedler]

Já ale musel místo uvolnit. / mám velké 40 GiB. Než jsem si včera začal hrát s VB, tak jsem měl volné místo ~ 30 GiB. A najednou mi systém oznámil, že pro /rootfs dochází místo a zbývá tuším ~ 170 MiB. Kouknul jsem do /var, ale tam bylo jen 3,5 GB. Pak jsem zjistil, že jsou to ty snapshoty. Bál jsem se, že bych nenabootoval a tak jsem jednal jak jsem uměl. Celý problém byl IMHO v tom, že při vytváření VHI jsem jej umístil do /data (jiný 365 GB oddíl na stejném disku) a nenapadlo mě, že VB bude snapshoty ukládat do /home/petr/VirtualBox VMs. Máš ale pravdu. Jsem zbrklý a měl bych napřed číst, než konám. Snad si to už konečně vezmu k srdci.

[Aleš Kapica]

Pokud ti mohu poradit, tak v prvé řadě zruš u těch Windows aby požívaly swap do souboru na disku. Já bohužel nevím kde se to teď u těch novějších verzí dělá.

Pak jim zakaž hibernaci - ať se normálně vypnou. Srovnej data na disku. Virtuálu nastav co nejví dostupné paměti – pokud na hostitelském stroji použiješ swap, tak můžeš nastavit víc paměti, než kolik ve skutečnosti máš. Používej přírůstkové virtuální disky – ušetříš místo na disku. SSD na kterém je virtuální disk je taky lepší volba než HDD. Když jedeš ve virtuálu, nespouštěj nic zbytečného v hostiteli. Zbytečně ho tím zaměstnáváš. Nenechávej otevřený browser s milionem záložek (zlozvyk mého syna) žere to paměť, kterou potřebuješ pro virtuál.

Kdy potřebuješ uvolnit místo, ruš postupně snapshoty. Začni ale od těch menších. Během integrace vytváří kopii toho do je pod tím, tak ať ho neumlátíš totálně. A ruš snapshoty od těch starších. Je totiž velká pravděpodobnost, že v nich hnijou data, co už jsou defakto smazaná.

[Petr Fiedler]

V podstatě tohle všechno dělám a swapy vůbec nepužívám. Jenom tedy nevím, jak zakázat swapování do soubory. Ale hibernaci ruším. Ty snapshoty mi nešly smazat, protože jak mi došlo místo v /, tak se mi VM kousl a musel jsem jej vypnout natvrdo. Pak nešel spustit a snapshoty nešly přirozeně smazat, takže jsem musel ručně. A pak jsem jen koukal, že teď nevím jeslti VDI, nebo VHI není na svém místě, které bylo jinde než snapshoty, které jsem mazal po 1 od nejstaršího a VM pořád nestartoval. A pak jsem zjistil, že žádný VM není. Takže tak.

Jinak v zálohování jsem docela důsledný a zálohu dat mám 2x + notebook + síťový disk v RPi.

[Petr Fiedler]

Vlastně vím, jak zakázat ve Windows swapování do souboru. Jen jsem si to neuvědomil. Dělávám to kvůli SSD. Pravomyš na "Tento počítač" > "Vlastnosti" ..... a zakázat stránkování.

[Aleš Kapica]

Jo a ruš přednostně snapshoty udělané za běhu. U těch se totiž ještě válí snímek paměti. Obecně je lepší snapshotovat vypnutý virtuál, než spuštěný. Ten se ti totiž nemusí podařit podruhé rozjet.

[Petr Fiedler]

V QEMU/KVM dělám snapshoty pouze při vypnutém VM. U VB jsem ale nepřišel na to jak?

[LarryL]

"Mám taky Skylake. Nejlepší i5 co byl - 6600K"

Já tak dobrý nemám a už vůbec ho nemám přetaktovaný.

"Disk mám Samsung 850 EVO 500 GB ~ 540/525 MB/s."

Já celý systém té virtuálky Win10 mám uložen na virtuálním disku ve formátu *.qcow2 což by mělo být pomalejší než raw a ten *.qcow2 je navíc na obyčejném HDD.

Takže s tvým HW co máš by ti to mělo jed jak z praku a s přehráváním motorek z YT (při plném rozlišení) bys problémy mít neměl.

- Nevymýšlel jsi tam náhodou nějaké komba jako, že jsi třeba zprůchodnil (passthrougnul) do VM celé to SSD Samsungu? Né, že by na tom bylo něco špatného, ale můžeš to mít špatně nastavené.

- Nebo že bys narazil na bug v QXL? Virtio ovladače jsou "latest" nebo "stable". Máš "stable". Mně to ve Win10 ukazuje verzi QXL 10.0.0.18000 ze dne 28.5.2017.

- Nepřiřadil jsi náhodou VM příliš mnoho RAM? Tím pádem HostOS nemá k dispozici dost volné RAM a swapuje na disk což zapříčinujě trhání videa a zvuku uvnitř VM.

Poslední varianta se mi zatím zdá být nejpravděpodobnější.

[LarryL]

*jet jak z praku

[Petr Fiedler]

... a už vůbec ho nemám přetaktovaný.

Ani já.

- Nevymýšlel jsi tam náhodou nějaké komba jako ...

Ne_e

- Nebo že bys narazil na bug v QXL? Virtio ovladače jsou "latest" nebo "stable". Máš "stable"? Mně to ve Win10 ukazuje verzi QXL 10.0.0.18000 ze dne 28.5.2017.

Napřed jsem nainstaloval spice-quest-tools-0.141.exe z 2018-01-04. Měl jsem dané problémy a tak jsem ve Windows ve správci zařízení aktualizoval všechny ovladače co šly z virtio-win-0.1.171.iso. To je tuším z 2019 a jedná se o "latest".

- Nepřiřadil jsi náhodou VM příliš mnoho RAM? Tím pádem HostOS nemá k dispozici dost volné RAM a swapuje na disk což zapříčinujě trhání videa a zvuku uvnitř VM.

Mám 16 GB RAM. 4 GB jsem naalokoval pro /tmpfs. Pro VM Windows jsem přiřadil 4 GiB a pro hostitelský OS mi zůstává ~ 8 GB. Tady bych problém neviděl.

[LarryL]

Záhada

spice-quest-tools-0.141.exe nemám nainstalované.

Zkus sem hodit XMLko té VM.

Teď asi používáš i440fx a bios (Seabios). Zkus vytvořit q35 machine a používat OVMF. Kromě aktualizace Win10 mě nic jiného nenapadá. Možná ještě prohlídnout logy. Případně vysledovat jestli ty záseky zpusobuje Win10 nebo zda je způsobuje nějaký proces v hostitelském OS (linuxu).

[Petr Fiedler]

Příloha:

• w10_xml.txt (4106 bytů)

spice-quest-tools-0.141.exe nemám nainstalované.

Můžu zkusit Windows přeinstalovat, aniž bych nainstaloval spice-quest-tools a použil k instalaci ovladačů pouze to iso. Mám zkusit "latest", nebo "stable"? Teď používám latest, takže bych asi zkusil stable.

Zkus sem hodit XMLko té VM.

Viz. příloha.

Teď asi používáš i440fx a bios (Seabios). Zkus vytvořit q35 machine a používat OVMF.

Na odkaz jsem zatím neklikl, ale myslím, že s OVMF, které by mělo zpřístupnit UEFI nejdou dělat snapshoty. Nebo se pletu?

Pokud to nevyřešíme, tak se asi zeptám na fóru MS.

[LarryL]

Teď používám latest, takže bych asi zkusil stable.

Já vidím, že latest je 0.1.173 a stable je 0.1.171, takže zkus tu z nich, kterou jsi nepoužil.

Viz. příloha

Zkusil jsem si to naimportovat do libvirtu a mám pouze pocit, že to video 4K z CostaRica má nižší framerate než jsem zkoušel před tím na svojí VM = video se mi zdá méně plynulé, ale u těch motorek bych si toho ani nevšiml. Možná to bylo i tím, že Win10 po instalaci furt šahal na disk (aktualizace, optimalizace...). Plus to praskání ve zvuku, které je ale řešitelné ovladačem AC97.

že s OVMF, které by mělo zpřístupnit UEFI nejdou dělat snapshoty. Nebo se pletu?

No vida, nejsi takový začátečník jak to vypadalo. Vždyť vy ty znalosti máte Kefalín. Aby ti šly dělat snapshoty, tak lze od verze Qemu 4.0 lze použít takto (umožňuje snapshotting):

-blockdev node-name=pflash0,driver=file,read-only=on,filename=/usr/share/edk2/ovmf/OVMF_CODE.fd \
-blockdev node-name=pflash1,driver=file,filename=copy-of-OVMF_VARS.fd \
-machine pflash0=pflash0,pflash1=pflash1

Nejsem si 100% jistý jestli je to správně, když tak dohledej na netu.

Před tím to šlo když jsi pflash převedl z raw do qcow2, protože když je disk raw, tak nejde udělat snapshot. Snad to říkám dobře.

[k3dAR]

nebyl sem si jistej jak s QEMU4 v virt-manager/xml zadat ty tve radky, zkusil sem hledat a vypadlo na me jine reseni:

<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
#zmena na:
<loader readonly='yes' type='rom'>/usr/share/OVMF/OVMF_CODE.fd</loader>

ale jinde sem o tom nic nenasel, vyzkousel ze s tim snapshot funguje, ale nevim zda to neni nejake spatne/obsolete reseni, netusis?

[LarryL]

Po rychlém prozkoumáním mám dojem, že to je takto:

- Libvirt ve verzi libvirt-3.3.0 zakázal snapshoty s pflash

- type='rom' se používá při použití XENu

- některé chytré hlavy, ale type='rom' používají jako fígl, aby i od verze libvirt-3.3.0 šly dělat snapshoty s OVMF a nevyskakovala hláška "Internal snapshots of a VM with pflash based firmware are not supported.".

[k3dAR]

dik, no prave mi unika, jestli ale tou zmenou typu pflash na rom, pouze neobejdu tu detekci a nezustanou ty negativni veci kvuli kterejm libvirt tu detekci tehdy pridalo, resp. zda Tve puvodni reseni neni aktualne bezpecnejsi ci cistejsi :)

[LarryL]

nezustanou ty negativni veci kvuli kterejm libvirt tu detekci tehdy pridalo

Ano, myslím, že ty negativní věci zůstanou, protože jinak by libvirt dovolil dělat snapshoty i s type='pflash'

resp. zda Tve puvodni reseni neni aktualne bezpecnejsi ci cistejsi

Vzhledem k popisu bugu a k tomu, že je to v changelogu qemu:

Machines pc-* now support configuring firmware with -machine pflash0=ID0,pflash1=ID1 in addition to -drive if=pflash,... This permits use of -blockdev.

to podle mě čistější je. Tedy v čistém Qemu. Mám dojem, že to neřeší problém s OVMF v raw formátu, tak jak jsem původně myslel. Teď jsem to zkoušel v Qemu v4.2 s raw formátem a při příkazu savevm to pořád píše "Error: Device '' is writable but does not support snapshots". Takže pořád je asi nutné convertovat raw do qcow2, ale asi tohle řešení přináší benefity při migraci. Podle mě si libvirt dělá snapshoty vlastní cestou (nepoužívá savevm v Qemu), takže těžko říct jestli to lze v libvirtu využít dokud to sám neimplementuje.

[k3dAR]

jestli dobre chapu tu "negativni veci" tak slo o to ze se do "snapshotu" nedostane stav pflash, coz predpokladam znamena nastaveni "biosu" a pripadne uefi vars pro registrovane efi boot(order), i kdyz na druhou stranu *VARS.fd je v XML v sekci nvram, mimo sekci loader kde je typ pflash (menen na rom)... takze nemuze jit jen o to ze v snaphot by nebyl ulozen konkretni ro bios?

jinak QEMU4.2 z primarniho Xubuntu18.04 slo ven, nicmene sem zjistil ze ten "figl" se zmenou na rom funguje pro snapshoty v UEFI i s z repositare verze QEMU 2.11, ted jen mit jasno v tom zda ten muze znamenat realne problem

[LarryL]

jestli dobre chapu tu "negativni veci"

Moc nerozumím větě: "use a qcow2 ... but then it would become eligible to become target of the memory dump.", takže nevím jestli při převedení pflash z raw do qcow2 a vytvoření/načtení snapshotu to představuje nějaké riziko.

takze nemuze jit jen o to ze v snaphot by nebyl ulozen konkretni ro bios?

pflash který je jen pro čtení se do snapshotu neukládá. Problém je v tom, že *VARS.fd je povolen pro zápis a tudíž je snaha uložit jeho aktuální stav do snapshotu. Pokud bys u *VARS.fd nastavil příznak readonly, tak ti půjde udělat snapshot i bez fíglu s type='rom'. Myslím, že tím, že nastavíš rom pouze řekneš libvirtu, aby stav *VARS.fd do snapshotu neukládal.

jinak QEMU4.2 z primarniho Xubuntu18.04 slo ven, nicmene sem zjistil ze ten "figl" se zmenou na rom funguje pro snapshoty v UEFI i s z repositare verze QEMU 2.11

Zkusil jsem to na QEMU4.2 s libvirt-5.10.0 a když je tam pflash, tak to pořád píše chybu:

libvirt.libvirtError: Operace nepodporována: vnitřní zachycené stavy virt. strojů s firmware, založeným na pflash, nejsou podporovány

bez ohledu, jestli je stroj q35+ovmf nebo i440fx+ovmf a když změním na rom, tak je to bez chybové hlášky a funguje to.

ted jen mit jasno v tom zda ten muze znamenat realne problem

Z výše uvedeného je podle mě jedno jestli fígl s rom použiješ pro QEMU4.2 nebo QEMU 2.11, výsledkem bude, že nebudeš mít uložen stav *VARS.fd ve snapshotu.

[LarryL]

Pokud bys u *VARS.fd nastavil příznak readonly

Zkoušel jsem u čistého Qemu, ale zdá se, že u "<nvram>" v libvirtu nelze nastavit readonly.

[LarryL]

Myslím, že tím, že nastavíš rom pouze řekneš libvirtu, aby stav *VARS.fd do snapshotu neukládal.

Nebo druhá varianta, že pri nastavení na rom se element <nvram> úplně ignoruje. Všimni si, že pri nastavení na rom můžeš element <nvram> úplně vymazat což při nastavení na pflash nemůžeš.

Teď jsem si uvědomil, že kromě OVMF_VARS.fd+OVMF_CODE.fd může být i jeden společný OVMF.fd.

Ano, ano, ano, to je ono. Když zadáš type='rom' tak je to stejné jak kdybys nezadal nic a to je způsob jak se v libvirtu zadává "OVMF.fd":

<loader>/usr/share/OVMF/OVMF.fd</loader>

a element <nvram> není vůbec vytvořen. V command-linu pro qemu se to pak projeví takto:

-bios OVMF.fd

[Aleš Kapica]

Pro úspěšné obnovení snapshotu je důležité aby virtuál najel do stejných podmínek. Proto zároveň se snapshotem ukládám i aktuální konfiguraci virtuálu a používám u cpu jen ty flagy, které jsou zastoupeny u věech hostitelů. A pokud se používá UEFI, tak i verze souboru s UEFI biosem (OVMF) by měla být v okamžiku obnovení taky stejná. Proto to nepoužívám. Je to zbytečná komplikace, která nic zajímavého navíc nepřináší.

[LarryL]

Proto zároveň se snapshotem ukládám i aktuální konfiguraci virtuálu

Aktuální konfiguraci ukládáš ručně nebo je na to nějaký příkaz, který sváže snapshot s aktuální konfigurací?

A pokud se používá UEFI, tak i verze souboru s UEFI biosem (OVMF) by měla být v okamžiku obnovení taky stejná. Proto to nepoužívám.

Tak pokud si OVMF*.fd vykopíruješ z /usr/share/ovmf/x64/ do adresáře kde máš uloženou VM a nastavíš na readonly, tak ani při aktualizaci balíčku ovmf nehrozí změna OVMF*.fd souboru(ů).

[Aleš Kapica]

Ano, s tím vykopírováním by to bylo možné. Jinak ten můj skript pracuje se zjednodušenou konfigurací. Nastavuješ bloková zařízení, síťovky a zbytek je na libovůli. Aktuální konfigurace se uloží při uspání, a při probuzení (nebo migraci) se se stejnými parametry spouští instance do níž se buď migruje, nebo probouzí pauznutý stroj. Jak už jsem ale napsal, OVMF pro mě žádný přínos nemá, takže ho nepoužívám, i když by to šlo.

[LarryL]

OVMF pro mě žádný přínos nemá

Já bych bez OVMF asi více bojoval s pass-through, takže pro mne to výhody má.

[Petr Fiedler]

Taky s tím teď bojuju. Čeká mě teď instalace VM Windows na nb. Než se do ní pustím, tak jsem chtěl zkusit passthrough dedikované GPU nVidia GeForce MX150 do VM GNU/Linux Mint. Běžně na nb používám pouze integrovanou GPU, takže když spustím VM Mint, tak se mi stejně jako na pc, kde ani dedikovanou GPU nemám, po naběhnutí VM objeví upzornění:

"Váš systém je nyní provozován bez hardwarového urychlení videa. Můžete zaznamenat chybný výkon a vysoké využití procesoru."

Tak jsem v nb nainstaloval ovladač pro nVidia GPU, ve VM Mint přidal hardware PCIe s tou GPU a po kliku na "Spustit" se objevilo:

"Chyba při startu domény: unsupported configuration: host doesn't support passtrough of host PCI devices."

Tento VM Mint používá i440FX+BIOS. Ten nový VM Windows bych chtěl nainstalvat s q35+BIOS právě kvůli snapshotům. Šachovat se mi s tím moc nechce, protože v tom ještě nejsem úplně kovaný. Navíc teď používám QEMU2. Brzy má vyjít nový Mint (~ konec června) a tam by mělo být QEMU4. Tak to už vydržím. Mám 2 otázky:

1. Půjde nějak passthrough ve VM Mint?
2. Jak nainstalovat VM Windows (passthrough GPU)? Já to vidím na q35+BIOS. OK?

[LarryL]

jsem chtěl zkusit passthrough dedikované GPU nVidia GeForce MX150...Tak jsem v nb nainstaloval ovladač pro nVidia GPU, ve VM Mint přidal hardware PCIe s tou GPU a po kliku na "Spustit" se objevilo: "Chyba při startu domény: unsupported configuration: host doesn't support passtrough of host PCI devices."

PCI/VGA passthrough je na nb problém. Pokud si myslíš, že by to na tvém nb mělo fungovat založ nové vlákno, bude zřejmě hodně dlouhé.

po naběhnutí VM objeví upzornění: "Váš systém je nyní provozován bez hardwarového urychlení videa. Můžete zaznamenat chybný výkon a vysoké využití procesoru."

Tak teď jsi možná rozluštil záhadu proč se ti ve VM Win10 tak moc trhá YT video Hledal bych problém s video driverem na Mint fóru, případně taky nové vlákno.

tam by mělo být QEMU4...Půjde nějak passthrough ve VM Mint?

Nejsem si vědom, že Qemu v4 ti nějak pomůže při pci passthrough na nb. Pokud se bavíme o pc, tak by to mělo jít i na Mintu.

Jak nainstalovat VM Windows (passthrough GPU)? Já to vidím na q35+BIOS. OK?

Na pc by to mohlo být OK (záleží hlavně na IOMMU group)

[k3dAR]

z praxe nevim, ale u NB minimalne zalezi zda cpu i deska podporje VT-d, z teorie sem pred tejdnem nasel ze T430s s i5-3530 nebo i7 + Nvidia s KVM fungje passthrough, snad do tejdne overim v praxi :)

btw: na Mintu mu to sice hlasi bez hw urcyhleni, ale video YT mu jede plynule v FHD

[k3dAR]

EDIT: [...] s i5-3320M [...], s i5-3230M ne protoze to nema VT-d

[LarryL]

minimalne zalezi zda cpu i deska podporje VT-d

jj, to je základ. U nb je, zjednodušeně řečeno, ten problém, že Nvidia nemá vlastní výstup (DVI, HDMI, VGA) jako je tomu u Nvidia karet pro desktopy a je více "zadrátovaná" do HW notebooku.

btw: na Mintu mu to sice hlasi bez hw urcyhleni, ale video YT mu jede plynule v FHD

Co si vzpomínám, tak naposledy Petr psal, že zvuk (AC97) mu už jede dobře, ale pořád se trhá video, ale že mu to nevadí, protože mu jde ve VM Win10 hlavně o zvuk.

[Petr Fiedler]

Ve VM Windows jede zvuk díky tobě dobře. Video se sem tam lehce trhne, ale není to problém, protože ve Windows mi skutečně jde o zvuk.

Ve VM Mint mi jede dobře oboje hned od instalace. Docela jsem se tomu divil. Jak výše píše Radek, na YT mi videa jedou krásně na 1080p i bez passthrogh dGPU a i s tou chybovou hláškou. Zajímavé ale pro mě bylo, když mě Radek zlanařil od VB ke QEMU, že VM Mint ve VB videa na YT na 1080p nedával ani omylem. Přešel jsem na QEMU a nevěřil jsem vlastním očím.

Jinak na tu tvojí včerejší reakci jsem ještě nereagoval, protože jsem si četl ten článek a chtěl si prostudovat, jak je na tom můj nb s dGPU. Ale zatím jsem to nezjistil. V manuálu o tom nic nebylo (pochopitelně) a v servisním manuálu taky ne. Datasheet nemůžu najít. Mám teď povinnosti, ale večer se podívám do UEFI nb po VT-d.

Jinak dík za všechno. Hodně si mě v QEMU posunul.

PS: Jinak mám tento nb.

[k3dAR]

Pro úspěšné obnovení snapshotu je důležité aby virtuál najel do stejných podmínek. [...] i verze souboru s UEFI biosem (OVMF) by měla být v okamžiku obnovení taky stejná.[...]

ciste logicky myslim ze pro obnoveni snapshotu musi byt verze OVMF irelevantni, kdyz budu mit na zeleze snapshot (lvm, btrfs), pak udelam upgrade UEFI, tak kdyz se budu chtit vratit k stavu snapshotu preci nebudu muset delat downgrade UEFI...
resp. jeste jednodusejc, kdyz vezmu disk z jednoho HW a vrazim ho do uplne jineho HW, tak system na disku take neresi "naprostou" rozdilnost UEFI, pokud by na tom disku bylo pripraveno i BIOS partisna + grub-pc tak je dokonce irelevantni zda na cilovem stroji bude BIOS-Legacy nebo UEFI...

[Aleš Kapica]

No. Až na to že UEFI není legacy.

[k3dAR]

asi jsi prehledl ze jsem psal BIOS-Legacy

[Aleš Kapica]

Ne, nepřehlédl, jenom jsem to nepovažoval za nutné zdůrazňovat. Chtěl jsem tě jen upozornit na to, co obšírněji popsal LarryL.

[k3dAR]

pokud si tim tedy chtel rict, ze na UEFI narozdil od Legacy jsou vyssi pozadavky, tak ok, nicmene pak si tedy prehledl tu celou zbylou cast, radeji zopakuji:
1. na zeleze pri upgrade UEFI a naslednem vraceni k snapshotu na disku, preci nemusis provest downgrade UEFI na verzei ktera byla v dobe porizeni snapshotu
2. na zeleze take neresis kdyz disk prendas z HW1 kterej ma UEFI od Vyrobce X ve verzi Y na HW2 kterej ma UEFI od jineho vyrobce jine verze

[Aleš Kapica]

Ne. Chtěl jsem tím jen říct, že pokud používáš nějakou verzi UEFI v okamžiku kdy stroj uspíš, tak bys měl použít stejnou verzi i v okamžiku kdy ho probouzíš. A ten hlavní rozdíl mezi legacy biosem, je že je součástí instalace QEMU, kdežto soubor OVMF (UEFI bios), není. Tudíž si musíš ohlídat použití správné verze jiným způsobem.

[k3dAR]

no pokud mluvis o uspani tak tam UEFI asi stejne potreba je, ja mluvil o snapshotu kde podle me duvod stejneho UEFI neni
ad BIOS Vs UEFI - jasne, to sem myslel temi "vyssi pozadavky"

[Aleš Kapica]

Záleží na tom, co je u tebe snapshot.

Při snapshotu živého systému potřebuješ mít splněny všechny podmínky, při snapshotu vypnutého systému záleží na tom, co virtualizuješ. Většinou by to mělo být jedno, ale nemusí. Stejně jako u fyzických strojů může být aktualizované UEFI vadné.

Zrovna počátkem února jsem řešil takovou věc. Nové stroje od HP, aktuální UEFI, nainstaluješ, vše ok a po restartu nevidí žádný disk. Necháš ten stroj bez šťávy. Nastartuješ a opět ho vidí. Zopakuješ reboot, nevidí.

Všechno se jinak tvářilo ok – mám možnost na takovém stroji najet disklessově, zkrátka při restartu "jenom" mizel disk. Udělal jsem downgrade UEFI a voilá. Bylo po problému. No a teď si vem, že ty uděláš snapshot, předhodíš jiné UEFI, které může mít podobnou chybu a pak řešíš proč ti systém, který normálně nastartoval a běžel, při rebootu nenajíždí.

[Petr Fiedler]

O tom ale řeč nebyla:

... ja mluvil o snapshotu kde podle me duvod stejneho UEFI neni ...

Předmětem sporu je, jestli u snapshotu musí nutně být stejné UEFI? S vadným UEFI by byl prolém z principu. Ale to nemyslel, že jo? Myslel funkční UEFI.

[Aleš Kapica]

Jaký spor? Tady si pouze vyjasňujeme jaká rizika mohou nastat v případě, že při virtualizaci použiješ jiný bios, než s jakým jsi ten stroj vytvořil. Toť vše.

Protože když na podobný problém narazíš, tak tě to pak napadne jako jedna z možných příčin, která se buď vyloučí, nebo potvrdí.

[k3dAR]

psal sem to tu nekde, ze ja delam snapshoty pri vypnutem systemu, v mejch pripadech nepotrebuju delat zapnuteho a usetrim si tim navic pripadne zbytecne problemy...

ten tvuj pripad (jak pise Petr) ale neni problem snapshotu, ale chyba verze UEFI ktera nesouvisi se snapshotem, to ze stav z funkci snapshotu muze pri zmene na problemovej "bios" nastat chapu, ale to jak sam pises nastalo pri instalaci rovnou s tim vadnym...

takze shrnuto, podle me neni potreba s UEFI snapshotem pres "figl" zmeny pflash na rom, resit zalohu aktualniho OVMF "biosu", ale pokud by pri povyseni OVMF nastal problem pomuze vedet ktera verze pretim fungovala

[LarryL]

Opravte mě jestli se mýlím, ale záleží co snapshotuješ. Pokud jen filesystém, tak tam by konfigurace PC neměla hrát roli, ale pokud snapshotuješ celý stroj včetně stavu CPU a RAM, tak tam by upgrade UEFI měl vadit a tipoval bych pád OS poté co načteš snapshot. Jelikož Qemu i Libvirt snapshotuje i stav CPU a RAM, tak by změna verze OVMF měla vadit. Stejně tak jako bude vadit upgrade Qemu. Párkrát se mi stalo, že jsem hibernoval na disk Win10, pak proběhla aktualizace Qemu a po probuzení se Win10 resetoval. U snapshotu by to zřejmě bylo stejné.

[k3dAR]

pokud vim ve virt-manager se snapshotem snapshotuje stav filesystemu do qcow2 a konfigurace do /var/lib/libvirt/qemu/snapshot/jmenovirtualu/jmenosnapshotu.xml...
stav CPU a RAM se snapshotuje pouze pri bezicim systemu, nebo (nesnapshotuje ale) uklada pri volbe ShutDown/Save

[k3dAR]

pokud je jedine to negativum ze se s snapshtem nezachova stav UEFI VARS, kde pokud se nepletu je s virtualnim pouzitim dulezite jedine registrovane bootloadery a bootorder, tak sem s tim v pohode :)

[LarryL]

Taky si myslím, že je to jediné negativum.

Jen jestli jsi mě pochopil správně: OVMF VARS se ti s type='rom' ani snapshotnout nemůže, protože ho libvirt úplně ignoruje, jinými slovy Libvirt ho do Qemu vůbec nepředá.

[k3dAR]

ze s rom VARS nesnapshotne mi bylo jasne, ze VARS ale stavajici stav ignoruje pri spusteni je druha vec... nicmene pri startu (s rom) v bootorder vidim podle spravne poradi... dal sem zkusil:

1. v xml vratit zmenu rom zpatky na pflash
2. pustit virtual a overil z procesu ze qemu pouzilo parametr pro VARS file
3. pres efibootmgr zmenil bootorder (prvni poradi nechal ubuntu)
4. reboot
5. v efibootmgr vidim ze ta ma zmena bootorder zmizela

tzn. pokud mi neco neuniklo, tak i kdyz VARS file qemu pouzije, tak bootorder se stejne po restartu pouzije "odjinud" :)

[LarryL]

Když mám nastaveno type='pflash' a udělám změny v GUI OVMF (při bootování zmáčknu F2 a změním bootorder), tak se to uloží a po restartu nebo vypnutí a zapnutí VM je to správně uložené. Takže u mě OK.

efibootmgr jsem netestoval.

[k3dAR]

u me s pflash take toto jde, s rom nejde, takze ok ocekavane chovani s tim bych dokazal fungovat, kdyz bych z nejakeho duvodu potreboval mit ulozenej jinej order tak si prepnu na pflash, nebo naopak kdyz bych potreboval udelat snapshot tak si prepnu na rom, dulezite pro me je ulozit bezpecne stav disku+config a mit moznost se k tomu vratit... :)

[LarryL]

Taky si myslím, že je to jediné negativum.

Tak beru zpět. Jak jsem psal, že když zadáš "rom", tak se to do Qemu předá jako parametr "-bios", tak jsem si v maillistu nevšiml varování:

This will map to "-bios OVMF.fd" on the QEMU command line.

Be *strongly* warned though that by this, you are throwing away
persistent non-volatile variables, and that the fake variable support
that OVMF falls back to does not -- cannot -- conform to the UEFI spec.
You will encounter obscure mis-behavior with variables. (One of the
obvious glitches will be that Secure Boot settings will not survive a
reboot.)

Zároveň máš v odkazu i odpovědi jak řešit bootorder - <boot index="..."/>.

Podobné varování je i přímo v dokumentaci OVMF:

IMPORTANT: Never pass OVMF.fd to qemu with the -bios option. That option maps
the firmware image as ROM into the guest's address space, and forces OVMF to
emulate non-volatile variables with a fallback driver that is bound to have
insufficient and confusing semantics.

Takže přepínání z "pflash" na "rom" se nezdá být dobrý figl

Možná, že přišel čas přejít z libvirtu na čisté qemu

V Qemu, abys mohl dělat snapshoty s ovmf máš možnosti:

1.) převést OVMF_VARS z raw na qcow2

2.) nastavit OVMF_VARS readonly

Co jsem se dočetl, tak variantu 1 nechtěli vývojáři libvirtu implementovat, protože se qcow2 bude s přibývajícím snapshoty zvětšovat (Moc jsem nepochopil proč jim to tak moc vadí). U 2. možnosti taky nechápu proč to libvirt nemá.

Takže suma sumárum libvirt žádnou možnost jak dělat snapshoty s ovmf nemá? Kromě "špinavého" přepnutí na rom?

[k3dAR]

s tim sem pocital kdyz psal o "virtualizacnim pouziti", protoze uchvoani Var kvuli boot order nepotrebuju, stejne tak nepotrebuju (pro me pripady pouziti UEFI) SecureBoot, samozrejme vyjma toho kdyz bych testoval neco kolem SecureBoot ve virtualu...

i kdyz chapu ze je to spinave, tak pro me potreby je to ciste, mam nekolik virtualu v UEFI kde testuju instalace novych systemu z PXE v rezimu UEFI, tedy zacnu s cistym diskem, provedu instalaci s ve virt-manager nastavenym boot poradim IPV4,Disk kdy si napr. ulozim snapshot pri prvnim a druhem instalcnim reboot u W10, pripadne snapshot po prvnim nabehnuti plochy a automaticke "customizaci a instalaci aplikaci"... bez moznosti snapshotu bych:
1. v pripade ze druha faze (po prvnim reboot) selze, nemohl upravit soubory v obnovenem snapshotu pri prvnim reboot a nechat znovu bezet jen druhou fazi, ale musel bych to instalovat cele znovu
2. v pripade ze treti faze provede spatne customizaci a/nebo instalaci app, musel bych opet provest komplet instlaci, misto zmeny souboru na serverru ktere to pri tom pouziva
3. v pripade ze bych potreboval znovu provest treti fazi a nebo proste mit znovu prvni nabehnuti desktopu kvuli overeni rozdilu mezi prvnim a druhym nabehem plochy, opet bych musel provest komplet instlaci znovu
4. v pripade ze vse mam overene, nemohl bych vratit snapshot stav cisteho disku, ale musel sem "externe" nekterym zpusobem ho smazat (odstraneni a znovu vytvoreni qcow2, pustit z PXE WinPE+AutoFormatDisku, pres qemu-img atd)

to vse by pouhe prepnuti pflash na rom melo resit a neprinest zadne (v tomto kontextu) problemy

[k3dAR]

edit: ty snapshoty fazi instalace "pri rebootu" mysleno kdyz install udela reboot, vypnu virtual, udelam snapshot, zapnu virtual, dam z PXE start z first/next device nebo pres Bootmenu OVMF a pokracuje install

[Petr Fiedler]

A nezapomínej, že naprosto identicky nastavený VM Linux Mint mi jede krásně. Právě z něj píšu. Zkoušel jsem teď to video a ani jeden vůbec žádný problém. Jak si to vysvětluješ?

BTW: Já motorky nesleduji. Jen mi to video přijde dobré k testování a tak je používám.

[LarryL]

Tak to naznačuje, že problém bude uvnitř VM. Možná nakonec zjistíš, že je to nějaký triviální problém s video kodekem ve Win10.

[LarryL]

Jo zvuk stačí. Předpokládám, že to je nahrávka s defaultní zvukovkou ve VM, protože u USB zvukovky jsi psal, že "tak zvuk jede krásně" a tohle krásné není. Tvůj problém není ten co jsem myslel, u tebe to vypadá vážnější, protože tobě se zvuk opravdu trhá. Problém, který jsem měl na mysli je tento https://www.youtube.com/watch?v=f8YBa6H-NV0 , tam sice zvuk "praská" a není čistý, ale není přerušovaný.

Pokud je problém u videí, tak bych se přiklonil k tomu co už napsali Aleš a MadCat, že ti nestíhá nějaký HW, ale pokud máš problém i při přehrávání nějakého zvukového souboru, tak bude problém někde jinde, protože přehrát zvuk by virtuálka měla zvládnout. Takže když spustíš nějaký lokální mp3, tak je ten zvuk také trhaný?

[Petr Fiedler]

Pustil jsem si to video, co jsi odkázal a tohle mi to dělá, když kliknu na hlasitost v systray a ozve se tón, který ukazuje výšku hlasitosti. I při tom mi normálně praská z repráků. No, a zajímavé je, že u přehrávání mp3 ne.

[Petr Fiedler]

A tobě to teď funguje dobře? Já používám nejnovější QEMU/KVM (libvirt) a Windows 10 Pro Build 1909.

[PetebLazar]

Používám Windows 10 Home 1909, ze zdrojáků přeložený QEMU4.0(OPTS), GPU passthrough GTX1660Ti, USB passthrough zvukovky Axagon 10. HostOS je Xubuntu 18.04 s vanilla kernel 5.3.8(1000Hz). https://passthroughpo.st/config_hz-how-does-it-affect-kvm/

Ještě mne napadlo, že v předchozí instalaci Win10 ve VM jsem pociťoval cca jednou za +/- jednu sekundu periodické lagování (jako by se VM na malý okamžik zcela zastavila). Vidět to bylo v 3D benchmarcích, které ač dosahovali stovek FPS trpěly tímto syndromem (krátkodobým pozastavením renderingu). Jeho původ se mi nikdy zjistit nepodařilo, pominul novou instalací W10 do VM. Tak mne napadá, za zvuk nemůže trpět na něco podobného (jak to detekovat lagování bez výše uvedeného způsobnu netuším).

Jaké hodnoty vrací ve virtuálních Windows 10 program LatencyMon. Mě to typicky dlouhodobě drží na 160-170us a pak najednu vyskočí na šílených 5000+ (načež mi to vynadá, ve zvuku problémy nepozoruji). Nejspíš důsledek virtualizace.

[Petr Fiedler]

Current measured interrupt to process latency (µs):
255, 958, 1430, 600, 388, 2555, 914, 241, 1577, 808, 407, 1662, 3527, ...

Mění se mi to každou vteřinu.

Při použití ať už integrované, nebo USB zvukovky se v LatencyMon objeví červené varování:

Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. Also one or more ISR routines that belong to a driver running is your system appear to be executing for too long. One problem may be related to power management. Disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.

[LarryL]

Ano, praskání zvuku je známý dávný problém.

Já sem to vyřešil ovladačem AC97. Je to asi ta nejlevnější - nejrychlejší cesta.

Ve scriptu, který spouští VM Qemu to mám u Win10 takto:

export QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 QEMU_AUDIO_DRV=alsa
qemu-system-x86_64 -device AC97 ...

V libvirtu by to mělo jít tak, že otevřeš XML pro editaci příkazem:

sudo virsh edit *vm_name*

A vložíš tam:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:env name='QEMU_AUDIO_DRV' value='alsa'/>
    <qemu:env name='QEMU_ALSA_DAC_BUFFER_SIZE' value='512'/>
    <qemu:env name='QEMU_ALSA_DAC_PERIOD_SIZE' value='170'/>
  </qemu:commandline>
</domain>

No a pak ve virt-manageru přepneš na AC97 (to už víš jak).

Ty čísla na QEMU_ALSA_DAC_BUFFER_SIZE, QEMU_ALSA_DAC_PERIOD_SIZE jsem zkoušel různě podle návodů z netu měnit a u těch výše uvedených jsem zůstal a problémy s trháním už nemám.

AC97 nemá ovladač pro Win10, proto ti nejel zvuk. Musíš Win10 spustit ve "stavu nouze" (nebo jak se to teď jmenuje) a pak ti půjde ovladač nainstalovat. Bohužel odkaz na ovladač, který mám už nefunguje. Asi tohle bude ono: https://www.realtek.com/en/component/zoo/category/pc-audio-codecs-ac-97-audio-codecs-software

Ono se to má tak, že dříve na to byl patch pro Qemu od Spheenika (nikdy jsem ho nepoužil, nechtělo se mi překompilovávát Qemu). V Qemu verzi 4 bylo ohledně audia provedeno dost změn a zvuk by praskat neměl, ale neověřoval jsem, pořád používám AC97.

PS: je možné, že i u AC97 sem tam k prasknutí ve zvuku dojde - AC97 je spíše takový hack než doporučované řešení, takže pokud by výstup zvuku měl dosahovat profesionálních hodnota, pak by nějaká ta USB zvukovka nebo si pohrání s novými parametry Qemu v4 bylo vhodné. Více zde.

[LarryL]

Pokud by někoho zajímalo jak v novém Qemu zprovoznit třeba i zvuk s 5.1 surround, tak zde.

[Aleš Kapica]

Mě by spíš zajímalo jak donutit ke spolupráci pulseaudio a Xspice server.

[LarryL]

Nevím jak přesně to myslíš, ale asi jsem to nikdy nepotřeboval.

[Aleš Kapica]

Spice používám na qemu už dávno. Tam problém není. Ale existuje také Xspice server, který si můžeš nahodit podobně jako VNC, a ten by měl umět také protlačit i zvuk. Ale zatím se mi to nepodařilo.

Až se dokopu k uspokojivému výsledku, pošlu odkaz na video ze kterého pochopíš proč to řeším.

[PetebLazar]

Koukal jsem, že u Looking Glass (zaměřujícího se primárně na přenos obrazu Guest=>Host) zmiňují možnost transportu zvuku mezi Guestem a Hostem pomocí Scream. Nezkoušel to někdo? https://github.com/duncanthrax/scream

[PetebLazar]

Doplnění: Scream over LAN by měl být jednodušší a snad i méně náročný než Scream over IVSHMEM. https://looking-glass.hostfission.com/wiki/Using_Scream_over_LAN

[Aleš Kapica]

Dík za tip. Chtěl jsem to jen zkusit rozběhat. Priorita to není.

[Aleš Kapica]

No trvalo mi to dýl než jsem čekal. Tady je link na slíbené video.

[LarryL]

Takže místo VMware (které máš v tom videu) chceš použít Qemu + XSpice? Pokud jsi to už testoval, tak kromě toho zvuku to funguje stejně dobře jako VMware?

PS: Je XSpice ještě vyvíjený? Protože stránky se mi zdají dost prehitorické a poslední změny v kódu jsem našel před 3 lety.

[Aleš Kapica]

Takže místo VMware (které máš v tom videu) chceš použít Qemu + XSpice?

Ne. Jsou to fyzické stroje. Takže buď Xspice + X server, nebo Xpra + X server. Oboje má plusy i bolavá místa. Oproti VNC ale podporují 3D akceleraci. U VNC to tak jednoduché není.

PS: Je XSpice ještě vyvíjený? Protože stránky se mi zdají dost prehitorické a poslední změny v kódu jsem našel před 3 lety.

Pokud něco funguje, tak není důvod dělat změny. Já taky používám ke správě virtuálních strojů shellový skript, do kterého jsem nevrtnul už dva roky. A funguje mi to líp než kdybych se drbal s libvirtem. A to od roku 2015 podporuje kromě lokálních virtuálních disků, NFS a síťových blokových zařízení i distribuovaná bloková zařízení. Umí to migrovat, uspávat na disk, deployovat se na jiné stroje a používají se v podstatě jen základní nástroje: ssh, qemu a openvswitch. Jednoduchá konfigurace, jednoduchý debug v případě problému. A jako bonus: můžeš k řízení virtuálu používat paralelně i monitorovací konzoli.

[LarryL]

Takže zaměstnanci Katedry kybernetiky, kteří jsou dnes v karanténě se můžou připojit z domu ze svého počítače na kterém mají Linux, Windows nebo MacOS za pomocí Xpra/Spice clienta do fyzického počítače na katedře kde je nainstalován Linux + X server a na něm lze také spustit pomocí VMware virtuální počítač s Windowsem. Chápu to správně?

A funguje mi to líp než kdybych se drbal s libvirtem.

Jj, taky mám raději vlastní script než libvirt.

[Aleš Kapica]

Ano. I studenti.

Akorát tam teda není nic nainstalováno, protože je to diskless.

[Aleš Kapica]

Jenom bych k tomu dodal, že zpřístupnění laborek on-line byl můj dlouhodobý plán. Ta mimořádná situace mi v podstatě jen nahrála do ruky.

[Aleš Kapica]

Hm. Asi jsem to tam nepodal dost srozumitelně. Cílem bylo ukázat, že se přes vzdálenou plochu dají ty virtuály s MS Windows používat stejně, jako kdyby u toho člověk seděl.

Momentálně dělám na třetím manuálu, který se věnuje spouštění a připojení vzdálené plochy. Ale díky za zpětnou reakci, pro finální verzi se to pokusím upravit.

[k3dAR]

nezkousel sem

[Aleš Kapica]

Já jo. Nefunguje.

Sice zvuk ve virtuálu někam posílal, ale pulseaudio na straně klienta žádný vstup nemělo.

Momentálně se zkouším, jak si s tím poradí Xpra.

[Aleš Kapica]

Oprava, ne ve virtuálu, ale v ovládání hlasitosti na straně vzdáleného X serveru.

[Aleš Kapica]

Ale Xpra to audio protáhnout umí.

[Aleš Kapica]

Ovšem žádná hitparáda to není. Kvalitou linky to ale nejspíš nebude, protože jsem na 1G síti, kde je momentálně minimální provoz a stejně to drhne.

[dustin]

Velikost bufferu a periody bych doporučoval větší. 512 vzorků odpovídá 10ms časové rezervy/latency při 48kHz, to je nastavení pro interaktivní audio nebo hry. Klidně bych to zvednul 10x. V linkovaném nastavení pro 5.1 mají buffer-size 10000 a period-size 2500, to je časově dost bezpečná hodnota (aplikace má 200ms na dodání nových dat, jinak nastanu xrun = prasknutí). Samozřejmě na hry nebo editace audia to nebude, 200ms latence už je pro interaktivní práci nepříjemná.

[LarryL]

Klidně bych to zvednul 10x. V linkovaném nastavení pro 5.1 mají buffer-size 10000 a period-size 2500, to je časově dost bezpečná hodnota (aplikace má 200ms na dodání nových dat, jinak nastanu xrun = prasknutí).

Nevím jak ty buffery přesně pracují, ale když to nastavím na tak vysoké hodnoty, tak to praskání slyším. Naopak u těch mých nižších hodnot slyším prasknutí jen výjmečně a ještě se na to musím hodně soustředit.

[Petr Fiedler]

Díky moc. Jak bude čas, tak to zkusím a napíšu.

[Petr Fiedler]

sudo virsh edit *vm_name*

A vložíš tam:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:env name='QEMU_AUDIO_DRV' value='alsa'/>
    <qemu:env name='QEMU_ALSA_DAC_BUFFER_SIZE' value='512'/>
    <qemu:env name='QEMU_ALSA_DAC_PERIOD_SIZE' value='170'/>
  </qemu:commandline>
</domain>

Je jedno kam? Tedy ne do prostřed nějaké sekce, ale můžu např. na konec sekce zvuk?

[LarryL]

Počáteční tag <domain ...> a koncový </domain> tam už mít budeš. Ty musiš blok

  <qemu:commandline>
    <qemu:env name='QEMU_AUDIO_DRV' value='alsa'/>
    <qemu:env name='QEMU_ALSA_DAC_BUFFER_SIZE' value='512'/>
    <qemu:env name='QEMU_ALSA_DAC_PERIOD_SIZE' value='170'/>
  </qemu:commandline>

vložit před tag </domain>

[Petr Fiedler]

Jansě. Dík.

[Petr Fiedler]

Nejde mi to ani jedním způsobem:

$ sudo virsh edit *win10*
error: failed to get domain '*win10*'
error: Domain not found: no domain with matching name '*win10*'

A když vložím ten blok na konec XML před tag domain a potvrdím, tak ten blok zmizí. Tím myslím XML kartu v nastavení.

[LarryL]

Bez hvězdiček nebo i přes záložku XML, ale změnit domain: https://unix.stackexchange.com/questions/235414/libvirt-how-to-pass-qemu-command-line-args

[Petr Fiedler]

Který z těch ovladačů myslíš? Pro Windows 10 tam není žádný.

[Petr Fiedler]

Přesněji, který z kodeků?

[Petr Fiedler]

Zkusím ten pro W7.

[Petr Fiedler]

"Tuto sadu kodeků podporuje pouze Vista."

[Petr Fiedler]

Zkusil jsem i jiný kodek, ale nepomohlo to. Zítra zkusím přemístit virtuální disk na nešifrovaný HDD. Třeba to pomůže.

Jinak AC97.exe pro W10 jsem nenašel. Jen AC97.cab. Ten je pro aktualizaci a to mi píše, že už jsou nainstalovány ty nejlepší ovladače. V nouzovém režimu jsem to nezkoušel. Dopadlo by to asi stejně.

[LarryL]

Pro Win10 není žádný ovladač AC97, proto se to musí instalovat pomocí "stavu nouze". Já tam vidím "Vista/Win7 (32/64 bits) Driver only (ZIP file)", takže předpokládám, že tam nebude kodek, ale ovladač, který potřebuješ.

[Petr Fiedler]

Přesně to jsem zkoušel v tom nouzovém režimu a skončilo to chybou, jak jsem napsal.

[LarryL]

To je divné. Jak to mohlo napsat u AC97, že "už jsou nainstalovány ty nejlepší ovladače." když pro Win10 žádné ovladače neexitují? To by mě teda zajímalo jaké ovladače má když mrkneš do "Správce zařízení > AC97". Teď jsem to zkusil na té tvojí VM, podle toho videa co jsem postnul a ovladač AC97 se normálně nainstaloval.

No a teď to nejdůležitější. Po té co jsem nainstaloval v nouzovém režimu ovladač AC97 jsem začal mít problémy podobné těm co jsi popisoval

1) Video z YT se vůbec nechtělo spustit ani když jsem párkrát resetnul VM. V okně s videem (Firefox) to psalo: "Pokud se přehrávání brzy nespustí zkuste zařízení restartovat".

2) Tak jsem odebral z XML blok "<qemu:commandline>... </qemu:commandline>" a video pak šlo spustit, ale začal jsem mít přesně ty záškuby co jsi posílal v té nahrávce (škubalo se video i zvuk).

Tohle se mi nikdy v čistém Qemu (typ stroje q35+OVMF) nestalo a driver AC97 naopak problém se zvukem vyřešil. Myslím, že jsem použil i stejnou instalačku Win10 jako mám u svých VM. Takže nejlepší bude když zkusíš ve virt-manageru nahodit q35 + OVMF, ať víme jestli je to typem stroje.

[Petr Fiedler]

To je divné. Jak to mohlo napsat u AC97, že "už jsou nainstalovány ty nejlepší ovladače."...

Ne, když jsem v nouzovém režimu zkoušel nainstalovat "Vista/Win7 (32/64 bits) Driver only (ZIP file)", tak mi to napsalo:

"Tuto sadu kodeků podporuje pouze Vista."

q35 + OVMF zkusím. Dej mi trochu času. Momentálně zachraňuji tu licenci.

[LarryL]

"Nouzový režim" není přesný, to jsem napsal, když jsem si nemohl vzpomenout, že se jedná o "vypnutí vyžadování podpisů". Drž se tohoto videa https://www.youtube.com/watch?v=5-Y-oq3DMMA , které v té záplavě komentů možná zapadlo.

[Petr Fiedler]

Tak jsem se alespoň naučil ve W10 restartovat do nouzového režimu.

[Petr Fiedler]

1. Při vytváření VM mi nejde přepnout firmware na UEFI. Když kliknu na "potvrdit", tak se to vrátí na BIOS. Balík ovmf nainstalovaný mám. QEMU/KVM jsem původně instaloval z repositáře. Byla to ale starší verze a nebyla tam ta karta XML. k3dar mi pomohl nainstalovat nejnovější verzi. Poslal mi na to skript. Ovmf jsme ale neřešili. Nemůže být problém v tomto?
2. Ještě přemýšlím o tom, jestli s Windows nemohl být problém kvůli CPU. Přiřadil jsem pro VM všechna 4 jádra. Hostitel je šifrovaný a nemám dedikovanou GPU, takže vše vykresluje CPU. Nemohlo to být tím? Už to nemám jak vyzkoušet, protože jsem už ten VM smazal. Na druhou stranu, stejně nastavený Mint jede dobře a Cinnamon není zrovna nenáročné.

[k3dAR]

[...]QEMU/KVM jsem původně instaloval z repositáře. Byla to ale starší verze a nebyla tam ta karta XML. k3dar mi pomohl nainstalovat nejnovější verzi. Poslal mi na to skript.[...]

vsiml sem si ze si to zminoval parkrat, ale vzdy zapomel upresnit, tim skriptem si ziskal pouze nejnovejsi git verzi virt-manager, ale QEMU mas stale repositarovou verzi 2.x (aktualni je 4.x stable, 5.x devel), stejne tak libvirt mas verzi z repozitare, KVM je soucast jadra...

[Petr Fiedler]

Upřímně řečeno, já vlastně nevím, co je QEMU, co je KVM a co libvirt.

[k3dAR]

zjednodusene, KVM je jadernej "pomocnik" ktereho pro primejsi/rychlejsi pristup k jadru/hw pouziva QEMU, nad tim je libvirt vrstva nastroju pro spravu a spristupneni/sjednoceni virtualizacnich technologii a nad tim virt-manager zajistujici GUI

[Petr Fiedler]

Dík, nastuduju.

[Petr Fiedler]

Tak zvuk mi už jede krásně. DÍKY MOC!

Sice jsem nemohl vytvořit VM s UEFI viz. teď nevím jestli níže, nebo výše, ale vytvořil jsem alespoň nový VM. Zvuk jsem v nastavení QEMU/KVM přepnul na AC97 a vše udělal podle toho jak jsi mi to poradil. A zvuk jede nádherně i bez té USB zvukovky a bez úpravy XML. Tedy pořád se lehce trhá video na YT, ale to by mi nevadilo. Windows mám kvůli jednomu biblickému softwaru, ve kterém pod Wine nelze upravovat barevné téma a kvůli tomu odečítači. Nechám si články na netu číst a nebudu muset koukat do monitoru. Pohoda. Jen doufám, že to nerozbije nějaká aktualizace. Ještě jsem nic nestahoval. Jdu teď na to a pak zkusím i ten odečítač. Ten jsem zatím taky nezkoušel.

Jinak kdyby se ti ještě chtělo zkusit rozjet to UEFI, tak to by byla paráda. Jestli budeš souhlasit, tak bych na to mohl založit nové vlákno. Tohle už je moc dlouhé.

[Petr Fiedler]

Tak je to dobrý. Po nainstalování všech aktualizací je zvuk OK. A odečítač taky.

[LarryL]

Pokud ti funguje kombinace q35 + bios + AC97, tak to tak nechej. OVMF asi potřebovat nebudeš, naopak by ti to mohlo přidělat práci - párkrát se mi stalo, že nová verze Qemu a OVMF z repozitáře nebyly spolu kompatibilní, takže jsem musel stahovat nejnovější build od Gerda Hoffmanna - https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#Installing_.27UEFI_for_QEMU.27_nightly_builds

Akorát je divné, že ti nefungovala ta USB zvukovka. Všiml jsem si, že jsi v tom XMLku co jsi sem dával měl kromě zprůchodněné USB zvukovky také defaultní ich6 zvukovku, tu bych asi odstranil, no ale jestli ti funguje AC97, tak už je to asi jedno, ale kdyby se s AC97 trhalo video tak můžeš ještě tu USB zvukovku zkusit.

[Petr Fiedler]

Nemám q35, ale i440FX a jede to OK. S q35 jsem měl problém instalaci vůbec spustit. Vlastně se mi to nepovedlo.

[LarryL]

Já jsem u i440fx + AC97 napsal:

"video pak šlo spustit, ale začal jsem mít přesně ty záškuby co jsi posílal v té nahrávce (škubalo se video i zvuk).".

A ty jsi u té samé kombinace (i440fx + AC97) napsal:

"Zvuk jsem v nastavení QEMU/KVM přepnul na AC97 a vše udělal podle toho jak jsi mi to poradil (instalace AC97 ovladače). A zvuk jede nádherně i bez té USB zvukovky a bez úpravy XML. Tedy pořád se lehce trhá video na YT, ale to by mi nevadilo."

Takže jsme u stejné kombinace měli rozdílný výsledek a už mi to hlava nebere

---

Pak jsem si tvoji VM přehodil do q35 + bios + AC97 (samozřejmě jsem musel virtuální HW změnit, aby vyhovoval q35) a zvuk byl dobrý, ale pozoroval jsem, že video není plynulé, ostré záškuby to sice nebyly, ale nebylo to tak plynulé jako na mé VM Win10. Zkoušel jsem tvoji VM spouštět bez libvirtu:

export QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 QEMU_AUDIO_DRV=alsa; /usr/bin/qemu-system-x86_64 -name guest=win10 ...

jestli to nezlepší plynulost videa, ale nepomohlo. Kombinaci q35 + ovmf + AC97 jsem u tvojí VM nezkoušel, protože bych musel Win10 znovu nainstalovat. Důvody, proč je na mé VM (q35 + ovmf + AC97) video i zvuk plynulejší, mohou podle mne být tyto:

- mám jinak uspořádaný virtuální HW (virtio, řadiče, pcie-root-porty ...) a ve VM Win10 dochází k jinému sdílení např. IRQ,

- mám u nějakého virtuálního HW jiné parametry než co tobě vytvořil virt-manager,

- mám q35+ovmf nikoliv q35+bios

- mám zaktualizovaný Win10 (ve tvé VM jsem měl jen základní instalaci + virtio ovladače).

---

S q35 jsem měl problém instalaci vůbec spustit. Vlastně se mi to nepovedlo.

Pokud ti nešla vytvořit VM q35 + ovmf, tak možná budeš potřebovat do souboru /etc/libvirt/qemu.conf uvést správnou cestu k OVMF souborům:

nvram = [ "/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd", ]

Cestu k OVMF_CODE.fd a OVMF_VARS.fd možná budeš mít jinou. V novějším libvitu může být cesta k OVMF_VARS.fd také uvedena v XML souboru dané VM.

Pokud ti to ani pak nepůjde, tak založ nové vlákno "Jak vytvořit q35 ve Virt-manageru?"

---

Problém je ale v tom, že když ve Windows používám tu USB zvukovku, tak se ten zvuk po pár vteřinách vypne. Myslíš, že bychom to mohli odladit? Klidně bych zkusil q35, ale potřeboval bych s tím pomoct.

Z tou USB zvukovkou fakt nevím, připadá mně to jako problém Win10 a nikoliv problém virtualizace, ale zkusit ji v q35 určitě můžeš. Možná bych nejdřív zkusil na volný disk nainstalovat Win10 (na železo) jestli ti i tam bude blbnout. Je klidně možné, že je to vadný kus nebo nějaký problém s Win ovladačem.

[Petr Fiedler]

Já jsem u i440fx + AC97 napsal:

"video pak šlo spustit, ale začal jsem mít přesně ty záškuby co jsi posílal v té nahrávce (škubalo se video i zvuk).".

A ty jsi u té samé kombinace (i440fx + AC97) napsal:

"Zvuk jsem v nastavení QEMU/KVM přepnul na AC97 a vše udělal podle toho jak jsi mi to poradil (instalace AC97 ovladače). A zvuk jede nádherně i bez té USB zvukovky a bez úpravy XML. Tedy pořád se lehce trhá video na YT, ale to by mi nevadilo."

Takže jsme u stejné kombinace měli rozdílný výsledek a už mi to hlava nebere

Pokud ti nešla vytvořit VM q35 + ovmf, tak možná budeš potřebovat do souboru /etc/libvirt/qemu.conf uvést správnou cestu k OVMF souborům:

Může na to mít vliv, že v /etc/fstab mám tohle:

# QEMU/KVM images na data_evo /dev/sda3
/data/data_evo/qemu_kvm /var/lib/libvirt/images none bind,x-gvfs-hide 0 0

Z tou USB zvukovkou fakt nevím, připadá mně to jako problém Win10 a nikoliv problém virtualizace, ale zkusit ji v q35 určitě můžeš. Možná bych nejdřív zkusil na volný disk nainstalovat Win10 (na železo) jestli ti i tam bude blbnout. Je klidně možné, že je to vadný kus nebo nějaký problém s Win ovladačem.

Hned to zkusím a dám vědět. Chtěl jsem to udělat už dávno a zapomněl jsem na to.

[LarryL]

Může na to mít vliv, že v /etc/fstab mám tohle:

# QEMU/KVM images na data_evo /dev/sda3
/data/data_evo/qemu_kvm /var/lib/libvirt/images none bind,x-gvfs-hide 0 0

Pokud by virt-manageru vadilo zrovna tohle, tak bys pak nevytvořil žádný virtuální disk (např. *.qcow2), přesněji řečeno žádnou virtuálku, protože do adresáře images si libvirt ukládá virtuální disky nově vytvořených virtuálek.

[Petr Fiedler]

No já vím, ale raději jsem se zeptal, protože nechápu všechny souvislosti.

[Petr Fiedler]

Tak ta USB zvukovka ve Windows, která jsou na železe funguje dobře.

Ještě jsem dnes zkusil ve VM odstranit klasickou zvukovku AC97 a ponechat jen tu USB, ale nepomohlo to. Tedy zvuk u videa na YT jel místo 3 sekund asi tak 30 sekund, ale pak bylo stejně ticho. Zkusim q35. Tím spíše, když jsem se dnes dozvěděl, že i440FX je deska z minulého tisíciletí

[Petr Fiedler]

S q35 jsem měl problém instalaci vůbec spustit. Vlastně se mi to nepovedlo.

Pokud ti nešla vytvořit VM q35 + ovmf, tak možná budeš potřebovat do souboru /etc/libvirt/qemu.conf uvést správnou cestu k OVMF souborům:

nvram = [ "/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd", ]

Cestu k OVMF_CODE.fd a OVMF_VARS.fd možná budeš mít jinou. V novějším libvitu může být cesta k OVMF_VARS.fd také uvedena v XML souboru dané VM.

Pokud ti to ani pak nepůjde, tak založ nové vlákno "Jak vytvořit q35 ve Virt-manageru?"

Prošel jsem celý, hodně dlouhý /etc/libvirt/qemu.conf a není v něm ani jeden řádek, který by nebyl zakomentován. Našel jsem v něm tohle:

# Location of master nvram file
#
# When a domain is configured to use UEFI instead of standard
# BIOS it may use a separate storage for UEFI variables. If
# that's the case libvirt creates the variable store per domain
# using this master file as image. Each UEFI firmware can,
# however, have different variables store. Therefore the nvram is
# a list of strings when a single item is in form of:
#   ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}.
# Later, when libvirt creates per domain variable store, this list is
# searched for the master image. The UEFI firmware can be called
# differently for different guest architectures. For instance, it's OVMF
# for x86_64 and i686, but it's AAVMF for aarch64. The libvirt default
# follows this scheme.
#nvram = [
#   "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
#   "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",
#   "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd",
#   "/usr/share/AAVMF/AAVMF32_CODE.fd:/usr/share/AAVMF/AAVMF32_VARS.fd"
#]

To bude IMHO ono. Jak to mám prosím Tě upravit?

[LarryL]

1.) Zkontroluj jestli máš nainstalovaný balíček ovmf.

2.) Zjisti kde se ti nainstalovaly soubory OVMF_CODE.fd a OVMF_VARS.fd (někdy mají také příponu .*bin). Bude to v adresáři /usr/share/.

3.) Klidně to nech zakomentované a nakonec souboru qemu.conf vlož nvram = [ "/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd", ]. Správné cesty k OVMF_CODE.fd a k OVMF_VARS.fd vlož tu z bodu 2.

[Petr Fiedler]

Tady.

[LarryL]

Zítra zkusím přemístit virtuální disk na nešifrovaný HDD

To je nová informace, že to máš na šifrovaném disku.

[k3dAR]

ze vespod je LUKS by mohlo mit vyznam na nejakem starem Atomu, ale s iCore 5gen bude AES-NI vykon pocitam daleko nad hranici rychlosti disku

[Petr Fiedler]

Skylake je 6 generace.

[Petr Fiedler]

To se omlouvám. Pod systémem mám LUKS a LVM.

[Petr Fiedler]

Pokud by někdo řešil podobný problém, tak mě pomohlo toto:

1. Virt-manager > "Zobrazit" > "Detaily" > "Zvuk" > "Model" > "AC97" > "Použít".
2. Spustit VM Windows 10, stáhnout Vista/Win7 (32/64 bits) Driver only (ZIP file), uložit např. do "Stažené soubory" a rozbalit.
3. Ve VM Windows 10 "Start" > "Napájení" > Zmáčknout a držet shift > "Restartovat" > "Odstranit potíže" > "Upřesnit možnosti" > "Nastavení spouštění" > "Restartovat" > stisknout "7" - "Zakázat vynucení podpisu ovladače" > systém se restartuje. Potom pravým tlačítkem myši na "Tento počítač" > "Spravovat" > "Správce zařízení" > a protože jsme ve virt-manageru přepli zvuk na AC97, bude zde jedno "Neznámé zařízení". Klik pravým talčítkem myši na položku, kterou obsahuje > "Aktualizovat ovladač" > "Vyhledat ovladač v počítači" > "Procházet" > "Stažené soubory" > a zde vybrat tu rozbalenou složku > "OK" > "Další". Pak se systém zeptá, jestli chceme instalovat nepodepsaný ovladač? Potvrdíme, že ano, restartujeme Windows a je to

Děkuji LarryLovi, že mi s velikou ochotou a trpělivostí ukázal tento hack