December 2017 - Devel - libvirt List Archives

[libvirt] [PATCH] docs: Fix news.xml syntax
by John Ferlan 13 Dec '17

13 Dec '17

Commit id '1241e487' used <code><interface></code> which is not valid syntax for a <summary>. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Pushed under build breaker rule as CI libvirt-master-check was failing docs/news.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/news.xml b/docs/news.xml index 7509416ec..bb611b7ba 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -39,8 +39,7 @@ <section title="Improvements"> <change> <summary> - Xen: Add support for multiple IP addresses on - <code><interface></code> devices + Xen: Add support for multiple IP addresses on interface devices </summary> </change> </section> -- 2.13.6

1 0

[libvirt] [PATCH] xenconfig: fix issues found by coverity in multiple IP support
by Marek Marczykowski-Górecki 13 Dec '17

13 Dec '17

- virStringSplit may return NULL - VIR_ALLOC_N initialize the array already Cc: John Ferlan <jferlan(a)redhat.com> Signed-off-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com> --- src/xenconfig/xen_common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c index ff0df5fb7..ca3b4dee6 100644 --- a/src/xenconfig/xen_common.c +++ b/src/xenconfig/xen_common.c @@ -968,6 +968,9 @@ xenParseVif(virConfPtr conf, virDomainDefPtr def, const char *vif_typename) char **ip_list = virStringSplit(ip, " ", 0); size_t i; + if (!ip_list) + goto cleanup; + for (i = 0; ip_list[i]; i++) { if (virDomainNetAppendIPAddress(net, ip_list[i], 0, 0) < 0) { virStringListFree(ip_list); @@ -1191,8 +1194,6 @@ xenMakeIPList(virNetDevIPInfoPtr guestIP) if (!address_array[i]) goto cleanup; } - address_array[guestIP->nips] = NULL; - ret = virStringListJoin((const char**)address_array, " "); cleanup: -- 2.13.6

2 1

[libvirt] [PATCH 0/4] Complete storage pool object privatization and use of RWLockable
by John Ferlan 13 Dec '17

13 Dec '17

After this series the storage pool will be private to virstorageobj and will be a self locking list of hash tables similar to other drivers. All that remains will be to make the storage volume lists be hash tables, but that's only once this is accepted. First patch is related to review comment from last series. John Ferlan (4): storage: Fix path check in storagePoolLookupByTargetPath storage: Privatize virStoragePoolObjListPtr storage: Convert virStoragePoolObjList to use virObjectRWLockable storage: Reduce need for using storageDriverLock src/conf/virstorageobj.c | 649 ++++++++++++++++++++++++++++++------------- src/conf/virstorageobj.h | 12 +- src/libvirt_private.syms | 2 +- src/storage/storage_driver.c | 180 +++++------- src/test/test_driver.c | 51 ++-- 5 files changed, 545 insertions(+), 349 deletions(-) -- 2.13.6

2 8

[libvirt] [RFC v2] arm64: KVM: KVM API extensions for SVE
by Dave Martin 13 Dec '17

13 Dec '17

Hi all, Here's a second, slightly more complete stab at the KVM API extensions for SVE. I haven't started implementing in earnest yet, so any comments at this stage would be very helpful. [libvir-list readers: this is a proposal for extending the KVM API on AArch64 systems to support the Scalable Vector Extension [1], [2]. This has some interesting configuration and migration quirks -- see "Vector length control" in particular, and feel free to throw questions my way...] Cheers ---Dave [1] Overview https://community.arm.com/processors/b/blog/posts/technology-update-the-sca… [2] Architecture spec https://developer.arm.com/products/architecture/a-profile/docs/ddi0584/late… ---8<--- New feature KVM_ARM_VCPU_SVE: * enables exposure of SVE to the guest * enables visibility of / access to KVM_REG_ARM_SVE_*() via KVM reg ioctls. The main purposes of this are a) is to allow userspace to hide weird-sized registers that it doesn't understand how to deal with, and b) allow SVE to be hidden from the VM so that it can migrate to nodes that don't support SVE. ZCR_EL1 is not specifically hidden, since it is "just a system register" and does not have a weird size or semantics etc. Registers: * A new register size is defined KVM_REG_SIZE_U2048 (which can be encoded sensibly using the next unused value for the reg size field in the reg ID) (grep KVM_REG_SIZE_). * Reg IDs for the SVE regs will be defined as "coproc" 0x14 (i.e., 0x14 << KVM_REG_ARM_COPROC_SHIFT) KVM_REG_ARM_SVE_Z(n, i) is slice i of Zn (each slice is 2048 bits) KVM_REG_ARM_SVE_P(n, i) is slice i of Pn (each slice is 256 bits) KVM_REG_ARM_FFR(i) is slice i of FFR (each slice is 256 bits) The slice sizes allow each register to be read/written in exactly one slice for SVE. Surplus bits (beyond the maximum VL supported by the vcpu) will be read-as-zero write-ignore. Reading/writing surplus slices will probably be forbidden, and the surplus slices would not be reported via KVM_GET_REG_LIST. (We could make these RAZ/WI too, but I'm not sure if it's worth it, or why it would be useful.) Future extensions to the architecture might grow the registers up to 32 slices: this may or may not actually happen, but SVE keeps the possibilty open. I've tried to design for it. * KVM_REG_ARM_SVE_Z(n, 0) bits [127:0] alias Vn in KVM_REG_ARM_CORE(fp_regs.v[n]) .. KVM_REG_ARM_CORE(fp_regs.v[n])+3. It's simplest for userspace if the two views always appear to be in sync, but it's unclear whether this is really useful. Perhaps this can be relaxed if it's a big deal for the KVM implementation; I don't know yet. Vector length control: Some means is needed to determine the set of vector lengths visible to guest software running on a vcpu. When a vcpu is created, the set would be defaulted to the maximal set that can be supported while permitting each vcpu to run on any host CPU. SVE has some virtualisation quirks which mean that this set may exclude some vector lengths that are available for host userspace applications. The common case should be that the sets are the same however. * New ioctl KVM_ARM_VCPU_{SET,GET}_SVE_VLS to set or retrieve the set of vector lengths available to the guest. Adding random vcpu ioctls To configure a non-default set of vector lengths, KVM_ARM_VCPU_SET_SVE_VLS can be called: this would only be permitted before the vcpu is first run. This is primarily intended for supporting migration, by providing a robust check that the destination node will run the vcpu correctly. In a cluster with non-uniform SVE implementation across nodes, this also allows a specific set of VLs to be requested that the caller knows is usable across the whole cluster. For migration purposes, userspace would need to do KVM_ARM_VCPU_GET_SVE_VLS at the origin node and store the returned set as VM metadata: on the destination node, KVM_ARM_VCPU_SET_SVE_VLS should be used to request that exact set of VLs: if the destination node can't support that set of VLs, the call will fail. The interface would look something like: ioctl(vcpu_fd, KVM_ARM_SVE_SET_VLS, __u64 vqs[SVE_VQ_MAX / 64]); How to expose this to the user in an intelligible way would be a problem for userspace to solve. At present, other than initialising each vcpu to the maximum supportable set of VLs, I don't propose having a way to probe for what sets of VLs are supportable: the above call either succeeds or fails. Cheers ---Dave

2 2

[libvirt] [PATCH 0/6] Improvements to CPU frequency reporting
by Andrea Bolognani 13 Dec '17

13 Dec '17

A few steps towards eventually fixing https://bugzilla.redhat.com/show_bug.cgi?id=1206353 The commit message for patch 6/6 contains most of the rationale, previous patches are cleanups. If not for the new test case added with patch 1/6, the overall diffstat would be negative. Andrea Bolognani (6): tests: Add host CPU data for Moonshot (RHEL 7.4) util: Introduce virHostCPUGetInfoParseCPUInfo() util: Introduce virHostCPUGetInfoParseCPUFrequency() util: Tweak virHostCPUGetInfoParseCPUFrequency() util: Tweak s390(x) case for CPU frequency util: Don't report CPU frequency for ARM hosts src/util/virhostcpu.c | 151 ++++++++++----------- .../linux-aarch64-rhel74-moonshot.cpuinfo | 72 ++++++++++ .../linux-aarch64-rhel74-moonshot.expected | 1 + .../linux-armv6l-raspberrypi.expected | 2 +- .../linux-rhel74-moonshot/cpu/cpu0/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu0/online | 1 + .../cpu/cpu0/topology/core_id | 1 + .../cpu/cpu0/topology/core_siblings | 1 + .../cpu/cpu0/topology/core_siblings_list | 1 + .../cpu/cpu0/topology/physical_package_id | 1 + .../cpu/cpu0/topology/thread_siblings | 1 + .../cpu/cpu0/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu1/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu1/online | 1 + .../cpu/cpu1/topology/core_id | 1 + .../cpu/cpu1/topology/core_siblings | 1 + .../cpu/cpu1/topology/core_siblings_list | 1 + .../cpu/cpu1/topology/physical_package_id | 1 + .../cpu/cpu1/topology/thread_siblings | 1 + .../cpu/cpu1/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu2/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu2/online | 1 + .../cpu/cpu2/topology/core_id | 1 + .../cpu/cpu2/topology/core_siblings | 1 + .../cpu/cpu2/topology/core_siblings_list | 1 + .../cpu/cpu2/topology/physical_package_id | 1 + .../cpu/cpu2/topology/thread_siblings | 1 + .../cpu/cpu2/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu3/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu3/online | 1 + .../cpu/cpu3/topology/core_id | 1 + .../cpu/cpu3/topology/core_siblings | 1 + .../cpu/cpu3/topology/core_siblings_list | 1 + .../cpu/cpu3/topology/physical_package_id | 1 + .../cpu/cpu3/topology/thread_siblings | 1 + .../cpu/cpu3/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu4/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu4/online | 1 + .../cpu/cpu4/topology/core_id | 1 + .../cpu/cpu4/topology/core_siblings | 1 + .../cpu/cpu4/topology/core_siblings_list | 1 + .../cpu/cpu4/topology/physical_package_id | 1 + .../cpu/cpu4/topology/thread_siblings | 1 + .../cpu/cpu4/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu5/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu5/online | 1 + .../cpu/cpu5/topology/core_id | 1 + .../cpu/cpu5/topology/core_siblings | 1 + .../cpu/cpu5/topology/core_siblings_list | 1 + .../cpu/cpu5/topology/physical_package_id | 1 + .../cpu/cpu5/topology/thread_siblings | 1 + .../cpu/cpu5/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu6/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu6/online | 1 + .../cpu/cpu6/topology/core_id | 1 + .../cpu/cpu6/topology/core_siblings | 1 + .../cpu/cpu6/topology/core_siblings_list | 1 + .../cpu/cpu6/topology/physical_package_id | 1 + .../cpu/cpu6/topology/thread_siblings | 1 + .../cpu/cpu6/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/cpu7/node0 | 1 + .../linux-rhel74-moonshot/cpu/cpu7/online | 1 + .../cpu/cpu7/topology/core_id | 1 + .../cpu/cpu7/topology/core_siblings | 1 + .../cpu/cpu7/topology/core_siblings_list | 1 + .../cpu/cpu7/topology/physical_package_id | 1 + .../cpu/cpu7/topology/thread_siblings | 1 + .../cpu/cpu7/topology/thread_siblings_list | 1 + .../linux-rhel74-moonshot/cpu/kernel_max | 1 + .../linux-rhel74-moonshot/cpu/offline | 1 + .../linux-rhel74-moonshot/cpu/online | 1 + .../linux-rhel74-moonshot/cpu/possible | 1 + .../linux-rhel74-moonshot/cpu/present | 1 + .../linux-rhel74-moonshot/node/has_cpu | 1 + .../linux-rhel74-moonshot/node/has_memory | 1 + .../linux-rhel74-moonshot/node/has_normal_memory | 1 + .../linux-rhel74-moonshot/node/node0/cpu0 | 1 + .../linux-rhel74-moonshot/node/node0/cpu1 | 1 + .../linux-rhel74-moonshot/node/node0/cpu2 | 1 + .../linux-rhel74-moonshot/node/node0/cpu3 | 1 + .../linux-rhel74-moonshot/node/node0/cpu4 | 1 + .../linux-rhel74-moonshot/node/node0/cpu5 | 1 + .../linux-rhel74-moonshot/node/node0/cpu6 | 1 + .../linux-rhel74-moonshot/node/node0/cpu7 | 1 + .../linux-rhel74-moonshot/node/node0/cpulist | 1 + .../linux-rhel74-moonshot/node/node0/cpumap | 1 + .../linux-rhel74-moonshot/node/online | 1 + .../linux-rhel74-moonshot/node/possible | 1 + tests/virhostcputest.c | 1 + 89 files changed, 230 insertions(+), 81 deletions(-) create mode 100644 tests/virhostcpudata/linux-aarch64-rhel74-moonshot.cpuinfo create mode 100644 tests/virhostcpudata/linux-aarch64-rhel74-moonshot.expected create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu0/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu1/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu2/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu3/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu4/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu5/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu6/topology/thread_siblings_list create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/node0 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/core_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/core_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/core_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/physical_package_id create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/thread_siblings create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/cpu7/topology/thread_siblings_list create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/kernel_max create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/offline create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/possible create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/cpu/present create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/has_cpu create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/has_memory create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/has_normal_memory create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu0 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu1 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu2 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu3 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu4 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu5 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu6 create mode 120000 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpu7 create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpulist create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/node0/cpumap create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/online create mode 100644 tests/virhostcpudata/linux-rhel74-moonshot/node/possible -- 2.14.3

3 20

[libvirt] [PATCH v2 1/1] audit: Log only an info message if audit_level < 2 and audit is not supported
by Marc Hartmayer 13 Dec '17

13 Dec '17

Replace the error message during startup of libvirtd with an info message if audit_level < 2 and audit is not supported by the kernel. Audit is not supported by the current kernel if the kernel does not have audit compiled in or if audit is disabled (e.g. by the kernel cmdline). Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- daemon/libvirtd.c | 2 +- src/util/viraudit.c | 16 ++++++++++++++-- src/util/viraudit.h | 2 +- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 5103e8debea6..6d3b83355bca 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1422,7 +1422,7 @@ int main(int argc, char **argv) { if (config->audit_level) { VIR_DEBUG("Attempting to configure auditing subsystem"); - if (virAuditOpen() < 0) { + if (virAuditOpen(config->audit_level) < 0) { if (config->audit_level > 1) { ret = VIR_DAEMON_ERR_AUDIT; goto cleanup; diff --git a/src/util/viraudit.c b/src/util/viraudit.c index 17e58b3a9574..3c444b69ab9f 100644 --- a/src/util/viraudit.c +++ b/src/util/viraudit.c @@ -55,11 +55,23 @@ static int auditfd = -1; #endif static bool auditlog; -int virAuditOpen(void) +int virAuditOpen(ATTRIBUTE_UNUSED unsigned int audit_level) { #if WITH_AUDIT if ((auditfd = audit_open()) < 0) { - virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + /* You get these error codes only when the kernel does not + * have audit compiled in or it's disabled (e.g. by the kernel + * cmdline) */ + if (errno == EINVAL || errno == EPROTONOSUPPORT || + errno == EAFNOSUPPORT) { + if (audit_level < 2) + VIR_INFO("Audit is not supported by the kernel"); + else + virReportError(VIR_FROM_THIS, "%s", _("Audit is not supported by the kernel")); + } else { + virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + } + return -1; } diff --git a/src/util/viraudit.h b/src/util/viraudit.h index ed3d66ab5d0f..478dc8408f4e 100644 --- a/src/util/viraudit.h +++ b/src/util/viraudit.h @@ -32,7 +32,7 @@ typedef enum { VIR_AUDIT_RECORD_RESOURCE, } virAuditRecordType; -int virAuditOpen(void); +int virAuditOpen(unsigned int audit_level); void virAuditLog(bool enabled); -- 2.13.4

2 2

[libvirt] [PATCH v2] autogen.sh: tell user the correct make command
by Daniel P. Berrange 13 Dec '17

13 Dec '17

When autogen.sh finishes it helpfully prints "Now type 'make' to compile libvirt." which is fine if on a host with GNU make, but on *BSD running 'make' will end in tears. We should tell users to run 'gmake' on these platforms. If 'gmake' doesn't exist then we should report an error too "GNU make is required to build libvirt" Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- autogen.sh | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index d5d836aa71..ea94528de6 100755 --- a/autogen.sh +++ b/autogen.sh @@ -175,6 +175,18 @@ if test "$OBJ_DIR"; then } fi +# Make sure we can find GNU make and tell the user +# the right command to run +if make -v 2>&1 | grep -q "GNU Make"; then + MAKE=make +else + if which gmake >/dev/null 2>&1; then + MAKE=gmake + else + die "GNU make is required to build libvirt" + fi +fi + if test -z "$*" && test -z "$extra_args" && test -f config.status; then echo "Running config.status..." ./config.status --recheck || { @@ -193,4 +205,4 @@ else fi echo -echo "Now type 'make' to compile libvirt." +echo "Now type '$MAKE' to compile libvirt." -- 2.14.3

2 2

[libvirt] [PATCH] audit: Log only an info message if audit_level < 2 and audit is not supported
by Marc Hartmayer 13 Dec '17

13 Dec '17

Replace the error message during startup of libvirtd with an info message if audit_level < 2 and audit is not supported by the kernel. Audit is not supported by the current kernel if the kernel does not have audit compiled in or if audit is disabled (e.g. by the kernel cmdline). Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- daemon/libvirtd.c | 2 +- src/util/viraudit.c | 17 +++++++++++++++-- src/util/viraudit.h | 2 +- 3 files changed, 17 insertions(+), 4 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 589b32192e3d..6bbff0d45684 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1418,7 +1418,7 @@ int main(int argc, char **argv) { if (config->audit_level) { VIR_DEBUG("Attempting to configure auditing subsystem"); - if (virAuditOpen() < 0) { + if (virAuditOpen(config->audit_level) < 0) { if (config->audit_level > 1) { ret = VIR_DAEMON_ERR_AUDIT; goto cleanup; diff --git a/src/util/viraudit.c b/src/util/viraudit.c index 17e58b3a9574..9b755e384f24 100644 --- a/src/util/viraudit.c +++ b/src/util/viraudit.c @@ -55,11 +55,24 @@ static int auditfd = -1; #endif static bool auditlog; -int virAuditOpen(void) +int virAuditOpen(unsigned int audit_level) { #if WITH_AUDIT if ((auditfd = audit_open()) < 0) { - virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + /* You get these error codes only when the kernel does not + * have audit compiled in or it's disabled (e.g. by the kernel + * cmdline) */ + if (errno == EINVAL || errno == EPROTONOSUPPORT || + errno == EAFNOSUPPORT) { + const char msg[] = "Audit is not supported by the kernel"; + if (audit_level < 2) + VIR_INFO("%s", _(msg)); + else + virReportError(VIR_FROM_THIS, "%s", _(msg)); + } else { + virReportSystemError(errno, "%s", _("Unable to initialize audit layer")); + } + return -1; } diff --git a/src/util/viraudit.h b/src/util/viraudit.h index edaddf3c886f..e0471be1a85d 100644 --- a/src/util/viraudit.h +++ b/src/util/viraudit.h @@ -32,7 +32,7 @@ typedef enum { VIR_AUDIT_RECORD_RESOURCE, } virAuditRecordType; -int virAuditOpen(void); +int virAuditOpen(unsigned int audit_level); void virAuditLog(bool enabled); -- 2.13.4

2 5

[libvirt] [PATCH] virsh: fix typo s/node filters/network filters/
by Daniel P. Berrange 12 Dec '17

12 Dec '17

Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Pushed under trivial rule tools/virsh-nwfilter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-nwfilter.c b/tools/virsh-nwfilter.c index 0f64c446f3..40bc193ad5 100644 --- a/tools/virsh-nwfilter.c +++ b/tools/virsh-nwfilter.c @@ -272,7 +272,7 @@ virshNWFilterListCollect(vshControl *ctl, } /* there was an error during the call */ - vshError(ctl, "%s", _("Failed to list node filters")); + vshError(ctl, "%s", _("Failed to list network filters")); goto cleanup; -- 2.14.3

1 0

Re: [libvirt] [PATCH 12/12] qemu: block: add iSER support in qemu block type
by Peter Krempa 12 Dec '17

12 Dec '17

This is not a properly formatted patch. Please use git send-email for submissions. Also read https://libvirt.org/hacking.html for coding style guidelines ... On Tue, Dec 12, 2017 at 16:53:48 +0800, zhangshengyu(a)fusionstack.cn wrote: > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c > index 66e21c4bd..c83ce5718 100644 > --- a/src/conf/domain_conf.c > +++ b/src/conf/domain_conf.c > @@ -4554,6 +4554,11 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDefPtr dev, > disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI && > virDomainPostParseCheckISCSIPath(&disk->src->path) < 0) > return -1; > + > + if (disk->src->type == VIR_STORAGE_TYPE_NETWORK && > + disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISER && > + virDomainPostParseCheckISCSIPath(&disk->src->path) < 0) > + return -1; ... like how to format the code properly. > > if (disk->bus != VIR_DOMAIN_DISK_BUS_VIRTIO && > virDomainCheckVirtioOptions(disk->virtio) < 0) > @@ -5160,7 +5165,8 @@ virDomainDiskDefValidate(const virDomainDiskDef *disk) > if (!(disk->src->type == VIR_STORAGE_TYPE_BLOCK || > disk->src->type == VIR_STORAGE_TYPE_VOLUME || > (disk->src->type == VIR_STORAGE_TYPE_NETWORK && > - disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI))) { > + (disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI || > + disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISER)))) { > virReportError(VIR_ERR_CONFIG_UNSUPPORTED, > _("disk '%s' improperly configured for a " > "device='lun'"), disk->dst); > diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c > index 585f0255e..a9543293d 100644 > --- a/src/qemu/qemu_block.c > +++ b/src/qemu/qemu_block.c > @@ -831,7 +831,7 @@ qemuBlockStorageSourceGetISCSIProps(virStorageSourcePtr src) > "s:portal", portal, > "s:target", target, > "u:lun", lun, > - "s:transport", "tcp", > + "s:transport", src->protocol == VIR_STORAGE_NET_PROTOCOL_ISER? "iser":"tcp", too long line. > "S:user", username, > "S:password-secret", objalias, > NULL)); > @@ -1030,6 +1030,7 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src) > break; > > case VIR_STORAGE_NET_PROTOCOL_ISCSI: > + case VIR_STORAGE_NET_PROTOCOL_ISER: Is it really a new protocol? Isn't it just a variation of ISCSI. Qemu treats it as a variation. > if (!(fileprops = qemuBlockStorageSourceGetISCSIProps(src))) > return NULL; > break; > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c > index d7150cae1..76b2a6cc9 100644 > --- a/src/qemu/qemu_domain.c > +++ b/src/qemu/qemu_domain.c > @@ -8133,7 +8133,7 @@ int > qemuDomainDefValidateDiskLunSource(const virStorageSource *src) > { > if (virStorageSourceGetActualType(src) == VIR_STORAGE_TYPE_NETWORK) { > - if (src->protocol != VIR_STORAGE_NET_PROTOCOL_ISCSI) { > + if (src->protocol != VIR_STORAGE_NET_PROTOCOL_ISCSI && src->protocol != VIR_STORAGE_NET_PROTOCOL_ISER) { > virReportError(VIR_ERR_CONFIG_UNSUPPORTED, > _("disk device='lun' is not supported " > "for protocol='%s'"), [...] > diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c > index 5fe3f97d0..72e137ce4 100644 > --- a/src/qemu/qemu_parse_command.c > +++ b/src/qemu/qemu_parse_command.c > @@ -709,6 +709,12 @@ qemuParseCommandLineDisk(virDomainXMLOptionPtr xmlopt, > > if (qemuParseISCSIString(def) < 0) > goto error; > + } else if (STRPREFIX(def->src->path, "iser:")) { > + def->src->type = VIR_STORAGE_TYPE_NETWORK; > + def->src->protocol = VIR_STORAGE_NET_PROTOCOL_ISER; > + > + if (qemuParseISCSIString(def) < 0) > + goto error; > } else if (STRPREFIX(def->src->path, "sheepdog:")) { > char *p = def->src->path; > char *port, *vdi; > @@ -2157,6 +2163,7 @@ qemuParseCommandLine(virCapsPtr caps, > goto error; > > break; > + case VIR_STORAGE_NET_PROTOCOL_ISER: > case VIR_STORAGE_NET_PROTOCOL_ISCSI: > if (qemuParseISCSIString(disk) < 0) > goto error; > diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c > index 6594715e5..cf5c2904e 100644 > --- a/src/util/virstoragefile.c > +++ b/src/util/virstoragefile.c [...] > @@ -3295,6 +3368,7 @@ static const struct virStorageSourceJSONDriverParser jsonParsers[] = { > {"tftp", virStorageSourceParseBackingJSONUri, VIR_STORAGE_NET_PROTOCOL_TFTP}, > {"gluster", virStorageSourceParseBackingJSONGluster, 0}, > {"iscsi", virStorageSourceParseBackingJSONiSCSI, 0}, > + {"iser", virStorageSourceParseBackingJSONiSER, 0}, So this is plain wrong. In qemu it's stil protocol called 'iscsi' with a transport of 'iser', not a completely new protocol. citation from qemu.git/qmp/block-core.json: ## # @IscsiTransport: # # An enumeration of libiscsi transport types # # Since: 2.9 ## { 'enum': 'IscsiTransport', 'data': [ 'tcp', 'iser' ] } ## # @IscsiHeaderDigest: # # An enumeration of header digests supported by libiscsi # # Since: 2.9 ## { 'enum': 'IscsiHeaderDigest', 'prefix': 'QAPI_ISCSI_HEADER_DIGEST', 'data': [ 'crc32c', 'none', 'crc32c-none', 'none-crc32c' ] } ## # @BlockdevOptionsIscsi: # # @transport: The iscsi transport type # # @portal: The address of the iscsi portal # # @target: The target iqn name # # @lun: LUN to connect to. Defaults to 0. # # @user: User name to log in with. If omitted, no CHAP # authentication is performed. # # @password-secret: The ID of a QCryptoSecret object providing # the password for the login. This option is required if # @user is specified. # # @initiator-name: The iqn name we want to identify to the target # as. If this option is not specified, an initiator name is # generated automatically. # # @header-digest: The desired header digest. Defaults to # none-crc32c. # # @timeout: Timeout in seconds after which a request will # timeout. 0 means no timeout and is the default. # # Driver specific block device options for iscsi # # Since: 2.9 ## { 'struct': 'BlockdevOptionsIscsi', 'data': { 'transport': 'IscsiTransport', 'portal': 'str', 'target': 'str', '*lun': 'int', '*user': 'str', '*password-secret': 'str', '*initiator-name': 'str', '*header-digest': 'IscsiHeaderDigest', '*timeout': 'int' } } Also it's missing a test case. > {"nbd", virStorageSourceParseBackingJSONNbd, 0}, > {"sheepdog", virStorageSourceParseBackingJSONSheepdog, 0}, > {"ssh", virStorageSourceParseBackingJSONSSH, 0}, I don't object to adding iser transport per-se, but this patch is a mess. It's missing proper commit message and the protocol is not a new protocol but rather a different transport for ISCSI. Please follow the contributor guidelines before submitting a new patch. Also please add a case to the qemuxml2argv test so that this addition is tested properly as I suspect that iser would work only if you enable authentication in current libvirt since you did not tweak qemuDiskSourceNeedsProps Peter

1 0