Hi Richard thanks for the info. I took the strace approach and ran into this looping over and over again. Is it failing to get time? timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 0}}) = 0 timer_settime(0x8, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 204443}}) = 0 select(16, [0 6 9 13 15], [], [], {1, 0}) = 2 (in [6 13], left {0, 999998}) read(13, "\1\0\0\0\0\0\0\0", 4096) = 8 read(13, 0x7fffa2ed3f70, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(6, "\0", 512) = 1 read(6, 0x7fffa2ed4d70, 512) = -1 EAGAIN (Resource temporarily unavailable) select(16, [0 6 9 13 15], [], [], {1, 0}) = 1 (in [15], left {0, 999998}) read(15, "\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0"..., 128) = 128 rt_sigaction(SIGALRM, NULL, {0x7f6d8b8d17d0, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7f6d8b211710}, 8) = 0 write(7, "\0", 1) = 1 write(14, "\1\0\0\0\0\0\0\0", 8) = 8 read(15, 0x7fffa2ed4ee0, 128) = -1 EAGAIN (Resource temporarily unavailable) timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 0}}) = 0 timer_settime(0x8, 0, {it_interval={0, 0}, it_value={0, 988758000}}, NULL) = 0 select(16, [0 6 9 13 15], [], [], {1, 0}) = 2 (in [6 13], left {0, 999998}) read(13, "\1\0\0\0\0\0\0\0", 4096) = 8 read(13, 0x7fffa2ed3f70, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(6, "\0", 512) = 1 read(6, 0x7fffa2ed4d70, 512) = -1 EAGAIN (Resource temporarily unavailable) It looks a lot like the bug you filed here. https://bugzilla.redhat.com/show_bug.cgi?id=553689 There are quite a few hits on this trace but nothing real specific. -Zetan On Thu, Jul 31, 2014 at 4:31 AM, Richard W.M. Jones <rjones@redhat.com> wrote:

On Wed, Jul 30, 2014 at 03:58:43PM -0700, Zetan Drableg wrote:

...

[00183ms] /usr/libexec/qemu-kvm \ -global virtio-blk-pci.scsi=off \ -nodefconfig \ -nodefaults \ -nographic \ -machine accel=kvm:tcg \ -cpu host,+kvmclock \ -m 500 \ -no-reboot \ -kernel /var/tmp/.guestfs-0/kernel.47903 \ -initrd /var/tmp/.guestfs-0/initrd.47903 \ -device virtio-scsi-pci,id=scsi \ -drive file=/tmp/libguestfs-test-tool-sda-Iakpwe,cache=none,format =raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/var/tmp/.guestfs-0/root.47903,snapshot=on,id=appliance, if=none,cache=unsafe \ -device scsi-hd,drive=appliance \ -device virtio-serial \ -serial stdio \ -device sga \ -chardev socket,path=/tmp/libguestfspx9994/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm edd=off' \x1b[1;256r\x1b[256;256H\x1b[6n Google, Inc. Serial Graphics Adapter 10/14/11 SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (mockbuild@ ca-build44.us.oracle.com) Fri Oct 14 20:04:36 UTC 2011 Term: 80x24 4 0 SeaBIOS (version seabios-0.6.1.2-28.el6) \x1b[2J

At this point it hangs forever.

These hangs can be tricky to diagnose.

There are a couple of things you can do however:

(1) strace qemu to find out what it is doing, or:

(2) [harder, but much more informative] gdb into the guest to find out where the guest hangs, or:

(3) Take the command line above, and cut it down to try to isolate the problematic options. I would concentrate on the following options as being most likely to cause trouble:

-cpu -machine -kernel -device sga (remove it)

For (1) and (2) you can use a qemu wrapper to modify the qemu command that the test tool runs.

See also:

http://libguestfs.org/guestfs.3.html#qemu-wrappers

http://rwmj.wordpress.com/2011/10/12/tip-debugging-the-early-boot-process-wi...

Rich.

-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html