1:52 p.m.
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
3:58 p.m.
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
4:38 p.m.
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
5:12 p.m.
Hello Richard,
I'm using:
> virt-sysprep 1.25.6
I honestly don't remember if the currently installed version is from the
tarball or pulled from the github source... Now that you mention it, I
think it could even be the version with my "hack" to fix virt-sysprep...
Which version are you building? I see there's a:
Would you recommend building that or building from the git repository?
Thanks,
Jon A
On Mon, Nov 25, 2013 at 3:38 PM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
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
5:19 p.m.
On Mon, Nov 25, 2013 at 04:12:40PM -0700, Jon wrote:
Hello Richard,
I'm using:
>> virt-sysprep 1.25.6
I honestly don't remember if the currently installed version is from the
tarball or pulled from the github source... Now that you mention it, I
think it could even be the version with my "hack" to fix virt-sysprep...
Which version are you building?
1.25.8
I see there's a:
libguestfs-1.25.11.tar.gz<http://libguestfs.org/download/1.25-developm...
Would you recommend building that or building from the git repository?
From git is probably your best bet. The README file explains
how to build it.
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
5:24 p.m.
Hello Richard,
Ok, I'll give it a shot.
Thanks!
Jin A
On Nov 25, 2013 4:19 PM, "Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Mon, Nov 25, 2013 at 04:12:40PM -0700, Jon wrote:
> Hello Richard,
>
> I'm using:
>
> >> virt-sysprep 1.25.6
>
> I honestly don't remember if the currently installed version is from the
> tarball or pulled from the github source... Now that you mention it, I
> think it could even be the version with my "hack" to fix virt-sysprep...
>
> Which version are you building?
1.25.8
> I see there's a:
> libguestfs-1.25.11.tar.gz<
http://libguestfs.org/download/1.25-development/libguestfs-1.25.11.tar.gz
>23-Nov-2013
>
> Would you recommend building that or building from the git repository?
From git is probably your best bet. The README file explains
how to build it.
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
5:56 p.m.
Hello Richard,
Well... The good news is I get the same error I was getting previously
[1], so at least it's consistent :)
> libguestfs: trace: add_drive
"libvirt-pool/guestfish_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 = -1 (error)
> rbd: image name must begin with a '/' at guestfs_test.pl line 53.
Prepending a slash to the device name e.g.:
> libguestfs: trace: add_drive
"/libvirt-pool/guestfish_test-os"
"format:raw"
"protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789
192.168.0.40:6789"
does allow me to mount the drive.
This is using:
> virt-sysprep 1.25.11
So I guess ultimately, it really is the same issue rearing it's head.
Thank you for the assistance.
Best Regards,
Jon A
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1026688
On Mon, Nov 25, 2013 at 4:24 PM, Jon <three18ti(a)gmail.com> wrote:
Hello Richard,
Ok, I'll give it a shot.
Thanks!
Jin A
On Nov 25, 2013 4:19 PM, "Richard W.M. Jones" <rjones(a)redhat.com> wrote:
> On Mon, Nov 25, 2013 at 04:12:40PM -0700, Jon wrote:
> > Hello Richard,
> >
> > I'm using:
> >
> > >> virt-sysprep 1.25.6
> >
> > I honestly don't remember if the currently installed version is from the
> > tarball or pulled from the github source... Now that you mention it, I
> > think it could even be the version with my "hack" to fix
virt-sysprep...
> >
> > Which version are you building?
>
> 1.25.8
>
> > I see there's a:
> > libguestfs-1.25.11.tar.gz<
> http://libguestfs.org/download/1.25-development/libguestfs-1.25.11.tar.gz
> >23-Nov-2013
> >
> > Would you recommend building that or building from the git repository?
>
> From git is probably your best bet. The README file explains
> how to build it.
>
> 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
>
2:45 a.m.
* 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
4:59 a.m.
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(a)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
5:08 a.m.
On Tue, Nov 26, 2013 at 03:59:49AM -0700, Jon wrote:
How do you normally deal with that warning?
The warning is just that, so it doesn't really matter at the moment.
However you can configure libguestfs like this if you want to use a
particular binary:
./configure --with-qemu="qemu-system-x86_64"
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...)
x86-64 as a platform supports 32 bit operating systems. So there's no
special KVM emulator required to run 32 bit VMs.
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.
This is a bug in how libguestfs validates the exportname.
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
6:39 a.m.
* Richard W.M. Jones:
On Tue, Nov 26, 2013 at 03:59:49AM -0700, Jon wrote:
> How do you normally deal with that warning?
The warning is just that, so it doesn't really matter at the moment.
However you can configure libguestfs like this if you want to use a
particular binary:
./configure --with-qemu="qemu-system-x86_64"
And that's exactly what I have done in the build script (debian/rules)
for the Debian package.
Cheers,
-Hilko
6:43 a.m.
* Jon:
> 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...
The package in Debian/unstable had release-critical bugs (failed to
build on several architectures) that nobody bothered to fix before
wheezy was released. The package was stuck as 0.47-something forever and
was only recently upgraded to a current version.
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.
Are qemu-system-x86-64 and qemu-img linked against the relevant
libraries (librbd or something) on your system?
Cheers,
-Hilko
3895
days inactive
3896
days old
11 comments
3 participants
participants (3)
-
Hilko Bengen -
Jon -
Richard W.M. Jones