- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] network: add dnsmasq option 'dhcp-authoritative'
by Martin Wilck 10 Oct '16

10 Oct '16

Lest it be forgotten, here is a rebased version of my "dhcp-authoritative" patch (against 77d24de). According to dnsmasq(8), this option "should be set when dnsmasq is definitely the only DHCP server on a network", whis is the case for libvirt-managed networks. In practice, this option has the effect that an expired lease can be reacquired by the client using a DHCPREQUEST unless it has been given to another client in the meantime. Without "dhcp-authoritative", this operation always fails, which can be quite cumbersome. There is no protection against rogue clients hijacking other client's IP addresses, but that isn't specific to libvirt, and IP addresses don't provide security anyway. This is ovbiously not aimed at production environments; it's a convenience for developers and casual users who'd rather not be bothered with network XML host entries or the like. Original submission: https://www.redhat.com/archives/libvir-list/2016-September/msg00739.html Daniel's post where he said that "unless there's a obvious downside to it, it seems reasonable to add that": https://www.redhat.com/archives/libvir-list/2016-September/msg01305.html Regards, Martin Martin Wilck (2): network: add dnsmasq option 'dhcp-authoritative' tests/networkxml2confdata: add dhcp-authoritative option src/network/bridge_driver.c | 4 +++- tests/networkxml2confdata/dhcp6-nat-network.conf | 1 + tests/networkxml2confdata/dhcp6host-routed-network.conf | 1 + tests/networkxml2confdata/isolated-network.conf | 1 + tests/networkxml2confdata/nat-network-dns-srv-record-minimal.conf | 1 + tests/networkxml2confdata/nat-network-dns-srv-record.conf | 1 + tests/networkxml2confdata/nat-network-dns-txt-record.conf | 1 + tests/networkxml2confdata/nat-network-name-with-quotes.conf | 1 + tests/networkxml2confdata/nat-network.conf | 1 + tests/networkxml2confdata/netboot-network.conf | 1 + tests/networkxml2confdata/netboot-proxy-network.conf | 1 + 11 files changed, 13 insertions(+), 1 deletion(-) -- 2.10.0

2 4

[libvirt] dnsmasq option "dhcp-authoritative" in libvirt virtual networks?
by Martin Wilck 10 Oct '16

10 Oct '16

Hello, I am seeing a slightly annoying behavior of libvirt-created networks on my system. Whenever a VM fails to renew its DHCP lease in time (for example because my laptop is suspended), the IP address changes, causing various annoyances. If this happens, the log message "DHCPNAK(virbrX): ... lease not found" appears in the libvirtd logs. Looking at the dnsmasq code, it seems that this would be fixed by running dnsmasq with the "dhcp-authoritative" option, which, according to the dnsmasq man page, "should be set when dnsmasq is definitely the only DHCP server on a network" - IMO that's the case for libvirtd- managed virtual networks. So the question comes to my mind: is there a good reason why libvirtd doesn't set "dhcp-authoritative" on the dnsmasq instances it starts? Regards Martin -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSELinux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

4 6

[libvirt] [PATCH] audit: add audit information about panic devices
by Chen Hanxiao 10 Oct '16

10 Oct '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> This patch add audit info for panic notifier devices. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- docs/auditlog.html.in | 15 +++++++++++++++ src/conf/domain_audit.c | 38 ++++++++++++++++++++++++++++++++++++++ src/conf/domain_audit.h | 4 ++++ src/libvirt_private.syms | 1 + 4 files changed, 58 insertions(+) diff --git a/docs/auditlog.html.in b/docs/auditlog.html.in index 0c778aa..45464af 100644 --- a/docs/auditlog.html.in +++ b/docs/auditlog.html.in @@ -371,5 +371,20 @@ <dd>Path of the backing character device for given emulated device</dd> </dl> + + <h4><a name="typeresourcepanic">Panic notifier</a></h4> + <p> + The <code>msg</code> field will include the following sub-fields + </p> + + <dl> + <dt><code>resrc</code></dt> + <dd>The type of resource assigned. Set to <code>panic</code></dd> + <dt><code>reason</code></dt> + <dd>The reason which caused the resource to be assigned to happen</dd> + <dt><code>model</code></dt> + <dd>The model of the panic notifier device</dd> + </dl> + </body> </html> diff --git a/src/conf/domain_audit.c b/src/conf/domain_audit.c index fd20ace..e48a63d 100644 --- a/src/conf/domain_audit.c +++ b/src/conf/domain_audit.c @@ -893,6 +893,9 @@ virDomainAuditStart(virDomainObjPtr vm, const char *reason, bool success) for (i = 0; i < vm->def->nshmems; i++) virDomainAuditShmem(vm, vm->def->shmems[i], "start", true); + for (i = 0; i < vm->def->npanics; i++) + virDomainAuditPanic(vm, vm->def->panics[i], "start", true); + virDomainAuditMemory(vm, 0, virDomainDefGetMemoryTotal(vm->def), "start", true); virDomainAuditVcpu(vm, 0, virDomainDefGetVcpus(vm->def), "start", true); @@ -1006,3 +1009,38 @@ virDomainAuditShmem(virDomainObjPtr vm, VIR_FREE(shmem); return; } + +void +virDomainAuditPanic(virDomainObjPtr vm, + virDomainPanicDefPtr def, + const char *reason, + bool success) +{ + char uuidstr[VIR_UUID_STRING_BUFLEN]; + char *vmname = virAuditEncode("vm", vm->def->name); + const char *panic_model = virDomainPanicModelTypeToString(def->model); + char *model = virAuditEncode("model", VIR_AUDIT_STR(panic_model)); + const char *virt = virDomainVirtTypeToString(vm->def->virtType); + + virUUIDFormat(vm->def->uuid, uuidstr); + + if (!vmname || !model) { + VIR_WARN("OOM while encoding audit message"); + goto cleanup; + } + + if (!virt) { + VIR_WARN("Unexpected virt type %d while encoding audit message", + vm->def->virtType); + virt = "?"; + } + + VIR_AUDIT(VIR_AUDIT_RECORD_RESOURCE, success, + "virt=%s resrc=PanicNotifier reason=%s %s uuid=%s %s", + virt, reason, vmname, uuidstr, model); + + cleanup: + VIR_FREE(vmname); + VIR_FREE(model); + return; +} diff --git a/src/conf/domain_audit.h b/src/conf/domain_audit.h index 8cb585d..10ecc2a 100644 --- a/src/conf/domain_audit.h +++ b/src/conf/domain_audit.h @@ -133,6 +133,10 @@ void virDomainAuditShmem(virDomainObjPtr vm, virDomainShmemDefPtr def, const char *reason, bool success) ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); +void virDomainAuditPanic(virDomainObjPtr vm, + virDomainPanicDefPtr def, + const char *reason, bool success) + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); #endif /* __VIR_DOMAIN_AUDIT_H__ */ diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 923afd1..94ec7cb 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -146,6 +146,7 @@ virDomainAuditIOThread; virDomainAuditMemory; virDomainAuditNet; virDomainAuditNetDevice; +virDomainAuditPanic; virDomainAuditRedirdev; virDomainAuditRNG; virDomainAuditSecurityLabel; -- 1.8.3.1

3 3

[libvirt] [PATCH 00/11] cleanups and improvements for video device code
by Pavel Hrdina 10 Oct '16

10 Oct '16

Pavel Hrdina (11): tests: fix some QXL capability combinations that doesn't make sense qemu_capabilities: join capabilities for qxl and qxl-vga devices qemu_capabilities: mark QEMU_CAPS_VGA_QXL capability as deprecated qemu_domain: move video validation out of qemu_command qemu_process: move video validation out of qemu_command qemu_capabilities: rename QEMU_CAPS_VIRTIO_GPU_VIRGL qemu_command: separate code for video device via -vga attribute qemu_command: cleanup qemuBuildVideoCommandLine qemu_capabilities: check for existence of virtio-vga qemu_command: properly detect which model to use for video device qemu_command: add support to use virtio as secondary video device docs/formatdomain.html.in | 3 +- src/qemu/qemu_capabilities.c | 23 +- src/qemu/qemu_capabilities.h | 15 +- src/qemu/qemu_command.c | 335 +++++++++------------ src/qemu/qemu_domain.c | 70 +++++ src/qemu/qemu_domain.h | 3 + src/qemu/qemu_domain_address.c | 6 - src/qemu/qemu_process.c | 54 +++- .../qemu_2.6.0-gicv2-virt.aarch64.xml | 1 - .../qemu_2.6.0-gicv3-virt.aarch64.xml | 1 - tests/domaincapsschemadata/qemu_2.6.0.aarch64.xml | 1 - tests/domaincapsschemadata/qemu_2.6.0.ppc64le.xml | 1 - .../qemucapabilitiesdata/caps_1.2.2.x86_64.replies | 70 +---- tests/qemucapabilitiesdata/caps_1.2.2.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.3.1.x86_64.replies | 76 +---- tests/qemucapabilitiesdata/caps_1.3.1.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.4.2.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.4.2.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.5.3.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.6.0.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.7.0.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 107 ++----- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 6 +- .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 117 +++---- tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 6 +- .../caps_2.6.0-gicv2.aarch64.replies | 43 ++- .../caps_2.6.0-gicv2.aarch64.xml | 1 - .../caps_2.6.0-gicv3.aarch64.replies | 43 ++- .../caps_2.6.0-gicv3.aarch64.xml | 1 - .../caps_2.6.0.ppc64le.replies | 43 ++- tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 117 +++---- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 6 +- .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 122 +++----- tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 6 +- tests/qemuhelptest.c | 4 - .../qemuxml2argv-pcie-root-port.args | 5 +- .../qemuxml2argv-pcie-switch-downstream-port.args | 5 +- .../qemuxml2argv-pcie-switch-upstream-port.args | 5 +- .../qemuxml2argv-pcihole64-q35.args | 5 +- .../qemuxml2argv-q35-usb2-multi.args | 5 +- .../qemuxml2argv-q35-usb2-reorder.args | 5 +- tests/qemuxml2argvdata/qemuxml2argv-q35-usb2.args | 5 +- tests/qemuxml2argvdata/qemuxml2argv-q35.args | 5 +- .../qemuxml2argv-video-virtio-gpu-device.args | 2 +- .../qemuxml2argv-video-virtio-gpu-sec.args | 25 ++ .../qemuxml2argv-video-virtio-gpu-sec.xml | 36 +++ .../qemuxml2argv-video-virtio-gpu-spice-gl.args | 2 +- .../qemuxml2argv-video-virtio-gpu-virgl.args | 2 +- .../qemuxml2argv-video-virtio-vga.args | 24 ++ ...evice.xml => qemuxml2argv-video-virtio-vga.xml} | 11 +- tests/qemuxml2argvtest.c | 152 +++++----- tests/qemuxml2xmltest.c | 18 +- 58 files changed, 778 insertions(+), 1215 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-sec.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-sec.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-vga.args rename tests/qemuxml2argvdata/{qemuxml2argv-video-qxl-sec-nodevice.xml => qemuxml2argv-video-virtio-vga.xml} (77%) -- 2.10.0

2 31

[libvirt] [PATCH v2 00/20] Split parsing and defining logic of daemon's logging
by Erik Skultety 10 Oct '16

10 Oct '16

v2 of the original series https://www.redhat.com/archives/libvir-list/2016-May/msg00229.html since v1: - as Cole pointed out in 20/38 of the original series, the patches were not designed in an elegant way and they were hard to review, so this series reworked the whole series: -> first the existing methods that do combine parsing and defining logic and which should be dropped are renamed to a more accurate name -> all the necessary methods to achieve the "split" are introduced gradually, interconnected with each other -> finally, all the callers switch to the new logic introduced in the early patches in a transparent way -> all the original poorly named methods are completely dropped - also, the original series introduced a new set of API locks because there was an issue with 2 concurrent setters that while setter1 was preparing its local set of outputs to replace the existing global one, setter2 might just replace the global set with its copy, invalidating all fds of the setter1's set because the original series used a concept of *copying* (not duplicating) of fds, so the copied fd would be invalidated by issuing reset by setter2. This series however, duplicates the file-based outputs' (that should remain opened) fds. So even if setter2 replaces the original set with its copy and calls reset, effectively closing all fds, it does not matter for setter1, since unlink only decrements the number of references to a specific opened fd. Erik Skultety (20): virlog: Rename virLogParse* to virLogParseAndDefine* virlog: Introduce virLogOutputNew virlog: Introduce virLogFilterNew virlog: Introduce virLogFindOutput virlog: Introduce virLogDefineOutputs virlog: Introduce virLogDefineFilters virlog: Introduce virLogNewOutputTo* as a replacement for virLogAddOutputTo* virlog: Take a special care of syslog when setting new set of log outputs virlog: Introduce virLogParseOutput virlog: Introduce virLogParseFilter virlog: Introduce virLogParseOutputs virlog: Introduce virLogParseFilters virlog: Introduce virLogSetOutputs virlog: Introduce virLogSetFilters daemon: Split output parsing and output defining daemon: Split filter parsing and filter defining virlog: Remove functions that aren't used anywhere anymore virlog: Make some of the methods static virlog: Store the journald fd within the output object virlog: Split parsing and setting priority daemon/libvirtd.c | 8 +- src/libvirt_private.syms | 10 +- src/locking/lock_daemon.c | 8 +- src/logging/log_daemon.c | 8 +- src/util/virlog.c | 1079 ++++++++++++++++++++++++++------------------- src/util/virlog.h | 61 +-- tests/eventtest.c | 3 +- tests/testutils.c | 11 +- tests/virlogtest.c | 10 +- 9 files changed, 702 insertions(+), 496 deletions(-) -- 2.5.5

3 52

[libvirt] [PATCH] vz: fix vnc host address
by Mikhail Feoktistov 10 Oct '16

10 Oct '16

Empty string means 127.0.0.1 in terms of vzSDK But in this case we should set 0.0.0.0 --- .gnulib | 2 +- src/vz/vz_sdk.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.gnulib b/.gnulib index e89b4a7..a2a3943 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit e89b4a7aefce9cb02963920712ba7cdd13641644 +Subproject commit a2a39436b65f329630df4a93ec4e30aeae403c54 diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index f2a5c96..7011cbf 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -2967,7 +2967,7 @@ static int prlsdkApplyGraphicsParams(PRL_HANDLE sdkdom, glisten = virDomainGraphicsGetListen(gr, 0); pret = PrlVmCfg_SetVNCHostName(sdkdom, glisten && glisten->address ? - glisten->address : ""); + glisten->address : "0.0.0.0"); prlsdkCheckRetGoto(pret, cleanup); ret = 0; -- 1.8.3.1

3 3

[libvirt] [PATCH] Add 2 systemtap script in EXTRA_DIST
by Luyao Huang 10 Oct '16

10 Oct '16

Then we will include these 2 useful script in VPATH build. Signed-off-by: Luyao Huang <lhuang(a)redhat.com> --- examples/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/examples/Makefile.am b/examples/Makefile.am index bd8460d..ca6e039 100644 --- a/examples/Makefile.am +++ b/examples/Makefile.am @@ -28,6 +28,8 @@ EXTRA_DIST = \ lxcconvert/virt-lxc-convert \ polkit/libvirt-acl.rules \ systemtap/events.stp \ + systemtap/lock-debug.stp \ + systemtap/qemu-monitor.stp \ systemtap/rpc-monitor.stp \ $(FILTERS) \ $(wildcard $(srcdir)/xml/storage/*.xml) \ -- 1.8.3.1

2 2

[libvirt] [PATCH] Forbid new-line char in name of networks
by Sławek Kapłoński 10 Oct '16

10 Oct '16

New line character in name of network is now forbidden because it mess virsh output and can be confusing for users. Closes-Bug: https://bugzilla.redhat.com/show_bug.cgi?id=818064 --- src/conf/network_conf.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index aa39776..f9c537f 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -2123,6 +2123,13 @@ virNetworkDefParseXML(xmlXPathContextPtr ctxt) goto error; } + if (strchr(def->name, '\n')) { + virReportError( + VIR_ERR_XML_ERROR, + _("name %s cannot contain new-line character"), def->name); + goto error; + } + /* Extract network uuid */ tmp = virXPathString("string(./uuid[1])", ctxt); if (!tmp) { -- 2.10.0

3 3

[libvirt] [PATCH v3] virsh domdisplay: introduce '--all' for showing all possible graphical displays
by Chen Hanxiao 10 Oct '16

10 Oct '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> For one VM, it could had more than one graphical display. Such as we coud add both vnc and spice display to a VM. This patch introduces '--all' for showing all possible graphical display of a active VM. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- v2: VIR_FREE befor use in loops add descriptions in virsh.pod v3: add missing command args list in virsh.pod suppress --type if --all specified tools/virsh-domain.c | 17 +++++++++++++++-- tools/virsh.pod | 6 ++++-- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 3829b17..bd18798 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10648,6 +10648,10 @@ static const vshCmdOptDef opts_domdisplay[] = { .help = N_("select particular graphical display " "(e.g. \"vnc\", \"spice\", \"rdp\")") }, + {.name = "all", + .type = VSH_OT_BOOL, + .help = N_("show all possible graphical displays") + }, {.name = NULL} }; @@ -10671,6 +10675,7 @@ cmdDomDisplay(vshControl *ctl, const vshCmd *cmd) int tmp; int flags = 0; bool params = false; + bool all = vshCommandOptBool(cmd, "all"); const char *xpath_fmt = "string(/domain/devices/graphics[@type='%s']/%s)"; virSocketAddr addr; @@ -10697,10 +10702,11 @@ cmdDomDisplay(vshControl *ctl, const vshCmd *cmd) /* Attempt to grab our display info */ for (iter = 0; scheme[iter] != NULL; iter++) { /* Particular scheme requested */ - if (type && STRNEQ(type, scheme[iter])) + if (!all && type && STRNEQ(type, scheme[iter])) continue; /* Create our XPATH lookup for the current display's port */ + VIR_FREE(xpath); if (virAsprintf(&xpath, xpath_fmt, scheme[iter], "@port") < 0) goto cleanup; @@ -10733,6 +10739,7 @@ cmdDomDisplay(vshControl *ctl, const vshCmd *cmd) /* Attempt to get the listening addr if set for the current * graphics scheme */ + VIR_FREE(listen_addr); listen_addr = virXPathString(xpath, ctxt); VIR_FREE(xpath); @@ -10788,6 +10795,7 @@ cmdDomDisplay(vshControl *ctl, const vshCmd *cmd) goto cleanup; /* Attempt to get the password */ + VIR_FREE(passwd); passwd = virXPathString(xpath, ctxt); VIR_FREE(xpath); @@ -10840,12 +10848,17 @@ cmdDomDisplay(vshControl *ctl, const vshCmd *cmd) } /* Print out our full URI */ + VIR_FREE(output); output = virBufferContentAndReset(&buf); vshPrint(ctl, "%s", output); /* We got what we came for so return successfully */ ret = true; - break; + if (!all) { + break; + } else { + vshPrint(ctl, "\n"); + } } if (!ret) { diff --git a/tools/virsh.pod b/tools/virsh.pod index 49abda9..2a49553 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1223,13 +1223,15 @@ I<size> is a scaled integer (see B<NOTES> above) which defaults to KiB "B" to get bytes (note that for historical reasons, this differs from B<vol-resize> which defaults to bytes without a suffix). -=item B<domdisplay> I<domain> [I<--include-password>] [[I<--type>] B<type>] +=item B<domdisplay> I<domain> [I<--include-password>] +[[I<--type>] B<type>] [I<--all>] Output a URI which can be used to connect to the graphical display of the domain via VNC, SPICE or RDP. The particular graphical display type can be selected using the B<type> parameter (e.g. "vnc", "spice", "rdp"). If I<--include-password> is specified, the SPICE channel password will be -included in the URI. +included in the URI. If I<--all> is specified, then all show all possible +graphical displays, for a VM could have more than one graphical displays. =item B<domfsinfo> I<domain> -- 1.8.3.1

2 1

[libvirt] QEMU migration with LOCAL STORAGE
by Lulina (A) 08 Oct '16

08 Oct '16

Hello, Libvirt consider it's safe to migrate a guest when its disks are readonly, or cache=none or has coherent cluster fs backend. But I've some questions over that: When migrating guests with LOCAL STORAGE, as qemu uses DRIVE MIRROR to migrate disk images, all storage data will migrate to dest by qemu. So, I don't find it necessary to let the disk cache be none, even its cache is not none, it's still safe to migrate. Is there any situation that destination VM can't see all completed writes? Regards, Lina

1 0

[libvirt] [RFC v2] libvirt vGPU QEMU integration
by Kirti Wankhede 07 Oct '16

07 Oct '16

Hi libvirt experts, Thanks for valuable input on v1 version of RFC. Quick brief, VFIO based mediated device framework provides a way to virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT and IBM's channel IO. This framework reuses VFIO APIs for all the functionalities for mediated devices which are currently being used for pass through devices. This framework introduces a set of new sysfs files for device creation and its life cycle management. Here is the summary of discussion on v1: 1. Discover mediated device: As part of physical device initialization process, vendor driver will register their physical devices, which will be used to create virtual device (mediated device, aka mdev) to the mediated framework. Vendor driver should specify mdev_supported_types in directory format. This format is class based, for example, display class directory format should be as below. We need to define such set for each class of devices which would be supported by mediated device framework. --- mdev_destroy --- mdev_supported_types |-- 11 | |-- create | |-- name | |-- fb_length | |-- resolution | |-- heads | |-- max_instances | |-- params | |-- requires_group |-- 12 | |-- create | |-- name | |-- fb_length | |-- resolution | |-- heads | |-- max_instances | |-- params | |-- requires_group |-- 13 |-- create |-- name |-- fb_length |-- resolution |-- heads |-- max_instances |-- params |-- requires_group In the above example directory '11' represents a type id of mdev device. 'name', 'fb_length', 'resolution', 'heads', 'max_instance' and 'requires_group' would be Read-Only files that vendor would provide to describe about that type. 'create': Write-only file. Mandatory. Accepts string to create mediated device. 'name': Read-Only file. Mandatory. Returns string, the name of that type id. 'fb_length': Read-only file. Mandatory. Returns <number>{K,M,G}, size of framebuffer. 'resolution': Read-Only file. Mandatory. Returns 'hres x vres' format. Maximum supported resolution. 'heads': Read-Only file. Mandatory. Returns integer. Number of maximum heads supported. 'max_instance': Read-Only file. Mandatory. Returns integer. Returns maximum mdev device could be created at the moment when this file is read. This count would be updated by vendor driver. Before creating mdev device of this type, check if max_instance is > 0. 'params' Write-Only file. Optional. String input. Libvirt would pass the string given in XML file to this file and then create mdev device. Set empty string to clear params. For example, set parameter 'frame_rate_limiter=0' to disable frame rate limiter for performance benchmarking, then create device of type 11. The device created would have that parameter set by vendor driver. 'requires_group' Read-Only file. Optional. This should be provided by vendor driver if vendor driver need to group mdev devices in one domain so that vendor driver can use 'first open' to commit resources of all mdev devices associated to that domain and 'last close' to free those. The parent device would look like: <device> <name>pci_0000_86_00_0</name> <capability type='pci'> <domain>0</domain> <bus>134</bus> <slot>0</slot> <function>0</function> <capability type='mdev'>  <type id='11'>  <name>GRID M60-0B</name> <attribute name='fb_length'>512M</attribute> <attribute name='resolution'>2560x1600</attribute> <attribute name='heads'>2</attribute> <attribute name='max_instances'>16</attribute> <attribute name='requires_group'>1</attribute> </type> </capability> <product id='...'>GRID M60</product> <vendor id='0x10de'>NVIDIA</vendor> </capability> </device> 2. Create/destroy mediated device With above example, vGPU device XML would look like: <device> <name>my-vgpu</name> <parent>pci_0000_86_00_0</parent> <capability type='mdev'> <type id='11'/> <group>1</group> <params>'frame_rate_limiter=0'</params> </capability> </device> 'type id' is mandatory. 'group' is optional. It should be a unique number in the system among all the groups created for mdev devices. Its usage is: - not needed if single vGPU device is being assigned to a domain. - only need to be set if multiple vGPUs need to be assigned to a domain and vendor driver have 'requires_group' file in type id directory. - if type id directory include 'requires_group' and user tries to assign multiple vGPUs to a domain without having <group> field in XML, it will create single vGPU. 'params' is optional field. User should set this field if extra parameters need to be set for a particular vGPU device. Libvirt don't need to parse these params. These are meant for vendor driver. Libvirt need to follow the sequence to create device: * Read /sys/../0000\:86\:00.0/11/max_instances. If it is greater than 0, then only proceed else fail. * Set extra params if 'params' field exist in device XML and 'params' file exist in type id directory echo "frame_rate_limiter=0" > /sys/../0000\:86\:00.0/11/params * Autogenerate UUID * Create device: echo "$UUID:<group>" > /sys/../0000\:86\:00.0/11/create where <group> is optional. Group should be unique number among all the groups created for mdev devices. * Clear params, if set earlier: echo "" > /sys/../0000\:86\:00.0/11/params * To destroy device: echo $UUID > /sys/../0000\:86\:00.0/mdev_destroy 3. Start/stop mediated device No change or requirement for libvirt as this will be handled by open() and close() callbacks to vendor driver. In case of multiple devices and 'requires_group' set, this will be handled in 'first open()' and 'last close()' on device in that group. 4. Launch QEMU/VM Pass the mdev sysfs path to QEMU as vfio-pci device. For above vGPU device example: -device vfio-pci,sysfsdev=/sys/bus/mdev/devices/$UUID 5. QEMU/VM Shutdown sequence No change or requirement for libvirt. 6. VM Reset No change or requirement for libvirt as this will be handled via VFIO reset API and QEMU process will keep running as before. 7. Hot-plug It is same syntax to create a virtual device for hot-plug. Thanks, Kirti

8 60

[libvirt] RFC: Exposing "ready" bool (of `query-block-jobs`) or QMP BLOCK_JOB_READY event
by Kashyap Chamarthy 07 Oct '16

07 Oct '16

Backround --------- For QEMU block device jobs, the "ready" boolean field (part of QMP `query-block-jobs`) was introduced in commit ef6dbf1 (available in QEMU v2.2.0 or above): http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ef6dbf1e4 -- blockjob: Add "ready" field "When a block job signals readiness, this is currently reported only through QMP. If qemu wants to use block jobs for internal tasks, there needs to be another way to correctly detect when a block job may be completed. For this reason, introduce a bool "ready" which is set when the block job may be completed." And, libvirt was fixed to use the above field in this commit (available in libvirt v1.2.18 or above): http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=eae5924 -- qemu: Update state of block job to READY only if it actually is ready RFC --- Currently libvirt block APIs (& consequently higher-level applications like Nova which use these APIs) rely on polling for job completion via virDomainGetBlockJobInfo(), which uses QMP `query-block-jobs`, and waits for QEMU to report "offset" == "len", which translates to libvirt "cur" == "end". Based on this, libvirt can take an action (whether to gracefully abort, or pivot to the copy in case of a COPY job). Since QEMU reports the "ready": true field (followed by a BLOCK_JOB_READY QMP event). It would be helpful if libvirt expose this via an API, so upper layers could instead use that, rather than polling. Problem scenario ---------------- When virDomainBlockRebase() is invoked to start a copy job, then aborting the said copy operation with virDomainBlockJobAbort() + flag VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT can result in a potential race condition (due to the way the virDomainGetBlockJobInfo() reports the job status) where the pivot operation fails. Race condition window ~~~~~~~~~~~~~~~~~~~~~ libvirt finds cur==end AND sends a pivot request, all in the window before QEMU would have sent "ready": true field [emitted as part of the QMP `query-block-jobs` command's response, indicating that the job has actually completed], however the pivot request fails because it requires "ready": true. So Eric Blake suggests: QEMU 2.0 or 1.x probably had a synchronous setup where you could never observer cur==end on a non-ready job. But I don't remember enough history to point to when QEMU switched jobs to be a bit more asynchronous. Maybe there was no qemu regression - maybe it was BECAUSE of other block-job additions in 2.2 that offset==len was no longer reliable. I don't know that for sure. But what it DOES sound like is that IF qemu reports "ready": false, offset==len is not reliable, and libvirt should be taught to fudge that. And hopefully, QEMU too old to report "ready:" at all is reliable with regards to offset==len, because that's all we have to go by. For now, I filed this upstream libvirt bug: https://bugzilla.redhat.com/show_bug.cgi?id=1382165 -- virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the "ready" field of `query-block-jobs` However, exposing the "ready" boolean from QMP `query-block-jobs` might be worth considering. -- /kashyap

4 8

[libvirt] [PATCH 0/3] Clean up some perf event issues
by John Ferlan 07 Oct '16

07 Oct '16

Resolve a couple of recently filed issues regarding perf events. Details in each patch. John Ferlan (3): docs: Alter descriptions of perf cpu_cycles util: Clear up some perf error messages util: Check/ignore already disabled event docs/formatdomain.html.in | 2 +- src/libvirt-domain.c | 2 +- src/util/virperf.c | 13 ++++++++----- src/util/virperf.h | 2 +- tools/virsh.pod | 9 +++++---- 5 files changed, 16 insertions(+), 12 deletions(-) -- 2.7.4

2 8

[libvirt] [libvirt-perl PATCH 0/2] Add new flags
by John Ferlan 07 Oct '16

07 Oct '16

Patch 1 is related to the on list iotune length/duration parameter Patch 2 is related to the already pushed vcpu hotpluggable flag These would be pushed once I push the blkdeviotune changes - the order was only because I made the blkdeviotune changes, then built and found that the vcpu hotpluggable flag cause test failure. John Ferlan (2): Add blkdeviotune length parameters Add VIR_DOMAIN_VCPU_HOTPLUGGABLE Changes | 3 ++- Virt.xs | 13 +++++++++++++ lib/Sys/Virt/Domain.pm | 29 +++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+), 1 deletion(-) -- 2.7.4

2 5

[libvirt] PCP libvirt Plugin
by Marko Myllynen 07 Oct '16

07 Oct '16

Hi, FYI, I've written a PCP plugin (PMDA in PCP parlance) to support most hypervisor / domain information and metrics available over the libvirt Python API, it's up to date as of libvirt 2.3 (so it already supports the recently added perf event metrics). In case you haven't heard about PCP, here's a brief intro: The Performance Co-Pilot (PCP, http://www.pcp.io/) system is a toolkit for collecting, archiving, and processing performance metrics. It supports system and application metrics from local and remote hosts, archives, and containers. A typical Linux PCP installation offers over 1,000 metrics by default and is easily extensible with its own plugins, or PMDAs ("Performance Metrics Domain Agents"). In addition to very complete /proc based statistics, readily available PCP PMDAs provide support components like 389 Directory Server, Apache, Ceph, GFS2, Gluster, MySQL, NFS, Oracle, Postfix, PostgreSQL, Samba, and Sendmail, among others. PCP also runs on many platforms, including Linux, Mac OS X, FreeBSD, NetBSD, Solaris, and Windows. And here's Quick Guide to get started with PCP: http://www.pcp.io/docs/guide.html (So PCP comes with handy clients like pmrep(1) for custom metrics reporting, sophisticated logging and inferencing tools, and support for Grafana based Web UI.) The libvirt metrics available with PCP libvirt PMDA and their descriptions are listed below, they include all the recently added perf event metrics as well as combined and per-device metrics for each VM. The plugin is available for Fedora in updates-testing and for Ubuntu from https://bintray.com/pcp/ . As this is a recent addition, the plugin or some of the later additions like per-device metrics have not propagated to all distributions yet. For those using PCP already, they may also manually grab the needed files from the below page without the need to upgrade any PCP packages: https://myllynen.fedorapeople.org/pmdalibvirt/ Upstream code lives here: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=pcp/pcp.git;a=tree;f=src/pmdas/libv… I wonder could this be mentioned at https://libvirt.org/apps.html ? Here's the list of the PCP metrics available with the current git code: libvirt.dominfo.container [VM container] libvirt.dominfo.description [VM description] libvirt.dominfo.memory.boot [VM memory, at boot] libvirt.dominfo.memory.current [VM memory, current] libvirt.dominfo.memory.max [VM memory, maximum] libvirt.dominfo.name [VM name] libvirt.dominfo.os.type [VM OS type] libvirt.dominfo.title [VM title] libvirt.dominfo.type [VM type] libvirt.dominfo.uuid [VM UUID] libvirt.dominfo.vcpu.current [VM vCPUs, current] libvirt.dominfo.vcpu.max [VM vCPUs, maximum] libvirt.domstats.balloon.current [VM balloon size, current] libvirt.domstats.balloon.maximum [VM balloon size, maximum] libvirt.domstats.block.all.allocation [VM backing imgs, total allocation] libvirt.domstats.block.all.backingIndex [VM block devs, backing chain imgs] libvirt.domstats.block.all.capacity [VM backing imgs, total capacity] libvirt.domstats.block.all.fl.reqs [VM block devs, total fl reqs] libvirt.domstats.block.all.fl.times [VM block devs, total fl times] libvirt.domstats.block.all.name [VM block devs, all names] libvirt.domstats.block.all.path [VM block devs, all paths] libvirt.domstats.block.all.physical [VM backing imgs, total physical] libvirt.domstats.block.all.rd.bytes [VM block devs, total rd bytes] libvirt.domstats.block.all.rd.reqs [VM block devs, total rd reqs] libvirt.domstats.block.all.rd.times [VM block devs, total rd times] libvirt.domstats.block.all.wr.bytes [VM block devs, total wr bytes] libvirt.domstats.block.all.wr.reqs [VM block devs, total wr reqs] libvirt.domstats.block.all.wr.times [VM block devs, total wr times] libvirt.domstats.block.allocation [VM backing img, allocation] libvirt.domstats.block.backingIndex [VM block dev, backing chain img] libvirt.domstats.block.capacity [VM backing img, capacity] libvirt.domstats.block.count [VM block devs, count] libvirt.domstats.block.fl.reqs [VM block dev, fl reqs] libvirt.domstats.block.fl.times [VM block dev, fl times] libvirt.domstats.block.name [VM block dev, name] libvirt.domstats.block.path [VM block dev, path] libvirt.domstats.block.physical [VM backing img, physical] libvirt.domstats.block.rd.bytes [VM block dev, rd bytes] libvirt.domstats.block.rd.reqs [VM block dev, rd reqs] libvirt.domstats.block.rd.times [VM block dev, rd times] libvirt.domstats.block.wr.bytes [VM block dev, wr bytes] libvirt.domstats.block.wr.reqs [VM block dev, wr reqs] libvirt.domstats.block.wr.times [VM block dev, wr times] libvirt.domstats.cpu.system [VM CPU time, system] libvirt.domstats.cpu.time [VM CPU time, total] libvirt.domstats.cpu.user [VM CPU time, user] libvirt.domstats.mem.actual [VM memory, balloon size] libvirt.domstats.mem.available [VM memory, available] libvirt.domstats.mem.major_fault [VM memory, major faults] libvirt.domstats.mem.minor_fault [VM memory, minor faults] libvirt.domstats.mem.rss [VM memory, proc RSS] libvirt.domstats.mem.swap_in [VM memory, swapped in total] libvirt.domstats.mem.swap_out [VM memory, swapped out total] libvirt.domstats.mem.unused [VM memory, unused] libvirt.domstats.net.all.name [VM NICs, all names] libvirt.domstats.net.all.rx.bytes [VM NICs, total rx bytes] libvirt.domstats.net.all.rx.drop [VM NICs, total rx drop] libvirt.domstats.net.all.rx.errs [VM NICs, total rx errs] libvirt.domstats.net.all.rx.pkts [VM NICs, total rx pkts] libvirt.domstats.net.all.tx.bytes [VM NICs, total tx bytes] libvirt.domstats.net.all.tx.drop [VM NICs, total tx drop] libvirt.domstats.net.all.tx.errs [VM NICs, total tx errs] libvirt.domstats.net.all.tx.pkts [VM NICs, total tx pkts] libvirt.domstats.net.count [VM NICs, count] libvirt.domstats.net.name [VM NIC, name] libvirt.domstats.net.rx.bytes [VM NIC, rx bytes] libvirt.domstats.net.rx.drop [VM NIC, rx drop] libvirt.domstats.net.rx.errs [VM NIC, rx errs] libvirt.domstats.net.rx.pkts [VM NIC, rx pkts] libvirt.domstats.net.tx.bytes [VM NIC, tx bytes] libvirt.domstats.net.tx.drop [VM NIC, tx drop] libvirt.domstats.net.tx.errs [VM NIC, tx errs] libvirt.domstats.net.tx.pkts [VM NIC, tx pkts] libvirt.domstats.perf.cache_misses [VM perf stats, cache misses] libvirt.domstats.perf.cache_references [VM perf stats, cache references] libvirt.domstats.perf.cmt [VM perf stats, cmt] libvirt.domstats.perf.cpu_cycles [VM perf stats, CPU cycles/instr] libvirt.domstats.perf.instructions [VM perf stats, instructions count] libvirt.domstats.perf.mbml [VM perf stats, mbml] libvirt.domstats.perf.mbmt [VM perf stats, mbmt] libvirt.domstats.vcpu.all.state [VM vCPUs, total state] libvirt.domstats.vcpu.all.time [VM vCPUs, total time] libvirt.domstats.vcpu.all.wait [VM vCPUs, total wait] libvirt.domstats.vcpu.current [VM vCPUs, current] libvirt.domstats.vcpu.maximum [VM vCPUs, maximum] libvirt.domstats.vcpu.state [VM vCPU, state] libvirt.domstats.vcpu.time [VM vCPU, time] libvirt.domstats.vcpu.wait [VM vCPU, wait] libvirt.hv.devices [Libvirt devices] libvirt.hv.domains.active [Libvirt domains, active] libvirt.hv.domains.inactive [Libvirt domains, inactive] libvirt.hv.driver [Libvirt driver] libvirt.hv.interfaces.active [Libvirt interfaces, active] libvirt.hv.interfaces.inactive [Libvirt interfaces, inactive] libvirt.hv.networkfilters [Libvirt network filters] libvirt.hv.networks.active [Libvirt networks, active] libvirt.hv.networks.inactive [Libvirt networks, inactive] libvirt.hv.secrets [Libvirt secrets] libvirt.hv.storagepools.active [Libvirt storage pools, active] libvirt.hv.storagepools.inactive [Libvirt storage pools, inactive] libvirt.hv.uri [Libvirt URI] libvirt.hv.version [Libvirt version] Thanks, -- Marko Myllynen

3 4

[libvirt] [PATCH] virCgroupDetect: Print pid as long long
by Michal Privoznik 07 Oct '16

07 Oct '16

Pids are signed, report them as such. Before: Detected mount/mapping 2:cpuset at /sys/fs/cgroup/cpuset in /machine/qemu-4-fedora.libvirt-qemu/vcpu0 for pid 18446744073709551615 After: Detected mount/mapping 2:cpuset at /sys/fs/cgroup/cpuset in /machine/qemu-4-fedora.libvirt-qemu/vcpu0 for pid -1 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/vircgroup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c index 8b52816..0a06a8a 100644 --- a/src/util/vircgroup.c +++ b/src/util/vircgroup.c @@ -732,11 +732,12 @@ virCgroupDetect(virCgroupPtr group, return -1; } - VIR_DEBUG("Detected mount/mapping %zu:%s at %s in %s for pid %llu", i, + VIR_DEBUG("Detected mount/mapping %zu:%s at %s in %s for pid %lld", + i, virCgroupControllerTypeToString(i), group->controllers[i].mountPoint, group->controllers[i].placement, - (unsigned long long)pid); + (long long) pid); } return 0; -- 2.8.4

3 3

[libvirt] [PATCH] private_syms: add virLogFilterListFree to libvirt_private.syms
by Erik Skultety 06 Oct '16

06 Oct '16

Commit 660468b1 forgot to add it, so let's add it now to prevent future linker issues. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- Pushed under trivial rule src/libvirt_private.syms | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index c4af57d..923afd1 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1872,6 +1872,7 @@ virLockSpaceReleaseResourcesForOwner; virLogDefineFilter; virLogDefineOutput; virLogFilterFree; +virLogFilterListFree; virLogGetDefaultPriority; virLogGetFilters; virLogGetNbFilters; -- 2.5.5

1 0

[libvirt] [PATCH] qemu_process: add pid of vm in domain log
by Chen Hanxiao 06 Oct '16

06 Oct '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> Add pid of VM in domain log. We used to show this info in debug log. For example: If a process send SIGKILL to a qemu process, we could find something in audit logs. Then the pid of VM in domain log will be helpful. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/qemu/qemu_process.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 27d04a4..8510a89 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5392,11 +5392,14 @@ qemuProcessLaunch(virConnectPtr conn, _("Domain %s didn't show up"), vm->def->name); rv = -1; } - VIR_DEBUG("QEMU vm=%p name=%s running with pid=%llu", - vm, vm->def->name, (unsigned long long)vm->pid); + qemuDomainLogContextWrite(logCtxt, + "QEMU vm=%p name=%s running with pid=%llu\n", + vm, + vm->def->name, + (unsigned long long)vm->pid); } else { - VIR_DEBUG("QEMU vm=%p name=%s failed to spawn", - vm, vm->def->name); + qemuDomainLogContextWrite(logCtxt, "QEMU vm=%p name=%s failed to spawn", + vm, vm->def->name); } VIR_DEBUG("Writing early domain status to disk"); -- 1.8.3.1

3 2

[libvirt] [PATCH] m4: Drop PKG_PROG_PKG_CONFIG compatibility code
by Andrea Bolognani 06 Oct '16

06 Oct '16

This was needed for RHEL 4 vintage distributions, which we haven't supported for a long time now. --- m4/virt-pkgconfig-back-compat.m4 | 23 ----------------------- 1 file changed, 23 deletions(-) delete mode 100644 m4/virt-pkgconfig-back-compat.m4 diff --git a/m4/virt-pkgconfig-back-compat.m4 b/m4/virt-pkgconfig-back-compat.m4 deleted file mode 100644 index 7eab84b..0000000 --- a/m4/virt-pkgconfig-back-compat.m4 +++ /dev/null @@ -1,23 +0,0 @@ -dnl -dnl To support the old pkg-config from RHEL4 vintage, we need -dnl to define the PKG_PROG_PKG_CONFIG macro if its not already -dnl present -m4_ifndef([PKG_PROG_PKG_CONFIG], - [AC_DEFUN([PKG_PROG_PKG_CONFIG], -[m4_pattern_forbid([^_?PKG_[A-Z_]+$]) -m4_pattern_allow([^PKG_CONFIG(_PATH)?$]) -AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])dnl -if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then - AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) -fi -if test -n "$PKG_CONFIG"; then - _pkg_min_version=m4_default([$1], [0.9.0]) - AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version]) - if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then - AC_MSG_RESULT([yes]) - else - AC_MSG_RESULT([no]) - PKG_CONFIG="" - fi -fi[]dnl -])]) -- 2.7.4

2 1

[libvirt] Question about QEMU + hugepages + NUMA memory + migration
by Sam Bobroff 06 Oct '16

06 Oct '16

Hi libvirt people, I've been looking at a (probable) bug and I'm not sure how to progress. The situation is a bit complicated and involves both QEMU and libvirt (and I think it may have been looked at already) so I would really appreciate some advice on how to approach it. I'm using a pretty recent master version of libvirt from git and I'm testing on a ppc64le host with a similar guest but this doesn't seem to be arch-specific. If I create a QEMU guest (e.g. via virt-install) that requests both hugepage backing on the host and NUMA memory placement on the host, the NUMA placement seems to be ignored. If I do: # echo 0 > /proc/sys/vm/nr_hugepages # echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-16384kB/nr_hugepages # virt-install --name tmp --memory=4096 --graphics none --memorybacking hugepages=yes --disk none --import --wait 0 --numatune=8 ... then hugepages are allocated on node 0 and the machine starts successfully, which seems like a bug. I believe it should fail to start due to insufficient memory, and in fact that is what happens if cgroup support isn't detected in the host: there seems to be a fall-back path in libvirt (probably using mbind()) that works as I would expect. Note: the relevant part of the guest XML seems to be this: »·······<memoryBacking> »·······»·······<hugepages/> »·······</memoryBacking> »·······<numatune> »·······»·······<memory mode='strict' nodeset='8'/> »·······</numatune> It seems fairly clear what is happening: although QEMU is capable of allocating hugepages on specific NUMA nodes (using "memory-backend-file") libvirt is not passing those options to QEMU in this situation. I investigated this line of reasoning and if I hack libvirt to pass those options to QEMU it does indeed fix the problem... but it renders the machine state migration-incompatible with unfixed versions. This seems to have been why this hasn't been fixed already :-( So what can we do? I assume it's not acceptible to just break migration with a bugfix, and I can only think of two ways to fix migration: (a) Add a new flag to the XML, and for guests without the flag, maintain the old buggy behaviour (and therefore migration compatability). (b) Hack QEMU so that migration can succeed between un-fixed and fixed versions. (And possibly also in the reverse direction?) I don't like (a) because it's visible in the XML, and would have to be carried forever (or at least a long time?). I don't really like (b) either because it's tricky, and even if it could be made to work reliably, it would add mess and risk to the migration code. I'm not sure how the QEMU community would feel about it either. However, I did hack up some code and it worked at least in some simple cases. Can anyone see a better approach? Is anyone already working on this? Thanks, Sam.

2 5

[libvirt] [PATCH] virt-yajl: Fix detection of yajl requirements
by Martin Kletzander 06 Oct '16

06 Oct '16

Running the output of qemu -help doesn't make any sense. We should be looking for libvirt being mentioned in the output. This worked by accident, let's make it work as expected it to. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- m4/virt-yajl.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/virt-yajl.m4 b/m4/virt-yajl.m4 index adf2819eeb66..8c452adca653 100644 --- a/m4/virt-yajl.m4 +++ b/m4/virt-yajl.m4 @@ -26,7 +26,7 @@ AC_DEFUN([LIBVIRT_CHECK_YAJL],[ AC_PATH_PROGS([QEMU], [qemu-kvm qemu kvm qemu-system-x86_64], [], [$PATH:/usr/bin:/usr/libexec]) if test -x "$QEMU"; then - if `$QEMU -help | grep libvirt` >/dev/null; then + if $QEMU -help 2>/dev/null | grep -q libvirt; then with_yajl=yes else [qemu_version_sed='s/.*ersion $[0-9.,]*$.*/\1/'] -- 2.10.1

2 1

[libvirt] [PATCH] vsh: Fix warnings in command line completer
by Jiri Denemark 06 Oct '16

06 Oct '16

GCC complained that vsh.c: In function 'vshReadlineOptionsGenerator': vsh.c:2622:29: warning: unused variable 'opt' [-Wunused-variable] const vshCmdOptDef *opt = &cmd->opts[list_index]; ^ vsh.c: In function 'vshReadlineParse': vsh.c:2830:44: warning: 'opt' may be used uninitialized in this function [-Wmaybe-uninitialized] completed_list = opt->completer(autoCompleteOpaque, Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Notes: I'm not very fond of the second hunk, but the completer is such a horrible piece of code I couldn't believe it was pushed. I just made the easiest fix and ran away from the code screaming. tools/vsh.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/vsh.c b/tools/vsh.c index cdd1cba..420eb79 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -2619,7 +2619,6 @@ vshReadlineOptionsGenerator(const char *text, int state, const vshCmdDef *cmd_pa return NULL; while ((name = cmd->opts[list_index].name)) { - const vshCmdOptDef *opt = &cmd->opts[list_index]; char *res; list_index++; @@ -2648,7 +2647,7 @@ vshReadlineParse(const char *text, int state) static vshCommandParser parser, sanitizer; vshCommandToken tk; static const vshCmdDef *cmd; - const vshCmdOptDef *opt; + const vshCmdOptDef *opt = NULL; char *tkdata, *optstr, *const_tkdata, *completed_name; char *res = NULL; static char *ctext, *sanitized_text; -- 2.10.0

4 4

[libvirt] [PATCH 0/3] qemu: report block job errors from qemu to the user
by Nikolay Shirokovskiy 06 Oct '16

06 Oct '16

So that you can see nice report on migration: "error: operation failed: migration of disk sda failed: No space left on device" Nikolay Shirokovskiy (3): qemu: simplify switch case for blockjob events qemu: use blockjob completed event's error field to detect errors qemu: report block job errors from qemu to the user src/qemu/qemu_blockjob.c | 13 +++++++++++-- src/qemu/qemu_blockjob.h | 3 ++- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 4 ++-- src/qemu/qemu_migration.c | 34 ++++++++++++++++++++++------------ src/qemu/qemu_monitor.c | 5 +++-- src/qemu/qemu_monitor.h | 4 +++- src/qemu/qemu_monitor_json.c | 12 +++++------- src/qemu/qemu_process.c | 3 +++ 9 files changed, 52 insertions(+), 27 deletions(-) -- 1.8.3.1

3 9

[libvirt] [libvirt-glib 00/20] gconfig: <graphics> configuration work
by Christophe Fergeau 06 Oct '16

06 Oct '16

Hey, This series groups 2 series which were sent previously for review, one from Visarion https://www.redhat.com/archives/libvir-list/2016-August/msg00868.html and one from Fidencio https://www.redhat.com/archives/libvir-list/2016-March/msg00993.html I'm putting them together as they touch the same piece of code and thus conflict with each other. The separation would happen at 11/20 "gconfig: Implement gvir_config_domain_graphics_spice_get_tls_port()" if I were to send these separately. Visarion's changes add support for configuring the <listen> node for the graphics node, and Fidencio's changes add some base classes to make generic configuration of local/remote graphics nodes easier, regardless of their type (VNC/SPICE for example). This incorporate the various changes I suggested during review, in particular it renames _set_listen_nodes() in the original series to just _set_listen(), better naming suggestions welcome. I've also added a few patches of my own which made sense to have for completeness. Christophe

2 23

[libvirt] [[PATCH v2] 0/4] try harder to get dest qemu errors on migation
by Nikolay Shirokovskiy 06 Oct '16

06 Oct '16

Hi, all. In case migration fails due to destination qemu exits unexpectedly user recevies the qemu log in the error message. Unfortunately log is truncated and the most interesting part is missed (below is the example of such a log [1]). Actually for the most cases the first patch will be enough to fix the issue. Originally I thought the problem is qemu logging and reading the log are not in sync (which is true) so I tried to fix it as well in the next patches. * diff from v1: 1. split changes to libvirtd and virtlogd to different patches 2. split virtlogd patch further 3. simplify handling eofs and hangups in draining function [1] log example: CPU Reset (CPU 0) EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 ES =0000 00000000 00000000 00000000 CS =0000 00000000 00000000 00000000 SS =0000 00000000 00000000 00000000 DS =0000 00000000 00000000 00000000 FS =0000 00000000 00000000 00000000 GS =0000 00000000 00000000 00000000 LDT=0000 00000000 00000000 00000000 TR =0000 00000000 00000000 00000000 GDT= 00000000 00000000 IDT= 00000000 00000000 CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=0000000000000000 DR7=0000000000000000 CCS=00000000 CCD=00000000 CCO=DYNAMIC EFER=0000000000000000 FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 CPU Reset (CPU 1) EAX=00000000 EBX=00000000 ECX=00000000 EDX=000206a1 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 CCS=00000000 CCD=00000000 CCO=DYNAMIC EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=000 qemu: terminating on signal 15 from pid 168133 Nikolay Shirokovskiy (4): util: remove 1k limit for error messages virtlogd: stop reading on EOF instead of hangup virtlogd: add flag to wait for log end on read qemu: if virtlogd is used then read log tail correctly src/logging/log_handler.c | 46 ++++++++++++++++++++++++++++++++++++++++------ src/logging/log_protocol.x | 5 +++++ src/qemu/qemu_domain.c | 7 ++++++- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_process.c | 2 ++ src/util/virerror.c | 9 ++++----- 6 files changed, 58 insertions(+), 12 deletions(-) -- 1.8.3.1

3 12