Libvirt, SDL, jogosultságkezelés és a Hang

Hátha valaki másnak is jó lesz rovat következik:

Helyszín az otthoni Arch linuxos gépem. Egy ideje úgy határoztam, hogy a háztáji desktop virtualizációs igényeimre vmware workstation/player, virtualbox és hasonló proprietary (és az aktuális kernelekhez patchelni mindig szívás) megoldások helyett haladok a korral és qemu-t fogok használni. Pontosabban qemu + libvirt + virt-manager kombót. Hogy ez milyen szinten fapados az előző kettőhöz képest, az nem ennek a bejegyzésnek a tárgya. (Egyébként nagyon!).

A fapadosságért cserébe azt vártam volna, hogy - mainline kernelben karbantartott megoldásról lévén szó - egyszer összelövöm és utána update-ek és minden egyebek simán gond nélkül menni fognak, nem igényel folyamatos rejtvényfejtést mindenféle patchek kergetése, fordítási hibák kézi javítgatása, inkompatibilis library verziók workaroundolása. Na ez sem jött be. Több-kevesebb rendszerességgel jön olyan update, ami elrontja a konfigot és utána nyomozhatok, hogy ezúttal mit kell utánahúzni. Leginkább a jogosultságkezelés környékén szoktak bajok lenni, ott rendszeresen átvariálnak valamit.

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>.log

ilyeneket 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/dsp

ez 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 libvirtd

szinté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.

( Zahy v | 2013. 05. 12., v – 07:23 )

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)

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!

( dap | 2013. 05. 12., v – 12:17 )

Fedora-ban out of box működik a SPICE egy ideje, jól.

( batyu v | 2013. 05. 12., v – 12:52 )

É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.

( hrgy84 | 2013. 05. 12., v – 20:03 )

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.

( Oscon | 2013. 05. 13., h – 23:53 )

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.