similar to: [PATCH] launch: libvirt: use machine type when querying for domcaps

In case you configure libguestfs with a custom QEMU, e.g.: $ ./configure [...] QEMU=/path/to/qemu then the libvirt backend did not use to override it, launching the appliance with the default QEMU for libvirt. This does not change the manual emulator overriding using set-hv. Pino Toscano (2): launch: libvirt: get default QEMU from domcapabilities launch: libvirt: fix custom hypervisor

Starting with 5.2.0, libvirt has a way to select the firmware by specifying its type, provided configuration files for the firmware are shipped. Currently we start the appliance as UEFI if any of the firmware are found, so instead we can try to just set the firmware type iff: - the libvirt autoselection works - the 'efi' firmware is available The only behaviour change is that the default

Hi, I was asked by Nir and Eyal of the oVirt project on how to detect whether a certain feature is supported by libvirt. As I thought it might be better to document this publically rather than being lost in a private thread I'm posting this to libvirt-users. The specific question will be answered below. --- There are currently two interfaces which allow discovery of libvirts and in turn

Hi, some custom CPU models are reported from virConnectGetDomainCapabilities as usable='yes' on a physical machine while as usable='no' inside a VM running on the same machine. That's not completely surprising. But what surprises me is that those models are still reported from virConnectCompareCPU as supported (VIR_CPU_COMPARE_SUPERSET) in the nested environment and VMs can

Jiri Denemark <jdenemar@redhat.com> writes: > On Fri, Dec 07, 2018 at 11:52:38 +0100, Milan Zamazal wrote: >> Hi, some custom CPU models are reported from >> virConnectGetDomainCapabilities as usable='yes' on a physical machine > >> while as usable='no' inside a VM running on the same machine. That's >> not completely surprising. >>

Previously we used (on arm): -M virt -machine accel=... After this change, we use: -machine virt,accel=... On x86 there is no change. The -M option is an abbreviation for -machine, and we can combine the two options together. (Qemu combines the two options internally, but it's more predictable if we do it ourselves). Upstream qemu has supported the -machine option for over 5 years, and in

Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> --- mlcustomize/inject_virtio_win.ml | 2 +- mlcustomize/inject_virtio_win.mli | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml b/mlcustomize/inject_virtio_win.ml index 8d72c5d..cf078c0 100644 --- a/mlcustomize/inject_virtio_win.ml +++

This type is going to be used as a return value in case we're injecting virtio-scsi block driver during conversion. Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> Acked-by: Laszlo Ersek <lersek at redhat.com> --- mlcustomize/inject_virtio_win.ml | 2 +- mlcustomize/inject_virtio_win.mli | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

Hi, things are progressing slowly, but I feel that eventually I'll be getting there: supermin can be built on all Linux-based architectures that are part of Debian/unstable[1] -- (except for sparc, but I'll ignore that for now.) libguestfs on the other hand currently fails launching the appliance (necessary for running tests) on everything but x86 and mips. Apparently, qemu-system-arm

If "strdup (d->d_name)" fails with "i" > 0, then both "p" and "ret->guestfs_int_dirent_list_val" are non-null pointers, but the latter is no more valid (since "p" is the new realloc'ed buffer). Hence, trying to free both will access to invalid memory. Make sure to free only one of them, "p" if not null or

I am having trouble generating some of my scaffolding. I''m trying to use PostgreSQL as my back-end. Some of my scaffolding generates with no problem but for other parts I get this: Before updating scaffolding from new DB schema, try creating a table for your model The tables do exist. At least I can see them from psql. Here is the SQL I''m using to create my tables: CREATE

On Fri, Dec 07, 2018 at 11:52:38 +0100, Milan Zamazal wrote: > Hi, some custom CPU models are reported from > virConnectGetDomainCapabilities as usable='yes' on a physical machine > while as usable='no' inside a VM running on the same machine. That's > not completely surprising. > > But what surprises me is that those models are still reported from >

Specifically fixes the issue where <script path='vif-bridge'/> would be corrupted rather than removed properly. Makes metadata conversion less generic. --- lib/Sys/VirtV2V/Converter.pm | 144 +++++++++++++++++++++--------------------- 1 files changed, 73 insertions(+), 71 deletions(-) diff --git a/lib/Sys/VirtV2V/Converter.pm b/lib/Sys/VirtV2V/Converter.pm index a6eba45..64a5a46

Make sure to free the backend string after using it. --- src/launch-libvirt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c index 899742f..6f95e98 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -719,6 +719,8 @@ parse_capabilities (guestfs_h *g, const char *capabilities_xml, * appliance VM. */ if

On Tue, Dec 11, 2018 at 10:45:12 +0100, Milan Zamazal wrote: > Jiri Denemark <jdenemar@redhat.com> writes: > > > On Fri, Dec 07, 2018 at 11:52:38 +0100, Milan Zamazal wrote: > >> Hi, some custom CPU models are reported from > >> virConnectGetDomainCapabilities as usable='yes' on a physical machine > > > >> while as usable='no'

Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> --- mlcustomize/inject_virtio_win.ml | 2 +- mlcustomize/inject_virtio_win.mli | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml b/mlcustomize/inject_virtio_win.ml index acb3a93..62f7710 100644 --- a/mlcustomize/inject_virtio_win.ml +++

These patches contain the beginnings of discard (a.k.a. trim or unmap) support. This will allow us to change virt-sparsify to work on disk images in-place (instead of using slow & inefficient copying). The approach used is to add an optional 'discard' parameter to add-drive. It has 3 possible settings: - 'disable' : the default, no discard is done - 'besteffort' :

Dr. David Gilbert pointed out to me that the first line of the qemu -help output includes the qemu version, so we don't need to run qemu -version at all. This saves about 0.04s on the launch time when using the direct backend. --- src/launch-direct.c | 54 +++++++++++++++++++---------------------------------- 1 file changed, 19 insertions(+), 35 deletions(-) diff --git a/src/launch-direct.c

Previously, is_custom_hv() used to compare the QEMU executable found during configure to the hypervisor set to check whether it is a custom one; however, the QEMU found at configure time can be different than what libvirt was configured with. This fixes the libvirt backend when libguestfs is configured with a different QEMU, that now will be specified as emulator overriding the libvirt one. ---

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8