- Devel - libvirt List Archives

[libvirt] [PATCH] storage_backend_rbd: always call rados_conf_read_file when connect a rbd pool
by Chen Hanxiao 18 Jan '17

18 Jan '17

From: Chen Hanxiao <chenhanxiao(a)gmail.com> This patch fix a dead lock when try to read a rbd image When trying to connect a rbd server (ceph-0.94.7-1.el7.centos.x86_64), rbd_list/rbd_open enter a dead lock state. Backtrace: Thread 30 (Thread 0x7fdb342d0700 (LWP 12105)): #0 0x00007fdb40b16705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fdb294273f1 in librados::IoCtxImpl::operate_read(object_t const&, ObjectOperation*, ceph::buffer::list*, int) () from /lib64/librados.so.2 #2 0x00007fdb29429fcc in librados::IoCtxImpl::read(object_t const&, ceph::buffer::list&, unsigned long, unsigned long) () from /lib64/librados.so.2 #3 0x00007fdb293e850c in librados::IoCtx::read(std::string const&, ceph::buffer::list&, unsigned long, unsigned long) () from /lib64/librados.so.2 #4 0x00007fdb2b9dd15e in librbd::list(librados::IoCtx&, std::vector<std::string, std::allocator<std::string> >&) () from /lib64/librbd.so.1 #5 0x00007fdb2b98c089 in rbd_list () from /lib64/librbd.so.1 #6 0x00007fdb2e1a8052 in virStorageBackendRBDRefreshPool (conn=<optimized out>, pool=0x7fdafc002d50) at storage/storage_backend_rbd.c:366 #7 0x00007fdb2e193833 in storagePoolCreate (obj=0x7fdb1c1fd5a0, flags=<optimized out>) at storage/storage_driver.c:876 #8 0x00007fdb43790ea1 in virStoragePoolCreate (pool=pool@entry=0x7fdb1c1fd5a0, flags=0) at libvirt-storage.c:695 #9 0x00007fdb443becdf in remoteDispatchStoragePoolCreate (server=0x7fdb45fb2ab0, msg=0x7fdb45fb3db0, args=0x7fdb1c0037d0, rerr=0x7fdb342cfc30, client=<optimized out>) at remote_dispatch.h:14383 #10 remoteDispatchStoragePoolCreateHelper (server=0x7fdb45fb2ab0, client=<optimized out>, msg=0x7fdb45fb3db0, rerr=0x7fdb342cfc30, args=0x7fdb1c0037d0, ret=0x7fdb1c1b3260) at remote_dispatch.h:14359 #11 0x00007fdb437d9c42 in virNetServerProgramDispatchCall (msg=0x7fdb45fb3db0, client=0x7fdb45fd1a80, server=0x7fdb45fb2ab0, prog=0x7fdb45fcd670) at rpc/virnetserverprogram.c:437 #12 virNetServerProgramDispatch (prog=0x7fdb45fcd670, server=server@entry=0x7fdb45fb2ab0, client=0x7fdb45fd1a80, msg=0x7fdb45fb3db0) at rpc/virnetserverprogram.c:307 #13 0x00007fdb437d4ebd in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0x7fdb45fb2ab0) at rpc/virnetserver.c:135 #14 virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x7fdb45fb2ab0) at rpc/virnetserver.c:156 #15 0x00007fdb436cfb35 in virThreadPoolWorker (opaque=opaque@entry=0x7fdb45fa7650) at util/virthreadpool.c:145 #16 0x00007fdb436cf058 in virThreadHelper (data=<optimized out>) at util/virthread.c:206 #17 0x00007fdb40b12df5 in start_thread () from /lib64/libpthread.so.0 #18 0x00007fdb408401ad in clone () from /lib64/libc.so.6 366 len = rbd_list(ptr.ioctx, names, &max_size); (gdb) n [New Thread 0x7fdb20758700 (LWP 22458)] [New Thread 0x7fdb20556700 (LWP 22459)] [Thread 0x7fdb20758700 (LWP 22458) exited] [New Thread 0x7fdb20455700 (LWP 22460)] [Thread 0x7fdb20556700 (LWP 22459) exited] [New Thread 0x7fdb20556700 (LWP 22461)] infinite loop... Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/storage/storage_backend_rbd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index b1c51ab..233737b 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -95,6 +95,9 @@ virStorageBackendRBDOpenRADOSConn(virStorageBackendRBDStatePtr ptr, goto cleanup; } + /* try default location, but ignore failure */ + rados_conf_read_file(ptr->cluster, NULL); + if (!conn) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("'ceph' authentication not supported " @@ -124,6 +127,10 @@ virStorageBackendRBDOpenRADOSConn(virStorageBackendRBDStatePtr ptr, _("failed to create the RADOS cluster")); goto cleanup; } + + /* try default location, but ignore failure */ + rados_conf_read_file(ptr->cluster, NULL); + if (virStorageBackendRBDRADOSConfSet(ptr->cluster, "auth_supported", "none") < 0) goto cleanup; -- 2.7.4

2 3

[libvirt] [PATCH] qemu_domain: add timestamp in tainting of guests log
by Chen Hanxiao 18 Jan '17

18 Jan '17

From: Chen Hanxiao <chenhanxiao(a)gmail.com> We lacked of timestamp in tainting of guests log, which bring troubles for finding guest issues: such as whether a guest powerdown caused by qemu-monitor-command or others issues inside guests. If we had timestamp in tainting of guests log, it would be helpful when checking guest's logs(eg. /var/log/messages). Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/qemu/qemu_domain.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 35baffb..21c90a9 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4001,6 +4001,7 @@ void qemuDomainObjTaint(virQEMUDriverPtr driver, bool closeLog = false; if (virDomainObjTaint(obj, taint)) { + char *timestamp = NULL; char uuidstr[VIR_UUID_STRING_BUFLEN]; virUUIDFormat(obj->def->uuid, uuidstr); @@ -4018,27 +4019,31 @@ void qemuDomainObjTaint(virQEMUDriverPtr driver, logCtxt = qemuDomainLogContextNew(driver, obj, QEMU_DOMAIN_LOG_CONTEXT_MODE_ATTACH); if (!logCtxt) { - if (orig_err) { - virSetError(orig_err); - virFreeError(orig_err); - } VIR_WARN("Unable to open domainlog"); - return; + goto cleanup; } closeLog = true; } + if ((timestamp = virTimeStringNow()) == NULL) + goto cleanup; + if (qemuDomainLogContextWrite(logCtxt, - "Domain id=%d is tainted: %s\n", + "%s: Domain id=%d is tainted: %s\n", + timestamp, obj->def->id, virDomainTaintTypeToString(taint)) < 0) virResetLastError(); + + cleanup: if (closeLog) qemuDomainLogContextFree(logCtxt); if (orig_err) { virSetError(orig_err); virFreeError(orig_err); } + + VIR_FREE(timestamp); } } -- 2.7.4

2 1

[libvirt] [PATCH v2 0/3] virsh: pool-list: introduce option --name and --uuid
by Chen Hanxiao 18 Jan '17

18 Jan '17

virsh # pool-list --name default root virsh # pool-list --uuid 76bd3b4d-2d23-4741-b6de-7377fa4320a1 f97964af-a3df-44ff-8664-886729035c09 virsh # pool-list --uuid --name 76bd3b4d-2d23-4741-b6de-7377fa4320a1 default f97964af-a3df-44ff-8664-886729035c09 root v2: do something like 'virsh list` Chen Hanxiao (3): virsh: pool-list: introduce --uuid for printing pool's UUID only virsh: pool-list: introduce --name for printing pool's name only virsh: pool-list: allow both --uuid and --name in one cmd tools/virsh-pool.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- tools/virsh.pod | 9 +++++++-- 2 files changed, 53 insertions(+), 4 deletions(-) -- 2.5.5

2 4

[libvirt] [PATCH] util: disallow resetting a pci-bridge device
by Shivaprasad G Bhat 18 Jan '17

18 Jan '17

It is distructive to attempt a reset on pci-bridge, the host can crash. The bridges won't contain any guest data and neither they can be passed through using vfio/stub. So, no point in allowing a reset for them. Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.vnet.ibm.com> --- src/util/virpci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/util/virpci.c b/src/util/virpci.c index 0601f49..860f7aa 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -933,6 +933,16 @@ virPCIDeviceReset(virPCIDevicePtr dev, char *drvName = NULL; int ret = -1; int fd = -1; + int hdrType = -1; + + if (virPCIGetHeaderType(dev, &hdrType) < 0) + return -1; + + if (hdrType == VIR_PCI_HEADER_PCI_BRIDGE) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Resetting a pci-bridge device is not allowed")); + return -1; + } if (activeDevs && virPCIDeviceListFind(activeDevs, dev)) { virReportError(VIR_ERR_INTERNAL_ERROR,

3 2

[libvirt] [PATCH] Fix the incorrect memory freeing which will result in crash
by Wu Zongyong 18 Jan '17

18 Jan '17

The number of elements in new_params is equal to the length of info, instead of nparams, so it's wrong to free new_params using nparams. Signed-off-by: Wu Zongyong <wuzongyo(a)mail.ustc.edu.cn> --- libvirt-override.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libvirt-override.c b/libvirt-override.c index db14244..dac4250 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -632,7 +632,7 @@ libvirt_virDomainSetSchedulerParametersFlags(PyObject *self ATTRIBUTE_UNUSED, int nparams = 0; Py_ssize_t size = 0; unsigned int flags; - virTypedParameterPtr params, new_params = NULL; + virTypedParameterPtr params = NULL, new_params = NULL; if (!PyArg_ParseTuple(args, (char *)"OOI:virDomainSetScedulerParametersFlags", @@ -694,7 +694,7 @@ libvirt_virDomainSetSchedulerParametersFlags(PyObject *self ATTRIBUTE_UNUSED, cleanup: virTypedParamsFree(params, nparams); - virTypedParamsFree(new_params, nparams); + virTypedParamsFree(new_params, size); return ret; } @@ -7682,7 +7682,7 @@ libvirt_virNodeSetMemoryParameters(PyObject *self ATTRIBUTE_UNUSED, int nparams = 0; Py_ssize_t size = 0; unsigned int flags; - virTypedParameterPtr params, new_params = NULL; + virTypedParameterPtr params = NULL, new_params = NULL; if (!PyArg_ParseTuple(args, (char *)"OOI:virNodeSetMemoryParameters", @@ -7741,7 +7741,7 @@ libvirt_virNodeSetMemoryParameters(PyObject *self ATTRIBUTE_UNUSED, cleanup: virTypedParamsFree(params, nparams); - virTypedParamsFree(new_params, nparams); + virTypedParamsFree(new_params, size); return ret; } -- 2.10.0.windows.1

2 1

[libvirt] Entering freeze for libvirt-3.0.0
by Daniel Veillard 18 Jan '17

18 Jan '17

As planned, I tagged the RC1 in git and pushed signed tarball and rpms to the usual location: ftp://libvirt.org/libvirt/ This seems to work fine in my limited testing but as usual we need community feedback on it and especially testing on different systems and architectures, so please give it a try ! If everything works fine then I will push rc2 on Friday and hopefully 3.0.0 final on Monday, so please give it a try to make sure that 0.0 release is nonetheless a good one :-) thanks ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

7 16

[libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)
by Eduardo Habkost 18 Jan '17

18 Jan '17

On Wed, Jan 04, 2017 at 11:39:16AM -0200, Eduardo Habkost wrote: > On Wed, Jan 04, 2017 at 09:56:56AM -0200, Marcelo Tosatti wrote: > > On Tue, Dec 27, 2016 at 05:21:20PM -0200, Eduardo Habkost wrote: > > > Instead of blocking migration on the source when invtsc is > > > enabled, rely on the migration destination to ensure there's no > > > TSC frequency mismatch. > > > > > > We can't allow migration unconditionally because we don't know if > > > the destination is a QEMU version that is really going to ensure > > > there's no TSC frequency mismatch. To ensure we are migrating to > > > a destination that won't ignore SET_TSC_KHZ errors, allow invtsc > > > migration only on pc-*-2.9 and newer. > > > > > > Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> [...] > > > @@ -2655,12 +2656,14 @@ int kvm_arch_put_registers(CPUState *cpu, int level) > > > } > > > > > > if (level == KVM_PUT_FULL_STATE) { > > > - /* We don't check for kvm_arch_set_tsc_khz() errors here, > > > - * because TSC frequency mismatch shouldn't abort migration, > > > - * unless the user explicitly asked for a more strict TSC > > > - * setting (e.g. using an explicit "tsc-freq" option). > > > + /* Migration TSC frequency mismatch is fatal only if we are > > > + * actually reporting Invariant TSC to the guest. > > > */ > > > - kvm_arch_set_tsc_khz(cpu); > > > + ret = kvm_arch_set_tsc_khz(cpu); > > > + if ((x86_cpu->env.features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) && > > > + ret < 0) { > > > + return ret; > > > + } > > > } > > > > Will the guest continue in the source in this case? > > > > I think this is past the point where migration has been declared > > successful. > > > > Otherwise looks good. > > Good point. I will make additional tests and see if there's some > other place where the kvm_arch_set_tsc_khz() call can be moved > to. So, if we solve this and do something on (for example) post_load, we still have a problem: device state is migrated after RAM. This means QEMU will check for TSC scaling and abort migration very late. We could solve that by manually registering a SaveVMHandler that will send the TSC frequency on save_live_setup, so migration is aborted earlier. But: this sounds like just a complex hack to work around the real problems: 1) TSC frequency is guest-visible, and anything that affects guest ABI should depend on the VM configuration, not on host capabilities; 2) Setting TSC frequency depending on the host will make migratability unpredictable for management software: the same VM config could be migratable to host A when started on host B, but not migratable to host A when started on host C. I suggest we allow migration with invtsc if and only if tsc-frequency is set explicitly by management software. In other words, apply only patches 1/4 and 2/4 from this series. After that, we will need libvirt support for configuring tsc-frequency. -- Eduardo

5 21

[libvirt] [PATCH v3 0/2] Allow migration with invtsc if TSC frequency is explicitly set
by Eduardo Habkost 18 Jan '17

18 Jan '17

This series makes QEMU accept migration if tsc-frequency is explicitly set on configuration. As management software is required to keep device configuration the same on migration source or destination, explicit tsc-frequency will ensure that either: * The destination host has a matching TSC frequency; or * The destination host has TSC scaling available. Changelog ========= v2 -> v3: * Fix build failure ((missing closing braces) v1 -> v2: * v1 series subject was: * [PATCH 0/4] Allow migration with invtsc if there's no frequency mismatch * Removed patches 3/4 and 4/4, that allowed migration if no explicit tsc-frequency was set. Implementing the check on post_load or post_init is not enough to make migration abort, so we will need a more complex solution to implement that feature. Plans for future work ===================== 1) Querying host TSC frequency/scaling capability ------------------------------------------------- I plan to include TSC frequency/scaling information on query-cpu-model-expansion model="host" in a future series. Then management software will be able to automatically configure TSC frequency when invtsc is enabled, instead of requiring the user to configure it explicitly. While we don't implement that, invtsc migration will be possible only if the user configures TSC frequency manually. 2) invtsc migration with no explicit TSC frequency -------------------------------------------------- A future series can implement migration when TSC frequency is not specified explicitly. It will be a bit more complex because it requires either letting the destination abort the migration, or sending TSC frequency/scaling information from destination to source. --- Cc: Marcelo Tosatti <mtosatti(a)redhat.com> Cc: "Daniel P. Berrange" <berrange(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: kvm(a)vger.kernel.org Cc: Haozhong Zhang <haozhong.zhang(a)intel.com> Cc: "Michael S. Tsirkin" <mst(a)redhat.com> Cc: Igor Mammedov <imammedo(a)redhat.com> Cc: libvir-list(a)redhat.com Cc: Jiri Denemark <jdenemar(a)redhat.com> Eduardo Habkost (2): kvm: Simplify invtsc check kvm: Allow invtsc migration if tsc-khz is set explicitly target/i386/kvm.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) -- 2.11.0.259.g40922b1

2 1

[libvirt] [PATCH] Post-release version bump to 3.1.0
by Michal Privoznik 18 Jan '17

18 Jan '17

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial rule. configure.ac | 2 +- docs/news.xml | 11 +++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 9e41f8983..a217fc165 100644 --- a/configure.ac +++ b/configure.ac @@ -16,7 +16,7 @@ dnl You should have received a copy of the GNU Lesser General Public dnl License along with this library. If not, see dnl <http://www.gnu.org/licenses/>. -AC_INIT([libvirt], [3.0.0], [libvir-list(a)redhat.com] [], [http://libvirt.org] +AC_INIT([libvirt], [3.1.0], [libvir-list(a)redhat.com] [], [http://libvirt.org] AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_HEADERS([config.h]) diff --git a/docs/news.xml b/docs/news.xml index b912d8a62..4ff0cb638 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -10,6 +10,17 @@ and optionally a description where it's explained in more detail --> <libvirt> + <release version="v3.1.0" date="unreleased"> + <section title="New features"> + <change/> + </section> + <section title="Improvements"> + <change/> + </section> + <section title="Bug fixes"> + <change/> + </section> + </release> <release version="v3.0.0" date="2017-01-17"> <section title="New features"> <change> -- 2.11.0

1 0

[libvirt] [PATCH] tests: Distribute qemuhotplugtestcpus
by Michal Privoznik 18 Jan '17

18 Jan '17

Starting from a245abce436f4f333 another set of tests for qemuhotplugtest has been introduced. This time for vcpu hotplug. However, the test data (which live in qemuhotplugtestcpus dir) are not being distributed properly. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under build breaker rule. tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index c7d474817..87197841b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -121,6 +121,7 @@ EXTRA_DIST = \ qemucapabilitiesdata \ qemucaps2xmldata \ qemuhelpdata \ + qemuhotplugtestcpus \ qemuhotplugtestdevices \ qemuhotplugtestdomains \ qemumonitorjsondata \ -- 2.11.0

1 0