You are not logged in.

#1 2017-08-12 16:33:16

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

QEMU as a Window Manager Suggestions?

I am trying to change from Virtual Box to Qemu for Virtualization on my machine.  I have both a Debian guest and a Windows 7 guest that work very well under qemu.

I like to use Virtualbox as a Window Manager and start it using startx and my .xinitrc.  This allows me to log in as my user one one console, flip over to another console and start a VM in a full screen without being wrapped in a wm such as i3.  This allows me full control over keybindings without conflicts between the wm and the guest.  It also provides a much more "native" feel in the guest.

I've tried this using qemu and it works as well; with one serious problem.   If I change from the console on which the VM is running to the other console on which I am running i3, the VM stops executing; it just suspends operation.  If I change back to the console with the VM, it picks up right where it left off.  Windows' clock will be off by the time that I was on the other console.  Debian gets the time right, but it seems to be because it uses a time server.   This is an issue, because i am using Debian as a build environment for cross compiling the MIPS version of Asus Merlin;   Arch is not a supported environment (nor does it work because many of the installed tools are much newer).

Figuring it was something having to do with QEMU not being designed as a WM, I tried wrapping it in an openbox-session with a customized rc.xml that pretty much did nothing but run qemu in the mode I wished.  This did not work; the VM stopped just as before.  As an experiment, I ran another window in that openbox-session running a simple script that displayed the time every second along side the qemu VM.  I switched to the i3 console, then back to openbox-console.  The qemu had gone dormant in my absence, but the time script never missed a beat.

Furthermore, I configured QEMU in all of the above configurations to redirect the monitor function to tcp:localhost:1234,server,nowait to allow connection via telnet.  This works perfectly when the VM is in the same console session as is telnet.  If I connect to the monitor using telnet from the i3 console while the VM is running on another console, telnet will connect, but nothing happens.  Flip to the other console and back, and while you were gone, the telenet session suddenly shows (qemu).  Enter a command, like info cpustate and return, and nothing happens.  Flip consoles out and back, and while you were gone, the cpu information appeared.  This tells me that the monitor function is only being updated while the session with qemu has focus.

I have been combing the qemu documentation for a full day now and find nothing about qemu suspending when its session is not selected, nor can I find any knobs to prevent it from suspending. 

For all of you who have convinced me to move to qemu (A good thing, BTW), any suggestions on what I am missing?

Last edited by ewaller (2017-08-12 16:45:03)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#2 2017-08-12 17:09:14

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,680
Website

Re: QEMU as a Window Manager Suggestions?

Is there anything relevant printed to the journal before, during or after the "freeze"?

For the sake of completeness the relevant startup files should probably be posted also.

I would perhaps try running the QEMU command from a tmux session, that may continue regardless of the TTY status.]

EDIT: irrelevance removed.

Last edited by Head_on_a_Stick (2017-08-12 17:12:44)

Offline

#3 2017-08-12 17:28:45

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: QEMU as a Window Manager Suggestions?

Do the VM consoles start a separate X server ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#4 2017-08-12 17:52:03

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: QEMU as a Window Manager Suggestions?

Lone_Wolf wrote:

Do the VM consoles start a separate X server ?

Yes.

hoas wrote:

Is there anything relevant printed to the journal before, during or after the "freeze"?

Nothing in the host journal.  The guest journal has a register dump initiated by a "Self detected kernel freeze" posted to the journal.  Digging the actual non-persistent journal output from guest is non-trivial ; I'll pastebin it if need be; but yes, the guest journal indicated that the kernel figured out that it had stopped.

For the sake of completeness the relevant startup files should probably be posted also.

Yeah, I knew that wink

ewaller@turing ~ 1001 %cat .xinitrc
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

setxkbmap -option ctrl:nocaps
autocutsel -fork &
autocutsel -selection PRIMARY -fork &


case $WM in
    openbox)
	exec  openbox-session
	;;
    win7)
	win7 -full-screen
	;;
    win10)
	win10 -full-screen
	;;
    debian)
	exec debian_fullscreen
	;;
    i3)
	exec i3
	;;
    *)
	exec i3
	;;
esac

ewaller@turing ~ 1002 %cat bin/debian_fullscreen
debian -full-screen \
       -no-frame \
       -monitor tcp:localhost:1234,server,nowait
openbox --exit
ewaller@turing ~ 1003 %cat bin/debian
qemu-system-x86_64 -drive file=/home/ewaller/virtualization/debian.raw \
                                        -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
					-smp 2 \
					-m 1024 \
					-enable-kvm \
					-soundhw hda \
					-usbdevice host:0403:6001 \
					-machine type=pc,accel=kvm \
				         $@
					

					

ewaller@turing ~ 1004 %

Invoked by
WM=debian startx

startx invokes bin/debian_fullscreen which in turn invokes bin/debian and in turn, qemu-system-x86_64

Edit:  That openbox -exit is invoked after qemu exits.  I did not want a black openbox screen just hanging there; I want to exit  xorg at that point. It works.

Edit:  I dug out the relevant bits from the guest journal.  I established a connection to the built in SMB server to export stuff, then switched away briefly, at 11:52:26, came back, went away again for a longer period at 11:56:12

Aug 12 11:51:21 debian tracker-miner-f[869]: Could not find parent node for URI:'smb://10.0.2.4/qemu/'
Aug 12 11:51:21 debian tracker-miner-f[869]: NOTE: URI theme may be outside scheme expected, for example, expecting 'file://' when given 'http://' prefix.
Aug 12 11:51:21 debian tracker-miner-f[869]: Could not set mount point in database 'urn:nepomuk:datasource:4228c6c6b0320887568ba2e2f92fd8e8', GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: UNIQUE constraint failed: nie:DataObject.nie:url (strerror of errno (not necessarily related): No such file or directory)
Aug 12 11:52:26 debian rtkit-daemon[379]: The canary thread is apparently starving. Taking action.
Aug 12 11:52:26 debian rtkit-daemon[379]: Demoting known real-time threads.
Aug 12 11:52:26 debian rtkit-daemon[379]: Successfully demoted thread 764 of process 762 (n/a).
Aug 12 11:52:26 debian rtkit-daemon[379]: Successfully demoted thread 763 of process 762 (n/a).
Aug 12 11:52:26 debian rtkit-daemon[379]: Successfully demoted thread 762 of process 762 (n/a).
Aug 12 11:52:26 debian rtkit-daemon[379]: Demoted 3 threads.
Aug 12 11:53:07 debian pulseaudio[762]: [alsa-sink-Generic Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Aug 12 11:53:07 debian pulseaudio[762]: [alsa-sink-Generic Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Aug 12 11:53:07 debian pulseaudio[762]: [alsa-sink-Generic Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Aug 12 11:54:27 debian rtkit-daemon[379]: The canary thread is apparently starving. Taking action.
Aug 12 11:54:27 debian rtkit-daemon[379]: Demoting known real-time threads.
Aug 12 11:54:27 debian rtkit-daemon[379]: Successfully demoted thread 764 of process 762 (n/a).
Aug 12 11:54:27 debian rtkit-daemon[379]: Successfully demoted thread 763 of process 762 (n/a).
Aug 12 11:54:27 debian rtkit-daemon[379]: Successfully demoted thread 762 of process 762 (n/a).
Aug 12 11:54:27 debian rtkit-daemon[379]: Demoted 3 threads.
Aug 12 11:56:12 debian kernel: INFO: rcu_sched self-detected stall on CPU
Aug 12 11:56:12 debian kernel:         0-...: (1 GPs behind) idle=5f5/140000000000001/0 softirq=49750/49751 fqs=0 
Aug 12 11:56:12 debian kernel:          (t=17134 jiffies g=11993 c=11992 q=830)
Aug 12 11:56:12 debian kernel: rcu_sched kthread starved for 17134 jiffies! g11993 c11992 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
Aug 12 11:56:12 debian kernel: rcu_sched       S    0     7      2 0x00000000
Aug 12 11:56:12 debian kernel:  ffff9d2b90e08800 ffff9d2b90e08800 ffff9d2bbe349040 ffff9d2bbfd18240
Aug 12 11:56:12 debian kernel:  ffff9d2bb9f94100 ffffad99001c7db0 ffffffffa64015d3 ffffad99001c7de0
Aug 12 11:56:12 debian kernel:  000000010000adeb ffff9d2bbfd18240 0000000000000001 ffff9d2bbe349040
Aug 12 11:56:12 debian kernel: Call Trace:
Aug 12 11:56:12 debian kernel:  [<ffffffffa64015d3>] ? __schedule+0x233/0x6d0
Aug 12 11:56:12 debian kernel:  [<ffffffffa6401aa2>] ? schedule+0x32/0x80
Aug 12 11:56:12 debian kernel:  [<ffffffffa6404dae>] ? schedule_timeout+0x17e/0x310
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ee3e50>] ? del_timer_sync+0x50/0x50
Aug 12 11:56:12 debian kernel:  [<ffffffffa5edd605>] ? rcu_gp_kthread+0x505/0x850
Aug 12 11:56:12 debian kernel:  [<ffffffffa5eb8799>] ? __wake_up_common+0x49/0x80
Aug 12 11:56:12 debian kernel:  [<ffffffffa5edd100>] ? rcu_note_context_switch+0xe0/0xe0
Aug 12 11:56:12 debian kernel:  [<ffffffffa5e965d7>] ? kthread+0xd7/0xf0
Aug 12 11:56:12 debian kernel:  [<ffffffffa5e96500>] ? kthread_park+0x60/0x60
Aug 12 11:56:12 debian kernel:  [<ffffffffa64064f5>] ? ret_from_fork+0x25/0x30
Aug 12 11:56:12 debian kernel: Task dump for CPU 0:
Aug 12 11:56:12 debian kernel: cc1             R  running task        0 16443  16442 0x20020008
Aug 12 11:56:12 debian kernel:  ffffffffa6b13580 ffffffffa5ea3bcb 0000000000000000 ffffffffa6b13580
Aug 12 11:56:12 debian kernel:  ffffffffa5f7a4b6 ffff9d2bbfc18fc0 ffffffffa6a4a6c0 0000000000000000
Aug 12 11:56:12 debian kernel:  ffffffffa6b13580 00000000ffffffff ffffffffa5edee04 00000000003d0900
Aug 12 11:56:12 debian kernel: Call Trace:
Aug 12 11:56:12 debian kernel:  <IRQ> 
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ea3bcb>] ? sched_show_task+0xcb/0x130
Aug 12 11:56:12 debian kernel:  [<ffffffffa5f7a4b6>] ? rcu_dump_cpu_stacks+0x92/0xb2
Aug 12 11:56:12 debian kernel:  [<ffffffffa5edee04>] ? rcu_check_callbacks+0x754/0x8a0
Aug 12 11:56:12 debian kernel:  [<ffffffffa5eed0c3>] ? update_wall_time+0x473/0x790
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ef48c0>] ? tick_sched_handle.isra.12+0x50/0x50
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ee5718>] ? update_process_times+0x28/0x50
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ef4890>] ? tick_sched_handle.isra.12+0x20/0x50
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ef48f8>] ? tick_sched_timer+0x38/0x70
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ee60fc>] ? __hrtimer_run_queues+0xdc/0x240
Aug 12 11:56:12 debian kernel:  [<ffffffffa5ee67cc>] ? hrtimer_interrupt+0x9c/0x1a0
Aug 12 11:56:12 debian kernel:  [<ffffffffa6408ba9>] ? smp_apic_timer_interrupt+0x39/0x50
Aug 12 11:56:12 debian kernel:  [<ffffffffa6407ec2>] ? apic_timer_interrupt+0x82/0x90
Aug 12 11:56:12 debian kernel:  <EOI> 
Aug 12 11:56:12 debian kernel:  [<ffffffffa6405e41>] ? _raw_spin_unlock_irqrestore+0x11/0x20
Aug 12 11:56:12 debian kernel:  [<ffffffffc029d03e>] ? ata_scsi_queuecmd+0x9e/0x1e0 [libata]
Aug 12 11:56:12 debian kernel:  [<ffffffffc024ad96>] ? scsi_dispatch_cmd+0xd6/0x200 [scsi_mod]
Aug 12 11:56:12 debian kernel:  [<ffffffffc024db20>] ? scsi_request_fn+0x460/0x5e0 [scsi_mod]
Aug 12 11:56:12 debian kernel:  [<ffffffffa60f7c7f>] ? __blk_run_queue+0x2f/0x40
Aug 12 11:56:12 debian kernel:  [<ffffffffa60f7ef5>] ? queue_unplugged+0x25/0xa0
Aug 12 11:56:12 debian kernel:  [<ffffffffa60fcc4f>] ? blk_flush_plug_list+0x1cf/0x230
Aug 12 11:56:12 debian kernel:  [<ffffffffa60fd0a7>] ? blk_finish_plug+0x27/0x40
Aug 12 11:56:12 debian kernel:  [<ffffffffa5f8b67b>] ? __do_page_cache_readahead+0x1ab/0x240
Aug 12 11:56:12 debian kernel:  [<ffffffffa5f8b840>] ? ondemand_readahead+0x130/0x220
Aug 12 11:56:12 debian kernel:  [<ffffffffa5f7e2fe>] ? generic_file_read_iter+0x63e/0x8a0
Aug 12 11:56:12 debian kernel:  [<ffffffffa6001537>] ? new_sync_read+0xd7/0x120
Aug 12 11:56:12 debian kernel:  [<ffffffffa6001ca1>] ? vfs_read+0x91/0x130
Aug 12 11:56:12 debian kernel:  [<ffffffffa6003112>] ? SyS_read+0x52/0xc0
Aug 12 11:56:12 debian kernel:  [<ffffffffa5e03cdd>] ? do_fast_syscall_32+0x8d/0x170
Aug 12 11:56:12 debian kernel:  [<ffffffffa6407aac>] ? entry_SYSENTER_compat+0x4c/0x5b
Aug 12 11:56:12 debian rtkit-daemon[379]: The canary thread is apparently starving. Taking action.
Aug 12 11:56:12 debian rtkit-daemon[379]: Demoting known real-time threads.
Aug 12 11:56:12 debian rtkit-daemon[379]: Successfully demoted thread 764 of process 762 (n/a).
Aug 12 11:56:12 debian rtkit-daemon[379]: Successfully demoted thread 763 of process 762 (n/a).
Aug 12 11:56:12 debian rtkit-daemon[379]: Successfully demoted thread 762 of process 762 (n/a).
Aug 12 11:56:12 debian rtkit-daemon[379]: Demoted 3 threads.

Last edited by ewaller (2017-08-12 19:05:08)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#5 2017-08-13 15:35:27

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,680
Website

Re: QEMU as a Window Manager Suggestions?

Wild suggestion: start the QEMU command with nohup(1)

I will try some things out myself when I have a moment, sorry for the delay (MotoGP weekend).

Last edited by Head_on_a_Stick (2017-08-13 15:35:42)

Offline

#6 2017-08-19 21:57:50

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: QEMU as a Window Manager Suggestions?

HoaS, So how went the MotoGP insanity? nohup made no difference. sad

In any event, I've not given up on this; this has been a busy week in meat space.  In the mean time, I have changed how I start qemu to no avail.  Here are my new files.  For the case where it goes dormant, I am still logging into a different console and am starting this with WM=debian startx.  I now set up the networking using tunnels and taps.  I set up a DHCP server, create an unpredictable MAC

~/bin/startqemu

#!/bin/bash
USERID=$(whoami)
if [[ $# -lt 1 ]] ; then
   echo "Usage:  startqemu path_to_drive_image additional_parameters_passed_to_qemu ..."
   exit 1
fi

DRIVE=$1
shift

# Get name of newly created TAP device; see https://bbs.archlinux.org/viewtopic.php?pid=1285079#p1285079
precreationg=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)
sudo /usr/bin/ip tuntap add user $USERID mode tap
postcreation=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)

if [[ ! $(ip link | grep br0:) ]]; then
    echo "Adding bridge" 
    sudo sysctl net.ipv4.ip_forward=1
    sudo ip link add name br0 type bridge
    sudo iptables -t nat -A POSTROUTING -o wlo1 -j MASQUERADE                    
    sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    sudo iptables -A FORWARD -i wlo1 -o br0 -j ACCEPT                            

fi

IFACE=$(comm -13 <(echo "$precreationg") <(echo "$postcreation"))
HASH=$(echo $DRIVE | sha256sum)

# Make up a MAC address based upon a hash of the name of the disk drive image.
# the system is sensitive to the first byte.  Rather than figure out the legal
# values, I picked one that worked and made the other 5 unpredictable numbers.

macaddr=78:${HASH:3:2}:${HASH:5:2}:${HASH:7:2}:${HASH:9:2}:${HASH:11:2}
echo "Mac address set to $macaddr"
sudo ip link set br0 up
sudo ip addr add 172.168.1.1/24 dev br0
sudo dnsmasq --interface=br0 --bind-interfaces --dhcp-range=172.168.1.2,172.168.1.10

qemu-system-x86_64 -hda $DRIVE \
                   -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
		   -smp 2 \
		   -m 1024 \
		   -enable-kvm \
		   -soundhw hda \
		   -machine type=pc,accel=kvm \
		   -net nic,macaddr=$macaddr \
		   -net tap,ifname="$IFACE" \
		   $@ 

sudo ip link set dev $IFACE down &> /dev/null
sudo ip tuntap del $IFACE mode tap &> /dev/null

~/.xinitrc

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

setxkbmap -option ctrl:nocaps
autocutsel -fork &
autocutsel -selection PRIMARY -fork &


case $WM in
    openbox)
	exec  openbox-session
	;;
    win7)
	win7 
	;;
    win10)
	win10
	;;
    debian)
	exec debian_fullscreen
	;;
    i3)
	exec i3
	;;
    *)
	exec i3
	;;
esac

Other files remain the same.  So did the behavior.

The really interesting part

It appears that the issue has to do with the video driver.  If I restrict myself to debian and have it do nothing, its display on the output is essentially a static display; except for the clock which updates ones every minute.  If I start qemu running debian, and connect to the monitor via telnet from a urxvt window running in i3wm on the other console, it all works... for a minute.  At the top of the minute, it locks up.  Flipping over to the other console, the display under Debian updates.  Flip back to the i3 console, and the telnet session monitor for qemu works great - until the top of the next minute, at which time it stops displaying the (qemu) prompt.  Flip over to the other console and back, and things work until the top of the next minute,  Run a script on debian that sleeps for some period of time and then display something, same thing...  Things work until the display associated with the qemu emulation is updated.

I changed the startup script to use -vnc for output and ran it in a different log in console.  I connected to it with vncviewer from the i3wm session and it work well.  Really well; I think it has better performance than emulating a video card.

tl;dr:  It appears that qemu running on another console works great; right up to the moment it tries to update its display, at which point it seems to block and freeze until the associated window is brought into focus.   
Comments? Ideas?


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#7 2017-08-19 23:39:18

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,680
Website

Re: QEMU as a Window Manager Suggestions?

ewaller wrote:

HoaS, So how went the MotoGP insanity?

It was awesome, one of the best races ever so far  big_smile

On-topic: I have been able to make no headway with this at all, I think the freezing issue is intrinsic to KVM & agetty(8) (disclaimer: pure supposition).

Ideas?

Try SPICE instead and attach from your i3 desktop:

https://wiki.archlinux.org/index.php/QEMU#SPICE

Not really what you want but the performance is very good, apparently.

Offline

Board footer

Powered by FluxBB