March 2018 - Devel - libvirt List Archives

[libvirt] [PATCH] make sure libvirt is linked first
by Jan Palus 05 Mar '18

05 Mar '18

so it's not affected by flags that might be passed in $(*_LIBS) like -L/usr/lib which might result in linking against system library and requiring incorrect version of private symbols --- src/Makefile.am | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 3bf2da5..cb6ee84 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1456,10 +1456,11 @@ libvirt_driver_nwfilter_impl_la_CFLAGS = \ $(AM_CFLAGS) libvirt_driver_nwfilter_impl_la_LDFLAGS = $(AM_LDFLAGS) libvirt_driver_nwfilter_impl_la_LIBADD = \ + libvirt.la \ $(LIBPCAP_LIBS) \ $(LIBNL_LIBS) \ - $(DBUS_LIBS) -libvirt_driver_nwfilter_impl_la_LIBADD += libvirt.la ../gnulib/lib/libgnu.la + $(DBUS_LIBS) \ + ../gnulib/lib/libgnu.la libvirt_driver_nwfilter_impl_la_SOURCES = $(NWFILTER_DRIVER_SOURCES) endif WITH_NWFILTER -- 2.16.2

3 7

[libvirt] [PATCH python] Post-release version bump to 4.2.0
by Daniel P. Berrangé 05 Mar '18

05 Mar '18

Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as trivial change setup.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/setup.py b/setup.py index 63da8c5..c40908b 100755 --- a/setup.py +++ b/setup.py @@ -334,7 +334,7 @@ class my_clean(clean): _c_modules, _py_modules = get_module_lists() setup(name = 'libvirt-python', - version = '4.1.0', + version = '4.2.0', url = 'http://www.libvirt.org', maintainer = 'Libvirt Maintainers', maintainer_email = 'libvir-list(a)redhat.com', -- 2.14.3

1 0

[libvirt] [PATCH] Post-release version bump to 4.2.0
by Daniel P. Berrangé 05 Mar '18

05 Mar '18

Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as trivial fix configure.ac | 2 +- docs/news.xml | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5e720d1b76..970a695ad1 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], [4.1.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] +AC_INIT([libvirt], [4.2.0], [libvir-list(a)redhat.com] [], [https://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 e4d61d1d7f..4da692b269 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -33,6 +33,14 @@ --> <libvirt> + <release version="v4.2.0" date="unreleased"> + <section title="New features"> + </section> + <section title="Improvements"> + </section> + <section title="Bug fixes"> + </section> + </release> <release version="v4.1.0" date="2018-03-05"> <section title="New features"> <change> -- 2.14.3

1 0

Re: [libvirt] [Libvirt-ci] Build failed in Jenkins: libvirt-master-mingw » libvirt-fedora-rawhide #1863
by Daniel P. Berrangé 05 Mar '18

05 Mar '18

On Mon, Mar 05, 2018 at 02:28:37PM +0000, ci(a)centos.org wrote: > See <https://ci.centos.org/job/libvirt-master-mingw/systems=libvirt-fedora-rawhi…> > > Changes: > > [jtomko] conf: set postParseFailed even without ALLOW_POST_PARSE_FAIL > > [berrange] travis: force install of python2 into $PATH on macOS > > ------------------------------------------ > ../../libtool: line 3227: 17288 Segmentation fault (core dumped) $MV "${write_libobj}T" "$write_libobj" > ../../libtool: line 3780: 17291 Segmentation fault (core dumped) $RM $removelist > /bin/sh: line 2: 17297 Segmentation fault (core dumped) mv -f $depbase.Tpo $depbase.Plo > make[3]: *** [Makefile:2392: poll.lo] Error 139 > make[3]: *** Waiting for unfinished jobs.... Ignore this - the build host is in middle of a huge dnf update. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

[libvirt] [PATCH] travis: force install of python2 into $PATH on macOS
by Daniel P. Berrangé 05 Mar '18

05 Mar '18

The homebrew formula's ignored Python PEP-0394 recommendations and changed the plain python binary in /usr/local/bin to point to Python 3 instead of Python 2. Python 2 is not even installed into a location that is in $PATH by default anymore. The homebrew packages print a message to stderr claiming to provide a way to fix this [quote] This formula installs a python2 executable to /usr/local/opt/python@2/bin If you wish to have this formula's python executable in your PATH then add the following to ~/.bash_profile: export PATH="/usr/local/opt/python@2/libexec/bin:$PATH" [/quote] When trying to update $PATH are suggested we find out this message is a lie and /usr/local/opt/python@2 does not even exist, instead Python seems to end up in /usr/local/Cellar/python(a)2/2.7.14_1 Rather than hardcoding this version specific directory in our travis config, we change to run "brew link --force python@2", to make it create symlinks in /usr/local/bin for the python2 binary. The original change triggering this problem was https://github.com/Homebrew/homebrew-core/pull/24604#issue-171653084 There are countless bug reports against homebrew-core that are closed without fixes, so it seems they are determined to ignore the Python PEP 0394 recommendations on this. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 44f680ad07..699e4bf33a 100644 --- a/.travis.yml +++ b/.travis.yml @@ -97,7 +97,7 @@ env: - VIR_TEST_DEBUG=1 before_install: - - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update && brew upgrade && brew install rpcgen yajl xz; fi + - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update && brew upgrade && brew install rpcgen yajl xz && brew link --force python@2 ; fi before_script: - ./autogen.sh --prefix=$(pwd)/install-root -- 2.14.3

2 1

[libvirt] update keycodemapdb submodule for 4.1.0 release
by Jim Fehlig 05 Mar '18

05 Mar '18

I mistakenly dropped keycodemapdb commit 6b3d716e from our libvirt 4.1.0 builds only to stumble across the failures in py3 environments that are fixed by that commit. Should the submodule be updated for the 4.1.0 release? Regards, Jim

5 7

[libvirt] [PATCH 0/2] Fix crash from live attach of device (for 4.1.0)
by John Ferlan 05 Mar '18

05 Mar '18

Fix is in patch 1/2 - if virDomainDefCompatibleDevice is called with a NULL @oldDev, then call to virDomainDeviceGetInfo would fail rather spectacularly. Patch 2 extends the similar fix/adjustment from the update path to the add path for the cdrom/floppy since the add path since it's possible to use attach device as well as update device. John Ferlan (2): conf: Fix crash in virDomainDefCompatibleDevice qemu: Call virDomainDefCompatibleDevice when live add cdrom/floppy src/conf/domain_conf.c | 5 ++++- src/qemu/qemu_hotplug.c | 8 ++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) -- 2.13.6

2 4

[libvirt] [PATCH] virtlockd: acquire locks on re-exec
by Jim Fehlig 05 Mar '18

05 Mar '18

Locks held by virtlockd are dropped on re-exec. virtlockd 94306 POSIX 5.4G WRITE 0 0 0 /tmp/test.qcow2 virtlockd 94306 POSIX 5B WRITE 0 0 0 /run/virtlockd.pid virtlockd 94306 POSIX 5B WRITE 0 0 0 /run/virtlockd.pid Acquire locks in PostExecRestart code path. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- The CLOEXEC flag is set in virLockSpaceNewPostExecRestart(), so I assume it is fine to call virFileLock() here as well. src/util/virlockspace.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/util/virlockspace.c b/src/util/virlockspace.c index 41af0cdb6..420878b0a 100644 --- a/src/util/virlockspace.c +++ b/src/util/virlockspace.c @@ -337,6 +337,7 @@ virLockSpacePtr virLockSpaceNewPostExecRestart(virJSONValuePtr object) virJSONValuePtr owners; size_t j; ssize_t m; + bool shared = false; if (VIR_ALLOC(res) < 0) goto error; @@ -389,6 +390,21 @@ virLockSpacePtr virLockSpaceNewPostExecRestart(virJSONValuePtr object) goto error; } + shared = !!(res->flags & VIR_LOCK_SPACE_ACQUIRE_SHARED); + if (virFileLock(res->fd, shared, 0, 1, false) < 0) { + if (errno == EACCES || errno == EAGAIN) { + virReportError(VIR_ERR_RESOURCE_BUSY, + _("Lockspace resource '%s' is locked"), + res->name); + } else { + virReportSystemError(errno, + _("Unable to acquire lock on '%s'"), + res->path); + } + virLockSpaceResourceFree(res); + goto error; + } + if (!(owners = virJSONValueObjectGet(child, "owners"))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Missing resource owners in JSON document")); -- 2.16.2

3 5

[libvirt] [PATCH 0/6] Use query-cpus-fast instead of query-cpus
by Viktor Mihajlovski 05 Mar '18

05 Mar '18

The QEMU monitor commmand query-cpus is deprecated starting with QEMU 2.12.0 because it can adversely affect the performance of a running virtual machine. This series enables libvirt to use the new query-cpus-fast interface if supported by the local QEMU instance and is required in order to support QEMU once the interface has been removed. query-cpus-fast doesn't return the halted state for a virtual CPU, meaning that the vcpu.<n>.halted value won't be reported with 'virsh domstats' anymore. This is OK, as stats values are not guaranteed to be reported under all circumstances and on all architectures. Upstream discussion consensus was that the halted state was problematic anyway, as it had different semantics per architecture. The only known exploitation happened for s390, for this architecture the halted state will be computed based on an architecture-specific cpu value returned in query-cpus-fast. Viktor Mihajlovski (6): qemu: add capability detection for query-cpus-fast qemu: use query-cpus-fast in JSON monitor tests: add qemumonitorjson tests for query-cpus-fast qemu: add architecture-specific CPU info handling tests: add testcase for s390 query-cpus-fast qemu: refresh vcpu halted state only via query-cpus-fast src/qemu/qemu_capabilities.c | 4 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 9 +- src/qemu/qemu_monitor.c | 14 +- src/qemu/qemu_monitor_json.c | 149 +++++++++++++++++++-- src/qemu/qemu_monitor_json.h | 3 +- .../qemumonitorjson-cpuinfo-ppc64-hotplug-4.data | 8 ++ .../qemumonitorjson-cpuinfo-s390-fast-cpus.json | 21 +++ .../qemumonitorjson-cpuinfo-s390-fast-hotplug.json | 21 +++ .../qemumonitorjson-cpuinfo-s390-fast.data | 19 +++ ...emumonitorjson-cpuinfo-x86-basic-pluggable.data | 5 + ...qemumonitorjson-cpuinfo-x86-full-fast-cpus.json | 71 ++++++++++ ...umonitorjson-cpuinfo-x86-full-fast-hotplug.json | 115 ++++++++++++++++ .../qemumonitorjson-cpuinfo-x86-full-fast.data | 109 +++++++++++++++ .../qemumonitorjson-cpuinfo-x86-node-full.data | 2 + tests/qemumonitorjsontest.c | 121 +++++++++++++---- tests/qemumonitortestutils.c | 6 + tests/qemumonitortestutils.h | 1 + 18 files changed, 637 insertions(+), 42 deletions(-) create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-s390-fast-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-s390-fast-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-s390-fast.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast.data -- 1.9.1

3 12

[libvirt] [BUG]libvirt doesn't show the real state of vm
by Wuzongyong (Euler Dept) 03 Mar '18

03 Mar '18

Hi, I notice that monitor.sock still exist when I send SIGKILL to qemu process by accident, and I can't find the qemu process through `ps -ef |grep qemu` command. Then I execute `virsh list --all`, libvirt just show that the vm still in running state. I can't find log "Received EOF on xxx" either when set log level to debug. Any suggestion will be appreciated! Thanks, Zongyong Wu

1 0