search for: domcapabilities_xml

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

...unch-libvirt.c b/lib/launch-libvirt.c index 864eae314..f2cad9300 100644 --- a/lib/launch-libvirt.c +++ b/lib/launch-libvirt.c @@ -431,7 +431,12 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) if (parse_capabilities (g, capabilities_xml, data) == -1) goto cleanup; - domcapabilities_xml = virConnectGetDomainCapabilities (conn, NULL, NULL, NULL, + domcapabilities_xml = virConnectGetDomainCapabilities (conn, NULL, NULL, +#ifdef MACHINE_TYPE + MACHINE_TYPE, +#else + NULL,...

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

...t_drive_name (params.appliance_index, &params.appliance_dev[7]); - params.enable_svirt = ! is_custom_hv (g); + params.enable_svirt = ! is_custom_hv (g, data); xml = construct_libvirt_xml (g, &params); if (!xml) @@ -873,13 +873,15 @@ parse_domcapabilities (guestfs_h *g, const char *domcapabilities_xml, } static int -is_custom_hv (guestfs_h *g) +is_custom_hv (guestfs_h *g, struct backend_libvirt_data *data) { + if (g->hv && STRNEQ (g->hv, data->default_qemu)) + return 1; #ifdef QEMU - return g->hv && STRNEQ (g->hv, QEMU); -#else - return 1; + if (STRNEQ...