Re: [Qemu-devel] [Block-io] qemu virtual machine get stuck during startup

[Stefan Hajnoczi]

On Fri, Oct 20, 2017 at 09:51:01AM +0800, Wahaha Huang wrote:
> Sorry for the late reply.
> Unfortunately, when it gets stuck(block at the windows welcome screen),

Have you booted the same disk image with the same QEMU command-line
successfully before?

> there are no any error messages print out, with cpu usage 9%.
> I'm not quite sure whether the QEMU monitor is still work

It sounds like the VM is still running but Windows is not making
progress booting for some reason.

> Here is some more infomation:
> 
> 1. QEMU command-line:
> qemu-system-x86_64 -enable-kvm -full-screen -soundhw hda -soundhw ac97 -m
> 2816 -smp 2,sockets=1,cores=2,threads=1 -vga qxl -localtime -rtc
> clock=vm,base=localtime -net
> nic,addr=0x03,model=virtio,macaddr=C0:B1:A2:83:84:18 -net tap,ifname=b908v
> -device nec-usb-xhci,id=ehci -device nec-usb-xhci,id=ehci2 -boot d -smbios
> type=1,manufacturer=microcloud,product=cloudbox,version=2015,serial=microcloud,uuid=1f8e6f8e-5b74-4780-89c1-464dc1e7f319
> -usbdevice tablet -display gtk -cpu host -drive
> file=/pcvdata/vmtogo/user_images/9cc7-9ebee790f514a6dab92.img,cache=writeback,serial=9cc7-9ebee790f514a6dab92
> -drive
> file=/pcvdata/vmtogo/pri_desk/updbcc7-9ebee790f514a6dab92.img,cache=writeback,snapshot=off,serial=pridisk
> -device virtio-serial,id=ser0 -chardev
> socket,path=/tmp/virtio10280,server,nowait,id=virtio10280 -device
> virtserialport,bus=ser0.0,chardev=virtio10280,name=com.microcloud.0 -device
> virtio-serial,id=ser1 -chardev spicevmc,id=vdagent,name=vdagent -device
> virtserialport,bus=ser1.0,chardev=vdagent,name=com.redhat.spice.0 -chardev
> socket,path=/tmp/monitor10280,server,nowait,id=monitor10280 -mon
> chardev=monitor10280,mode=readline -serial /dev/ttyS0

You may be able to find the root cause by removing QEMU command-line
options that are not essential like -soundhw, -device nec-usb-xhci (and
USB devices), -device virtio-serial (and other options that use it),
etc.

I also noticed your QEMU command redirects the guest serial port to the
host's serial port.  Is this intentional?

> 
> 2. GDB info:
> The 3rd thread missing as mentioned earlier

Can you explain what you mean?

> (gdb) info threads
>   Id   Target Id         Frame
> * 1    LWP 21315 "qemu-system-x86" 0x00007f9a24739c8b in ppoll () from
> /lib/libc.so.6
>   2    LWP 21316 "qemu-system-x86" 0x00007f9a2473fee9 in syscall () from
> /lib/libc.so.6
>   3    LWP 21369 "qemu-system-x86" 0x00007f9a2473b697 in ioctl () from
> /lib/libc.so.6
>   4    LWP 21370 "qemu-system-x86" 0x00007f9a2473b697 in ioctl () from
> /lib/libc.so.6
>   5    LWP 21371 "qemu-system-x86" 0x00007f9a24739b9d in poll () from
> /lib/libc.so.6
>   6    LWP 21373 "threaded-ml" 0x00007f9a24739b9d in poll () from
> /lib/libc.so.6
>   7    LWP 21374 "qemu-system-x86" 0x00007f9a24a11e1d in pthread_cond_wait
> () from /lib/libpthread.so.0
>   8    LWP 21375 "qemu-system-x86" 0x00007f9a24a11e1d in pthread_cond_wait
> () from /lib/libpthread.so.0
> 
> 
> 2017-10-19 21:29 GMT+08:00 Stefan Hajnoczi <address@hidden>:
> 
> > On Thu, Oct 19, 2017 at 05:32:10PM +0800, Wahaha Huang wrote:
> > > Hi there,
> > > I'm a newbie of qemu(2.10.0), when i start a vm from qemu, it sometimes
> > get
> > > stuck,
> >
> > Please post your QEMU command-line and describe the behavior when it
> > gets stuck.
> >
> > Are there any error messages?  Does the QEMU monitor still work?  Is the
> > QEMU process running at 100% CPU?  etc
> >
> > > through gdb debugging, i found aio_worker thread(list below) missing when
> > > vm get stuck,
> > > but i don't know why, does anybody has further idea about this?
> >
> > Worker threads are temporary threads.  If there is no work to do then
> > they terminate.  New worker threads are started as needed.  Therefore
> > you can't assume that a specific number of worker threads exists.
> >
> > > (gdb) info threads
> > > >
> > > >   Id   Target Id         Frame
> > > >
> > > >   1    LWP 25451 "qemu-system-x86" 0x00007fc62081dc8b in ppoll () from
> > > >> /lib/libc.so.6
> > > >
> > > >   2    LWP 25452 "qemu-system-x86" 0x00007fc620823ee9 in syscall ()
> > from
> > > >> /lib/libc.so.6
> > > >
> > > > * 3    LWP 25495 "qemu-system-x86" 0x00007fc620af8e80 in ?? () from
> > > >> /lib/libpthread.so.0
> > > >
> > > >   4    LWP 25496 "qemu-system-x86" 0x00007fc62081f697 in ioctl () from
> > > >> /lib/libc.so.6
> > > >
> > > >   5    LWP 25497 "qemu-system-x86" 0x00007fc62081f697 in ioctl () from
> > > >> /lib/libc.so.6
> > > >
> > > >   6    LWP 25498 "qemu-system-x86" 0x00007fc62081db9d in poll () from
> > > >> /lib/libc.so.6
> > > >
> > > >   7    LWP 25500 "threaded-ml" 0x00007fc62081db9d in poll () from
> > > >> /lib/libc.so.6
> >
> > This looks like PulseAudio.  I suggest disabling audio and checking if
> > the hang still occurs.
> >
> > > >
> > > >   8    LWP 25501 "qemu-system-x86" 0x00007fc620af5e1d in
> > pthread_cond_wait
> > > >> () from /lib/libpthread.so.0
> > > >
> > > >   9    LWP 25502 "qemu-system-x86" 0x00007fc620af5e1d in
> > pthread_cond_wait
> > > >> () from /lib/libpthread.so.0
> > > >
> > > > (gdb) bt
> > > >
> > > > #0  0x00007fc620af8e80 in  () at /lib/libpthread.so.0
> > > >
> > > > #1  0x00007fc620af8f5f in  () at /lib/libpthread.so.0
> > > >
> > > > #2  0x00007fc620af906f in sem_timedwait () at /lib/libpthread.so.0
> > > >
> > > > #3  0x000055b66332e585 in qemu_sem_timedwait (sem=0x55b664e6c868,
> > > >> ms=10000) at util/qemu-thread-posix.c:289
> > > >
> > > > #4  0x000055b6633279b6 in worker_thread (opaque=0x55b664e6c7f0) at
> > > >> util/thread-pool.c:102
> > > >
> > > > #5  0x00007fc620aef767 in  () at /lib/libpthread.so.0
> > > >
> > > > #6  0x00007fc62082985f in clone () at /lib/libc.so.6
> >
> > This is a worker thread waiting for more work to do.  It's normal.
> >