- Devel - libvirt List Archives

[libvirt] [PATCH] conf: don't ignore <target dev='blah'/> for macvtap interfaces
by Laine Stump 27 Mar '17

27 Mar '17

The parser had been clearing out *all* suggested device names for type='direct' (aka macvtap) interfaces. All of the code implementing macvtap allows for a user-specified device name, so we should allow it. In the case that an interface name starts with "macvtap" or "macvlan" though, we do still clear it out, just as we do with "vnet" (which is the prefix used for automatically generated tap device names), since those are the prefixes for the names we autogenerate for macvtap and macvlan devices. Resolves: https://bugzilla.redhat.com/1335798 --- docs/formatdomain.html.in | 6 +++--- src/conf/domain_conf.c | 6 +++++- src/conf/domain_conf.h | 4 ++++ 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 4a3123e..8a2294f 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5125,9 +5125,9 @@ qemu-kvm -net nic,model=? /dev/null If no target is specified, certain hypervisors will automatically generate a name for the created tun device. This name can be manually specified, however the name should not - start with either 'vnet' or 'vif', which are prefixes - reserved by libvirt and certain hypervisors. Manually specified - targets using these prefixes may be ignored. + start with either 'vnet', 'vif', 'macvtap', or 'macvlan', + which are prefixes reserved by libvirt and certain hypervisors. + Manually specified targets using these prefixes may be ignored. diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 2139ab0..4b80018 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -9826,8 +9826,12 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, def->data.direct.linkdev = dev; dev = NULL; - if (flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) + if (ifname && + flags & VIR_DOMAIN_DEF_PARSE_INACTIVE && + (STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX) || + STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX))) { VIR_FREE(ifname); + } break; diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 8e6d874..38a15f1 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1033,6 +1033,10 @@ struct _virDomainNetDef { * by libvirt, and cannot be used for a persistent network name. */ # define VIR_NET_GENERATED_PREFIX "vnet" +/* except to macvtap/macvlan interfaces, which start with "macv(tap|lan) */ +# define VIR_NET_GENERATED_MACVTAP_PREFIX "macvtap" +# define VIR_NET_GENERATED_MACVLAN_PREFIX "macvlan" + typedef enum { VIR_DOMAIN_CHR_DEVICE_STATE_DEFAULT = 0, VIR_DOMAIN_CHR_DEVICE_STATE_CONNECTED, -- 2.9.3

2 1

[libvirt] Question about qemuDomainLogContextNew()
by Feng Feng24 Liu 27 Mar '17

27 Mar '17

Hi, Dear all I have a question, and need your help. 　　I want to output some log message to "/var/log/libvirt/qemu/instance-xxxxxx" when guest kernel crashed, so I add following the code: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> static int qemuProcessHandleGuestPanic(qemuMonitorPtr mon ATTRIBUTE_UNUSED, virDomainObjPtr vm, void *opaque) { ...... + qemuDomainLogContextPtr logCtxt = NULL; + if (!(logCtxt = qemuDomainLogContextNew(driver, vm, QEMU_DOMAIN_LOG_CONTEXT_MODE_START))){ + VIR_WARN("Unable to open domainlog"); + goto cleanup; + } ...... } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< But this code cannot get the logCtxt, logCtxt = qemuDomainLogContextNew(driver, vm, QEMU_DOMAIN_LOG_CONTEXT_MODE_START) always return NULL, so I CANNOT write message to log file. Really Need your help, Thanks! Thanks Feng

1 0

[libvirt] [PATCH 0/2] Fix possible use-after-free when sending event message
by John Ferlan 27 Mar '17

27 Mar '17

Rework patches/logic most recently posted here: https://www.redhat.com/archives/libvir-list/2017-March/msg00072.html John Ferlan (2): daemon: Rework remoteClientFreeFunc cleanup loops into C macro remote: Fix possible use-after-free when sending event message daemon/remote.c | 158 +++++++++++++++++++------------------------------------- 1 file changed, 52 insertions(+), 106 deletions(-) -- 2.9.3

2 3

[libvirt] [PATCH v4 00/10] Add TLS support for migration
by John Ferlan 26 Mar '17

26 Mar '17

v3: http://www.redhat.com/archives/libvir-list/2017-March/msg00878.html Changes from v1 Patch 1: Fix the (false); to (0) Patch 2: New to adjust the other (false); in qemu_conf.c Patch 3: Alter the text slightly - also found that the client parameters are only required if *tls_x509_verify = 1, so adjust the descriptions to reflect that Patch 4: Alter the vnc_* and chardev_* descriptions to match the migrate_* Patch 5: Previous patch 3, ACK'd Patch 6: Previous patch 4, altered comments Patch 7: Previous patch 5, fixed commit message Patch 8: Previous patch 6, multiple changes: - Reduced verbosity of comments - Rework the ResetTLS logic (combined code, fetched tls-creds if necessary again) - Add the qemuProcessRecoverMigrationIn call to ResetTLS in the FINISH3 stage Patch 9: Previous patch 7, alter based on patch 7 adjustments vis-a-vis ResetTLS Patch 10: Previous patch 8, alter text of description to include "migrate" All changes were tested in my nested virt environment... A virsh qemu-monitor-command $DOM '{"execute":"query-migrate-parameters"}' after the migrations were completed (back and forth) returned "" for tls-creds and tls-hostname for each hostname (incoming and outgoing tests). John Ferlan (10): qemu: Create #define for TLS configuration setup. qemu: Replace macro usage of (false); with just (0) conf: Introduce migrate_tls_x509_cert_dir qemu: Update the TLS client verify descriptions for vnc and chardev Add new migration flag VIR_MIGRATE_TLS qemu: Add TLS params to _qemuMonitorMigrationParams qemu: Add job for qemuDomain{Add|Del}TLSObjects qemu: Set up the migration TLS objects for target qemu: Set up the migration TLS objects for source docs: Add news entry for Migration using TLS docs/news.xml | 8 + include/libvirt/libvirt-domain.h | 8 + src/qemu/libvirtd_qemu.aug | 5 + src/qemu/qemu.conf | 63 ++++++- src/qemu/qemu_conf.c | 47 +++-- src/qemu/qemu_conf.h | 4 + src/qemu/qemu_domain.c | 7 +- src/qemu/qemu_domain.h | 91 ++++++---- src/qemu/qemu_driver.c | 4 +- src/qemu/qemu_hotplug.c | 24 ++- src/qemu/qemu_hotplug.h | 2 + src/qemu/qemu_migration.c | 363 ++++++++++++++++++++++++++++++++++++- src/qemu/qemu_migration.h | 16 +- src/qemu/qemu_monitor.c | 11 +- src/qemu/qemu_monitor.h | 5 + src/qemu/qemu_monitor_json.c | 21 +++ src/qemu/qemu_process.c | 3 + src/qemu/test_libvirtd_qemu.aug.in | 3 + tests/qemumonitorjsontest.c | 25 ++- tools/virsh-domain.c | 7 + 20 files changed, 641 insertions(+), 76 deletions(-) -- 2.9.3

3 21

[libvirt] [PATCH 1/2] bhyve: helper function to probe hypervisor caps
by Roman Bogorodskiy 26 Mar '17

26 Mar '17

There are a number of functions in bhyve_capabilities.c that probe hypervisor capabilities by executing the bhyve(1) binary with the specific device arugment, checking error message (if any) and setting proper capability bit. As those are extremely similar, move this logic into a helper function and convert existing functions to use that. --- src/bhyve/bhyve_capabilities.c | 122 +++++++++++++++++------------------------ 1 file changed, 49 insertions(+), 73 deletions(-) diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c index 4bf1d84fa..f72fdea41 100644 --- a/src/bhyve/bhyve_capabilities.c +++ b/src/bhyve/bhyve_capabilities.c @@ -193,121 +193,97 @@ virBhyveProbeGrubCaps(virBhyveGrubCapsFlags *caps) } static int -bhyveProbeCapsRTC_UTC(unsigned int *caps, char *binary) +bhyveProbeCapsDeviceHelper(unsigned int *caps, + char *binary, + const char *bus, + const char *device, + const char *errormsg, + unsigned int flag) { - char *help; + char *error; virCommandPtr cmd = NULL; - int ret = 0, exit; + int ret = -1, exit; cmd = virCommandNew(binary); - virCommandAddArg(cmd, "-h"); - virCommandSetErrorBuffer(cmd, &help); - if (virCommandRun(cmd, &exit) < 0) { - ret = -1; - goto out; - } + virCommandAddArgList(cmd, bus, device, NULL); + virCommandSetErrorBuffer(cmd, &error); + if (virCommandRun(cmd, &exit) < 0) + goto cleanup; - if (strstr(help, "-u:") != NULL) - *caps |= BHYVE_CAP_RTC_UTC; + if (strstr(error, errormsg) == NULL) + *caps |= flag; - out: - VIR_FREE(help); + ret = 0; + cleanup: + VIR_FREE(error); virCommandFree(cmd); return ret; } static int -bhyveProbeCapsAHCI32Slot(unsigned int *caps, char *binary) +bhyveProbeCapsRTC_UTC(unsigned int *caps, char *binary) { - char *error; + char *help; virCommandPtr cmd = NULL; int ret = 0, exit; cmd = virCommandNew(binary); - virCommandAddArgList(cmd, "-s", "0,ahci", NULL); - virCommandSetErrorBuffer(cmd, &error); + virCommandAddArg(cmd, "-h"); + virCommandSetErrorBuffer(cmd, &help); if (virCommandRun(cmd, &exit) < 0) { ret = -1; goto out; } - if (strstr(error, "pci slot 0:0: unknown device \"ahci\"") == NULL) - *caps |= BHYVE_CAP_AHCI32SLOT; + if (strstr(help, "-u:") != NULL) + *caps |= BHYVE_CAP_RTC_UTC; out: - VIR_FREE(error); + VIR_FREE(help); virCommandFree(cmd); return ret; } static int -bhyveProbeCapsNetE1000(unsigned int *caps, char *binary) +bhyveProbeCapsAHCI32Slot(unsigned int *caps, char *binary) { - char *error; - virCommandPtr cmd = NULL; - int ret = -1, exit; - - cmd = virCommandNew(binary); - virCommandAddArgList(cmd, "-s", "0,e1000", NULL); - virCommandSetErrorBuffer(cmd, &error); - if (virCommandRun(cmd, &exit) < 0) - goto cleanup; + return bhyveProbeCapsDeviceHelper(caps, binary, + "-s", + "0,ahci", + "pci slot 0:0: unknown device \"ahci\"", + BHYVE_CAP_AHCI32SLOT); +} - if (strstr(error, "pci slot 0:0: unknown device \"e1000\"") == NULL) - *caps |= BHYVE_CAP_NET_E1000; - ret = 0; - cleanup: - VIR_FREE(error); - virCommandFree(cmd); - return ret; +static int +bhyveProbeCapsNetE1000(unsigned int *caps, char *binary) +{ + return bhyveProbeCapsDeviceHelper(caps, binary, + "-s", + "0,e1000", + "pci slot 0:0: unknown device \"e1000\"", + BHYVE_CAP_NET_E1000); } static int bhyveProbeCapsLPC_Bootrom(unsigned int *caps, char *binary) { - char *error; - virCommandPtr cmd = NULL; - int ret = -1, exit; - - cmd = virCommandNew(binary); - virCommandAddArgList(cmd, "-l", "bootrom", NULL); - virCommandSetErrorBuffer(cmd, &error); - if (virCommandRun(cmd, &exit) < 0) - goto cleanup; - - if (strstr(error, "bhyve: invalid lpc device configuration 'bootrom'") == NULL) - *caps |= BHYVE_CAP_LPC_BOOTROM; - - ret = 0; - cleanup: - VIR_FREE(error); - virCommandFree(cmd); - return ret; + return bhyveProbeCapsDeviceHelper(caps, binary, + "-l", + "bootrom", + "bhyve: invalid lpc device configuration 'bootrom'", + BHYVE_CAP_LPC_BOOTROM); } static int bhyveProbeCapsFramebuffer(unsigned int *caps, char *binary) { - char *error; - virCommandPtr cmd = NULL; - int ret = -1, exit; - - cmd = virCommandNew(binary); - virCommandAddArgList(cmd, "-s", "0,fbuf", NULL); - virCommandSetErrorBuffer(cmd, &error); - if (virCommandRun(cmd, &exit) < 0) - goto cleanup; - - if (strstr(error, "pci slot 0:0: unknown device \"fbuf\"") == NULL) - *caps |= BHYVE_CAP_FBUF; - - ret = 0; - cleanup: - VIR_FREE(error); - virCommandFree(cmd); - return ret; + return bhyveProbeCapsDeviceHelper(caps, binary, + "-s", + "0,fbuf", + "pci slot 0:0: unknown device \"fbuf\"", + BHYVE_CAP_FBUF); } int -- 2.11.0

2 4

[libvirt] [PATCH] domaincapstest: add bhyve caps test
by Roman Bogorodskiy 26 Mar '17

26 Mar '17

* Extract filling bhyve capabilities from virBhyveDomainCapsBuild() into a new function virBhyveDomainCapsFill() to make testing easier by not having to mock firmware directory listing and hypervisor capabilities probing * Also, just presence of the firmware files is not sufficient to enable os.loader.supported, hypervisor should support UEFI boot too * Add tests to domaincapstest for the main caps possible flows: - when UEFI bootrom is supported - when video (fbus) is supported - neither of above is supported --- src/bhyve/bhyve_capabilities.c | 72 +++++++++++++++-------- src/bhyve/bhyve_capabilities.h | 3 + tests/Makefile.am | 4 ++ tests/domaincapsschemadata/bhyve_basic.x86_64.xml | 32 ++++++++++ tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml | 49 +++++++++++++++ tests/domaincapsschemadata/bhyve_uefi.x86_64.xml | 41 +++++++++++++ tests/domaincapstest.c | 65 ++++++++++++++++++++ 7 files changed, 242 insertions(+), 24 deletions(-) create mode 100644 tests/domaincapsschemadata/bhyve_basic.x86_64.xml create mode 100644 tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml create mode 100644 tests/domaincapsschemadata/bhyve_uefi.x86_64.xml diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c index 4bf1d84fa..6f8be45c4 100644 --- a/src/bhyve/bhyve_capabilities.c +++ b/src/bhyve/bhyve_capabilities.c @@ -87,6 +87,44 @@ virBhyveCapsBuild(void) return NULL; } +int +virBhyveDomainCapsFill(virDomainCapsPtr caps, + unsigned int bhyvecaps, + virDomainCapsStringValuesPtr firmwares) +{ + caps->disk.supported = true; + VIR_DOMAIN_CAPS_ENUM_SET(caps->disk.diskDevice, + VIR_DOMAIN_DISK_DEVICE_DISK, + VIR_DOMAIN_DISK_DEVICE_CDROM); + + VIR_DOMAIN_CAPS_ENUM_SET(caps->disk.bus, + VIR_DOMAIN_DISK_BUS_SATA, + VIR_DOMAIN_DISK_BUS_VIRTIO); + + caps->os.supported = true; + + if (bhyvecaps & BHYVE_CAP_LPC_BOOTROM) { + caps->os.loader.supported = true; + VIR_DOMAIN_CAPS_ENUM_SET(caps->os.loader.type, + VIR_DOMAIN_LOADER_TYPE_PFLASH); + VIR_DOMAIN_CAPS_ENUM_SET(caps->os.loader.readonly, + VIR_TRISTATE_BOOL_YES); + + caps->os.loader.values.values = firmwares->values; + caps->os.loader.values.nvalues = firmwares->nvalues; + } + + + if (bhyvecaps & BHYVE_CAP_FBUF) { + caps->graphics.supported = true; + caps->video.supported = true; + VIR_DOMAIN_CAPS_ENUM_SET(caps->graphics.type, VIR_DOMAIN_GRAPHICS_TYPE_VNC); + VIR_DOMAIN_CAPS_ENUM_SET(caps->video.modelType, VIR_DOMAIN_VIDEO_TYPE_GOP); + } + return 0; +} + + virDomainCapsPtr virBhyveDomainCapsBuild(bhyveConnPtr conn, const char *emulatorbin, @@ -101,6 +139,7 @@ virBhyveDomainCapsBuild(bhyveConnPtr conn, size_t firmwares_alloc = 0; virBhyveDriverConfigPtr cfg = virBhyveDriverGetConfig(conn); const char *firmware_dir = cfg->firmwareDir; + virDomainCapsStringValuesPtr firmwares = NULL; if (!(caps = virDomainCapsNew(emulatorbin, machine, arch, virttype))) goto cleanup; @@ -111,46 +150,31 @@ virBhyveDomainCapsBuild(bhyveConnPtr conn, goto cleanup; } - caps->os.supported = true; - caps->os.loader.supported = true; - VIR_DOMAIN_CAPS_ENUM_SET(caps->os.loader.type, - VIR_DOMAIN_LOADER_TYPE_PFLASH); - VIR_DOMAIN_CAPS_ENUM_SET(caps->os.loader.readonly, - VIR_TRISTATE_BOOL_YES); + if (VIR_ALLOC(firmwares) < 0) + goto cleanup; if (virDirOpenIfExists(&dir, firmware_dir) > 0) { while ((virDirRead(dir, &entry, firmware_dir)) > 0) { - if (VIR_RESIZE_N(caps->os.loader.values.values, - firmwares_alloc, caps->os.loader.values.nvalues, 2) < 0) + if (VIR_RESIZE_N(firmwares->values, + firmwares_alloc, firmwares->nvalues, 1) < 0) goto cleanup; if (virAsprintf( - &caps->os.loader.values.values[caps->os.loader.values.nvalues], + &firmwares->values[firmwares->nvalues], "%s/%s", firmware_dir, entry->d_name) < 0) goto cleanup; - caps->os.loader.values.nvalues++; + firmwares->nvalues++; } } else { VIR_WARN("Cannot open firmware directory %s", firmware_dir); } - caps->disk.supported = true; - VIR_DOMAIN_CAPS_ENUM_SET(caps->disk.diskDevice, - VIR_DOMAIN_DISK_DEVICE_DISK, - VIR_DOMAIN_DISK_DEVICE_CDROM); - - VIR_DOMAIN_CAPS_ENUM_SET(caps->disk.bus, - VIR_DOMAIN_DISK_BUS_SATA, - VIR_DOMAIN_DISK_BUS_VIRTIO); + if (virBhyveDomainCapsFill(caps, bhyve_caps, firmwares) < 0) + goto cleanup; - if (bhyve_caps & BHYVE_CAP_FBUF) { - caps->graphics.supported = true; - caps->video.supported = true; - VIR_DOMAIN_CAPS_ENUM_SET(caps->graphics.type, VIR_DOMAIN_GRAPHICS_TYPE_VNC); - VIR_DOMAIN_CAPS_ENUM_SET(caps->video.modelType, VIR_DOMAIN_VIDEO_TYPE_GOP); - } cleanup: + VIR_FREE(firmwares); VIR_DIR_CLOSE(dir); virObjectUnref(cfg); return caps; diff --git a/src/bhyve/bhyve_capabilities.h b/src/bhyve/bhyve_capabilities.h index 3db4f1b88..194061fde 100644 --- a/src/bhyve/bhyve_capabilities.h +++ b/src/bhyve/bhyve_capabilities.h @@ -28,6 +28,9 @@ # include "bhyve_utils.h" virCapsPtr virBhyveCapsBuild(void); +int virBhyveDomainCapsFill(virDomainCapsPtr caps, + unsigned int bhyvecaps, + virDomainCapsStringValuesPtr firmwares); virDomainCapsPtr virBhyveDomainCapsBuild(bhyveConnPtr, const char *emulatorbin, const char *machine, diff --git a/tests/Makefile.am b/tests/Makefile.am index af69a3a84..d4eedaf17 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -964,6 +964,10 @@ domaincapstest_SOURCES += testutilsxen.c testutilsxen.h domaincapstest_LDADD += ../src/libvirt_driver_libxl_impl.la $(GNULIB_LIBS) endif WITH_LIBXL +if WITH_BHYVE +domaincapstest_LDADD += ../src/libvirt_driver_bhyve_impl.la $(GNULIB_LIBS) +endif WITH_BHYVE + virnetmessagetest_SOURCES = \ virnetmessagetest.c testutils.h testutils.c virnetmessagetest_CFLAGS = $(XDR_CFLAGS) $(AM_CFLAGS) diff --git a/tests/domaincapsschemadata/bhyve_basic.x86_64.xml b/tests/domaincapsschemadata/bhyve_basic.x86_64.xml new file mode 100644 index 000000000..f6dfabed2 --- /dev/null +++ b/tests/domaincapsschemadata/bhyve_basic.x86_64.xml @@ -0,0 +1,32 @@ +<domainCapabilities> + <path>/usr/sbin/bhyve</path> + <domain>bhyve</domain> + <machine>(null)</machine> + <arch>x86_64</arch> + <os supported='yes'> + <loader supported='no'/> + </os> + <cpu> + <mode name='host-passthrough' supported='no'/> + <mode name='host-model' supported='no'/> + <mode name='custom' supported='no'/> + </cpu> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + </enum> + <enum name='bus'> + <value>virtio</value> + <value>sata</value> + </enum> + </disk> + <graphics supported='no'/> + <video supported='no'/> + <hostdev supported='no'/> + </devices> + <features> + <gic supported='no'/> + </features> +</domainCapabilities> diff --git a/tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml b/tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml new file mode 100644 index 000000000..6fec72c89 --- /dev/null +++ b/tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml @@ -0,0 +1,49 @@ +<domainCapabilities> + <path>/usr/sbin/bhyve</path> + <domain>bhyve</domain> + <machine>(null)</machine> + <arch>x86_64</arch> + <os supported='yes'> + <loader supported='yes'> + <value>/foo/bar</value> + <value>/foo/baz</value> + <enum name='type'> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + </enum> + </loader> + </os> + <cpu> + <mode name='host-passthrough' supported='no'/> + <mode name='host-model' supported='no'/> + <mode name='custom' supported='no'/> + </cpu> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + </enum> + <enum name='bus'> + <value>virtio</value> + <value>sata</value> + </enum> + </disk> + <graphics supported='yes'> + <enum name='type'> + <value>vnc</value> + </enum> + </graphics> + <video supported='yes'> + <enum name='modelType'> + <value>gop</value> + </enum> + </video> + <hostdev supported='no'/> + </devices> + <features> + <gic supported='no'/> + </features> +</domainCapabilities> diff --git a/tests/domaincapsschemadata/bhyve_uefi.x86_64.xml b/tests/domaincapsschemadata/bhyve_uefi.x86_64.xml new file mode 100644 index 000000000..c0b5c161b --- /dev/null +++ b/tests/domaincapsschemadata/bhyve_uefi.x86_64.xml @@ -0,0 +1,41 @@ +<domainCapabilities> + <path>/usr/sbin/bhyve</path> + <domain>bhyve</domain> + <machine>(null)</machine> + <arch>x86_64</arch> + <os supported='yes'> + <loader supported='yes'> + <value>/foo/bar</value> + <value>/foo/baz</value> + <enum name='type'> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + </enum> + </loader> + </os> + <cpu> + <mode name='host-passthrough' supported='no'/> + <mode name='host-model' supported='no'/> + <mode name='custom' supported='no'/> + </cpu> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + </enum> + <enum name='bus'> + <value>virtio</value> + <value>sata</value> + </enum> + </disk> + <graphics supported='no'/> + <video supported='no'/> + <hostdev supported='no'/> + </devices> + <features> + <gic supported='no'/> + </features> +</domainCapabilities> diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c index a4bc8d6d0..c61a5c05f 100644 --- a/tests/domaincapstest.c +++ b/tests/domaincapstest.c @@ -273,12 +273,37 @@ fillXenCaps(virDomainCapsPtr domCaps) } #endif /* WITH_LIBXL */ +#ifdef WITH_BHYVE +# include "bhyve/bhyve_capabilities.h" + +static int +fillBhyveCaps(virDomainCapsPtr domCaps, unsigned int *bhyve_caps) +{ + virDomainCapsStringValuesPtr firmwares = NULL; + int ret = -1; + + if (VIR_ALLOC(firmwares) < 0) + return -1; + + if (fillStringValues(firmwares, "/foo/bar", "/foo/baz", NULL) < 0) + goto cleanup; + + if (virBhyveDomainCapsFill(domCaps, *bhyve_caps, firmwares) < 0) + goto cleanup; + + ret = 0; + cleanup: + VIR_FREE(firmwares); + return ret; +} +#endif /* WITH_BHYVE */ enum testCapsType { CAPS_NONE, CAPS_ALL, CAPS_QEMU, CAPS_LIBXL, + CAPS_BHYVE, }; struct testData { @@ -333,6 +358,12 @@ test_virDomainCapsFormat(const void *opaque) goto cleanup; #endif break; + case CAPS_BHYVE: +#if WITH_BHYVE + if (fillBhyveCaps(domCaps, data->capsOpaque) < 0) + goto cleanup; +#endif + break; } if (!(domCapsXML = virDomainCapsFormat(domCaps))) @@ -354,6 +385,10 @@ mymain(void) { int ret = 0; +#if WITH_BHYVE + unsigned int bhyve_caps = 0; +#endif + #if WITH_QEMU virQEMUDriverConfigPtr cfg = virQEMUDriverConfigNew(false); @@ -419,6 +454,26 @@ mymain(void) DO_TEST("full", "/bin/emulatorbin", "my-machine-type", "x86_64", VIR_DOMAIN_VIRT_KVM, CAPS_ALL); +#define DO_TEST_BHYVE(Name, Emulator, BhyveCaps, Type) \ + do { \ + char *name = NULL; \ + if (virAsprintf(&name, "bhyve_%s.x86_64", Name) < 0) { \ + ret = -1; \ + break; \ + } \ + struct testData data = { \ + .name = name, \ + .emulator = Emulator, \ + .arch = "x86_64", \ + .type = Type, \ + .capsType = CAPS_BHYVE, \ + .capsOpaque = BhyveCaps, \ + }; \ + if (virTestRun(name, test_virDomainCapsFormat, &data) < 0) \ + ret = -1; \ + VIR_FREE(name); \ + } while (0) + #if WITH_QEMU DO_TEST_QEMU("1.7.0", "caps_1.7.0", @@ -488,6 +543,16 @@ mymain(void) #endif /* WITH_LIBXL */ +#if WITH_BHYVE + DO_TEST_BHYVE("basic", "/usr/sbin/bhyve", &bhyve_caps, VIR_DOMAIN_VIRT_BHYVE); + + bhyve_caps |= BHYVE_CAP_LPC_BOOTROM; + DO_TEST_BHYVE("uefi", "/usr/sbin/bhyve", &bhyve_caps, VIR_DOMAIN_VIRT_BHYVE); + + bhyve_caps |= BHYVE_CAP_FBUF; + DO_TEST_BHYVE("fbuf", "/usr/sbin/bhyve", &bhyve_caps, VIR_DOMAIN_VIRT_BHYVE); +#endif /* WITH_BHYVE */ + return ret; } -- 2.11.0

2 2

[libvirt] [PATCH] domain_capabilities: Don't report machine type for bhyve
by Michal Privoznik 26 Mar '17

26 Mar '17

For some drivers the domain's machine type makes no sense. They just don't use it. A great example is bhyve driver. Therefore it makes very less sense to report machine in domain capabilities XML. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/formatdomaincaps.html.in | 3 ++- src/conf/domain_capabilities.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 648e3d481..007cab62d 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -70,7 +70,8 @@ <dt><code>machine</code></dt> <dd>The domain's <a href="formatdomain.html#elementsOSBIOS">machine - type</a>.</dd> + type</a>. Since not every hypervisor has a sense of machine types + this element might be omitted in such drivers.</dd> <dt><code>arch</code></dt> <dd>The domain's <a href="formatdomain.html#elementsOSBIOS"> diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c index bb6742359..7a3d2e6fb 100644 --- a/src/conf/domain_capabilities.c +++ b/src/conf/domain_capabilities.c @@ -527,7 +527,8 @@ virDomainCapsFormatInternal(virBufferPtr buf, virBufferEscapeString(buf, "<path>%s</path>\n", caps->path); virBufferAsprintf(buf, "<domain>%s</domain>\n", virttype_str); - virBufferAsprintf(buf, "<machine>%s</machine>\n", caps->machine); + if (caps->machine) + virBufferAsprintf(buf, "<machine>%s</machine>\n", caps->machine); virBufferAsprintf(buf, "<arch>%s</arch>\n", arch_str); if (caps->maxvcpus) -- 2.11.0

2 5

[libvirt] [PATCH] schema: domaincaps: make machine element optional
by Roman Bogorodskiy 26 Mar '17

26 Mar '17

Commit df769041c made the 'machine' element in domaincaps optional. Update the schema to reflect that. --- Pushed as trivial as per https://www.redhat.com/archives/libvir-list/2017-March/msg01239.html docs/schemas/domaincaps.rng | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng index 20cbc4e94..39053181e 100644 --- a/docs/schemas/domaincaps.rng +++ b/docs/schemas/domaincaps.rng @@ -17,9 +17,11 @@ <element name='domain'> <text/> </element> - <element name='machine'> - <text/> - </element> + <optional> + <element name='machine'> + <text/> + </element> + </optional> <element name='arch'> <text/> </element> -- 2.11.0

1 0

[libvirt] [PATCH] qemu: fix build with clang
by Roman Bogorodskiy 26 Mar '17

26 Mar '17

qemuMigrationResetTLS() does not initialize 'ret' by default, so when it jumps to 'cleanup' on error, the 'ret' variable will be uninitialized, which clang complains about. Set it to '-1' by default. --- Pushed under the build-breaker rule. src/qemu/qemu_migration.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index d91279ec6..a69e8784a 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -3815,7 +3815,7 @@ qemuMigrationResetTLS(virQEMUDriverPtr driver, char *tlsAlias = in_tlsAlias; char *secAlias = in_secAlias; qemuMonitorMigrationParams migParams = { 0 }; - int ret; + int ret = -1; /* If coming from a path that doesn't know whether it's been used or not, * let's first check we need to do this. If the tls-creds doesn't exist -- 2.11.0

1 0

[libvirt] [PATCH libvirt-glib] examples: make detail strings match event details
by Guido Günther 25 Mar '17

25 Mar '17

--- examples/event-test.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/event-test.c b/examples/event-test.c index 7c9f4ec..a204485 100644 --- a/examples/event-test.c +++ b/examples/event-test.c @@ -78,7 +78,7 @@ static const char *eventDetailToString(int event, int detail) { break; case VIR_DOMAIN_EVENT_SUSPENDED: if (detail == VIR_DOMAIN_EVENT_SUSPENDED_PAUSED) - ret = "Unpaused"; + ret = "Paused"; else if (detail == VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED) ret = "Migrated"; break; @@ -103,7 +103,7 @@ static const char *eventDetailToString(int event, int detail) { ret = "Migrated"; break; case VIR_DOMAIN_EVENT_STOPPED_SAVED: - ret = "Failed"; + ret = "Saved"; break; case VIR_DOMAIN_EVENT_STOPPED_FAILED: ret = "Failed"; -- 2.11.0

2 2

[libvirt] [PATCH] util: fix build on non-Linux
by Roman Bogorodskiy 25 Mar '17

25 Mar '17

Fix typo in virNetDevPFGetVF() stub: ATTRUBUTE_UNUSED -> ATTRIBUTE_UNUSED. While here, use common indent style for arguments in virNetDevGetVirtualFunctionIndex() stub. --- Pushed under the build-breaker rule. src/util/virnetdev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index b9e9cbe54..93a931912 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1493,8 +1493,8 @@ virNetDevIsVirtualFunction(const char *ifname ATTRIBUTE_UNUSED) int virNetDevGetVirtualFunctionIndex(const char *pfname ATTRIBUTE_UNUSED, - const char *vfname ATTRIBUTE_UNUSED, - int *vf_index ATTRIBUTE_UNUSED) + const char *vfname ATTRIBUTE_UNUSED, + int *vf_index ATTRIBUTE_UNUSED) { virReportSystemError(ENOSYS, "%s", _("Unable to get virtual function index on this platform")); @@ -1513,7 +1513,7 @@ virNetDevGetPhysicalFunction(const char *ifname ATTRIBUTE_UNUSED, int virNetDevPFGetVF(const char *pfname ATTRIBUTE_UNUSED, int vf ATTRIBUTE_UNUSED, - char **vfname ATTRUBUTE_UNUSED) + char **vfname ATTRIBUTE_UNUSED) { virReportSystemError(ENOSYS, "%s", _("Unable to get virtual function name on this platform")); -- 2.11.0

2 1

[libvirt] [PATCH] Coverity fix for virNetDevIPCheckIPv6ForwardingCallback
by Cédric Bosdonnat 25 Mar '17

25 Mar '17

Add check for more than one RTA_OIF, even though this is rather unlikely and get rid of the buggy switch / break. --- src/util/virnetdevip.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/util/virnetdevip.c b/src/util/virnetdevip.c index c9ac6baf7..f5662413a 100644 --- a/src/util/virnetdevip.c +++ b/src/util/virnetdevip.c @@ -556,15 +556,17 @@ virNetDevIPCheckIPv6ForwardingCallback(const struct nlmsghdr *resp, if (resp->nlmsg_type != RTM_NEWROUTE) return ret; - /* Extract a few attributes */ + /* Extract a device ID attribute */ for (rta = RTM_RTA(rtmsg); RTA_OK(rta, len); rta = RTA_NEXT(rta, len)) { - switch (rta->rta_type) { - case RTA_OIF: + if (rta->rta_type == RTA_OIF) { oif = *(int *)RTA_DATA(rta); + /* Should never happen: netlink message would be broken */ + if (ifname) + goto error; + if (!(ifname = virNetDevGetName(oif))) goto error; - break; } } -- 2.12.0

3 2

[libvirt] [PATCH] virpci: fix build on non-Linux
by Roman Bogorodskiy 25 Mar '17

25 Mar '17

virPCIGetDeviceAddressFromSysfsLink() should return virPCIDeviceAddressPtr, so return NULL in the stub instead of "-1". --- Pushed under the build-breaker rule. src/util/virpci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virpci.c b/src/util/virpci.c index 546aeb550..65c108f2e 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2945,7 +2945,7 @@ virPCIDeviceAddressPtr virPCIGetDeviceAddressFromSysfsLink(const char *device_link ATTRIBUTE_UNUSED) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _(unsupported)); - return -1; + return NULL; } -- 2.11.0

1 0

[libvirt] ARMv7 guest PCI support broken in 3.0.0 onwards
by Daniel P. Berrange 24 Mar '17

24 Mar '17

$ cat arm.xml <domain type="qemu"> <name>f22-arm32</name> <uuid>a6bc14fb-585b-40b0-a15b-5e19f26079ba</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <os> <type arch="armv7l" machine="virt">hvm</type> <boot dev="hd"/> </os> <clock offset="utc"/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-system-arm</emulator> <disk type="file" device="disk"> <driver name="qemu" type="qcow2"/> <source file="/home/berrange/VirtualMachines/demo.qcow2"/> <target dev="sda" bus="scsi"/> </disk> <controller type="scsi" index="0" model="virtio-scsi"/> <interface type="user"> <mac address="52:54:00:87:d4:c0"/> <model type="virtio"/> </interface> <console type="pty"/> </devices> </domain> $ virsh define arm.xml Domain f22-arm32 defined from arm.xml $ virsh start f22-arm32 error: Failed to start domain f22-arm32 error: internal error: qemu unexpectedly closed the monitor: 2017-02-15T09:24:03.967648Z qemu-system-arm: -device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1: MSI is not supported by interrupt controller 2017-02-15T09:24:03.968154Z qemu-system-arm: -device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1: Device initialization failed I've not bisected it other than to find it works in 2.5.0 and is broken in 3.0.0 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|

3 7

[libvirt] [PATCH 0/3] Report block threshold in bulk stats
by Peter Krempa 24 Mar '17

24 Mar '17

This is a follow up to: https://www.redhat.com/archives/libvir-list/2017-March/msg00650.html so that management apps can query the current value. The series needs to be applied on top of the block threshold series. For convenience I've pushed it to the same remote repository as the original series. You can fetch it here: git fetch git://pipo.sk/pipo/libvirt.git block-threshold-1 Peter Krempa (3): util: json: Make function to free JSON values in virHash universal qemu: block: Add code to fetch block node data by node name qemu: stats: Display the block threshold size in bulk stats src/libvirt-domain.c | 4 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_block.c | 46 +++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_block.h | 3 +++ src/qemu/qemu_driver.c | 51 +++++++++++++++++++++++++++++++++++++++++--- src/qemu/qemu_monitor_json.c | 10 +-------- src/util/virjson.c | 8 +++++++ src/util/virjson.h | 1 + tools/virsh.pod | 3 +++ 9 files changed, 115 insertions(+), 12 deletions(-) -- 2.12.0

2 8

[libvirt] [PATCH v2] qemu: snapshot: Forbid internal snapshots with pflash firmware
by Peter Krempa 24 Mar '17

24 Mar '17

If the variable store (<nvram>) file is raw qemu can't do a snapshot of it and thus the snapshot would be incomplete. QEMU does no reject such snapshot. Additionally allowing to use a qcow2 variable store backing file would solve this issue but then it would become eligible to become target of the memory dump. Offline internal snapshot would be incomplete too with either storage format since libvirt does not handle the pflash file in this case. Forbid such snapshot so that we can avoid problems. --- Notes: v2: - changed error code to OPERATION_UNSUPPORTED (from CONFIG_UNSUPPORTED) - dropped mention of QEMU from the error message - dropped mentions of OVMF or the firmware itself altoghether, the culprit is the pflash device regardless of the software it contains - mentioned all the stuff in the commit message and comment We also will need to introduce a way to snapshot the pflash for external snapshots which is currently impossible as well, but fortunately does not have inherent drawbacks as internal snapshots. src/qemu/qemu_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 676295208..202d190b3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13873,6 +13873,16 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, goto cleanup; } + /* Internal snapshots don't work with VMs with OVMF loader since qemu does + * not snapshot the variable store */ + if (found_internal && + vm->def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("internal snapshots of a VM with pflash based " + "firmware are not supported")); + goto cleanup; + } + /* Alter flags to let later users know what we learned. */ if (external && !active) *flags |= VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY; -- 2.12.1

3 10

[libvirt] [PATCH v3 0/3] qemu: Forbid internal snapshots with pflash-based firmware (OVMF)
by Peter Krempa 24 Mar '17

24 Mar '17

Patches 1 and 2 are new in the series and add an option to override the check so that users can use the feature despite being unsafe. See patch 3/3 for clarification of the motiovation to do this. Peter Krempa (3): virerror: Introduce VIR_ERR_OPERATION_UNSAFE snapshot: Introduce flag VIR_DOMAIN_SNAPSHOT_CREATE_UNSAFE qemu: snapshot: Forbid internal snapshots with pflash firmware include/libvirt/libvirt-domain-snapshot.h | 3 +++ include/libvirt/virterror.h | 1 + src/qemu/qemu_driver.c | 18 +++++++++++++++++- src/util/virerror.c | 5 +++++ tools/virsh-snapshot.c | 6 ++++++ tools/virsh.pod | 6 +++++- 6 files changed, 37 insertions(+), 2 deletions(-) -- 2.12.1

1 4

[libvirt] [PATCH] Revert "qemu: forbid migration with an IOMMU device"
by Ján Tomko 24 Mar '17

24 Mar '17

This reverts commit b7118623ad5a8e6ea75d693881c08873eefa3e28. Migration was implemented by QEMU commit: commit 8cdcf3c1e58d04b6811956d7608efeb66c42d719 Author: Peter Xu <peterx(a)redhat.com> Date: Fri Jan 6 12:06:13 2017 +0800 intel_iommu: allow migration https://bugzilla.redhat.com/show_bug.cgi?id=1433994 --- src/qemu/qemu_migration.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 15ed830..f5711bc 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2359,12 +2359,6 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver, _("migration with shmem device is not supported")); return false; } - - if (vm->def->iommu) { - virReportError(VIR_ERR_OPERATION_INVALID, "%s", - _("migration with iommu device is not supported")); - return false; - } } return true; -- 2.10.2

2 2

[libvirt] [PATCH] network: only check for IPv6 RA routes when the network has an IPv6 address
by Laine Stump 24 Mar '17

24 Mar '17

commit 00d28a78 added a check to see if there were any IPv6 routes added by RA (Router Advertisement) via an interface that had accept_ra set to something other than "2". The check was being done unconditionally, but it's only relevant if IPv6 forwarding is going to be turned on, and that will only happen if the network has an IPv6 address. --- src/network/bridge_driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 0336ece..10e8f0e 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -2391,10 +2391,9 @@ networkStartNetworkVirtual(virNetworkDriverStatePtr driver, /* If forward.type != NONE, turn on global IP forwarding */ if (network->def->forward.type != VIR_NETWORK_FORWARD_NONE) { - if (!virNetDevIPCheckIPv6Forwarding()) + if (v6present && !virNetDevIPCheckIPv6Forwarding()) goto err3; /* Precise error message already provided */ - if (networkEnableIPForwarding(v4present, v6present) < 0) { virReportSystemError(errno, "%s", _("failed to enable IP forwarding")); -- 2.9.3

2 1

[libvirt] [PATCH 00/19] Fix saving/setting/restoring SR-IOV VF MAC address
by Laine Stump 24 Mar '17

24 Mar '17

There are multiple bugs filed against both libvirt and the kernel related to incorrect restoration of MAC addresses for SR-IOV VFs, both when used via VFIO device assignment and when used for macvtap passthrough mode https://bugzilla.redhat.com/1415609 - libvirt https://bugzilla.redhat.com/1341248 - kernel (igb) https://bugzilla.redhat.com/1415609 - kernel (ixgbe) https://bugzilla.redhat.com/1302166 - kernel (mlx, fixed) Beyond that, there are other problems with incorrect setting and restoration of VF MAC addresses that don't have their own bug reports (although they may be partially described in the comments of the BZes mentioned above). This patch series attempts (and I hope succeeds!) to fix all of these problems, which can be summarized in these three points: * The VF's own MAC address was not being set prior to using it for macvtap passthrough mode. Instead, due to serious misconception on my part, the "admin MAC" for that VF was set in the PF. The problem is that the admin MAC isn't put into use on the VF immediately; rather it is unused until the next time the VF driver is initialized (on either the host or in a guest) so setting it had no practical effect, meaning that the macvtap device's MAC didn't match the MAC of the VF device it was attached to - this meant that traffic wouldn't pass unless the device was in promiscuous mode (and apparently it was back when the code was changed to behave this way?). * The VF's own MAC address was never restored after it had been used (for both VFIO device assignment and for macvtap passthrough mode). Only the "admin MAC" address (which, again, won't take effect until/unless the VF driver is reloaded/reinitialized) was restored. * If the original admin MAC was 00:00:00:00:00:00, libvirt would save that, then attempt to restore it when the guest was finished with the device, but for some/many SRIOV-capable net drivers, an all 0 MAC is not allowed to be set (even though that is its initial value). This would result in the MAC not being changed (of course, since this is the admin MAC, that didn't actually matter, but the combination of the error message and the VF's own MAC still being set to the value used by the guest, users mistakenly believed this was the source of networking problems (e.g. when the guest moved to another host, but the old host still had an interface showing its MAC address). There are lots of details in the patches. 01 - 07 just clean up and slightly modify some existing utility functions. 08 - 11 define some functions to save/restore netdev MAC/vlan settings, and 12-14 change the existing setup/teardown code for macvtap and hostdev to use the new functions, then 15 and 17-19 modify their behavior further, while 16 just removes functions that are no longer used. In the end, the VF's own MAC *and* admin MAC are saved for all SRIOV VFs when we begin using a VF, and the VF's MAC is restored when finished. Since the admin MAC doesn't actually have any immediate practical effect, we don't concern ourselves with assuring it is restored in all cases (in particular, when use use the VF for VFIO assignment, we only restore the VF's MAC, but not the admin MAC during teardown, and when using the VF for macvtap passthrough we avoid restoring the admin MAC because that would unnecessarily turn on the "administratively set" flag in the PF driver (described in the commit log for one of these patches). I might decide to fix the former later, but for now it just unnecessarily complicates the code for no real gain). Laine Stump (19): util: permit querying a VF MAC address or VLAN tag by itself util: remove unused args from virNetDevSetVfConfig() util: use cleanup label consistently in virHostdevNetConfigReplace() util: eliminate useless local variable util: make virMacAddrParse more versatile util: change virPCIGetNetName() to not return error if device has no net name util: make virPCIGetDeviceAddressFromSysfsLink() public util: new function virPCIDeviceRebind() util: new internal function to permit silent failure of virNetDevSetMAC() util: new function virNetDevPFGetVF() util: new functions virNetDev(Save|Read|Set)NetConfig() util: use new virNetDev*NetConfig() functions for macvtap setup/teardown util: use new virNetDev*NetConfig() functions for hostdev setup/teardown util: replace virHostdevNetConfigReplace with ...(Save|Set)NetConfig() util: save hostdev network device config before unbinding from host driver util: after hostdev assignment, restore VF MAC address via setting admin MAC util: remove unused functions from virnetdev.c util: if setting admin MAC to 00:00:00:00:00:00 fails, try 02:00:00:00:00:00 util: try *really* hard to set the MAC address of an SRIOV VF src/libvirt_private.syms | 10 +- src/util/virhostdev.c | 171 ++++++-- src/util/virmacaddr.c | 2 +- src/util/virnetdev.c | 937 +++++++++++++++++++++++++++++++------------- src/util/virnetdev.h | 25 ++ src/util/virnetdevmacvlan.c | 45 ++- src/util/virpci.c | 65 ++- src/util/virpci.h | 4 + 8 files changed, 933 insertions(+), 326 deletions(-) -- 2.9.3

3 36

[libvirt] [PATCH] qemu: Fix typo in __QEMU_CAPSPRIV_H_ALLOW__
by Andrea Bolognani 23 Mar '17

23 Mar '17

--- Pushed as trivial. src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_capspriv.h | 2 +- tests/cputest.c | 4 ++-- tests/qemucapabilitiestest.c | 2 +- tests/qemucapsprobe.c | 2 +- tests/qemucpumock.c | 4 ++-- tests/qemuxml2argvtest.c | 4 ++-- tests/testutilsqemu.c | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 60ed31e..8bd39c7 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -44,7 +44,7 @@ #include "virstring.h" #include "qemu_hostdev.h" #include "qemu_domain.h" -#define __QEMU_CAPSRIV_H_ALLOW__ +#define __QEMU_CAPSPRIV_H_ALLOW__ #include "qemu_capspriv.h" #include <fcntl.h> diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h index ee29b8b..61ccd45 100644 --- a/src/qemu/qemu_capspriv.h +++ b/src/qemu/qemu_capspriv.h @@ -21,7 +21,7 @@ * Author: Pavel Fedin <p.fedin(a)samsung.com> */ -#ifndef __QEMU_CAPSRIV_H_ALLOW__ +#ifndef __QEMU_CAPSPRIV_H_ALLOW__ # error "qemu_capspriv.h may only be included by qemu_capabilities.c or test suites" #endif diff --git a/tests/cputest.c b/tests/cputest.c index 5e205c5..917b1a3 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -43,9 +43,9 @@ #if WITH_QEMU && WITH_YAJL # include "testutilsqemu.h" # include "qemumonitortestutils.h" -# define __QEMU_CAPSRIV_H_ALLOW__ +# define __QEMU_CAPSPRIV_H_ALLOW__ # include "qemu/qemu_capspriv.h" -# undef __QEMU_CAPSRIV_H_ALLOW__ +# undef __QEMU_CAPSPRIV_H_ALLOW__ #endif #define VIR_FROM_THIS VIR_FROM_CPU diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c index 2152e80..2918ff4 100644 --- a/tests/qemucapabilitiestest.c +++ b/tests/qemucapabilitiestest.c @@ -22,7 +22,7 @@ #include "testutils.h" #include "testutilsqemu.h" #include "qemumonitortestutils.h" -#define __QEMU_CAPSRIV_H_ALLOW__ +#define __QEMU_CAPSPRIV_H_ALLOW__ #include "qemu/qemu_capspriv.h" #define VIR_FROM_THIS VIR_FROM_NONE diff --git a/tests/qemucapsprobe.c b/tests/qemucapsprobe.c index fb9f3e9..561c5d7 100644 --- a/tests/qemucapsprobe.c +++ b/tests/qemucapsprobe.c @@ -24,7 +24,7 @@ #include "internal.h" #include "virthread.h" #include "qemu/qemu_capabilities.h" -#define __QEMU_CAPSRIV_H_ALLOW__ 1 +#define __QEMU_CAPSPRIV_H_ALLOW__ 1 #include "qemu/qemu_capspriv.h" #define VIR_FROM_THIS VIR_FROM_NONE diff --git a/tests/qemucpumock.c b/tests/qemucpumock.c index 2c1d24d..f0a113f 100644 --- a/tests/qemucpumock.c +++ b/tests/qemucpumock.c @@ -18,9 +18,9 @@ #include "internal.h" #include "qemu/qemu_capabilities.h" -#define __QEMU_CAPSRIV_H_ALLOW__ +#define __QEMU_CAPSPRIV_H_ALLOW__ #include "qemu/qemu_capspriv.h" -#undef __QEMU_CAPSRIV_H_ALLOW__ +#undef __QEMU_CAPSPRIV_H_ALLOW__ virCPUDefPtr diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 64e14af..ec73ac7 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -27,9 +27,9 @@ # include "storage/storage_driver.h" # include "virmock.h" -# define __QEMU_CAPSRIV_H_ALLOW__ +# define __QEMU_CAPSPRIV_H_ALLOW__ # include "qemu/qemu_capspriv.h" -# undef __QEMU_CAPSRIV_H_ALLOW__ +# undef __QEMU_CAPSPRIV_H_ALLOW__ # include "testutilsqemu.h" diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c index 026b73e..4cc482d 100644 --- a/tests/testutilsqemu.c +++ b/tests/testutilsqemu.c @@ -8,7 +8,7 @@ # include "cpu_conf.h" # include "qemu/qemu_driver.h" # include "qemu/qemu_domain.h" -# define __QEMU_CAPSRIV_H_ALLOW__ +# define __QEMU_CAPSPRIV_H_ALLOW__ # include "qemu/qemu_capspriv.h" # include "virstring.h" -- 2.7.4

1 0

[libvirt] [PATCH] qemu: forbid migration with an IOMMU device
by Ján Tomko 23 Mar '17

23 Mar '17

https://bugzilla.redhat.com/show_bug.cgi?id=1433994 --- src/qemu/qemu_migration.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index f5711bc..15ed830 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2359,6 +2359,12 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver, _("migration with shmem device is not supported")); return false; } + + if (vm->def->iommu) { + virReportError(VIR_ERR_OPERATION_INVALID, "%s", + _("migration with iommu device is not supported")); + return false; + } } return true; -- 2.10.2

2 1

[libvirt] [PATCH v3 0/7] Add TLS support for migration
by John Ferlan 23 Mar '17

23 Mar '17

v2: http://www.redhat.com/archives/libvir-list/2017-February/msg01374.html NB: Parts of the original series were split out, patches posted, ACK'd, and committed separately, see: http://www.redhat.com/archives/libvir-list/2017-March/msg00037.html Changes since v2: First and foremost after some gentle encouragement and lots of hours cursing at no one in particular, I was finally able to configure a couple of nested host guests, create a guest on each, and actually migrate that guest without TLS back and forth between the two nested hosts. Suffice to say there are dribs and drabs of "howto"'s that help, but it is quite a confusing setup and I was certainly left wondering how customers do this. OK beyond paying someone set things up for them! Now that I had the basics, the next task was creating the TLS environment. MANY more curse words uttered, including some I didn't know I knew, but I was actually able to test the changes in my environment. Suffice to say it's "somewhat confusing" because the TLS environment that QEMU expects (ok, the filenames) differ slightly than those that a libvirt TLS environment would expects. What really got frustrating is that all I'd get back is the following error message after 'migrate' started on the client and after the server was essentially waiting for the migration: error: operation failed: migration job: unexpectedly failed Turns out that I was missing the '/etc/pki/qemu/client-cert.pem' and '/etc/pki/qemu/client-key.pem' files, but got no message. Of course I did have something in my /etc/pki/libvirt directory, but of course those weren't being used. Still my brain wasn't exactly telling me that. The other piece I was missing was the "details" about when "tls-hostname" must be provided. In the previous patches, I would search on "fd" or "spec" in spec->dest.host.protocol; however, that wasn't quite right. What I needed to search on was MIGRATION_DEST_CONNECT_HOST or MIGRATION_DEST_FD in spec->destType (and _CONNECT_HOST only because it turns into _FD 'eventually'). Anyway, so happy days are here again and I can now liberally celebrate St Patrick's Day (not that I wasn't going to before, but now moreso!). Beyond the above description from my testing the real "key" behind all of this is ensuring that the 'right' QEMU bits are installed by fetching the "tls-creds" via qemuMonitorGetMigrationParams and as long as *something* is returned, then we are assured that we can proceed. This relates to QEMU commit '4af245dc3' (after v2.9.0-rc0) which sets a default for tls-creds and more importantly for our purposes allows us to "clear" the tls-creds and tls-hostname migration parameters by passing a "" (empty string). With that in place the rest of the logic falls into place with regard to qemuMigrationCheckSetupTLS ensuring that TLS for migration is available for libvirt to use. Once we know we can use TLS, we'll use qemuMigrationAddTLSObjects to add the "secret" and "tls-creds-x509" objects to the domain for either server (target) or client (source). Doing this also required an adjustment to the existing code to allow the Async monitor usage. Once those objects are created, we'll set the "tls-creds" and "tls-hostname" parameters appropriate. If TLS isn't being used, we'll be sure to clear them. This is only made tricky by needing to ensure the qemu that's running can support setting them to "", hence the qemuMigrationCheckTLSCreds prior to that clearing. If this wasn't done, older QEMU would be less than pleased to find "" in tls-creds and tls-hostname. Finally when the migration is successful, call qemuMigrationDeconstructTLS (naming credit goes to my wife!). Failures will call just qemuMigrationResetTLS in order to achieve the same call; however, for those paths we do not still have the original 'tlsAlias' and 'secAlias' available, so we have to recreate it on the fly' Have I won the prize for the longest cover letter yet? John Ferlan (7): qemu: Create #define for TLS configuration setup. conf: Introduce migrate_tls_x509_cert_dir Add new migration flag VIR_MIGRATE_TLS qemu: Add TLS params to _qemuMonitorMigrationParams qemu: Add job for qemuDomain{Add|Del}TLSObjects qemu: Set up the migrate TLS objects for target qemu: Set up the migration TLS objects for source include/libvirt/libvirt-domain.h | 8 + src/qemu/libvirtd_qemu.aug | 5 + src/qemu/qemu.conf | 37 ++++ src/qemu/qemu_conf.c | 45 ++-- src/qemu/qemu_conf.h | 4 + src/qemu/qemu_domain.c | 7 +- src/qemu/qemu_domain.h | 91 ++++---- src/qemu/qemu_driver.c | 4 +- src/qemu/qemu_hotplug.c | 24 ++- src/qemu/qemu_hotplug.h | 2 + src/qemu/qemu_migration.c | 423 ++++++++++++++++++++++++++++++++++++- src/qemu/qemu_migration.h | 9 +- src/qemu/qemu_monitor.c | 11 +- src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 28 +++ src/qemu/test_libvirtd_qemu.aug.in | 3 + tests/qemumonitorjsontest.c | 25 ++- tools/virsh-domain.c | 7 + 18 files changed, 668 insertions(+), 68 deletions(-) -- 2.9.3

2 23

[libvirt] [PATCH] util: fix build on non-Linux
by Roman Bogorodskiy 23 Mar '17

23 Mar '17

Decorate unused arguments of the virNetDevGetMaster() stub with ATTRIBUTE_UNUSED to fix build on systems where this stub is used. --- Pushed as a build-breaker. src/util/virnetdev.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 6805d32..455239a 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1017,7 +1017,8 @@ virNetDevGetMaster(const char *ifname, char **master) int -virNetDevGetMaster(const char *ifname, char **master) +virNetDevGetMaster(const char *ifname ATTRIBUTE_UNUSED, + char **master ATTRIBUTE_UNUSED) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Unable to get device master from netlink on this platform")); -- 2.7.4

1 0

[libvirt] [PATCH 1/1] qemu: snapshot: Forbid internal snapshots with OVMF firmware
by Peter Krempa 22 Mar '17

22 Mar '17

QEMU does not snapshot the pflash drive when doing a 'savevm' thus internal snapshots with OVMF would be incomplete. Forbid such snapshot so that we can avoid problems. --- CC: lersek(a)redhat.com There might be slight regression potential. While this did not work as expected I did not encounter any error while doing a savevm, thus users might actually think that this worked before. src/qemu/qemu_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 0e065081d..344917451 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13873,6 +13873,16 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, goto cleanup; } + /* Internal snapshots don't work with VMs with OVMF loader since qemu does + * not snapshot the variable store */ + if (found_internal && + vm->def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("internal snapshots of a VM with pflash based " + "firmware are not supported by QEMU")); + goto cleanup; + } + /* Alter flags to let later users know what we learned. */ if (external && !active) *flags |= VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY; -- 2.12.1

2 2