- Devel - libvirt List Archives

[libvirt] [PATCH v2 0/6] Some patches for native TLS encrypted chardev TCP support
by John Ferlan 16 Jun '16

16 Jun '16

v1: http://www.redhat.com/archives/libvir-list/2016-June/msg00824.html Based on Dan's review from patch 4, alter the methodology to use the libvirt qemu config file to add support for a 'default' and (at first) a 'chartcp' (I could use chardev, but I was concerned that would imply more options - udp, unix, etc.). I have started on the authentication portion of this (e.g. a passwordid= parameter pointing at a secret object), but I'm a bit held up by the need to have the secret key patches. I've separated those out and will post a separate set shortly as well to hopefully get some traction. For the chartcp, I went with the 'default' location for the /etc/pki path - that will at least test patch 1. I also tested those locally by removing the code in qemuxml2xmltest.c to specify the specific -vnc or -spice paths as the test has. John Ferlan (6): conf: Add new default TLS X.509 certificate default directory conf: Introduce chartcp_tls_x509_cert_dir qemu: Make qemuBuildShmemBackendStr private qemu: Add cfg pointer to various command line helpers qemu: Add support for TLS X.509 path to TCP chardev backend qemu: Add the ability to hotplug the TLS X.509 environment src/conf/domain_conf.h | 1 + src/qemu/libvirtd_qemu.aug | 9 +- src/qemu/qemu.conf | 52 ++++--- src/qemu/qemu_command.c | 158 ++++++++++++++++++--- src/qemu/qemu_command.h | 12 +- src/qemu/qemu_conf.c | 45 +++++- src/qemu/qemu_conf.h | 5 + src/qemu/qemu_hotplug.c | 29 +++- src/qemu/qemu_monitor_json.c | 9 ++ src/qemu/test_libvirtd_qemu.aug.in | 3 + .../qemuxml2argv-serial-tcp-tlsx509-chardev.args | 33 +++++ .../qemuxml2argv-serial-tcp-tlsx509-chardev.xml | 41 ++++++ tests/qemuxml2argvtest.c | 6 + .../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml | 50 +++++++ tests/qemuxml2xmltest.c | 1 + 15 files changed, 399 insertions(+), 55 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-tlsx509-chardev.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml -- 2.5.5

2 13

[libvirt] [PATCH 0/2] qemu: active blockjob error tweaks
by Cole Robinson 16 Jun '16

16 Jun '16

Just a couple error message tweaks/cleanups regarding active block jobs, noticed while looking at https://bugzilla.redhat.com/show_bug.cgi?id=1342276 Cole Robinson (2): qemu: More usage of qemuDomainDiskBlockJobIsActive qemu: migration: use consistent error message src/qemu/qemu_driver.c | 7 +------ src/qemu/qemu_hotplug.c | 6 +----- src/qemu/qemu_migration.c | 2 +- 3 files changed, 3 insertions(+), 12 deletions(-) -- 2.7.4

2 5

[libvirt] [PATCH 0/2] Don't add a pci-bridge unless needed on Q35/aarch64
by Laine Stump 16 Jun '16

16 Jun '16

I had these in a branch waiting for further work to make them more useful, and abologna asked about this topic, so I'm posting these two patches. Note that in most cases we'll still get a pci-bridge device added (since most devices are legacy PCI) but at least if the config doesn't have any unaddressed PCI devices, that won't happen. As patch 1 states, the dmi-to-pci-bridge will still be there in all cases for Q35/aarch64. That needs more work to eliminate. Laine Stump (2): qemu: don't be as insistent about adding dmi-to-pci-bridge or pci-bridge qemu: don't add pci-bridge to Q35/arm domains unless it's needed src/qemu/qemu_domain.c | 14 +++++++------- .../qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args | 1 - .../qemuxml2argv-aarch64-virtio-pci-default.args | 1 - tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args | 3 +-- .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 5 ----- tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root.xml | 5 ----- 6 files changed, 8 insertions(+), 21 deletions(-) -- 2.5.5

2 4

[libvirt] [PATCH] util: Fix broken syntax-check
by John Ferlan 16 Jun '16

16 Jun '16

Commit id '743db933' broke at least one syntax check rule regard open/close braces and perhaps more with spacing. Just remove the braces Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Pushed as build breaker src/util/virauthconfig.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/util/virauthconfig.c b/src/util/virauthconfig.c index b58937c..91c9c0c 100644 --- a/src/util/virauthconfig.c +++ b/src/util/virauthconfig.c @@ -123,9 +123,8 @@ int virAuthConfigLookup(virAuthConfigPtr auth, if (!virKeyFileHasGroup(auth->keyfile, authgroup)) { VIR_FREE(authgroup); - if (virAsprintf(&authgroup, "auth-%s-%s", service, "default") < 0){ + if (virAsprintf(&authgroup, "auth-%s-%s", service, "default") < 0) goto cleanup; - } } if (!virKeyFileHasGroup(auth->keyfile, authgroup)) { -- 2.5.5

1 0

[libvirt] RFC: New CPU hot(un)plug API and XML
by Peter Krempa 16 Jun '16

16 Jun '16

Hi list, I'm planing on adding API that will be used instead of virDomainSetVcpus and will allow a more granular control of which virtual CPUs are enabled for a guest. The new approach will allow to use cpu hotplug properly with NUMA guests as the old APIs would not allow adding CPUs to very specific cgroups. The old APIs should still work fine with the current approach although the final implementation should also allow to unplug vcpus from the guest by using new qemu features. I'm still not sure though whether it will be possible to use this in a backward compatible fashion though depending how this stuff will exactly need to be set up in qemu. # API # As for the new API I'm thinking of the following design: int virDomainVcpu(virDomainPtr domain, unsigned int id, unsigned int flags); The flags for this API would be following: - usual domain modification impact: * VIR_DOMAIN_SET_VCPU_CURRENT * VIR_DOMAIN_SET_VCPU_LIVE * VIR_DOMAIN_SET_VCPU_CONFIG - for specifying the operation as the default operation would query the cpu state: * VIR_DOMAIN_SET_VCPU_ENABLE * VIR_DOMAIN_SET_VCPU_DISABLE - misc: * VIR_DOMAIN_SET_VCPU_GUEST - use the guest agent instead of ACPI hotplug * VIR_DOMAIN_SET_VCPU_NUMA_NODE - 'id' is the ID of a numa node where the cpu should be enabled/disabled rather than CPU id. This is a convenience flag that will allow to add cpu to a given numa node rather than having to find the correct ID. * VIR_DOMAIN_SET_VCPU_CORE - use thread level hotplug (see [1]). This makes sure that the CPU will be plugged in on platforms that require to plug in multiple threads at once. VIR_DOMAIN_SET_VCPU_NUMA_NODE and VIR_DOMAIN_SET_VCPU_GUEST are mutually exclusive as the guest agent doesn't report the guest numa node the CPU is belonging to . If the idea of one API that will both query and set is too nonconformist to our existing API design I have no problem adding Get/Set versions and/or explode the ADD/REMOVE flags into a separate parameter. # XML # The new API will require us to add new XML that will allow to track the state of VCPUs individually. Internally we now have a data structure allowing to keep the relevant data in one place. Currently we are setting data relevant to VCPUs in many places. <domain> [...] <vcpu current='1'>3</vcpu> [...] <cputune> <cpupin ... /> </cputune> [...] <cpu> <numa> <cell id='0' cpus='0' memory='102400' unit='KiB/> <cell id='1' cpus='1-2' memory='102400' unit='KiB/> </numa> As we'll be required to keep the state for every single cpu I'm thinking of adding a new subelement called '<vcpus>' to <domain>. This will have a '<vcpu>' subelement for every configured cpu. I'm specifically not going to add any of the cpupin or numa node ids to the /domain/vcpus/vcpu as input parameters to avoid introducing very compicated checking code that would be required to keep the data in sync. I'm thinking of adding the numa node id as an output only attribute since it's relevant to the hotplug case and it's misplaced otherwise. I certainly can add the duplicated data as output-only attributes. The XML with the new elements should look like: <domain> [...] <vcpu current='1'>3</vcpu> <vcpus> <vcpu id='0' state='enabled'/> <-- option 1, no extra data <vcpu id='1' state='disabled' cell='1'/> <--- option 2, just numa node, since it's non-obvious <vcpu id='2' state='disabled' cell='1' pin='1-2' scheduler='...'/>  </vcpus> [...] <cputune> <cpupin ... /> </cputune> [...] <cpu> <numa> <cell id='0' cpus='0' memory='102400' unit='KiB/> <cell id='1' cpus='1-2' memory='102400' unit='KiB/> </numa> # migration # To ensure migration compatibility a new libvirt will set a new migration feature flag in cases where a sparse topology was created by any means. Older versions of libvirt will reject it. As the new cpu data will be ignored by the parser of older libvirt we don't need to stop formatting them on migration. (fortunately schemas are not validated during migration) # qemu/platform implementation caveats # When starting the VM for the first time it might be necessary to start a throw-away qemu process to query some details that we'll need to pass in on a command line. I'm not sure if this is still necessary and I'll try to avoid it at all cost. [1] Some architectures (ppc64) don't directly support thread-level hotplug and thus require us to plug in a core which translates into multiple threads (8 in case of power 8). Possibly other yet unknown problems. Thanks for your feedback. Peter

3 4

[libvirt] [PATCH] syntax-check: drop prohibit_undesirable_word_seq
by Ján Tomko 16 Jun '16

16 Jun '16

This checks forbids using "can not" and checks the placement of some texinfo tags. Drop it since we do not use texinfo and the check takes almost twice as much as the rest of the checks. --- cfg.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/cfg.mk b/cfg.mk index 297ca3a..d82070d 100644 --- a/cfg.mk +++ b/cfg.mk @@ -64,6 +64,7 @@ local-checks-to-skip = \ sc_prohibit_quote_without_use \ sc_prohibit_quotearg_without_use \ sc_prohibit_stat_st_blocks \ + sc_prohibit_undesirable_word_seq \ sc_root_tests \ sc_space_tab \ sc_sun_os_names \ -- 2.7.3

2 1

[libvirt] Patch review request for Red Hat Bugzilla Bug 1341866
by Ashish Mittal 15 Jun '16

15 Jun '16

Hi, This is a patch review request in response to the following bugzilla: Bug 1341866 RFE: Request to upstream libvirt dependencies for qemu based network block driver from Veritas (1) This patch is required to enable Veritas OpenFlame functionality on RedHat OSP8 platform. (2) Patch has been created on top of libvirt-1.2.17-13.el7.x86_64. Please let me know in case patch has to be rebased on top of the latest libvirt git master branch instead. Regards, Ashish

2 5

[libvirt] [PATCH v3 0/7] Introducing storage pool lifecycle event APIs
by Jovanka Gulicoska 15 Jun '16

15 Jun '16

Changes since v2 listed in every commit separately Introducing implementation of storage pool event APIs. Code changes follow network event APIs. Implemented functions: virStoragePoolEventRegisterAny(), virStoragePoolEventDeregisterAny(), virStoragePoolLifeCycleEventNew(), introduced STARTED, STOPPED, DEFINE, UNDEFINE and REFRESHED. STARTED signal is emiited in storagePoolCreateXML() and storagePoolCreate() DEFINED signal is emitted in storagePoolDefineXML() UNDEFINED signal is emitted in storagePoolUndefine() STOPPED signal is emitted in storagePoolDestroy() and storagePoolRefresh() REFRESHED signal is emitted in storagePoolRefresh() There are also test as well as unittests for the new functions and signals. This is part of a GSOC project: Asynchronous lifecycle events for storage objects As part of the project there should also be implementation for storage volume events. For now there's no signal when volumes are created or deleted, they can also be implemented, but probably the easiest way is to have apps watch for REFRESH signal, and later extend storage driver code to refresh a pool after volume APIs are called. Jovanka Gulicoska (7): Introduce storage lifecycle event APIs conf: add storage_event handling test: implement storage lifecycle event APIs remote: implement storage lifecycle event APIs storage: implement storage lifecycle event APIs event-test: support storage lifecycle event APIs virsh: Introduce virsh-pool command daemon/libvirtd.h | 2 + daemon/remote.c | 207 ++++++++++++++++++++++++++++++- examples/object-events/event-test.c | 73 +++++++++++ include/libvirt/libvirt-storage.h | 93 ++++++++++++++ src/Makefile.am | 5 + src/conf/storage_conf.h | 4 + src/conf/storage_event.c | 235 ++++++++++++++++++++++++++++++++++++ src/conf/storage_event.h | 58 +++++++++ src/datatypes.h | 13 ++ src/driver-storage.h | 13 ++ src/libvirt-storage.c | 125 +++++++++++++++++++ src/libvirt_private.syms | 5 + src/libvirt_public.syms | 6 + src/remote/remote_driver.c | 128 ++++++++++++++++++++ src/remote/remote_protocol.x | 43 ++++++- src/remote_protocol-structs | 16 +++ src/storage/storage_driver.c | 110 +++++++++++++++++ src/test/test_driver.c | 71 +++++++++++ tests/objecteventtest.c | 177 +++++++++++++++++++++++++++ tools/virsh-pool.c | 184 ++++++++++++++++++++++++++++ 20 files changed, 1564 insertions(+), 4 deletions(-) create mode 100644 src/conf/storage_event.c create mode 100644 src/conf/storage_event.h -- 2.5.5

5 16

[libvirt] esx: What does "No storage volume with key or path" mean?
by Richard W.M. Jones 15 Jun '16

15 Jun '16

We've had a report of a particular vCenter server (using VMware clustering, we think) where virStorageVolInfo of a guest volume fails with: Storage volume not found: No storage volume with key or path '[...] ...' The error comes from esxVI_LookupFileInfoByDatastorePath: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/esx/esx_vi.c;h=f7eeeb5c… What does it mean? The reporter also said they could do some (frankly voodoo) moving guests around and then the error went away. We're not sure if that was just coincidence. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

1 1

[libvirt] [PATCH] vz: get rid of unused home state variable in private domain obj
by Nikolay Shirokovskiy 15 Jun '16

15 Jun '16

Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com> --- src/vz/vz_sdk.c | 16 ---------------- src/vz/vz_utils.h | 1 - 2 files changed, 17 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 2275572..3fe17e0 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -447,7 +447,6 @@ prlsdkDomObjFreePrivate(void *p) PrlHandle_Free(pdom->sdkdom); PrlHandle_Free(pdom->cache.stats); virCondDestroy(&pdom->cache.cond); - VIR_FREE(pdom->home); VIR_FREE(p); }; @@ -1484,7 +1483,6 @@ prlsdkLoadDomain(vzDriverPtr driver, virDomainObjPtr dom) virDomainDefPtr def = NULL; vzDomObjPtr pdom = NULL; VIRTUAL_MACHINE_STATE domainState; - char *home = NULL; PRL_RESULT pret; PRL_UINT32 ram; @@ -1541,17 +1539,6 @@ prlsdkLoadDomain(vzDriverPtr driver, virDomainObjPtr dom) pret = PrlVmCfg_GetEnvId(sdkdom, &envId); prlsdkCheckRetGoto(pret, error); - if (!(home = prlsdkGetStringParamVar(PrlVmCfg_GetHomePath, sdkdom))) - goto error; - - /* For VMs home is actually /directory/config.pvs */ - if (!IS_CT(def)) { - /* Get rid of /config.pvs in path string */ - char *s = strrchr(home, '/'); - if (s) - *s = '\0'; - } - pret = PrlVmCfg_GetAutoStart(sdkdom, &autostart); prlsdkCheckRetGoto(pret, error); if (autostart != PAO_VM_START_ON_LOAD && @@ -1588,8 +1575,6 @@ prlsdkLoadDomain(vzDriverPtr driver, virDomainObjPtr dom) virDomainDefFree(dom->def); dom->def = def; pdom->id = envId; - VIR_FREE(pdom->home); - pdom->home = home; prlsdkConvertDomainState(domainState, envId, dom); @@ -1607,7 +1592,6 @@ prlsdkLoadDomain(vzDriverPtr driver, virDomainObjPtr dom) return 0; error: PrlHandle_Free(sdkdom); - VIR_FREE(home); virDomainDefFree(def); return -1; } diff --git a/src/vz/vz_utils.h b/src/vz/vz_utils.h index ba4d3c5..1e2ed30 100644 --- a/src/vz/vz_utils.h +++ b/src/vz/vz_utils.h @@ -103,7 +103,6 @@ typedef struct _vzCountersCache vzCountersCache; struct vzDomObj { int id; - char *home; PRL_HANDLE sdkdom; vzCountersCache cache; }; -- 1.8.3.1

2 1