Ezúttal a hang esett áldozatul...
SDL-t használok a VM konzoljára, ez a helyi gépen idáig ki tudta hozni a guestből a hangot - sőt jelenlegi ismereteim szerint csak ez. (Tudom van ilyen, hogy SPICE, de látta már ezt valaki ténylegesen működni?)
A
/var/log/libvirt/qemu/<gepneve>.logilyeneket tartalmaz, jó sokat:
oss: Could not initialize ADC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
audio: Failed to create voice `ac97.pi'
Log message alapján sikerült megtalálni egy másik szerencsétlen kolléga forum posztját ugyanezzel a problémával: https://bbs.archlinux.org/viewtopic.php?id=159568, persze válasz nincs.
Hmm,
/dev/dspez mintha OSS API lenne? Eddig valahogy tudta, hogy ALSA-t kell használni... Természetesen a libvirt és virt-manager semmi beállítási lehetőséget nem tartalmaz erre vonatkozóan. Sőt, sajnos a qemu command line sem; csak annyi, hogy
-sdlés ezzel el van intézve. Az SDL-nek elvileg meg lehetne mondani, hogy milyen backendet használjon: http://www.libsdl.org/docs/html/sdlenvvars.html. Ez elsőre nem nagyon akart működni nekem, úgyhogy nem mentem tovább ebbe az irányba, bár nem kizárt, hogy valami obskurus módon ez is megoldható.
Legyen tehát OSS a gépen, vagy legalábbis ALSA-OSS.
sudo pacman -S alsa-oss
Kicsit szokni kell a bootoláskor automatikus modulbetöltés módját, de majdnem úgy megy mint bárhol máshol:
cat > /etc/modules-load.d/alsa-oss.conf
snd_pcm_oss
snd_seq_oss
snd_mixer_oss
Amíg nem rebootolunk, addig modprobe a felsorolt modulokra.
Már van /dev/dsp:
ls -la /dev/dsp
crw-rw-rw-+ 1 root audio 14, 3 May 12 00:04 /dev/dsp
Próba... hát nem nyert, de legalább már "csak" jogosultsági baja van:
oss: Could not initialize ADC
oss: Failed to open `/dev/dsp'
oss: Reason: Operation not permitted
audio: Failed to create voice `ac97.pi'
Ez könnyű:
sudo usermod -a -G audio xmi
- gondolja, aki téved. Nem segít. Természetesen logout-login megvolt,
systemctl restart libvirtdszintén (lévén, hogy a libvirt indítja a qemu-t...), teljes reboot... semmi nem segít, hang nincs, hibüzenet marad. Ellenpróba, qemu indítás kézzel -> és lám máris van hang. Hálózat az persze nincs, mert azt a libvirt rakná alá, de ne legyünk telhetetlenek, a lényeg, hogy az elképzelés működik, csak a libvirt nyilván nem adja át az én group set-emet a qemu processnek, annak ellenére, hogy
user = "xmi"benn van a konfig fájlban. Van ott olyan lehetőség is, hogy
group = , de ezzel csak egy group adható meg, nem pedig egy set.
Mint kiderült, úgy tünik ennél kicsit komplikáltabb a probléma... nem a qemu process effektív groupjai rosszak, hanem a libvirt egy cgroup-ban indítja qemu-t és annak van még egy külön ACL kezelő rétege, ami további jogosultságkorlátozást visz be a rendszerbe. A
/etc/libvirt/qemu.conf-ban az eredetileg kikommentezett részt vissza kell rakni, és hozzácsapni a
/dev/dsp-t a listához:
cgroup_device_acl = [
"/dev/null", "/dev/full", "/dev/zero",
"/dev/random", "/dev/urandom",
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",
"/dev/rtc","/dev/hpet",
"/dev/dsp"
]
Juttassuk érvényre:
systemctl restart libvirtd
És láss csodát, most már működik... egészen a következő update-ig, amikor majd valami egészen mást fognak elrontani.
- XMI blogja
- A hozzászóláshoz be kell jelentkezni
- 978 megtekintés
Hozzászólások
a) jól gondolom hogy a ma inkább KVM néven emlegetett dolgot használod? (Ezen lehet vitatkozni - és meggyőzni -, de én akkor hívom QEmu-nak, ha az a klasszikus emulátor, ha már a kernelbeli KVM-et használja - tehát a kvm és kvm(intel|amd) modulokat -, akkor KVM-nek)
b) jelentkezem, már láttam a SPICE-ot működni, de nem volt sétagalopp működőre összehozni (a hang részéről emlékeim sincsenek, hogy próbáltuk-e)
- A hozzászóláshoz be kell jelentkezni
Igen KVM-ről van szó, csak egyrészt ez a jelen problémát tekintve nem túl lényeges részlet, másrészt meg a "kvm" mint string lényegében már sehol nem jelenik meg, talán csak a kernel modulnak ez a neve. Az arch-ban már olyan verzió van, ahol nincs külön qemu-kvm bináris sem.
Legalábbis utólag így ideologizálom meg, hogy miért hagytam ki. :)
Szóval a SPICE-szal pont nekem is az volt a bajom, hogy arch-ra nem volt hozzá kész csomag (vagy AUR PKGBUILD), és a függőségeit kézzel összeszedni nem egyszerű. Fordítás közben meg töményen jöttek a hibák, és - amikor próbáltam - sehol nem volt egy összeszedett leírás arról, hogy pontosan milyen verziójú library-kkel számíthatok arra, hogy egyáltalán fordulni fog. Lehet, hogy javult azóta valamit a helyzet.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Háztáji virtualizáció.. =)
- A hozzászóláshoz be kell jelentkezni
Fedora-ban out of box működik a SPICE egy ideje, jól.
- A hozzászóláshoz be kell jelentkezni
Egyszer majd erre ránézek. Csak kíváncsiságból, hogy valójában mennyire használható.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Én ilyen mélységig bele sem ástam magam a dolgokba. Tettem egy próbát úgy két hónapja kb. ugyanazokból a megfontolásokból merítve, mint te. Kapásból nem boldogultam a virt-managerrel jogosultság-problémák miatt, pedig elvben az arch wiki szerint belőttem amit kellett. Egy darabig használtam parancssorból indítgatva, mert úgy működgetett, de hol volt hálózat, hol nem, (egyik vm indításnál volt, 5 perc múlva restartolva meg nem), hol el tudott indulni normális felbontással, hol nem (természetesen a parancs ugyanaz, semmi nem változott a két indítás között), feladtam, maradt a virtualbox. Persze amikor frissült valamelyik kvm vagy libvirt komponens, akkor jött is a figyelmeztetés, hogy ezt vagy azt a group policyt megváltoztatták, és hogy mi a teendő, na ez pl az amivel nem volt kedvem szívni, mivel a guest-et csak alkalmanként használom, de akkor meg nem reszelni szeretném, hanem elindítani, aztán jónapot. Persze értem én, hogy a fejlesztéssel ezeket a dolgokat is finomhangolni, meg változtatni kell, de így rolling release alatt nincs értelme használni desktop virtualizációs megoldásként szerintem.
- A hozzászóláshoz be kell jelentkezni
En az egesz libvirt tortenetet visszazavarnam a tervezoasztal melle. A nyiltforrasu, kivaloan dokumentalt Xen -t sem kepesek normalisan megoldani, legalabbis a libvirt altal az xml-je alapjan generalt konfiggal konkretan teljesitmenyproblemaim voltak, mig az ugyanazon parameterek menten altalam irt xen konfig rohogve mukodott. Azota nagyon kiabrandultam a libvirt-bol, pedig amugy jo otlet lenne.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
SDL-t használok a VM konzoljára, ez a helyi gépen idáig ki tudta hozni a guestből a hangot - sőt jelenlegi ismereteim szerint csak ez.
Szerintem én ezt használom pár éve a guest(ek)ben hang "megszólaltatására" debian host rendszer alatt:
export QEMU_AUDIO_DRV=sdl
export SDL_AUDIODRV=alsa
export SDL_VIDEO_X11_DGAMOUSE=0
Ez van a kvm_start szkript elején pár éve a kvm-es parancs előtt, részben a hang miatt, a dgamouse rész nem tudom miért van ott. :-)))
Valami oka van, hogy pár éve odakerült pontosan ebben a formában, kommentet nem írtam hozzá, ott van és kész :-). debiant használok néhány éve még talán tudtam, dehát a szenilitás nagy úr.
Amíg működik addig nem piszkáljuk. :-)))
"nem igényel folyamatos rejtvényfejtést mindenféle patchek kergetése,"
tulajdonképpen így volt, legutóbb talán azért nyivákolt a kvm, mert a vdekvm már deprecated, elavult volt, meg az egyik -net tun kapcsoló helyett -net vde -vel ment a hálókártya a guestben aztán asszem nagyjából ennyi nyűgje volt, de azért nem vagyok benne 100%ig biztos.
Az utóbbi időben elég ritkán kell előkapnom virtuális desktopot. Mindenesetre kipróbáltam és most is megy, szerintem min. hónapok óta nem indítottam el, érdekes a guest image fájlok még megvannak. Hmmm. több guest igame fájljai is, huhh. asszem takaratítani kell. Szóval ezért (is) ilyen kevés a hely a home könyvtárban.hmmm...
--------
Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.
- A hozzászóláshoz be kell jelentkezni