Re: [Libguestfs] Virt-v2v conversion issue

Now, the conversion hangs on the first disk at 54,03/100%, here is the gdb result :

(gdb) t a a bt Thread 2 (Thread 0x7f0f3cea9700 (LWP 9583)): #0 sem_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_timedwait.S:101 #1 0x00007f0f45b765e7 in qemu_sem_timedwait () #2 0x00007f0f45b0750c in worker_thread () #3 0x00007f0f4203bdf3 in start_thread (arg=0x7f0f3cea9700) at pthread_create.c:308 #4 0x00007f0f41d6901d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 1 (Thread 0x7f0f45aa88c0 (LWP 9582)): #0 0x00007f0f41d5eb0f in __GI_ppoll (fds=0x7f0f470d7a00, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56 #1 0x00007f0f45b146db in qemu_poll_ns () #2 0x00007f0f45b15430 in aio_poll () #3 0x00007f0f45b0eedd in bdrv_prwv_co () #4 0x00007f0f45b0efd3 in bdrv_rw_co () #5 0x00007f0f45b05b35 in img_convert () #6 0x00007f0f41c94af5 in __libc_start_main (main=0x7f0f45b01e80 <main>, argc=10, ubp_av=0x7fff19cb3ab8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff19cb3aa8) at libc-start.c:274 #7 0x00007f0f45b022ed in _start () Alain -----Message d'origine----- De : Richard W.M. Jones [mailto:rjones@redhat.com] Envoyé : mardi 14 octobre 2014 22:52 À : VONDRA Alain Cc : libguestfs(a)redhat.com Objet : Re: [Libguestfs] Virt-v2v conversion issue On Tue, Oct 14, 2014 at 03:40:22PM +0000, VONDRA Alain wrote: > Rich, > I've followed your instructions to trace, but I am not very skilful with gdb, maybe I made a mistake : > > (1) As root do: > > echo core.%p > /proc/sys/kernel/core_pattern -> OK > > (2) Before running virt-v2v, do: > > ulimited -c unlimited -> I think it's ulimit -c unlimited -> -> OK > > and you should get a core.* file in the current directory when qemu-img segfaults. Attach that file to gdb to get a stack trace: > > gdb /usr/bin/qemu-img core.XYZ -> Do I need to wait the crash becase I don't have any core ??? Yes, you have to wait for qemu-img to crash before there will be a core dump. If it's not crashing, then connect to qemu-img directly, something like this: gdb /usr/bin/qemu-img `pidof qemu-img` and run this command: > (gdb) t a a bt to show the stack trace in all threads. If qemu-img is consuming CPU then it's probably not hung. I'm still interested to find out why fstrim didn't work. Can you run: guestfish --ro -d unc-srv-qual03 ><fs> run ><fs> part-list /dev/sda ><fs> part-list /dev/sdb ><fs> part-list /dev/sdc ><fs> part-list /dev/sdd (etc) I'd be interested to see if the partitions are unaligned, which is the only reason why fstrim should fail on NTFS. 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