- Devel - libvirt List Archives

[libvirt] [jenkins-ci PATCH v2 0/4] Fix virt-manager build failure
by Andrea Bolognani 08 Feb '18

08 Feb '18

Changes from [v1]: * expand coverage instead of reducing it, which makes for a far more acceptable solution. [v1] https://www.redhat.com/archives/libvir-list/2018-February/msg00354.html Andrea Bolognani (4): jobs: Make Python version configurable projects: Build libvirt-python for Python 3 too projects: Build virt-manager using Python 3 guests: Fix Python installation guests/host_vars/libvirt-centos-7/main.yml | 1 - guests/host_vars/libvirt-debian-8/main.yml | 1 - guests/host_vars/libvirt-ubuntu-14/main.yml | 1 - guests/host_vars/libvirt-ubuntu-16/main.yml | 1 - guests/vars/mappings.yml | 50 +++++++++++++++++------------ guests/vars/projects/libvirt-python.yml | 2 ++ guests/vars/projects/virt-manager.yml | 8 ++--- jobs/python-distutils.yaml | 22 ++++++------- projects/libvirt-python.yaml | 29 +++++++++++++++-- projects/virt-manager.yaml | 14 ++++---- 10 files changed, 80 insertions(+), 49 deletions(-) -- 2.14.3

2 5

[libvirt] [PATCH python 1/1] Fix type extracting from PyDict
by Edgar Kaziakhmedov 08 Feb '18

08 Feb '18

PyInt_Check returns value whether or not an input object is the integer type. The existing implementation of extracting leads to the wrong type interpretation in the following code: params = {libvirt.VIR_MIGRATE_PARAM_DISKS_PORT : 50123} ... dom.migrate3(%option1, params, %option3) where libvirt reports: libvirt.libvirtError: invalid argument: invalid type 'ullong' for parameter 'disks_port', expected 'int' So, this patch fixes that bug and allows casting to the VIR_TYPED_PARAM_INT type. Signed-off-by: Edgar Kaziakhmedov <edgar.kaziakhmedov(a)virtuozzo.com> --- libvirt-utils.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/libvirt-utils.c b/libvirt-utils.c index f7b4478..3a00e9f 100644 --- a/libvirt-utils.c +++ b/libvirt-utils.c @@ -434,10 +434,7 @@ virPyDictToTypedParamOne(virTypedParameterPtr *params, type = VIR_TYPED_PARAM_ULLONG; #if PY_MAJOR_VERSION < 3 } else if (PyInt_Check(value)) { - if (PyInt_AS_LONG(value) < 0) - type = VIR_TYPED_PARAM_LLONG; - else - type = VIR_TYPED_PARAM_ULLONG; + type = VIR_TYPED_PARAM_INT; #endif } else if (PyFloat_Check(value)) { type = VIR_TYPED_PARAM_DOUBLE; -- 2.11.0

2 6

[libvirt] [PATCH] apparmor: allow libvirt to send term signal to unconfined
by Guido Günther 08 Feb '18

08 Feb '18

Otherwise stopping domains with qemu://session fails like [164012.338157] audit: type=1400 audit(1516202208.784:99): apparmor="DENIED" operation="signal" profile="/usr/sbin/libvirtd" pid=18835 comm="libvirtd" requested_mask="send" denied_mask="send" signal=term peer="unconfined" --- examples/apparmor/usr.sbin.libvirtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 0ddec3f6e2..be4fabf905 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -63,7 +63,7 @@ signal (send) peer=/usr/sbin/dnsmasq, signal (read, send) peer=libvirt-*, - signal (send) set=("kill") peer=unconfined, + signal (send) set=("kill", "term") peer=unconfined, # Very lenient profile for libvirtd since we want to first focus on confining # the guests. Guests will have a very restricted profile. -- 2.15.1

8 8

[libvirt] [PATCH v1 01/51] util: conf: separate virDomainDefParseXML into serial parts
by xinhua.Cao 08 Feb '18

08 Feb '18

beacause virDomainDefParseXML is too long, and all domain xml parse in this function, it's difficulty to maintain this function so separate virDomainDefParseXML into serial parts use virDomainPreaseInfoFunc. then it will easy to maintain --- src/conf/domain_conf.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 34aae82..e36783b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -18527,6 +18527,28 @@ virDomainCachetuneDefParse(virDomainDefPtr def, } +typedef struct _virDomainParseTotalParam virDomainParseTotalParam; +typedef virDomainParseTotalParam *virDomainParseTotalParamPtr; + +struct _virDomainParseTotalParam{ + //input parameters + virDomainDefPtr def; + xmlDocPtr xml; + xmlNodePtr root; + xmlXPathContextPtr ctxt; + virCapsPtr caps; + virDomainXMLOptionPtr xmlopt; + void *parseOpaque; + unsigned int flags; + + //internal parameters + bool usb_none; + bool usb_other; + bool usb_master; + bool uuid_generated; +}; + + static virDomainDefPtr virDomainDefParseXML(xmlDocPtr xml, xmlNodePtr root, @@ -18536,11 +18558,14 @@ virDomainDefParseXML(xmlDocPtr xml, void *parseOpaque, unsigned int flags) { + typedef int (*virDomainPreaseInfoFunc)(virDomainParseTotalParamPtr params); + xmlNodePtr *nodes = NULL, node = NULL; char *tmp = NULL; size_t i, j; int n, virtType, gic_version; long id = -1; + size_t fun_index = 0; virDomainDefPtr def; bool uuid_generated = false; virHashTablePtr bootHash = NULL; @@ -18548,6 +18573,25 @@ virDomainDefParseXML(xmlDocPtr xml, bool usb_other = false; bool usb_master = false; char *netprefix = NULL; + virDomainParseTotalParam param = { + NULL, + xml, + root, + ctxt, + caps, + xmlopt, + parseOpaque, + flags, + false, + false, + false, + false + + }; + + virDomainPreaseInfoFunc parse_funs[] = { + NULL + }; if (flags & VIR_DOMAIN_DEF_PARSE_VALIDATE_SCHEMA) { char *schema = virFileFindResource("domain.rng", @@ -18565,6 +18609,14 @@ virDomainDefParseXML(xmlDocPtr xml, if (!(def = virDomainDefNew())) return NULL; + param.def = def; + + while (parse_funs[fun_index]) { + if (parse_funs[fun_index](&param) < 0) + goto error; + fun_index++; + } + if (!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE)) if (virXPathLong("string(./@id)", ctxt, &id) < 0) id = -1; -- 2.8.3

3 52

[libvirt] [PATCH v1 01/35] util: conf: add bootHash to virDomainParseTotalParam
by xinhua.Cao 08 Feb '18

08 Feb '18

add bootHash to virDomainParseTotalParam --- src/conf/domain_conf.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 1e949ea..1a8248d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -18516,6 +18516,7 @@ struct _virDomainParseTotalParam{ virCapsPtr caps; virDomainXMLOptionPtr xmlopt; void *parseOpaque; + virHashTablePtr bootHash; unsigned int flags; //internal parameters @@ -19816,6 +19817,7 @@ virDomainDefParseXML(xmlDocPtr xml, caps, xmlopt, parseOpaque, + NULL, flags, false, false, @@ -19861,7 +19863,11 @@ virDomainDefParseXML(xmlDocPtr xml, if (!(def = virDomainDefNew())) return NULL; + if (!(bootHash = virHashCreate(5, NULL))) + goto error; + param.def = def; + param.bootHash = bootHash; while (parse_funs[fun_index]) { if (parse_funs[fun_index](&param) < 0) -- 2.8.3

1 9

[libvirt] Support interface network stats for SR-IOV in Switchdev mode(VF representors)
by Jai Singh Rana 08 Feb '18

08 Feb '18

Hi All, Currently libvirt does not support networks interface stats for <interface type='hostdev'>. With availability of switchdev model in linux, it is possible to capture stats for SR-IOV VFs on host using its VF representor interface on host for nics supporting switchdev model. https://github.com/torvalds/linux/blob/master/Documentation/networking/swit… I want to preapre a patch supporting this feature for hostdev and write some function like 'virHostdevSwitchdevVfRepresentorInterfaceStats' for returning stats. Should I include this function and supporting methods in src/util/virhostdev.c or should i include it in new file something like src/util/virswitchdev.c . Thanks, Jai

2 3

[libvirt] [RFC v2 REPOST] arm64: KVM: KVM API extensions for SVE
by Dave Martin 07 Feb '18

07 Feb '18

Hi all, Reposting this to give people another chance to comment before I move ahead... ---8<--- 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 _______________________________________________ kvmarm mailing list kvmarm(a)lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

2 8

[libvirt] [jenkins-ci PATCH 0/2] Fix virt-manager build failure
by Andrea Bolognani 07 Feb '18

07 Feb '18

By making a lot of compromises. Not a perfect solution, but still better than not building virt-manager at all until we've come up with a proper one I reckon. ¯\_(ツ)_/¯ Andrea Bolognani (2): guests: Install Python 3 dependencies for virt-manager jobs: Switch all Python builds to Python 3 guests/host_vars/libvirt-centos-6/main.yml | 1 - guests/host_vars/libvirt-centos-7/main.yml | 2 -- guests/host_vars/libvirt-debian-8/main.yml | 1 - guests/host_vars/libvirt-ubuntu-14/main.yml | 1 - guests/host_vars/libvirt-ubuntu-16/main.yml | 1 - guests/vars/mappings.yml | 41 ++++++++++++++++------------- guests/vars/projects/virt-manager.yml | 8 +++--- jobs/python-distutils.yaml | 8 +++--- projects/virt-manager.yaml | 2 +- 9 files changed, 31 insertions(+), 34 deletions(-) -- 2.14.3

1 2

[libvirt] [jenkins-ci] lcitool: Use default python for creating salty passwords
by Martin Kletzander 07 Feb '18

07 Feb '18

On my system the crypt module in python2 doesn't have mksalt() function. However python3 does and the code is perfectly fine python3 code as well. So let's make it run in the default python version as that has the highest chance to work. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- guests/lcitool | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guests/lcitool b/guests/lcitool index ccd0a597785a..24274d800742 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -18,7 +18,7 @@ die() { hash_file() { PASS_FILE="$1" - python2 -c " + python -c " import crypt password = open('$PASS_FILE', 'r').read().strip() print(crypt.crypt(password, -- 2.16.1

3 3

[libvirt] [PATCH] util: Fix syntax-check
by Andrea Bolognani 07 Feb '18

07 Feb '18

Broken by 759b4d1b0fe5f4d84d98b99153dfa7ac289dd167. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as a CI build fix. src/util/virlog.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/util/virlog.c b/src/util/virlog.c index 9105337ce..8f1e4800d 100644 --- a/src/util/virlog.c +++ b/src/util/virlog.c @@ -478,9 +478,8 @@ virLogHostnameString(char **rawmsg, if (!virLogHostname) return -1; - if (virAsprintfQuiet(&hoststr, "hostname: %s", virLogHostname) < 0) { + if (virAsprintfQuiet(&hoststr, "hostname: %s", virLogHostname) < 0) return -1; - } if (virLogFormatString(msg, 0, NULL, VIR_LOG_INFO, hoststr) < 0) { VIR_FREE(hoststr); -- 2.14.3

1 0