Libguestfs - Nov 2013 - Problem Connecting to RBD images using Sys::Guestfs Perl Module

Hello,

I'm having trouble connecting to rbd images. It seems like somewhere the
name is getting chewed up.  I wonder if this is related to my previous
troubles [1] [2] with rbd images.

I'm trying to add an rbd image, but when I launch the guestfs object I get
an error:
>> libguestfs: trace: launch = -1 (error)
I'm adding a single RBD
>> libguestfs: trace: add_drive "libvirt-pool/build_vm_test-os"
"format:raw" "protocol:rbd" "server:192.168.0.35:6789
192.168.0.2:6789
192.168.0.40:6789"

But it seems like the name is getting chewed up in the call to kvm:
>> -drive
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none
>> disk image
rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none:
Invalid argument

I am able to add non rbd images without an issue.

Any thoughts?

Thanks,
Jon A


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1026688
[2] https://www.redhat.com/archives/libguestfs/2013-November/msg00003.html

Full Debug Output:

libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: create: flags = 0, handle = 0x2e74d90, program = perl
libguestfs: trace: set_trace true
libguestfs: trace: set_trace = 0
libguestfs: trace: add_drive "libvirt-pool/build_vm_test-os"
"format:raw"
"protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789
192.168.0.40:6789"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfshHZEx5
libguestfs: launch: umask=0022
libguestfs: launch: euid=0
libguestfs: command: run: /usr/local/bin/supermin-helper
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ -f checksum
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/local/lib/guestfs/supermin.d
supermin helper [00000ms] whitelist = (not specified)
supermin helper [00000ms] host_cpu = x86_64
supermin helper [00000ms] dtb_wildcard = (not specified)
supermin helper [00000ms] inputs:
supermin helper [00000ms] inputs[0] = /usr/local/lib/guestfs/supermin.d
supermin helper [00000ms] outputs:
supermin helper [00000ms] kernel = (none)
supermin helper [00000ms] dtb = (none)
supermin helper [00000ms] initrd = (none)
supermin helper [00000ms] appliance = (none)
checking modpath /lib/modules/3.11.0-12-generic is a directory
checking modpath /lib/modules/3.8.0-32-generic is a directory
checking modpath /lib/modules/3.11.0-13-generic is a directory
picked kernel vmlinuz-3.11.0-13-generic
supermin helper [00000ms] finished creating kernel
supermin helper [00000ms] visiting /usr/local/lib/guestfs/supermin.d
supermin helper [00000ms] visiting
/usr/local/lib/guestfs/supermin.d/base.img.gz
supermin helper [00000ms] visiting
/usr/local/lib/guestfs/supermin.d/daemon.img.gz
supermin helper [00000ms] visiting
/usr/local/lib/guestfs/supermin.d/hostfiles
supermin helper [00015ms] visiting
/usr/local/lib/guestfs/supermin.d/init.img
supermin helper [00015ms] visiting
/usr/local/lib/guestfs/supermin.d/udev-rules.img
supermin helper [00015ms] adding kernel modules
supermin helper [00050ms] finished creating appliance
libguestfs: checksum of existing appliance:
399c008d1c7f2ca97e64a5c37f3111a9f07c694475e5566e7e7d3b615f8bb079
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: [00054ms] begin testing qemu features
libguestfs: command: run: /usr/bin/kvm
libguestfs: command: run: \ -nographic
libguestfs: command: run: \ -help
W: kvm binary is deprecated, please use qemu-system-x86_64 instead
libguestfs: command: run: /usr/bin/kvm
libguestfs: command: run: \ -nographic
libguestfs: command: run: \ -version
W: kvm binary is deprecated, please use qemu-system-x86_64 instead
libguestfs: qemu version 1.5
libguestfs: command: run: /usr/bin/kvm
libguestfs: command: run: \ -nographic
libguestfs: command: run: \ -machine accel=kvm:tcg
libguestfs: command: run: \ -device ?
libguestfs: [00145ms] finished testing qemu features
[00147ms] /usr/bin/kvm \
    -global virtio-blk-pci.scsi=off \
    -nodefconfig \
    -nodefaults \
    -nographic \
    -machine accel=kvm:tcg \
    -cpu host,+kvmclock \
    -m 500 \
    -no-reboot \
    -no-hpet \
    -kernel /var/tmp/.guestfs-0/kernel.19756 \
    -initrd /var/tmp/.guestfs-0/initrd.19756 \
    -device virtio-scsi-pci,id=scsi \
    -drive
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none
\
    -device scsi-hd,drive=hd0 \
    -drive
file=/var/tmp/.guestfs-0/root.19756,snapshot=on,id=appliance,cache=unsafe,if=none
\
    -device scsi-hd,drive=appliance \
    -device virtio-serial-pci \
    -serial stdio \
    -device sga \
    -chardev socket,path=/tmp/libguestfshHZEx5/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'
W: kvm binary is deprecated, please use qemu-system-x86_64 instead
qemu-system-x86_64: -drive
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none:
could not open disk image
rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none:
Invalid argument
libguestfs: child_cleanup: 0x2e74d90: child process died
libguestfs: sending SIGTERM to process 19861
libguestfs: trace: launch = -1 (error)
guestfs_launch failed, see earlier error messages at guestfs_test.pl line
62.
libguestfs: trace: close
libguestfs: closing guestfs handle 0x2e74d90 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfshHZEx5

On Mon, Nov 25, 2013 at 12:52:21PM -0700, Jon wrote:
> Hello,
> 
> I'm having trouble connecting to rbd images. It seems like somewhere
the
> name is getting chewed up.  I wonder if this is related to my previous
> troubles [1] [2] with rbd images.
> 
> I'm trying to add an rbd image, but when I launch the guestfs object I
get
> an error:
> 
> >> libguestfs: trace: launch = -1 (error)
> 
> I'm adding a single RBD
> >> libguestfs: trace: add_drive
"libvirt-pool/build_vm_test-os"
> "format:raw" "protocol:rbd"
"server:192.168.0.35:6789 192.168.0.2:6789
> 192.168.0.40:6789"
> 
> But it seems like the name is getting chewed up in the call to kvm:
> 
> >> -drive
>
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none
> >> disk image
>
rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none:
> Invalid argument
> 
> I am able to add non rbd images without an issue.
> 
> Any thoughts?
As a general comment, there should be no difference between the API
from C and the API from Perl.  Of course, occasionally we introduce
Perl-specific bugs in the bindings, but these are rarer than you would
think (the Perl bindings are automatically generated, so any bugs
would be systematic, affecting many different calls at once).

[...]
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1026688
> [2] https://www.redhat.com/archives/libguestfs/2013-November/msg00003.html
> 
> Full Debug Output:
> 
> libguestfs: trace: set_verbose true
> libguestfs: trace: set_verbose = 0
> libguestfs: create: flags = 0, handle = 0x2e74d90, program = perl
> libguestfs: trace: set_trace true
> libguestfs: trace: set_trace = 0
> libguestfs: trace: add_drive "libvirt-pool/build_vm_test-os"
"format:raw"
> "protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789
192.168.0.40:6789"
> libguestfs: trace: add_drive = 0
> libguestfs: trace: launch
> libguestfs: trace: get_tmpdir
> libguestfs: trace: get_tmpdir = "/tmp"
> libguestfs: trace: get_backend
> libguestfs: trace: get_backend = "direct"
[...]
>     -drive
>
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none
In this case the export name is getting truncated ...

With the direct backend, the following code is responsible for
constructing the -drive parameter:

https://github.com/libguestfs/libguestfs/blob/master/src/drives.c#L1307

There seems to be something pretty strange going on with the
u.exportname field.  I can't quite understand it at the moment, but it
is certainly a bug.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On Mon, Nov 25, 2013 at 09:58:50PM +0000, Richard W.M. Jones
wrote:
> On Mon, Nov 25, 2013 at 12:52:21PM -0700, Jon wrote:
> > Hello,
> > 
> > I'm having trouble connecting to rbd images. It seems like
somewhere the
> > name is getting chewed up.  I wonder if this is related to my previous
> > troubles [1] [2] with rbd images.
> > 
> > I'm trying to add an rbd image, but when I launch the guestfs
object I get
> > an error:
> > 
> > >> libguestfs: trace: launch = -1 (error)
> > 
> > I'm adding a single RBD
> > >> libguestfs: trace: add_drive
"libvirt-pool/build_vm_test-os"
> > "format:raw" "protocol:rbd"
"server:192.168.0.35:6789 192.168.0.2:6789
> > 192.168.0.40:6789"
> > 
> > But it seems like the name is getting chewed up in the call to kvm:
> > 
> > >> -drive
> >
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none
> > >> disk image
> >
rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none:
> > Invalid argument
> > 
> > I am able to add non rbd images without an issue.
> > 
> > Any thoughts?
> 
> As a general comment, there should be no difference between the API
> from C and the API from Perl.  Of course, occasionally we introduce
> Perl-specific bugs in the bindings, but these are rarer than you would
> think (the Perl bindings are automatically generated, so any bugs
> would be systematic, affecting many different calls at once).
> 
> [...]
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1026688
> > [2]
https://www.redhat.com/archives/libguestfs/2013-November/msg00003.html
> > 
> > Full Debug Output:
> > 
> > libguestfs: trace: set_verbose true
> > libguestfs: trace: set_verbose = 0
> > libguestfs: create: flags = 0, handle = 0x2e74d90, program = perl
> > libguestfs: trace: set_trace true
> > libguestfs: trace: set_trace = 0
> > libguestfs: trace: add_drive "libvirt-pool/build_vm_test-os"
"format:raw"
> > "protocol:rbd" "server:192.168.0.35:6789
192.168.0.2:6789 192.168.0.40:6789"
> > libguestfs: trace: add_drive = 0
> > libguestfs: trace: launch
> > libguestfs: trace: get_tmpdir
> > libguestfs: trace: get_tmpdir = "/tmp"
> > libguestfs: trace: get_backend
> > libguestfs: trace: get_backend = "direct"
> [...]
> >     -drive
> >
file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none
> 
> In this case the export name is getting truncated ...
> 
> With the direct backend, the following code is responsible for
> constructing the -drive parameter:
> 
> https://github.com/libguestfs/libguestfs/blob/master/src/drives.c#L1307
> 
> There seems to be something pretty strange going on with the
> u.exportname field.  I can't quite understand it at the moment, but it
> is certainly a bug.
BTW I am unable to reproduce this with upstream libguestfs.  Which
version are you using?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

* Jon:
> I'm having trouble connecting to rbd images. It seems like somewhere
> the name is getting chewed up.  I wonder if this is related to my
> previous troubles [1] [2] with rbd images.
The "W: kvm binary is deprecated, please use qemu-system-x86_64
instead"
message looks like the one I know from Debian. From the names of the
kernel images, I'm guessing that you're using Ubuntu, am I right?

The ceph package in Debian has been a mess until very recently, so rbd
support was dropped from the qemu pacakges. Possibly Ubuntu just imports
them from Debian and therefore its qemu packages have no rbd support
either.

Cheers,
-Hilko

Hey Hilko,
>> I'm guessing that you're using Ubuntu, am I right?
Pretty good guess. :)

For the time being I'm using 13.10.  I know I've said it previously, 
but
your right, I should include that info so I don't make people have to go
digging.

How do you normally deal with that warning? I typically rename the kvm
binary, then link qemu-system-x86_64 but my concern is that will cause
problems if I want a 32 bit vm... (I don't see a reason to run i386 these
days,  but I _guarntee_ you, I have a customer who /refuses/ to use 64bit
vms...)
>> The ceph package in Debian has been a mess until very recently
Really? I have no problems with ceph. Until I upgraded to 13.10, I was
using the opscode ppa; there are no 13.10 repis I'm the ppa...

Ok... I take that back.... Ceph::RADOS is largely incomplete,  and my C is
*really* rusty, so I've had some trouble extending the library... but other
than that, ceph has been rock solid for me since at least 12.04.
>> support was dropped from the qemu pacakges.
It's funny you should say that. I can't for the life of me get qemu-img
to
create firmat 2 rbd images... but I think that may be a ceph config
problem, not an issue with qemu/kvm.
>> therefore its qemu packages have no rbd support
either.

libvirt has no problem with my rbds. It's just libguestfs that doesn't
like
my rbds... unless I prefix the name of the pool with a "/".

I'm open to suggestions, I do most of my work in Perl with the expectation
my code will run on other platforms, so I'm not married to Ubuntu/debian.

Thanks for your feedback.

Best Regards,
Jon A
On Nov 26, 2013 3:33 AM, "Hilko Bengen"
<bengen@hilluzination.de> wrote:
> * Jon:
>
> > I'm having trouble connecting to rbd images. It seems like
somewhere
> > the name is getting chewed up.  I wonder if this is related to my
> > previous troubles [1] [2] with rbd images.
>
> The "W: kvm binary is deprecated, please use qemu-system-x86_64
instead"
> message looks like the one I know from Debian. From the names of the
> kernel images, I'm guessing that you're using Ubuntu, am I right?
>
> The ceph package in Debian has been a mess until very recently, so rbd
> support was dropped from the qemu pacakges. Possibly Ubuntu just imports
> them from Debian and therefore its qemu packages have no rbd support
> either.
>
> Cheers,
> -Hilko
>