[libvirt] [PATCH] make sure libvirt is linked first
by Jan Palus
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
7 years, 2 months
[libvirt] [PATCH python] Post-release version bump to 4.2.0
by Daniel P. Berrangé
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
7 years, 2 months
[libvirt] [PATCH] Post-release version bump to 4.2.0
by Daniel P. Berrangé
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
7 years, 2 months
[libvirt] [PATCH] travis: force install of python2 into $PATH on macOS
by Daniel P. Berrangé
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
7 years, 2 months
[libvirt] update keycodemapdb submodule for 4.1.0 release
by Jim Fehlig
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
7 years, 2 months
[libvirt] [PATCH 0/2] Fix crash from live attach of device (for 4.1.0)
by John Ferlan
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
7 years, 2 months
[libvirt] [PATCH] virtlockd: acquire locks on re-exec
by Jim Fehlig
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
7 years, 2 months
[libvirt] [PATCH 0/6] Use query-cpus-fast instead of query-cpus
by Viktor Mihajlovski
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
7 years, 2 months
[libvirt] [BUG]libvirt doesn't show the real state of vm
by Wuzongyong (Euler Dept)
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
7 years, 2 months
