[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Block-io] qemu virtual machine get stuck during startu
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [Block-io] qemu virtual machine get stuck during startup |
Date: |
Fri, 20 Oct 2017 11:51:56 +0200 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
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.
> >