[libvirt] [PATCH] lxc: don't try to resolve a NULL path for filesystems
by Daniel P. Berrange
<filesystem type='ram' accessmode='passthrough'>
<source usage='524288' units='KiB'/>
<target dir='/dev/shm'/>
</filesystem>
would lead to lxcContainerResolveSymlinks calling
access(NULL) because it failed to check if fs->src->path
was non-NULL. This is a regression caused by
commit da665fbd4858890fbb3bbf5da2a7b6ca37bb3220
Author: Olga Krishtal <okrishtal(a)virtuozzo.com>
Date: Thu Jul 14 16:52:38 2016 +0300
filesystem: adds possibility to use storage pool as fs source
Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com>
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/lxc/lxc_container.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 124b441..e1eb434 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -616,7 +616,7 @@ static int lxcContainerResolveSymlinks(virDomainFSDefPtr fs, bool gentle)
{
char *newroot;
- if (!fs->src || fs->symlinksResolved)
+ if (!fs->src || !fs->src->path || fs->symlinksResolved)
return 0;
if (access(fs->src->path, F_OK)) {
--
2.7.4
8 years, 3 months
[libvirt] [PATCH 0/7] qemu: Trivially add support for newer ivshmem
by Martin Kletzander
It's "trivially" because it's just about using different parameters.
It is a series because I wanted to make some code paths saner and some
output nicer, but I tried keeping every patch self-contained and as
small as possible while keeping the readability. Also I wanted to
make the series to be looked upon by more people by just using the
word "trivial". Sorry for that =)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1347049
Martin Kletzander (7):
qemu: Add capabilities for ivshmem-{plain,doorbell}
qemu: Save various defaults for shmem
qemu: Make qemuBuildShmemDevStr static
qemu: Rename qemuBuildShmemDevStr to qemuBuildShmemDevLegacyStr
qemu: Move common checks outside qemuBuildShmemDevLegacyStr
qemu: Reorder shmem params nicely
qemu: Support newer ivshmem and prefer that over the legacy one
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_command.c | 144 +++++++++++++++------
src/qemu/qemu_command.h | 4 -
src/qemu/qemu_domain.c | 18 +++
.../caps_2.6.0-gicv2.aarch64.xml | 2 +
.../caps_2.6.0-gicv3.aarch64.xml | 2 +
tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 2 +
tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 +
tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 +
.../qemuxml2argv-shmem-plain-doorbell.args | 42 ++++++
.../qemuxml2argv-shmem-plain-doorbell.xml} | 14 +-
tests/qemuxml2argvdata/qemuxml2argv-shmem.args | 16 +--
tests/qemuxml2argvtest.c | 3 +
tests/qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml | 1 +
15 files changed, 193 insertions(+), 65 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.args
copy tests/{qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml => qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.xml} (66%)
--
2.9.2
8 years, 3 months
[libvirt] an AB deadlock or libvirtd crash problem in virsh console and virsh destroy
by weifuqiang
Hi all:
I encountered with an AB deadlock and libvirtd crash problem the other day.
The process to generate the problems:
1 use the command "virsh create ***.xml" to create a vm
2 after vm is running , use the command "virsh console ***" to connect vm with console
3 after connection, use the command "virsh destroy ****" to destroy vm and delete it
Then, an AB lock problem occurs, or libvirtd got crashed.
AB LOCK stack:
[Switching to thread 1 (Thread 0x7ff96bf3d7a0 (LWP 9772))]
#0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0
#0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007ff967b44669 in _L_lock_1008 () from /lib64/libpthread.so.0
#2 0x00007ff967b4447e in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007ff96b3bd96c in virChrdevFDStreamCloseCb () from /usr/lib64/libvirt.so.0
#4 0x00007ff96b3c9a34 in virFDStreamCloseInt () from /usr/lib64/libvirt.so.0
#5 0x00007ff96b40ac3e in virStreamAbort () from /usr/lib64/libvirt.so.0
#6 0x00007ff96bfa242a in daemonStreamHandleAbort ()
#7 0x00007ff96bfa2803 in daemonStreamEvent ()
#8 0x00007ff96b3c9bfc in virFDStreamEvent () from /usr/lib64/libvirt.so.0
#9 0x00007ff96b3083aa in virEventPollRunOnce () from /usr/lib64/libvirt.so.0
#10 0x00007ff96b307042 in virEventRunDefaultImpl () from /usr/lib64/libvirt.so.0
#11 0x00007ff96b4503dd in virNetDaemonRun () from /usr/lib64/libvirt.so.0
#12 0x00007ff96bf72528 in main ()
[Switching to thread 12 (Thread 0x7ff9640ff700 (LWP 9778))]
#0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0
#0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007ff967b44669 in _L_lock_1008 () from /lib64/libpthread.so.0
#2 0x00007ff967b4447e in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007ff96b3c8f26 in virFDStreamSetInternalCloseCb () from /usr/lib64/libvirt.so.0
#4 0x00007ff96b30f7b9 in virHashForEach () from /usr/lib64/libvirt.so.0
#5 0x00007ff96b3be1a2 in virChrdevFree () from /usr/lib64/libvirt.so.0
#6 0x00007ff96055980f in qemuDomainObjPrivateFree () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#7 0x00007ff96b367014 in virDomainObjDispose () from /usr/lib64/libvirt.so.0
#8 0x00007ff96b330c33 in virObjectUnref () from /usr/lib64/libvirt.so.0
#9 0x00007ff96b35edb9 in virDomainObjEndAPI () from /usr/lib64/libvirt.so.0
#10 0x00007ff9605c6e89 in qemuDomainUndefineFlags () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#11 0x00007ff96b3e35ac in virDomainUndefine () from /usr/lib64/libvirt.so.0
#12 0x00007ff96bf996db in remoteDispatchDomainUndefineHelper ()
#13 0x00007ff96b4537ef in virNetServerProgramDispatch () from /usr/lib64/libvirt.so.0
#14 0x00007ff96b45205e in virNetServerProcessMsg () from /usr/lib64/libvirt.so.0
#15 0x00007ff96b4520e8 in virNetServerHandleJob () from /usr/lib64/libvirt.so.0
#16 0x00007ff96b349f94 in virThreadPoolWorker () from /usr/lib64/libvirt.so.0
#17 0x00007ff96b3494a8 in virThreadHelper () from /usr/lib64/libvirt.so.0
#18 0x00007ff967b42806 in start_thread () from /lib64/libpthread.so.0
#19 0x00007ff96789d67d in clone () from /lib64/libc.so.6
#20 0x0000000000000000 in ?? ()
coredump stack
(gdb) f 1
#1 0x00007f1672a7c73f in virMutexLock (m=0x68) at util/virthread.c:89
89 pthread_mutex_lock(&m->lock);
(gdb) bt
#0 0x00007f1670ace444 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1 0x00007f1672a7c73f in virMutexLock (m=0x68) at util/virthread.c:89
#2 0x00007f1672b2fda2 in virFDStreamSetInternalCloseCb (st=0x7f1673a1a370, cb=0x0, opaque=0x0, fcb=0x0) at fdstream.c:796
#3 0x00007f1672b1f5ad in virChrdevFreeClearCallbacks (payload=0x7f1673a1a370, name=0x7f1673a12520, data=0x0) at conf/virchrdev.c:301
#4 0x00007f1672a36c9b in virHashForEach (table=0x7f1673a0ba20, iter=0x7f1672b1f567 <virChrdevFreeClearCallbacks>, data=0x0) at util/virhash.c:521
#5 0x00007f1672b1f626 in virChrdevFree (devs=0x7f1673a2f820) at conf/virchrdev.c:316
#6 0x00007f1669cca988 in qemuDomainObjPrivateFree (data=0x7f1673a1afa0) at qemu/qemu_domain.c:496
#7 0x00007f1672a9e293 in virDomainObjDispose (obj=0x7f1673a16400) at conf/domain_conf.c:2545
#8 0x00007f1672a5b326 in virObjectUnref (anyobj=0x7f1673a16400) at util/virobject.c:265
#9 0x00007f1672a9e7a5 in virDomainObjEndAPI (vm=0x7f166b07d8d0) at conf/domain_conf.c:2684
#10 0x00007f1669d3ff00 in qemuDomainDestroyFlags (dom=0x7f16600017f0, flags=0) at qemu/qemu_driver.c:2264
#11 0x00007f1669d3ff69 in qemuDomainDestroy (dom=0x7f16600017f0) at qemu/qemu_driver.c:2273
#12 0x00007f1672b39333 in virDomainDestroy (domain=0x7f16600017f0) at libvirt-domain.c:483
#13 0x00007f16737167a5 in remoteDispatchDomainDestroy (server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70, rerr=0x7f166b07db50, args=0x7f1673a2f9b0)
at remote_dispatch.h:4002
#14 0x00007f1673716648 in remoteDispatchDomainDestroyHelper (server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70, rerr=0x7f166b07db50, args=0x7f1673a2f9b0, ret=
0x7f1673a10e10) at remote_dispatch.h:3977
#15 0x00007f1672bd8a9b in virNetServerProgramDispatchCall (prog=0x7f167399c610, server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70)
at rpc/virnetserverprogram.c:437
#16 0x00007f1672bd85fd in virNetServerProgramDispatch (prog=0x7f167399c610, server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70) at rpc/virnetserverprogram.c:307
#17 0x00007f1672bd2a08 in virNetServerProcessMsg (srv=0x7f167398f4f0, client=0x7f1673a172f0, prog=0x7f167399c610, msg=0x7f1673a2fc70) at rpc/virnetserver.c:136
#18 0x00007f1672bd2aed in virNetServerHandleJob (jobOpaque=0x7f1673a1d780, opaque=0x7f167398f4f0) at rpc/virnetserver.c:157
#19 0x00007f1672a7d833 in virThreadPoolWorker (opaque=0x7f167399bad0) at util/virthreadpool.c:145
#20 0x00007f1672a7cbec in virThreadHelper (data=0x7f167399c980) at util/virthread.c:206
#21 0x00007f1670acc806 in start_thread () from /lib64/libpthread.so.0
#22 0x00007f167082767d in clone () from /lib64/libc.so.6
#23 0x0000000000000000 in ?? ()
(gdb) bt
#0 0x00007f1670ad3324 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f1670ace669 in _L_lock_1008 () from /lib64/libpthread.so.0
#2 0x00007f1670ace47e in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f1672a7c73f in virMutexLock (m=0x7f1673a2f820) at util/virthread.c:89
#4 0x00007f1672b1f3fe in virChrdevFDStreamCloseCb (st=0x7f1673a1a370, opaque=0x7f1673a149e0) at conf/virchrdev.c:254
#5 0x00007f1672b2e8a8 in virFDStreamCloseInt (st=0x7f1673a1a370, streamAbort=true) at fdstream.c:329
#6 0x00007f1672b2e9d5 in virFDStreamAbort (st=0x7f1673a1a370) at fdstream.c:355
#7 0x00007f1672b7d856 in virStreamAbort (stream=0x7f1673a1a370) at libvirt-stream.c:663
#8 0x00007f16737497e8 in daemonStreamHandleAbort (client=0x7f1673a1b1b0, stream=0x7f1673a1ec50, msg=0x7f1673a0d660) at stream.c:613
#9 0x00007f16737499fa in daemonStreamHandleWrite (client=0x7f1673a1b1b0, stream=0x7f1673a1ec50) at stream.c:662
#10 0x00007f167374866b in daemonStreamEvent (st=0x7f1673a1a370, events=14, opaque=0x7f1673a1b1b0) at stream.c:138
#11 0x00007f1672b2e17a in virFDStreamEvent (watch=18, fd=17, events=14, opaque=0x7f1673a1a370) at fdstream.c:173
#12 0x00007f1672a2c2cb in virEventPollDispatchHandles (nfds=12, fds=0x7f1673a2fda0) at util/vireventpoll.c:509
#13 0x00007f1672a2cb08 in virEventPollRunOnce () at util/vireventpoll.c:658
#14 0x00007f1672a2a9e0 in virEventRunDefaultImpl () at util/virevent.c:308
#15 0x00007f1672bd25d2 in virNetDaemonRun (dmn=0x7f1673990ed0) at rpc/virnetdaemon.c:707
#16 0x00007f167370cad4 in main (argc=3, argv=0x7ffd63276288) at libvirtd.c:1581
The reason of this problem is that fdstream abort event or close event occured at the same time, libvirtd doesn't deal with the synchronousness well enough.
the flows about fdStream is bellow
1、qemuDomainDefineXMLFlags -> virDomainObjListAdd -> qemuDomainObjPrivateAlloc -> virChrdevAlloc -> virHashCreate
2、qemuDomainOpenConsole -> virChrdevOpen -> virHashAddEntry(devs->hash, path, st)
3、virDomainObjDispose -> privateDataFreeFunc (qemuDomainObjPrivateFree) - > virChrdevFree(*dev locked*) -> virChrdevFreeClearCallbacks - > virFDStreamSetInternalCloseCb(*fdst locked*)
4、virFDStreamCloseInt (*fdst locked*) -> icbFreeOpaque(virChrdevFDStreamCloseCb (*dev locked*)) -> virHashRemoveEntry
The AB lock problem is obviouse: in step 3, it locks chardev before fdst, and in step 4, it's the opsite way.
The reason of libvirtd crash is that: in virFDStreamCloseInt function we set fdst to NULL, while in virFDStreamSetInternalCloseCb we use fdst->lock, note that fdst has already been freed.
another crash problem occurs because that when virChrdevFree was earlier finished, dev->hash freed and all date of hash is freed, but fdstream event flow use fdStream after hash free. Ahha~~， libvirtd coredump.
All of those problem is because clear vm flow and fdStream flow concurs synchronously.
then I fix this problem by modify virChrdevFree()
void virChrdevFree(virChrdevsPtr devs)
{
if (!devs || !devs->hash)
return;
for (;;) {
virMutexLock(&devs->lock);
if (0 == virHashSize(devs->hash)) {
virMutexUnlock(&devs->lock);
break;
}
virMutexUnlock(&devs->lock);
usleep(10 * 1000);
}
virMutexLock(&devs->lock);
virHashFree(devs->hash);
virMutexUnlock(&devs->lock);
virMutexDestroy(&devs->lock);
VIR_FREE(devs);
}
If the chardev is removed by fdStream close or fdStream abort when vm destroy or shutdown, the modification works well. But I'm not sure is that all chardev would be removed when we clear vm, if not, it would always sleep here.
Another solution is as follows:
virMutexLock(vm);
virChrdevFree();
virMutexUnlock(vm);
virMutexLock(vm);
virFDStreamCloseInt();
virMutexUnlock(vm);
I lock vm before calling these 2 functions, which makes them run sequently.
Do you have other better idea to solve this problem. thanks in advance.
Thanks in advance.
Wei Fuqiang
8 years, 3 months
[libvirt] [PATCH v2] libxl: support serial list
by Bob Liu
Add support for multi serial devices, after this patch virsh can be used to
connect different serial devices of running domains. E.g.
vish # console <xxx> --devname serial<xxx>
Note:
This depends on a xen/libxl bug fix to have libxl_console_get_tty(...) correctly
returning the tty path (as opposed to always returning the first one).
[0] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00438.html
Signed-off-by: Bob Liu <bob.liu(a)oracle.com>
---
v2: Add #ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST
---
src/libxl/libxl_conf.c | 24 +++++++++++++++++++++---
src/libxl/libxl_domain.c | 23 +++++++++++++++++++++++
src/libxl/libxl_driver.c | 17 +++++++++--------
3 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 146e08a..26c704d 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -431,14 +431,32 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
}
if (def->nserials) {
- if (def->nserials > 1) {
+ if (def->nserials == 1) {
+ if (libxlMakeChrdevStr(def->serials[0], &b_info->u.hvm.serial) <
+ 0)
+ return -1;
+ } else {
+#ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST
+ if (VIR_ALLOC_N(b_info->u.hvm.serial_list, def->nserials + 1) <
+ 0)
+ return -1;
+
+ for (i = 0; i < def->nserials; i++) {
+ if (libxlMakeChrdevStr(def->serials[i],
+ &b_info->u.hvm.serial_list[i]) < 0)
+ {
+ libxl_string_list_dispose(&b_info->u.hvm.serial_list);
+ return -1;
+ }
+ }
+ b_info->u.hvm.serial_list[i] = NULL;
+#else
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
"%s",
_("Only one serial device is supported by libxl"));
return -1;
+#endif
}
- if (libxlMakeChrdevStr(def->serials[0], &b_info->u.hvm.serial) < 0)
- return -1;
}
if (def->nparallels) {
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 0e26b91..5d8c9c1 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -989,6 +989,29 @@ libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
VIR_FREE(console);
}
}
+ for (i = 0; i < vm->def->nserials; i++) {
+ virDomainChrDefPtr chr = vm->def->serials[i];
+ char *console = NULL;
+ int ret;
+
+ ignore_value(virAsprintf(&chr->info.alias, "serial%zd", i));
+ if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
+ if (chr->source.data.file.path)
+ continue;
+ ret = libxl_console_get_tty(ctx, ev->domid,
+ chr->target.port,
+ LIBXL_CONSOLE_TYPE_SERIAL,
+ &console);
+ if (!ret) {
+ VIR_FREE(chr->source.data.file.path);
+ if (console && console[0] != '\0') {
+ ignore_value(VIR_STRDUP(chr->source.data.file.path,
+ console));
+ }
+ }
+ VIR_FREE(console);
+ }
+ }
virObjectUnlock(vm);
libxl_event_free(ctx, ev);
}
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index f153f69..a34eb02 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -4450,13 +4450,6 @@ libxlDomainOpenConsole(virDomainPtr dom,
virCheckFlags(VIR_DOMAIN_CONSOLE_FORCE, -1);
- if (dev_name) {
- /* XXX support device aliases in future */
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Named device aliases are not supported"));
- goto cleanup;
- }
-
if (!(vm = libxlDomObjFromDomain(dom)))
goto cleanup;
@@ -4472,8 +4465,16 @@ libxlDomainOpenConsole(virDomainPtr dom,
}
priv = vm->privateData;
+ if (dev_name) {
+ size_t i;
- if (vm->def->nconsoles) {
+ for (i = 0; !chr && i < vm->def->nserials; i++) {
+ if (STREQ(dev_name, vm->def->serials[i]->info.alias)) {
+ chr = vm->def->serials[i];
+ break;
+ }
+ }
+ } else if (vm->def->nconsoles) {
chr = vm->def->consoles[0];
if (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL)
chr = vm->def->serials[0];
--
2.6.5
8 years, 3 months
[libvirt] [PATCH 0/2] libxl USB vendor/product support
by Cédric Bosdonnat
Hi all,
Libxl API only allows providing bus/dev for USB hostdevs. If libvirt
libxl driver users provide vendor/product they get an error, instead
search for the corresponding bus/dev pair and feed them to libxl.
Cédric Bosdonnat (2):
Add virHostdevFindUSBDevice to private symbols
libxl: allow vendor/product addressing for USB hostdevs
src/libvirt_private.syms | 1 +
src/libxl/libxl_conf.c | 25 +++++++++++++++++--------
src/util/virhostdev.c | 2 +-
src/util/virhostdev.h | 6 ++++++
4 files changed, 25 insertions(+), 9 deletions(-)
--
2.6.6
8 years, 3 months
[libvirt] [PATCH jenkins-ci 00/19] Use jenkins-job-builder for CI
by Daniel P. Berrange
We are using the CentOS Jenkins server for running CI tasks.
Currently those tasks are maintained by people manually
updating the Jenkins web UI. This is a horrible interface
that requires 100's of mouse clicks to achieve even the
simplest things. It is also incredibly hard to compare
the config of different jobs to make sure they are working
in a consistent manner.
Fortunately there are tools which can help - OpenStack
created the jenkins-job-builder tool which uses the Jenkins
REST API to create/update jobs from a simple YAML file
definition.
This series thus creates a set of YAML files which will
(almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to
generate Jenkins XML files and then compared them to what
we currently have and they are mostly the same. So there
should not be too many suprises lurking, but I do still
expect some accidental breakage in places. As such I have
not actually uploaded the new auto-generated job configs
to ci.centos.org at this time.
The intention is that these configs will all live in the
libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Daniel P. Berrange (19):
jobs: add global default variables
jobs: add a template for generic build process
jobs: add a template for GNU autotools
jobs: add a template for Python distutils
jobs: add a template for Perl ExtUtils::MakeMaker
jobs: add a template for Perl Module::Build
projects: add the libvirt package
projects: add the libvirt-python package
projects: add the libvirt-perl package
projects: add the libvirt-tck package
projects: add the libvirt-glib package
projects: add the libvirt-sandbox package
projects: add the osinfo-db-tools package
projects: add the osinfo-db package
projects: add the libvirt-cim package
projects: add the virt-viewer package
projects: add the virt-manager package
projects: add the libosinfo package
Add README explaining how to use it
README | 34 ++++++++
jobs/autotools.yaml | 198 ++++++++++++++++++++++++++++++++++++++++++
jobs/defaults.yaml | 11 +++
jobs/generic.yaml | 124 ++++++++++++++++++++++++++
jobs/perl-makemaker.yaml | 105 ++++++++++++++++++++++
jobs/perl-modulebuild.yaml | 104 ++++++++++++++++++++++
jobs/python-distutils.yaml | 99 +++++++++++++++++++++
projects/libosinfo.yaml | 20 +++++
projects/libvirt-cim.yaml | 24 +++++
projects/libvirt-glib.yaml | 20 +++++
projects/libvirt-perl.yaml | 18 ++++
projects/libvirt-python.yaml | 18 ++++
projects/libvirt-sandbox.yaml | 19 ++++
projects/libvirt-tck.yaml | 16 ++++
projects/libvirt.yaml | 44 ++++++++++
projects/osinfo-db-tools.yaml | 19 ++++
projects/osinfo-db.yaml | 24 +++++
projects/virt-manager.yaml | 19 ++++
projects/virt-viewer.yaml | 19 ++++
19 files changed, 935 insertions(+)
create mode 100644 README
create mode 100644 jobs/autotools.yaml
create mode 100644 jobs/defaults.yaml
create mode 100644 jobs/generic.yaml
create mode 100644 jobs/perl-makemaker.yaml
create mode 100644 jobs/perl-modulebuild.yaml
create mode 100644 jobs/python-distutils.yaml
create mode 100644 projects/libosinfo.yaml
create mode 100644 projects/libvirt-cim.yaml
create mode 100644 projects/libvirt-glib.yaml
create mode 100644 projects/libvirt-perl.yaml
create mode 100644 projects/libvirt-python.yaml
create mode 100644 projects/libvirt-sandbox.yaml
create mode 100644 projects/libvirt-tck.yaml
create mode 100644 projects/libvirt.yaml
create mode 100644 projects/osinfo-db-tools.yaml
create mode 100644 projects/osinfo-db.yaml
create mode 100644 projects/virt-manager.yaml
create mode 100644 projects/virt-viewer.yaml
--
2.7.4
8 years, 3 months
[libvirt] [PATCH] qemu: fix qemu.conf security_driver
by Cole Robinson
Since a9331394 (first release v2.1.0), specifying a manual
security_driver setting in qemu.conf causes the daemon to fail to
start, erroring with 'Duplicate security driver X'.
The duplicate checking was incorrectly comparing every entry
against itself, guaranteeing a false positive.
https://bugzilla.redhat.com/show_bug.cgi?id=1365607
---
src/qemu/qemu_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index b51f36f..7b971f1 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -436,7 +436,7 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
goto cleanup;
for (i = 0; cfg->securityDriverNames && cfg->securityDriverNames[i] != NULL; i++) {
- for (j = i; cfg->securityDriverNames[j] != NULL; j++) {
+ for (j = i + 1; cfg->securityDriverNames[j] != NULL; j++) {
if (STREQ(cfg->securityDriverNames[i],
cfg->securityDriverNames[j])) {
virReportError(VIR_ERR_CONF_SYNTAX,
--
2.7.4
8 years, 3 months
[libvirt] [PATCH 0/3] Couple of virNetDevMacVLanCreateWithVPortProfile fixes
by Michal Privoznik
Le sigh. How come this slipped uncaught for that long?
Michal Privoznik (3):
virNetDevMacVLanCreateWithVPortProfile: Don't mask
virNetDevMacVLanTapOpen error
virNetDevMacVLanCreateWithVPortProfile: Drop @rc
virNetDevMacVLanCreateWithVPortProfile: Drop @ret
src/util/virnetdevmacvlan.c | 37 ++++++++++++++-----------------------
1 file changed, 14 insertions(+), 23 deletions(-)
--
2.8.4
8 years, 3 months
[libvirt] [PATCH] virt-admin: Fix the error when an invalid URI has been provided
by Erik Skultety
After commit 9d479dd1 fiddled with the cmdConnect's output which used to be a
bit more verbose prior to the mentioned commit, the program flow would result
in a quite confusing error if an invalid URI has been provided:
error: Failed to connect to the admin server
Connected to the admin server
error: <some error>
The problem is that the commit mentioned above relied on the fact that
connect routine always succeeds which is not true.
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
tools/virt-admin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virt-admin.c b/tools/virt-admin.c
index 2ae05da..513054b 100644
--- a/tools/virt-admin.c
+++ b/tools/virt-admin.c
@@ -351,7 +351,7 @@ cmdConnect(vshControl *ctl, const vshCmd *cmd)
}
vshAdmReconnect(ctl);
- if (!connected)
+ if (!connected && priv->conn)
vshPrint(ctl, "%s\n", _("Connected to the admin server"));
return !!priv->conn;
--
2.5.5
8 years, 3 months
[libvirt] [PATCH 0/4] Fix host-model CPUs on hosts with CMT
by Jiri Denemark
Since the introduction of CMT features (commit v1.3.5-461-gf294b83)
starting a domain with host-model CPU on a host which supports CMT fails
because QEMU complains about unknown 'cmt' feature:
qemu-system-x86_64: CPU feature cmt not found
https://bugzilla.redhat.com/show_bug.cgi?id=1355857
Jiri Denemark (4):
cpu_x86: Introduce x86FeatureIsMigratable
cpu_x86: Properly drop non-migratable features
tests: Add a test for host-model CPU with CMT feature
cpu_x86: Fix host-model CPUs on hosts with CMT
src/cpu/cpu_x86.c | 53 +++++++++++++++-------
.../qemuxml2argv-cpu-host-model-cmt.args | 22 +++++++++
.../qemuxml2argv-cpu-host-model-cmt.xml | 19 ++++++++
tests/qemuxml2argvtest.c | 1 +
tests/testutilsqemu.c | 1 +
5 files changed, 79 insertions(+), 17 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-host-model-cmt.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-host-model-cmt.xml
--
2.9.2
8 years, 3 months
