On Thu, Jul 31, 2014 at 03:32:18PM -0700, Zetan Drableg wrote:> Ok - > By the way, I looked into updating out KVM versions. Since we already > have so many KVM servers of this version in production, I can't easily > forklift update everything without much testing. > > exec /usr/libexec/qemu-kvm -s -S "$@" > > export LIBGUESTFS_HV=/root/work/qemu-wrapper > export LIBGUESTFS_BACKEND=direct > > How do I simulate the setup of devices the test tool perform? > Just copy/pasting the qemu-kvm argument list doesn't work. > > I was hoping that LIBGUESTFS_HV would replace usage of > /usr/libexec/qemu-kvm with /root/work/qemu-wrapper, but does not > appear toOK I think the problem is that it's libguestfs 1.20, where the environment variable names are different (check guestfs(3) in your local copy). This should work: export LIBGUESTFS_ATTACH_METHOD=appliance export LIBGUESTFS_QEMU=/root/work/qemu-wrapper There's an additional problem which is you need the wrapper to distinguish between -help and -version tests and the final command. Use a wrapper like this: ---------------------------------------------------------------------- #!/bin/bash - qemu=/usr/libexec/qemu-kvm if ! echo "$@" | grep -sqE -- '-help|-version'; then echo QEMU debugging enabled. debug="-s -S" fi exec $qemu $debug "$@" ---------------------------------------------------------------------- The wrapper must be executable. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Ok now we are getting somewhere! Those old vars did the trick. libguestfs-test-tool launched with qemu-wrapper as expected with the debug port open. Now on to the fun part! (gdb) set architecture i8086 The target architecture is assumed to be i8086 (gdb) break *0x7c00 Breakpoint 1 at 0x7c00 (gdb) target remote :1234 Remote debugging using :1234 0x0000fff0 in ?? () (gdb) cont Continuing. The breakpoint you documented as when the boot sector has been loaded into memory by the BIOS and control is passed to the boot sector. Never hits the breakpoint..... Next steps? Do I need to load a symbol table? Where might I find it? On Fri, Aug 1, 2014 at 12:24 AM, Richard W.M. Jones <rjones@redhat.com> wrote:> On Thu, Jul 31, 2014 at 03:32:18PM -0700, Zetan Drableg wrote: >> Ok - >> By the way, I looked into updating out KVM versions. Since we already >> have so many KVM servers of this version in production, I can't easily >> forklift update everything without much testing. >> >> exec /usr/libexec/qemu-kvm -s -S "$@" >> >> export LIBGUESTFS_HV=/root/work/qemu-wrapper >> export LIBGUESTFS_BACKEND=direct >> >> How do I simulate the setup of devices the test tool perform? >> Just copy/pasting the qemu-kvm argument list doesn't work. >> >> I was hoping that LIBGUESTFS_HV would replace usage of >> /usr/libexec/qemu-kvm with /root/work/qemu-wrapper, but does not >> appear to > > OK I think the problem is that it's libguestfs 1.20, where the > environment variable names are different (check guestfs(3) in your > local copy). This should work: > > export LIBGUESTFS_ATTACH_METHOD=appliance > export LIBGUESTFS_QEMU=/root/work/qemu-wrapper > > There's an additional problem which is you need the wrapper to > distinguish between -help and -version tests and the final command. > Use a wrapper like this: > > ---------------------------------------------------------------------- > #!/bin/bash - > > qemu=/usr/libexec/qemu-kvm > > if ! echo "$@" | grep -sqE -- '-help|-version'; then > echo QEMU debugging enabled. > debug="-s -S" > fi > > exec $qemu $debug "$@" > ---------------------------------------------------------------------- > > The wrapper must be executable. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v
On Fri, Aug 01, 2014 at 07:43:08AM -0700, Zetan Drableg wrote:> Ok now we are getting somewhere! Those old vars did the trick. > libguestfs-test-tool launched with qemu-wrapper as expected with the > debug port open. > Now on to the fun part! > > (gdb) set architecture i8086 > The target architecture is assumed to be i8086 > (gdb) break *0x7c00 > Breakpoint 1 at 0x7c00 > (gdb) target remote :1234 > Remote debugging using :1234 > 0x0000fff0 in ?? () > (gdb) cont > Continuing. > > The breakpoint you documented as when the boot sector has been loaded > into memory by the BIOS and control is passed to the boot sector. > Never hits the breakpoint..... > > Next steps? > > Do I need to load a symbol table? Where might I find it?This is getting very much to the edge of my experience, but yes, you probably do need to load the symbol table, and I know how. First install the kernel-debuginfo package that exactly corresponds to the kernel which is being run inside the guest. You can usually tell which kernel that is by looking at the output of supermin (it's usually the one which has the highest version number out of all of those "picked"). Then in the kernel-debuginfo package, find the 'vmlinux' file, eg: $ rpm -ql kernel-debuginfo | grep vmlinux /usr/lib/debug/lib/modules/3.14.4-200.fc20.x86_64/vmlinux Then you can get gdb to take the symbols from that file using the gdb command: (gdb) symbol-file /path/to/vmlinux Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top