similar to: Re: --with-qemu option in libguestfs

On Fri, Aug 04, 2017 at 10:20:39AM +0000, emlyn.jose@wipro.com wrote: > Hi Richard, > > Thank you for the feedback! > I have been following them and facing the below issue while building the same: > ….. > podwrapper.pl: wrote virt-v2v-test-harness.1 > podwrapper.pl: wrote ../../html/virt-v2v-test-harness.1.html > touch stamp-virt-v2v-test-harness.pod > ocamlfind

Hi Richard, As per your suggestion we removed pango-devel and build was successful. Thank you! After the delivery, our customer reported another error related to virt-resize as below: virt-resize: error: libguestfs error: internal_feature_available: dispatch_incoming_message: unknown procedure number 458, set LIBGUESTFS_PATH to point to the matching libguestfs appliance directory Regards,

On Thu, Oct 05, 2017 at 10:32:09AM +0000, emlyn.jose@wipro.com wrote: > Hi Richard, > > The --with-qemu option description is given as below: > > --with-qemu="bin1 bin2 ..." > set default QEMU binary [default="[qemu-kvm] > qemu-system-<host> qemu"] > > Does specifying this option takes

[Please keep replies on the mailing list so that others can benefit from following the discussion] On Fri, Oct 06, 2017 at 06:04:46AM +0000, emlyn.jose@wipro.com wrote: > > qemu is a hypervisor, qemu-img is a program for manipulating disk > > images. They are very different things, and it makes no sense to > > substitute qemu-img for qemu. > > I do not want to substitute

On Tue, Aug 01, 2017 at 12:55:21PM +0000, emlyn.jose at wipro.com wrote: > Hello Richard, > > I have been following that link to build libguestfs that includes > virt-resize binary. But it is found that the libguetfs is split into > another libguestfs-tools-c which actually provides this virt-resize > binary. In the Fedora packaging we put virt-resize into libguestfs-tools-c,

On Wed, Nov 07, 2018 at 12:32:48PM +0200, Peter Dimitrov wrote: > Thank you, Rich, > This was the issue indeed. export LIBGUESTFS_BACKEND=direct fixed it. > > The next step I tried was to integrate libguestfs in collectd virt plugin > to collect this data automatically. > In this case I'm having an unknown error in add_libvirt_dom() (same with > add_domain) when it's

This worked wonderfully!  What are the odds of getting this upstream in the near future?  I'd rather not build from source in production. # ./run guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_tmpdir "/root/libguestfs/tmp" libguestfs:

On Thursday, 17 August 2017 12:54:19 CEST emlyn.jose@wipro.com wrote: > Hello Richard! > > Another problem came up today while working on it: > > [INFO] >>> Resizing qcow image... > [INFO] >>> Executing: cp AirFrameVirtualized-3.0.76999.qcow2 image.tmp > [INFO] >>> Executing: qemu-img resize -f qcow2 AirFrameVirtualized-3.0.76999.qcow2 10G >

On Tue, Jul 25, 2017 at 01:20:15PM +0000, emlyn.jose@wipro.com wrote: > Hello, > > This is regarding the binary missing from libguestfs built from the source code(v 1.30.3). > Here there are some binaries missing when compared to the libguestfs rpm installed from the rhel6-server repo. > Below are the list of binaries > >From the os rpm

On Thu, Sep 07, 2017 at 10:10:52AM +0000, emlyn.jose@wipro.com wrote: > Hello Richard, > > Attaching a log file just to check if the issue is with the virt-resize binary. > Kindly have a look at the attached log. The error is: virt-resize: error: libguestfs error: internal_feature_available: dispatch_incoming_message: unknown procedure number 458, set which is caused by and can

I have scoured the web and can't find anything on the topic: Is IPv6 supported for remote image targets? For example: guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 Does not work citing the following: libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: create: flags = 0, handle = 0x5560231bdfb0, program =

On Thu, Aug 10, 2017 at 04:49:22AM +0000, emlyn.jose@wipro.com wrote: > Hello Richard! > > Ocaml solved my problem. Thank you so much :) > > There are many unpackaged ocaml files created outside the BUILDROOT. Will removing them harm the working of the package? > > error: Installed (but unpackaged) file(s) found: > /usr/lib64/ocaml/guestfs/META >

Thank you, Rich, This was the issue indeed. export LIBGUESTFS_BACKEND=direct fixed it. The next step I tried was to integrate libguestfs in collectd virt plugin to collect this data automatically. In this case I'm having an unknown error in add_libvirt_dom() (same with add_domain) when it's invoking qemu-img to create overlay image. There is no difference between manual and service

On Wed, Aug 30, 2017 at 01:50:25AM +0000, emlyn.jose@wipro.com wrote: > Hi, > We installed it from the source code. Most likely you've run ‘make install’ at some point and now have multiple copies installed all over the place, which is why binaries and libraries are linked to the wrong versions. I suggest started from scratch (reinstalling your operating system), and NOT running ’make

> That makes no sense because we are supposed to have just forked successfully I just realized libguestfs uses fork. Now we know why qemu-img worked - I launched it with popen. > So it must be something to do with collectd and how it runs programs. > Is it using LD_PRELOAD trickery, or replacing libc, or using seccomp? If I understand the question correctly - it's about how

Hi,Richard: &nbsp; &nbsp; &nbsp; &nbsp;I use&nbsp;/bin/virt-copy-in&nbsp; failed , virt-copy-in&nbsp;&nbsp;have no diff with other nomarl machine(work well ) ,&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; /bin/virt-copy-in: symbol lookup error: /lib64/libguestfs.so.0: undefined symbol: json_string_length&nbsp; &nbsp; &nbsp; &nbsp;here are

On Fri, Mar 29, 2019 at 06:17:17PM -0500, Jonathan Wright wrote: > I have scoured the web and can't find anything on the topic: Is IPv6 > supported for remote image targets? It definitely should work, although I don't know if anyone has tried using the address explicitly (rather than a hostname which resolves to an AAAA record). > For example: > > guestfish --format=raw

On Wed, Jan 08, 2020 at 09:05:55PM +0800, 谢威 wrote: > &gt; libguestfs: trace: disk_create "/tmp/libguestfsHRQGUn/overlay1.qcow2" "qcow2" -1 "backingfile:/var/tmp/.guestfs-0/appliance.d/root" "backingformat:raw" > &gt; libguestfs: command: run: qemu-img > &gt; libguestfs: command: run: \ create > &gt; libguestfs: command: run: \ -f

On Mon, Apr 01, 2019 at 08:45:48AM -0500, Jonathan Wright wrote: > Unfortunately I do need to use the address explicitly as opposed to > hostnames because the source of the data fed here is Ceph's monmap > which returns the addresses explicitly. > > I've tried all the common ways to escape the : in the v6 address to > no avail.  I definitely agree that the problem looks

Thanks Rich for you quick reply. I enabled logs and the program stuck again, here is the call stack and log: Thread 1 (Thread 0x7fac58edc8c0 (LWP 1271)): #0 0x00007fac578fac20 in __poll_nocancel () from /lib64/libc.so.6 #1 0x00007fac56df3c5a in virNetClientIOEventLoop () from /lib64/libvirt.so.0 #2 0x00007fac56df441b in virNetClientSendInternal () from /lib64/libvirt.so.0 #3 0x00007fac56df5843