- Devel - libvirt List Archives

[libvirt] [PATCH 0/3] Clean up qemuhotplugtest xml files
by Tomasz Flendrich 12 Jul '16

12 Jul '16

I plan on doing bigger changes to qemuhotplugtest.c. It's going to test device attachment/detachment to both live (like now) and persistent (something that is missing now) domains. More files will be added, so I decided to clean up ones that are there now. Many files were not even connected to any qemuxml2argv test, and yet they were in tests/qemuxml2argvdata/ Tomasz Flendrich (3): Move all qemuhotplugtest XMLs to one directory Move domain and device xmls to different directories Use virschematest on qemuhotplugtest domain xmls tests/qemuhotplugtest.c | 52 ++++++------- .../qemuhotplug-console-virtio.xml | 0 .../qemuhotplug-disk-cdrom-nochange.xml | 0 .../qemuhotplug-disk-scsi-2.xml | 0 .../qemuhotplug-disk-scsi.xml | 0 .../qemuhotplug-disk-usb.xml | 0 .../qemuhotplug-disk-virtio.xml | 0 ...lug-graphics-spice-listen-network-password.xml} | 0 .../qemuhotplug-graphics-spice-listen.xml | 0 .../qemuhotplug-graphics-spice-nochange.xml | 0 ...qemuhotplug-graphics-spice-timeout-nochange.xml | 0 ...qemuhotplug-graphics-spice-timeout-password.xml | 0 .../qemuhotplug-qemu-agent-detach.xml | 0 .../qemuhotplug-qemu-agent.xml | 0 .../qemuhotplug-base+qemu-agent-detach.xml} | 0 .../qemuhotplug-base+qemu-agent.xml} | 0 .../qemuhotplug-base-live+disk-scsi.xml} | 0 .../qemuhotplug-base-live+disk-usb.xml} | 0 .../qemuhotplug-base-live+disk-virtio.xml} | 0 .../qemuhotplug-base-live+qemu-agent-detach.xml} | 0 .../qemuhotplug-base-live+qemu-agent.xml} | 0 .../qemuhotplug-base-live.xml} | 0 ...base-with-scsi-controller-live+disk-scsi-2.xml} | 0 ...qemuhotplug-base-with-scsi-controller-live.xml} | 0 ...e-without-scsi-controller-live+disk-scsi-2.xml} | 0 ...uhotplug-base-without-scsi-controller-live.xml} | 0 ...otplug-console-compat-2-live+console-virtio.xml | 0 .../qemuhotplug-console-compat-2-live.xml} | 0 .../qemuhotplug-disk-cdrom.xml | 37 +++++++++ .../qemuhotplug-graphics-spice-listen-network.xml} | 0 .../qemuhotplug-graphics-spice-timeout.xml | 87 ++++++++++++++++++++++ .../qemuhotplug-graphics-spice.xml | 47 ++++++++++++ tests/virschematest.c | 3 +- 33 files changed, 199 insertions(+), 27 deletions(-) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-console-virtio.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-cdrom-nochange.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-scsi-2.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-scsi.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-usb.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-virtio.xml (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-graphics-spice-listen-network.xml => qemuhotplugtestdevices/qemuhotplug-graphics-spice-listen-network-password.xml} (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-listen.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-nochange.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-timeout-nochange.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-timeout-password.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-qemu-agent-detach.xml (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-qemu-agent.xml (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+qemu-agent-detach.xml => qemuhotplugtestdomains/qemuhotplug-base+qemu-agent-detach.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+qemu-agent.xml => qemuhotplugtestdomains/qemuhotplug-base+qemu-agent.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-scsi.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-scsi.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-usb.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-usb.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-virtio.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-virtio.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent-detach.xml => qemuhotplugtestdomains/qemuhotplug-base-live+qemu-agent-detach.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent.xml => qemuhotplugtestdomains/qemuhotplug-base-live+qemu-agent.xml} (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-live.xml => qemuhotplugtestdomains/qemuhotplug-base-live.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-with-scsi-controller-live+disk-scsi-2.xml => qemuhotplugtestdomains/qemuhotplug-base-with-scsi-controller-live+disk-scsi-2.xml} (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-with-scsi-controller-live.xml => qemuhotplugtestdomains/qemuhotplug-base-with-scsi-controller-live.xml} (100%) rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-without-scsi-controller-live+disk-scsi-2.xml => qemuhotplugtestdomains/qemuhotplug-base-without-scsi-controller-live+disk-scsi-2.xml} (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-without-scsi-controller-live.xml => qemuhotplugtestdomains/qemuhotplug-base-without-scsi-controller-live.xml} (100%) rename tests/{qemuhotplugtestdata => qemuhotplugtestdomains}/qemuhotplug-console-compat-2-live+console-virtio.xml (100%) rename tests/{qemuxml2argvdata/qemuxml2argv-console-compat-2-live.xml => qemuhotplugtestdomains/qemuhotplug-console-compat-2-live.xml} (100%) create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-disk-cdrom.xml rename tests/{qemuxml2argvdata/qemuxml2argv-graphics-spice-listen-network.xml => qemuhotplugtestdomains/qemuhotplug-graphics-spice-listen-network.xml} (100%) create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-graphics-spice-timeout.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-graphics-spice.xml -- 2.7.4 (Apple Git-66)

2 1

[libvirt] [PATCH 0/5] Couple of memleaks fixes
by Michal Privoznik 11 Jul '16

11 Jul '16

I've found these while procrastinating on friday afternoon. Michal Privoznik (5): virStorageEncryptionSecretFree: Don't leak secret lookup definition qemuBuildCpuCommandLine: Don't leak @buf qemuDomainObjPrivateFree: Free @masterKey too qemuxml2argvtest: Don't leak dummy monitor qemuxml2argvmock: Don't leak @netdef->ifname src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 21 +++++++++++++++------ src/util/virstorageencryption.c | 1 + tests/qemuxml2argvmock.c | 1 + tests/qemuxml2argvtest.c | 5 +++-- 5 files changed, 21 insertions(+), 8 deletions(-) -- 2.8.4

2 10

[libvirt] [PATCH v3] virsh: allow both --uuid and --name at same time
by Chen Hanxiao 11 Jul '16

11 Jul '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> #virsh list --uuid --name 49c765a0-25e7-40d0-964f-dac99724b32c c7 918f1dd6-b19f-412b-ba17-d113bad89af8 f23 Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- v3: add virsh.pod sections v2: drop uuid-name option, enable both --uuid and --name tools/virsh-domain-monitor.c | 14 ++++++++------ tools/virsh.pod | 10 ++++++++-- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c index 0a93949..c712fa5 100644 --- a/tools/virsh-domain-monitor.c +++ b/tools/virsh-domain-monitor.c @@ -1844,12 +1844,8 @@ cmdList(vshControl *ctl, const vshCmd *cmd) FILTER("state-shutoff", VIR_CONNECT_LIST_DOMAINS_SHUTOFF); FILTER("state-other", VIR_CONNECT_LIST_DOMAINS_OTHER); - if (optTable + optName + optUUID > 1) { - vshError(ctl, "%s", - _("Only one argument from --table, --name and --uuid " - "may be specified.")); - return false; - } + VSH_EXCLUSIVE_OPTIONS("table", "name"); + VSH_EXCLUSIVE_OPTIONS("table", "uuid"); if (!optUUID && !optName) optTable = true; @@ -1907,6 +1903,12 @@ cmdList(vshControl *ctl, const vshCmd *cmd) state == -2 ? _("saved") : virshDomainStateToString(state)); } + } else if (optUUID && optName) { + if (virDomainGetUUIDString(dom, uuid) < 0) { + vshError(ctl, "%s", _("Failed to get domain's UUID")); + goto cleanup; + } + vshPrint(ctl, "%-36s %-30s\n", uuid, virDomainGetName(dom)); } else if (optUUID) { if (virDomainGetUUIDString(dom, uuid) < 0) { vshError(ctl, "%s", _("Failed to get domain's UUID")); diff --git a/tools/virsh.pod b/tools/virsh.pod index 601cb44..d7cd10e 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -524,8 +524,14 @@ Note that this flag does not filter the list of domains. If I<--name> is specified, domain names are printed instead of the table formatted one per line. If I<--uuid> is specified domain's UUID's are printed instead of names. Flag I<--table> specifies that the legacy table-formatted -output should be used. This is the default. All of these are mutually -exclusive. +output should be used. This is the default. + +If both I<--name> and I<--uuid> are specified, domain UUID's and names +are printed side by side without any header. Flag I<--table> specifies +that the legacy table-formatted output should be used. This is the +default if neither I<--name> nor I<--uuid> are specified. Options +I<--uuid> and I<--name> are mutually exclusive if option I<--table> is +specified. If I<--title> is specified, then the short domain description (title) is printed in an extra column. This flag is usable only with the default -- 1.8.3.1

2 1

[libvirt] [PATCH RFC 0/5] libxl: host cpu element in capabilities
by Joao Martins 11 Jul '16

11 Jul '16

Hey! This series is the RFC I mentioned in cpu map discussion for libxl[0]. That is to implement host.cpu element in caps,by getting topology and xen hwcaps parsing done, followed by having cpu-{compare,baseline} and get cpu models APIs implemented. Last thing missing I think it would be to libxl_cpuid_set the features to enable/disable whichever format we choose plus the appropriate XML convertion to/from XM and XL config formats. Cheers, Joao [0] https://www.redhat.com/archives/libvir-list/2016-July/msg00237.html Joao Martins (5): libxl: describe host topology in capabilities libxl: describe host cpu features based on hwcaps libxl: implement virConnectCompareCPU libxl: implement virConnectBaselineCPU libxl: implement virConnectGetCPUModelNames src/libxl/libxl_capabilities.c | 148 ++++++++++++++++++++++++++++++++++++++--- src/libxl/libxl_driver.c | 74 +++++++++++++++++++++ 2 files changed, 212 insertions(+), 10 deletions(-) -- 2.1.4

2 7

[libvirt] [PATCH] libvirt.spec.in: soft-static allocation of qemu and kvm groups
by Jaroslav Suchanek 11 Jul '16

11 Jul '16

Follow the same logic for adding qemu user also for kvm and qemu groups. As is described in https://fedoraproject.org/wiki/Packaging:UsersAndGroups document there should be preallocated UIDs and GIDs for libvirt. A check for required group id was added prior groupadd execution. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1351792 --- libvirt.spec.in | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 2b98836..3dc3193 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1464,8 +1464,20 @@ fi # We want soft static allocation of well-known ids, as disk images # are commonly shared across NFS mounts by id rather than name; see # https://fedoraproject.org/wiki/Packaging:UsersAndGroups -getent group kvm >/dev/null || groupadd -f -g 36 -r kvm -getent group qemu >/dev/null || groupadd -f -g 107 -r qemu +if ! getent group kvm >/dev/null; then + if ! getent group 36 >/dev/null; then + groupadd -f -g 36 -r kvm + else + groupadd -f -r kvm + fi +fi +if ! getent group qemu >/dev/null; then + if ! getent group 107 >/dev/null; then + groupadd -f -g 107 -r qemu + else + groupadd -f -r qemu + fi +fi if ! getent passwd qemu >/dev/null; then if ! getent passwd 107 >/dev/null; then useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin -c "qemu user" qemu -- 1.8.3.1

2 2

Re: [libvirt] [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features
by David Hildenbrand 11 Jul '16

11 Jul '16

Are there any further comments, especially on patches 23-25, introducing new QOM interfaces? Also, if anybody is planning to look into this, please speak up :) Otherwise it might make sense to put this onto the next KVM call agenda. David > This is our second attempt to implement CPU models for s390x. We realized > that we also want to have features exposed via the CPU model. While doing > that we realized that we want to have a better interface for libvirt. > > Unfortunately, CPU models on s390x are special and we have to take care of: > - A CPU like z13 looks differently in various environments (under different > LPAR versions, under different z/VM versions, under different KVM > versions, export regulation) - we have _a lot_ of feature variability. > - We still have certain features that are not published but might be > implemented/introduced in the future. As they are a theoretical part > of a CPU already, we have to find a way to model these future changes. > - We still have certain features that are already published, but not > implemented. Implementation might be added in the future in KVM. > - We heavily rely on KVM to tell us which features it can actually > virtualize - user space queries like "STFL(e)" give no guarantees. > - Certain "subfeatures" were introduced in one run. In practice, they are > always around, but in theory, subfeatures could be dropped in the future. > - Just because two CPU models have the same features doesn't mean they > are equal - some internal numbers might be different. E.g. we won't allow > running a z13 under a zBC12 just by turning off features. > - We cannot blindly enable all possible features for a CPU generation, > the IBC "Instruction Blocking Control" in KVM will try to block > instructions introduced with certain features. So a CPU generation always > has some maximum feature set that is guaranteed to work. > > It all boils down to a specific released CPU to have. > a) A fixed feature set that we expect it to be have on every hypervisor. > b) A variable part that depends on the hypervisor and that could be > extended in the future (adding not yet implemented features) that we > always want to enable later on. > c) A variable part that we want to enable only if requested - nested > virtualization ("vsie") and assists are one example. > > But, the fixed feature set is not really what we want to use as a default. > It is just like a really minimum, stable base. > > So we have > a) A "stable" CPU model for each released CPU that will never change and > maps to the minimum feature set we expect to be around on all > hypervisors. e.g. "z13-base" or "z10EC.2-base". These are migration > safe. > b) A "default" CPU model for each released CPU, that can change between > QEMU versions and that will always include the features we expect to > be around in our currently supported environments and will contain only > features we expect to be stable. E.g. nested virtualization will not be > contained in these models. These models are not migration safe, e.g > "z13" or "z10EC.2". The feature set can differ between QEMU versions. > c) An internal "maximum" CPU model for each generation that tells us which > features were supported as a maximum back when the hardware was > released. This will not be exposed > > To not have to replicate all CPU model changes ("new default fetaures") in > libvirt, to not duplicate the logic about compatibility and the like, > our approach tries to keep all the QEMU logic in libvirt and provide > standardized interfaces for libvirt to e.g. baseline, compare. This > allows libvirt to not have to care about any model names or feature names, > it can just pass the data from interface to interface and report it to > the user. > > Also, libvirt might want to know what the "host" model looks like and > convert a CPU model to a migration safe variant. For this reason, a QMP > command is added that can create a migration safe variant of a variable > CPU model, indicating only the delta changes done to a stable model. > > So we have: > a) "query-cpu-model-expansion" - tell us what the "host" or a migration > unsafe model looks like. Either falling back to a stable model or > completely exposing all properties. We are interested in stable models. > b) "query-cpu-model-comparison" - tell us how two CPU models compare, > indicating which properties were responsible for the decision. > c) "query-cpu-model-baseline" - create a new model out of two models, > taking a requested level of stability into account. > > As we are aware that e.g. x86 has their own idea of a CPU model and their > existing implementation in place, but are also looking into to ways to e.g. > expand the "host" CPU model to a detailed representation, we designed the > "expansion" interface to also allow that. > > Comments are very welcome, but please always keep the restrictions and > specialties in mind when suggesting some major design changes. > > The header update will be replaced by a kvm-next header update as soon as > the VSIE patches are upstream. The major KVM interface changes are already > part of kvm-next. > > The current state is available on git://github.com/cohuck/qemu on branch > "cpumodel-s390x". > > David Hildenbrand (26): > s390x/cpumodel: "host" and "qemu" as CPU subclasses > s390x/cpumodel: expose CPU class properties > s390x/cpumodel: generate CPU feature group lists > s390x/cpumodel: introduce CPU feature group definitions > s390x/cpumodel: register defined CPU models as subclasses > s390x/cpumodel: store the CPU model in the CPU instance > s390x/cpumodel: expose features and feature groups as properties > s390x/cpumodel: let the CPU model handle feature checks > s390x/cpumodel: check and apply the CPU model > s390x/sclp: factor out preparation of cpu entries > s390x/sclp: introduce sclp feature blocks > s390x/sclp: indicate sclp features > s390x/sclp: propagate the ibc val(lowest and unblocked ibc) > s390x/sclp: propagate the mha via sclp > s390x/sclp: propagate hmfai > update linux headers (CPU model) > s390x/kvm: allow runtime-instrumentation for "none" machine > s390x/kvm: implement CPU model support > s390x/kvm: disable host model for existing compat machines > s390x/kvm: let the CPU model control CMM(A) > qmp: add QMP interface "query-cpu-model-expansion" > qmp: add QMP interface "query-cpu-model-comparison" > qmp: add QMP interface "query-cpu-model-baseline" > s390x/cpumodel: implement QMP interface "query-cpu-model-expansion" > s390x/cpumodel: implement QMP interface "query-cpu-model-comparison" > s390x/cpumodel: implement QMP interface "query-cpu-model-baseline" > > Michael Mueller (2): > s390x/cpumodel: introduce CPU features > s390x/cpumodel: generate CPU feature lists for CPU models > > Makefile.target | 2 +- > hw/s390x/s390-virtio-ccw.c | 5 + > hw/s390x/s390-virtio.c | 6 +- > hw/s390x/sclp.c | 35 +- > include/hw/s390x/sclp.h | 17 +- > include/sysemu/arch_init.h | 10 + > linux-headers/asm-s390/kvm.h | 40 ++ > qapi-schema.json | 184 ++++++ > qmp-commands.hx | 18 + > qmp.c | 22 + > rules.mak | 1 + > stubs/Makefile.objs | 3 + > stubs/arch-query-cpu-model-baseline.c | 13 + > stubs/arch-query-cpu-model-comparison.c | 12 + > stubs/arch-query-cpu-model-expansion.c | 12 + > target-s390x/Makefile.objs | 22 +- > target-s390x/cpu-qom.h | 5 + > target-s390x/cpu.c | 35 +- > target-s390x/cpu.h | 5 + > target-s390x/cpu_features.c | 376 +++++++++++ > target-s390x/cpu_features.h | 302 +++++++++ > target-s390x/cpu_models.c | 1055 +++++++++++++++++++++++++++++++ > target-s390x/cpu_models.h | 113 ++++ > target-s390x/gen-features.c | 587 +++++++++++++++++ > target-s390x/helper.c | 29 +- > target-s390x/kvm.c | 346 +++++++++- > target-s390x/machine.c | 14 +- > 27 files changed, 3203 insertions(+), 66 deletions(-) > create mode 100644 stubs/arch-query-cpu-model-baseline.c > create mode 100644 stubs/arch-query-cpu-model-comparison.c > create mode 100644 stubs/arch-query-cpu-model-expansion.c > create mode 100644 target-s390x/cpu_features.c > create mode 100644 target-s390x/cpu_features.h > create mode 100644 target-s390x/cpu_models.c > create mode 100644 target-s390x/cpu_models.h > create mode 100644 target-s390x/gen-features.c >

2 2

[libvirt] [PATCH v2 0/4] devices: filesystem: type volume
by Olga Krishtal 11 Jul '16

11 Jul '16

The patches introduce new filesystem type volume: <filesystem type='volume' accessmode='passthrough'> <driver type='ploop' format='ploop'/> <source pool='pool' volume='volume'/> <target dir='/'/> </filesystem> This makes possible to use storage volumes as the source for disks. v2: -split patches -rebased Olga Krishtal (4): filesystem: adds possibility to use storage pool as fs source devices: filesystems: added volume type vz: refactoring of prlsdkCreateCt vz: support filesystem type volume src/conf/domain_audit.c | 4 +- src/conf/domain_conf.c | 52 +++++++++++++--- src/conf/domain_conf.h | 4 +- src/libvirt_private.syms | 1 + src/lxc/lxc_cgroup.c | 2 +- src/lxc/lxc_container.c | 50 +++++++-------- src/lxc/lxc_controller.c | 18 +++--- src/lxc/lxc_native.c | 5 +- src/lxc/lxc_process.c | 4 +- src/openvz/openvz_conf.c | 6 +- src/openvz/openvz_driver.c | 4 +- src/qemu/qemu_command.c | 2 +- src/storage/storage_driver.c | 4 +- src/vbox/vbox_common.c | 6 +- src/vmx/vmx.c | 6 +- src/vz/vz_driver.c | 2 +- src/vz/vz_sdk.c | 145 ++++++++++++++++++++++++++++++++++--------- src/vz/vz_sdk.h | 2 +- 18 files changed, 221 insertions(+), 96 deletions(-) -- 1.8.3.1

2 6

[libvirt] [PATCH] Fix logic in qemuDomainObjPrivateXMLParseVcpu
by Daniel P. Berrange 11 Jul '16

11 Jul '16

The code in qemuDomainObjPrivateXMLParseVcpu for parsing the 'idstr' string was comparing the overall boolean result against 0 which was always true qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu': qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare] if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 || ^ It was further performing two distinct error checks in the same conditional and reporting a single error message, which was misleading in one of the two cases. This splits the conditional check into two parts with distinct error messages and fixes the logic error. Fixes the bug in commit 5184f398b40a5e0d7d84b86182edcb2b48ab04ba Author: Peter Krempa <pkrempa(a)redhat.com> Date: Fri Jul 1 14:56:14 2016 +0200 qemu: Store vCPU thread ids in vcpu private data objects Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Pushed as a broken build fix src/qemu/qemu_domain.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index bf23d46..f7c659b 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -1479,10 +1479,15 @@ qemuDomainObjPrivateXMLParseVcpu(xmlNodePtr node, idstr = virXMLPropString(node, "id"); - if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 || - !(vcpu = virDomainDefGetVcpu(def, idx))) { + if (idstr && + (virStrToLong_uip(idstr, NULL, 10, &idx) < 0)) { virReportError(VIR_ERR_INTERNAL_ERROR, - _("invalid vcpu index '%s'"), idstr); + _("cannot parse vcpu index '%s'"), idstr); + goto cleanup; + } + if (!(vcpu = virDomainDefGetVcpu(def, idx))) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("invalid vcpu index '%u'"), idx); goto cleanup; } -- 2.7.4

1 0

[libvirt] [PATCH REPOST 0/3] Small cleanups and improvements
by Andrea Bolognani 11 Jul '16

11 Jul '16

Rebased on top of current master. Previous attempt: https://www.redhat.com/archives/libvir-list/2016-June/msg02037.html Andrea Bolognani (3): util: hostcpu: Add virHostCPUGetKVMMaxVCPUs() stub util: hostcpu: Drop obsolete compatibility code qemu: capabilities: Make virHostCPUGetKVMMaxVCPUs() errors fatal src/qemu/qemu_capabilities.c | 9 ++++++--- src/util/virhostcpu.c | 25 ++++++++++++------------- 2 files changed, 18 insertions(+), 16 deletions(-) -- 2.7.4

2 9

[libvirt] cpu_map data access for libxl driver
by Cedric Bosdonnat 11 Jul '16

11 Jul '16

Hi Jiri, all, As I mentioned earlier today on IRC, I have started implementing CPU configuration support for libxl driver. libxl expects a string definition the state of all the feature (easy to create), but also the numeric values for the CPU family and model. virCPUDef holds the name as a string, but not the numeric values though there are stored in the cpu_map.xml. For what libxl expects, search for 'cpuid=' in this man page: http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html Any idea how to get those values from the libxl driver? -- Cedric

4 8