similar to: [PATCH] launch: libvirt: Don't default to using NULL for libvirt connection URI (RHBZ#1045033).

This function was kind of like debug(), except that it didn't check the g->verbose flag and it only worked in the library (it would crash if used after fork). It also wasn't very useful. The sort of boot analysis done by tests/qemu/boot-analysis.c means that timestamping (some) messages is even less interesting than before. Remove it and replace calls with debug() instead. ---

From: "Richard W.M. Jones" <rjones at redhat.com> This commit models libvirt authentication events through the API, adding one new event (GUESTFS_EVENT_LIBVIRT_AUTH) and several new APIs: guestfs_set_libvirt_supported_credentials guestfs_get_libvirt_requested_credentials guestfs_get_libvirt_requested_credential_prompt guestfs_get_libvirt_requested_credential_challenge

On Fri, Nov 07, 2014 at 02:37:06PM +0000, Dan Ryder (daryder) wrote: > Thanks for the info, Richard. > > Hi Dan, > > Any additional information on this? I don't know if Dan B wants to chime in here, but can you try out the following patch? diff --git a/df/domains.c b/df/domains.c index b2d9537..6cbc0f9 100644 --- a/df/domains.c +++ b/df/domains.c @@ -77,7 +77,8 @@

Previously we had assumed that when running as root, libvirt would always run qemu as a non-root user (eg. qemu.qemu), unless you modify a global configuration file (/etc/libvirt/qemu.conf). It turns out there is a little-known feature to make libvirt run qemu as root without modifying any configuration files. We have to add a <seclabel/> element to the appliance XML: <seclabel

Introduce a new struct version with few helper functions for it: this allows to "atomically" represent a version number, without different variables to be used and checked together. Add a initialization function from a libvirt-style version number, and apply it for the qemu and libvirt versions in the direct and libvirt backends. --- src/Makefile.am | 1 +

On Thu, 2018-11-01 at 16:40 +0100, Erik Skultety wrote: > On Wed, Oct 31, 2018 at 05:33:09PM +0100, Martin Kletzander wrote: > > On Wed, Oct 31, 2018 at 09:32:30AM +0100, Andrea Bolognani wrote: > > > On Wed, 2018-10-31 at 10:56 +0900, Minjun Hong wrote: > > > > I searched how to change it but, I only found a bypass adding " LIBVIRT_DEFAULT_URI='xen:///'

On Wed, Oct 31, 2018 at 05:33:09PM +0100, Martin Kletzander wrote: > On Wed, Oct 31, 2018 at 09:32:30AM +0100, Andrea Bolognani wrote: > > On Wed, 2018-10-31 at 10:56 +0900, Minjun Hong wrote: > > > Hi. > > > > > > Thanks to help of this mailing list (especially Jim Fehlig), I have finished setup of libvirt. > > > However, there is something weird. It

Hi. Thanks to help of this mailing list (especially Jim Fehlig), I have finished setup of libvirt. However, there is something weird. It is that I installed libvirt on 5 servers but the default connection of one of them is 'qemu:///' even if those of the others are all 'xen:///'. I searched how to change it but, I only found a bypass adding "

On Wed, Oct 31, 2018 at 09:32:30AM +0100, Andrea Bolognani wrote: >On Wed, 2018-10-31 at 10:56 +0900, Minjun Hong wrote: >> Hi. >> >> Thanks to help of this mailing list (especially Jim Fehlig), I have finished setup of libvirt. >> However, there is something weird. It is that I installed libvirt on 5 servers but >> the default connection of one of them is

Enhance the Libvirt_utils module with libvirt connection objects, and read-only and read-writen open functions for them; adapt the rest of the mini-binding to use these objects, instead of opening + closing libvirt connections every time. This has different improvements: a) a libvirt connection is reused for different API calls, improving the communication with remote (input) servers b)

With modern libvirt, when fetching the XML of a VMware guest libvirt passes us the datacenter path (dcpath). However with older libvirt we had to guess this value, or else the user had to supply it on the command line. This commit removes all the guessing code and the --dcpath parameter (which will now give an error). This requires libvirt >= 1.2.20 for virt-v2v, released Oct 2015. ---

We are going to change <nbdkit-common.h> so it includes <sys/socket.h>. However because this exports connect(2) we need to rename globals called ‘connect’ to avoid a conflict. --- plugins/guestfs/guestfs-plugin.c | 8 ++++---- plugins/libvirt/libvirt-plugin.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/plugins/guestfs/guestfs-plugin.c

Previously the presence of the ‘--vddk <libdir>’ option magically enabled VDDK mode. However we want to introduce other transports for VMware conversions so this wasn't a very clean choice. With this commit you must use ‘-it vddk’ to specify that you want VDDK as a disk transport. The previous ‘--vddk <libdir>’ option has been renamed to ‘--vddk-libdir <libdir>’ to be

On Wed, 2018-10-31 at 10:56 +0900, Minjun Hong wrote: > Hi. > > Thanks to help of this mailing list (especially Jim Fehlig), I have finished setup of libvirt. > However, there is something weird. It is that I installed libvirt on 5 servers but > the default connection of one of them is 'qemu:///' even if those of the others are all 'xen:///'. You probably

Some of the libvirt XMLs for tests refer to a generated phony disk image, and so far the relative path used worked almost by chance. (For each disk, the path to it was ../test-data/etc, and since the overlay pointing to it is stored directly in $LIBGUESTFS_CACHEDIR, which is $buildir/tmp, then the relative path was resolved.) Instead, have configure place the right top-level directory in those

Updates commit f87f254b2bcda09713d908451f29512ec4286626. --- v2v/input_libvirt_xen_ssh.ml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/v2v/input_libvirt_xen_ssh.ml b/v2v/input_libvirt_xen_ssh.ml index a1b1dfa1e..545a8f5da 100644 --- a/v2v/input_libvirt_xen_ssh.ml +++ b/v2v/input_libvirt_xen_ssh.ml @@ -34,16 +34,16 @@ class input_libvirt_xen_ssh password

Don't pass these flags to dozens of functions. --- builder/builder.ml | 47 +++++++++-------- builder/cache.ml | 4 +- builder/cache.mli | 2 +- builder/cmdline.ml | 13 ++--- builder/downloader.ml | 14 +++-- builder/downloader.mli

Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/Makefile.am | 1 + v2v/test-v2v-copy-guest-tools.sh | 87 ++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+) create mode 100755 v2v/test-v2v-copy-guest-tools.sh diff --git a/v2v/Makefile.am b/v2v/Makefile.am index 2312812fb..84667e11d 100644 --- a/v2v/Makefile.am +++ b/v2v/Makefile.am @@

Currently we have a bunch of ad hoc options like --vddk* and --vdsm* (and proposed to add --rhv*) to handle extra parameters for input and output modes/transports. This complicates the command line parsing and also the clarity of the command line (becauseit's not very obvious which options apply to which side of the conversion). Replace these with a general mechanism for handling input and

I still have not found time to fully review the series, but I found out that this patch breaks VDDK. See below. On Thu, 22 Mar 2018 15:24:23 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > Currently we have a bunch of ad hoc options like --vddk* and --vdsm* > (and proposed to add --rhv*) to handle extra parameters for input and > output modes/transports. This