Maboroshi a Makoto bez Kanashimi: Nejen hrátky s QEMU/KVM 2

2.1.2015 14:30 | Přečteno: 1561× | Linux | | poslední úprava: 1.1.2015 14:34

Po včerejším díle je dnes na pořadu následující: KVM s LVM, btrfs a 9pfs – KVM hosté s X11 a systemd-user – slepé uličky s grafikou v KVM. Zakončení zítra.

Maboroshi v2

Ústup začal zkouknutím řady Star Treků, aby se mi uvolnilo místo na desktopu. Pak jsem si prakticky ověřil, že btrfs jde zmenšit, zkopíroval ho na Hikari a na Maboroshi vytvořil LVM. Škatulata hejbejte se zase zpátky a útok pokračuje.

KVM, LVM, btrfs a 9pfs

Když máme konečně blokové zařízení (LVM), které můžeme KVM hostovi předat, je třeba zajistit správná práva. Zde nastupuje UDEV (a ještě speciálně pro LVM):

# zjištění identifikátoru DM_UUID logického svazku LVM
udevadm info -q all /dev/maboroshi_ssd_lvm/kanashimi
# /etc/udev/rules.d/10-lvm-kvm.rules                                                  
ENV{DM_UUID}=="LVM-coy5HiEulYOchdjcqNqICAL2eRkx1UARaUWmyqlSAQcphdxa3ZLBU5ZMlfiJQCUw", OWNER="qemu-kanashimi"
ENV{DM_UUID}=="LVM-coy5HiEulYOchdjcqNqICAL2eRkx1UARCSidTziWvNwadexP3pJ2YjfLYHL40L7o", OWNER="qemu-makoto"
# pro ověření, zda je pravidlo napsané správně
udevadm trigger
					

Příslušné zařízení se pak KVM hostovi předá takto:

-drive file=/dev/maboroshi_ssd_lvm/makoto,index=0,media=disk,if=virtio
					

Pro /boot pak jde použít přes 9pfs nasdílený btrfs pododdíl. V tomto případě jsem na problémy nenarazil, nižší výkon na /boot nevadí a v případě těch tří souborů od jádra, co tam jsou, se zřejmě nepoužívají takové záludnosti jako jinde na /. Nejprve příprava na Maboroshi:

mount /dev/maboroshi_ssd_lvm/btrfs /mnt/maboroshi/
cd /mnt/maboroshi
btrfs subvol create makoto_boot
# /etc/fstab
LABEL=maboroshi_ssd_btrfs       /home/qemu-makoto/boot          btrfs rw,noatime,ssd,space_cache,subvol=makoto_boot0 0
					

Nasdílení přes 9pfs KVM hostovi (opět finální stav na Makoto):

-virtfs local,id=p9fs1,path=/home/qemu-makoto/boot,security_model=mapped,mount_tag=makoto_9p_boot
					

A připojení nasdíleného svazku na KVM hostovi:

# z ruky
mount -t 9p -o trans=virtio makoto_9p_boot /boot -oversion=9p2000.L
# /etc/fstab
makoto_9p_boot          /boot           9p              rw,noatime,sync,dirsync,trans=virtio,version=9p2000.L   0 0
					

KVM hosta pak lze bootovat přímo. Předání příslušných parametrů (finální stav na Makoto):

-kernel "/home/qemu-makoto/boot/vmlinuz-linux" -initrd "/home/qemu-makoto/boot/initramfs-linux.img" 
-append "root=/dev/disk/by-label/makoto_ssd_btrfs rootflags=subvol=makoto_root rw quiet systemd.unit=multi-user.target"
					

KVM hosté s X11 a systemd-user

Jak vyřešit spouštění KVM hostů při startu systému? Máme přece ten systemd… A když chceme, aby běžely pod běžným uživatelem? Máme přece ten systemd --user… No ale my jim potřebujeme pustit i X11… Máme přece tu aktivaci služeb na vyžádání… i X11 budou.

Aby fungoval systemd --user, musí být buď uživatel přihlášen, nebo se musí povolit automatické spouštění uživatelské instance systemd (což je to, co chceme):

loginctl enable-linger qemu-kanashimi
loginctl enable-linger qemu-makoto
					

Dále je potřeba nějaká ta konfigurace. Grafické aplikace mohou chtít D-Bus (nejsem si ale teď už jistý, zda je to i případ KVM):

# /etc/systemd/user/dbus.service 
[Unit]
Description=D-Bus Message Bus
Requires=dbus.socket
[Service]
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

# /etc/systemd/user/dbus.socket 
[Unit]
Description=D-Bus Message Bus Socket
Before=sockets.target

[Socket]
ListenStream=%t/dbus/user_bus_socket

[Install]
WantedBy=default.target

# Aktivace jako root
systemctl --global enable dbus.socket

# Nastavení proměnné prostředí
# /etc/systemd/system/user@.service.d/dbus.conf 
[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
					

Grafické aplikace ale určitě budou chtít X11. Od verze 1.16 lze sice X11 pouštět s uživatelským oprávněním, má to ale háček: musí to být v rámci sezení, tedy po přihlášení uživatele. Jako by tedy X11 tuto fíčurku neměl:

# Povolení spouštění X11 pod rootem jako dřív
# /etc/X11/Xwrapper.config
allowed_users=anybody
needs_root_rights=yes

# /home/qemu-kanashimi/.config/systemd/user/xorg@.service 
[Unit]
Description=Xorg server at display %i

Requires=xorg@%i.socket
After=xorg@%i.socket

[Service]
Type=simple
SuccessExitStatus=0 1

ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt7"

# /home/qemu-kanashimi/.config/systemd/user/xorg@.socket 
[Unit]
Description=Socket for xorg at display %i

[Socket]
ListenStream=/tmp/.X11-unix/X%i

# Ještě jedna proměnná prostředí
#/etc/systemd/system/user@.service.d/display.conf 
[Service]
Environment=DISPLAY=:0

# Povolení aktivace X11 přes systemd --user socket
systemctl --user enable xorg@0.socket
					

Spuštění grafické aplikace pod daným uživatelem teď pustí X11 na terminálu 7 a tam pustí danou aplikaci.

Když už se pouští X11 pro uživatele qemu-kanashimi na vyžádání, zbývá vytvořit unit soubor pro virtuál (jeden ze stavů, kam jsem se dopracoval):

# /home/qemu-kanashimi/.config/systemd/user/qemu-kanashimi.service 
[Unit]
Description=QEMU virtual kanashimi
After=xorg@0.socket
Requires=xorg@0.socket

[Service]
Environment="QEMU_AUDIO_DRV=alsa" 
ExecStart=/usr/bin/env qemu-system-x86_64 -name kanashimi \
        -enable-kvm -m 2048 -cpu host -smp 2 -soundhw ac97 -vga vmware \
        -device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:00 \
        -netdev type=tap,id=net2,ifname=tap1,script=no,downscript=no \
        -drive file=/dev/maboroshi_ssd_lvm/kanashimi,index=0,media=disk,if=virtio \
        -virtfs local,id=p9fs1,path=%h/boot,security_model=mapped,mount_tag=kanashimi_9p_boot \
        -monitor unix:%h/kvm-kanashimi.sock,server,nowait \
        -kernel "%h/boot/vmlinuz-linux" -initrd "%h/boot/initramfs-linux.img" \
        -append "root=/dev/disk/by-label/kanashimi_ssd_btrfs rootflags=subvol=kanashimi_root rw quiet systemd.unit=graphical.target" 
        #-drive media=cdrom,file=%h/archlinux-2014.09.03-dual.iso,readonly,index=1
ExecStop=/bin/sh -c "echo 'system_powerdown' | unixterm %h/kvm-kanashimi.sock"
TimeoutStopSec=30
KillMode=none

[Install]
WantedBy=default.target

# A službu povolit
systemctl --user enable qemu-kanashimi.service
					

Shin-Kanashimi

Tato kapitola obsahuje asi nejvíc nahromaděné frustrace… Máme tedy nainstalovaný a nakonfigurovaný lehký virtuální Arch s Xfce (Shin-Kanashimi), který se spouští pod svým neprivilegovaným uživatelem pomocí systemd --user, dokonce si pustí X11 na VT7… až potud sluníčkové. Jenže… Ukázalo se, že to má několik mušek a masařek:

• Automatické přepnutí na VT7 – nevím už, zda jsem vyřešil, nebo na řešení pro další nedošlo.
• Po startu Shin-Kanashimi není fokus v X11 na hostu, ale v X11 na hostiteli – k tomuhle jsem se nedostal.
• Zvuk na hostu – na toto zabrala výše uvedená proměnná QEMU_AUDIO_DRV a přepínač -soundhw ac97.
• Tragický grafický výkon – viz níže.

Druhá slepá ulička – vga=std

Tragický výkon s přepínačem -vga=std jsem očekával, tedy jen pro úplnost ve výčtu: hýbání s okýnky je slide-show.

Třetí slepá ulička – vga=vmware

Zde jsem měl ještě nějaké naděje. Přepínač -vga=vmware potřebuje mít na straně hosta nainstalované a použité správné ovladače: xf86-video-vmware a xf86-input-vmmouse z [extra]. Hýbávní s okýnky už není slide-show, jupí!

Jde se testovat! Dokonce to zvládá plynule přehrát mp3 v mplayeru, ovšem nesmí se při tom hejbat s okýnkama. Tak ještě nějaké video… Potíže začaly už na youtube, ale říkal jsem si, že to bude těmi blbými flashi, které by se měly zakázat. Staré čb nahrávky Peter, Paul and Mary se ještě držely, ale něco novějšího, barevného s Dylanem už to nevydýchalo. Star Trek TNG v avíčku bylo hodně pomalé slide-show a z Naruta v 720px emkávéčku byl vidět jen první snímek…

TO JE MARNÝ!

Čtvrtá slepá ulička – SPICE

Zde už jsem si naděje nedělal. Pro zprovoznění SPICE je potřeba na straně hosta ovladač xf86-video-qxl a agent spice-vdagent z AURu. Na hostiteli pak musí být klient (balíček spice) a pro spouštění při startu se pak upraví systemd unity. Povoluje se pak uživatelská služba spice-client.service, která závisí na vlastní službě pro virtuálního hosta:

#/home/qemu-kanashimi/.config/systemd/user/spice-client.service 
[Unit]
Description=Spice client for virtual kanashimi
Wants=qemu-kanashimi.service
After=qemu-kanashimi.service
After=xorg@0.socket
Requires=xorg@0.socket

[Service]
ExecStart=/usr/bin/env spicec -h 127.0.0.1 -p 5930

[Install]
WantedBy=default.target

#/home/qemu-kanashimi/.config/systemd/user/qemu-kanashimi-spice.service 
[Unit]
Description=QEMU virtual kanashimi

[Service]
Environment="QEMU_AUDIO_DRV=alsa" 
ExecStart=/usr/bin/env qemu-system-x86_64 -name kanashimi \
        -enable-kvm -m 2048 -cpu host -smp 2 -soundhw ac97 \
        -vga qxl -spice port=5930,disable-ticketing \
        -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent \
        -device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:00 \
        -netdev type=tap,id=net2,ifname=tap1,script=no,downscript=no \
        -drive file=/dev/maboroshi_ssd_lvm/kanashimi,index=0,media=disk,if=virtio \
        -virtfs local,id=p9fs1,path=%h/boot,security_model=mapped,mount_tag=kanashimi_9p_boot \
        -monitor unix:%h/kvm-kanashimi.sock,server,nowait \
        -kernel "%h/boot/vmlinuz-linux" -initrd "%h/boot/initramfs-linux.img" \
        -append "root=/dev/disk/by-label/kanashimi_ssd_btrfs rootflags=subvol=kanashimi_root rw quiet systemd.unit=graphical.target" 
        #-drive media=cdrom,file=%h/archlinux-2014.09.03-dual.iso,readonly,index=1
ExecStop=/bin/sh -c "echo 'system_powerdown' | unixterm %h/kvm-kanashimi.sock"
TimeoutStopSec=30
KillMode=none

[Install]
WantedBy=default.target
					

Tato konfigurace fungovala v tom smyslu, že se povedlo spustit Shin-Kanashimi, ovšem co se týče grafiky, bylo to ještě tragičtější, než s -vga=vmware.

TO JE VÁŽNĚ MARNÝ!

Přes KVM hosty s grafickým prostředím tedy zřejmě cesta nepovede. Nastal čas pro další taktický ústup.

       

Komentáře

[kolda]

Čoveče, ty fakt nevíš o čem psát, prostě potřebuješ jen dělat copy/paste a ťukat do klávesnice.

[Datel]

Teda nevim kde je chyba, ale ja pres KVM (SPICE/VNC) pouzivam par desktopu (linux, *BSD, Win, QNX), vcetne akcelerovaneho Gnome3 a bez problemu, flash, 1080p video... Pravda jedu na Red Hatu a Intelu.

[Nicky726]

Tak rád slyším, že to jde, a zároveň by mě teda zajímalo, čím to, že mé pokusy v tomto směru nedopadly.

[Špekáček z Intersparu s hořčicí Alba+]

Vyžaduje to jinak VT-d (pokud jste na Intleu, tedy...), nebo jde akcelerovaná grafika jen i s VT-x?

[Šangala]

S tou grafikou to nějak nechápu, vždyť i hloupé VNC na normální síti, v pohodě utáhne desktop.

[Nicky726]

No, a toto ani nešlo přes síť.

[Šangala]

No proto jsem ti to psal, bo ke KVM hostů normálně přistupuji přes VNC a v lokální síti nemám s graf. prostředím jako takovým žádný problém

[Nicky726]

OK, to by stálo za vyzkoušení. Je pravda, že jsem VNC jako síťovou věc rovnou zavrhl.

[Šangala]

Tady je krátký záznam na gigabit síti přes ssh tunel na testovací CentOS mašinu, client je spuštěn takto:
xtightvncviewer -compresslevel 9 -quality 9 -encodings Tight -owncmap …

Ale je to jen 1024×768…

[Dizz.]

Nějak nerozumím v čem je problém, to zda virtaulní stroj nastartuje do Xek nebo ne je přece věc nastavení toho virtualního stroje a né hostitele.

Co se tyka startovaní viralního stroje po startu počitače se dá elegantně řešit přes libvirt a podobně ne?

[Nicky726]

Věc hostitele je to také, protože tam chci s těmi X hosta pracovat, zároveň tam ale nechci mít normální prostředí, protože se tam nemá krom toho hoštění nic dělat, a tedy si ty X musí host na hostiteli při startu spustit. Tedy alespoň podle původního záměru.

Ano, vím že s virtuály jde pracovat přes libvirt. Asi bych to i zvolil pro pohodlí, pokud bych měl neustále nějaké hosty přidávat, odebírat a měnit, jenže tady čekám, že po úvodní konfiguraci bude už jen údržba. Zároveň se mi úplně nelíbí představa, že by se některé služby spouštěly standardně (přes systemd) a o jiné se staralo něco jiného (libvirt) a tedy mi řešení všechny služby pouští systemd přijde čistší.

[Dizz.]

OK, asi vubec nechapu co je presnym cilem. Ja mam hostitele(virtaulizace) bez Xek + 2 hosty s Xkama a startuje to "normalne". Na Xka tech virtalek pristupuji pres sit z jineho stroje.

Nevim jak to myslite stemi sluzbami, libvirt se stara o virtualizaci na hostiteli a o sluzby na tech virtulkach se stara jejich systemd (v tech virtualkach).

[Nicky726]

Cílem byl virtualizující systém Maboroshi a na něm virtualizované stroje Makoto bez X a Kanashimi s X, ale ke Kanashimi se bude přistupovat z fyzického hardwaru Maboroshi. Myslel jsem, že jsem toto jasně popsal v předchozím příspěvku, ale možná, že ne.

Z hlediska Maboroshi jsou službami oba dva virtuály. Tj. každý je jednou službou na stejné úrovni jako třeba sshd a apcupd.

[xkucf03]

A co starý dobrý X protokol tunelovaný přes SSH? Vím, v rámci localhostu to zní hrozně, ale kupodivu to funguje. Používám to hlavně na různé experimenty a blbnutí – teď jsem si třeba zkusil zahrát Nexuiz a šlo to v pohodě.

[Nicky726]

X11 jsem během testování přes SSH tuneloval po domácí síti na úrovni hostitel – jiný poč. A bylo to stejné jako, když to běželo lokálně. Může nastat něco jinak, když budu tunelovat X11 z hosta na hostitele?

[trekker.dk]

To jsem nedávno zkoušel mezi notebookem a domácím kompem. Jabbim klienta (kopete) to ještě zvládne, ale textový editor (kate) běžel jako slideshow.

[mimi.vx]

v tom pripade mas neco spatne v lokalni siti

[trekker.dk]

Jo, gigabitovou síť tu nemám.

[mimi.vx]

hraval jsem Freeciv na 5 kompech z jednocho a Xservery na win95 na 10 mbit siti a bez problemu ,

 

stejne jako pres 10mbit instaluji gfx instalatorem pres ssh servery v DE z prahy a no problem, nepoznas to od lolkalni app

[Limoto]

Napadají mě dvě řešení. Tím prvním je spuštění X servreu na hostiteli, ke kterýmu se host připojí normálně přes X protokol po síti (přes paravirtualizovanou síť by to podle mě mohlo fungovat dost dobře), tím druhým ,možná trošku hardcore, je VGA passtrough. Osobní zkušenost nemám ani s jedním

[Nicky726]

Na to druhé jsem při průzkumu narazil, ale nemám VT-D ani dvě grafiky. To prvé píšu na seznam věcí k dalšímu průzkumu, dík.

[Limoto]

Soudě dle blogu AMD bys IOMMU mít mohl. A teoreticky si myslím, že by stačila jedna grafika - když ji unbinduješ z hostitele, mohla by jít použít v hostovi (ale tohle je fakt totálně nepotvrzená teorie).