[libvirt] JNA Error Callback could cause core dump.
by Benjamin Wang (gendwang)
Hi,
When I changed code as following:
public class Connect {
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback());
}
The server will generate the following core dump:
Program terminated with signal 6, Aborted.
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
#1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6
#2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6
#3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6
#4 0x0000003f9b07276b in free () from /lib64/libc.so.6
#5 0x00002aaaacf46868 in ?? ()
#6 0x0000000000000000 in ?? ()
The problem was caused that when JNA call setErrorFunc, it will create ErrorCallback object. But when GC is executed, the object is GCed. But even I change code as following.
When GC is excuted, the callback object will be moved. Then C can't find this object. Both of scenarios will cause core dump. It seems that JNA mustn't provide ErrorCallback Class,
Because nobody can use this.
Please correct me.
public class Connect {
+ private static final ErrorCallback callback = new ErrorCallback();
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, callback);
}
B.R.
Benjamin Wang
10 years, 10 months
[libvirt] [PATCH 0/5] Fill qemucapabilitiesdata with some data
by Michal Privoznik
The actual patches are accessible at:
git://gitorious.org/libvirt/michal-staging.git
branch test_qemu_capabilities_data
I'm not sending the actual patches as it's big junk of JSON qemu replies. The
patches has from 35KiB to 59KiB. I don't want to overload the list.
Michal Privoznik (5):
qemucapabilitiesdata: Add qemu-1.2.2 data
qemucapabilitiesdata: Add qemu-1.3.1 data
qemucapabilitiesdata: Add qemu-1.4.2 data
qemucapabilitiesdata: Add qemu-1.6.0 data
qemucapabilitiesdata: Add qemu-1.6.50 data
tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 114 +
tests/qemucapabilitiesdata/caps_1.2.2-1.replies | 1543 +++++++++++++
tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 128 ++
tests/qemucapabilitiesdata/caps_1.3.1-1.replies | 1715 +++++++++++++++
tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 129 ++
tests/qemucapabilitiesdata/caps_1.4.2-1.replies | 1765 +++++++++++++++
tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 137 ++
tests/qemucapabilitiesdata/caps_1.6.0-1.replies | 2499 ++++++++++++++++++++++
tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 136 ++
tests/qemucapabilitiesdata/caps_1.6.50-1.replies | 2476 +++++++++++++++++++++
tests/qemucapabilitiestest.c | 5 +
11 files changed, 10647 insertions(+)
create mode 100644 tests/qemucapabilitiesdata/caps_1.2.2-1.caps
create mode 100644 tests/qemucapabilitiesdata/caps_1.2.2-1.replies
create mode 100644 tests/qemucapabilitiesdata/caps_1.3.1-1.caps
create mode 100644 tests/qemucapabilitiesdata/caps_1.3.1-1.replies
create mode 100644 tests/qemucapabilitiesdata/caps_1.4.2-1.caps
create mode 100644 tests/qemucapabilitiesdata/caps_1.4.2-1.replies
create mode 100644 tests/qemucapabilitiesdata/caps_1.6.0-1.caps
create mode 100644 tests/qemucapabilitiesdata/caps_1.6.0-1.replies
create mode 100644 tests/qemucapabilitiesdata/caps_1.6.50-1.caps
create mode 100644 tests/qemucapabilitiesdata/caps_1.6.50-1.replies
--
1.8.1.5
10 years, 10 months
[libvirt] [PATCH 0/4] Support for integrating cgroups with systemd
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
This is a much changed / expanded version of my previous work to
create cgroups via systemd. The difference is that this time it
actually works :-)
I'm not proposing this for merge until after the 1.1.1 release.
Daniel P. Berrange (4):
Add APIs for formatting systemd slice/scope names
Add support for systemd cgroup mount
Cope with races while killing processes
Enable support for systemd-machined in cgroups creation
src/libvirt_private.syms | 2 +
src/lxc/lxc_process.c | 10 +-
src/qemu/qemu_cgroup.c | 1 +
src/util/vircgroup.c | 270 +++++++++++++++++++++++++++++++++++++++++------
src/util/vircgroup.h | 2 +
src/util/virsystemd.c | 96 ++++++++++++++++-
src/util/virsystemd.h | 5 +
tests/vircgrouptest.c | 9 ++
tests/virsystemdtest.c | 48 +++++++++
9 files changed, 403 insertions(+), 40 deletions(-)
--
1.8.1.4
10 years, 10 months
[libvirt] Internal error message from netcf when trying to start libvirtd
by Christophe Fergeau
Hey,
Due to a configuration issue on my system, libvirtd is not starting on my
system (not complaining about this!):
2013-10-15 15:40:51.024+0000: 10222: info : libvirt version: 1.1.3
2013-10-15 15:40:51.024+0000: 10222: error : virNetTLSContextCheckCertFile:117 : Cannot read CA certificate
'/home/teuf/usr/etc/pki/CA/cacert.pem': No such file or directory
However, before libvirtd exits, I get another error message from the netcf
code, which is unexpected this time:
2013-10-15 15:49:18.361+0000: 10222: error : netcfStateCleanup:105 :
internal error: Attempt to close netcf state driver already closed
This message comes from the call of virStateCleanup() at the end of main()
in libvirtd.c. virStateCleanup() should not be called before
daemonStateInit() has been called in main.
After this call, things get more ugly as daemonStateInit() calls
virStateInitialize() from a thread, so there's probably a small window for
virStateInitialize() and virStateCleanup() running concurrently if an error
occurs between the call to daemonStateInit() and the call to
virNetServerRun().
I'm sending this email rather than a patch as I'm not sure what is the best
way to fix it. The easy way would be for virStateCleanup() to be a noop
when virStateInitialize() hasn't been called (iow remove the error message
from netcfStateCleanup). However, this would leave this small race
condition around (which is not that bad as it would only occurs in
situations when the daemon fails to start). So another approach would be to
set a vir_state_initialized boolean once the thread has called
ivrStateInitialize, and only call virStateCleanup() when it's set.
Or maybe there's a 3rd way to fix this?
Let me know if you have any guidance into the best way to fix this,
Christophe
10 years, 11 months
[libvirt] [PATCH 0/3 RESEND] qemu: Hotplug SCSI controllers/hostdevs
by Eric Farman
(Resending, as this has perhaps been lost during the release of 1.1.3.
I've rebased this patch series onto today's git repository.)
Today, hotplug of a SCSI hostdev relies on the presence of an existing
SCSI controller, which can be defined in the initial domain XML. Hotplug
of a SCSI controller relies on the presence of a PCI bus, which does not
work in all environments.
These patches correct this behavior, in order to allow hotplug (and unplug)
work without incident.
Reviewed-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com>
Eric Farman (3):
qemu: Rename controller hotplug functions to not be PCI-specific
qemu: Separate calls based on controller bus type
qemu: Auto-generate controller for hotplugged hostdev
src/qemu/qemu_driver.c | 4 +--
src/qemu/qemu_hotplug.c | 62 ++++++++++++++++++++++++++++++++---------------
src/qemu/qemu_hotplug.h | 12 ++++-----
3 files changed, 50 insertions(+), 28 deletions(-)
--
1.7.9.5
10 years, 11 months
[libvirt] [PATCH v2] virsh domxml-from-native to treat SCSI as the bus type for pseries by default
by Shivaprasad G Bhat
The bus type IDE being enum Zero, the bus type on pseries system appears as IDE for all the disk types. Pseries platform needs this to appear as SCSI instead of IDE.
Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.vnet.ibm.com>
---
src/qemu/qemu_domain.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index b8aec2d..df06c13 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -827,6 +827,12 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
if (dev->type == VIR_DOMAIN_DEVICE_DISK) {
virDomainDiskDefPtr disk = dev->data.disk;
+ if ((def->os.arch == VIR_ARCH_PPC64) &&
+ def->os.machine && STREQ(def->os.machine, "pseries") &&
+ (disk->bus == VIR_DOMAIN_DISK_BUS_IDE)) {
+ disk->bus = VIR_DOMAIN_DISK_BUS_SCSI;
+ }
+
/* both of these require data from the driver config */
if (driver && (cfg = virQEMUDriverGetConfig(driver))) {
/* assign default storage format and driver according to config */
@@ -868,6 +874,11 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
(def->os.arch == VIR_ARCH_S390 || def->os.arch == VIR_ARCH_S390X))
dev->data.chr->targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO;
+ if (dev->type == VIR_DOMAIN_DEVICE_CONTROLLER &&
+ dev->data.controller->type == VIR_DOMAIN_CONTROLLER_TYPE_IDE &&
+ def->os.machine && STREQ(def->os.machine, "pseries"))
+ dev->data.controller->type = VIR_DOMAIN_CONTROLLER_TYPE_SCSI;
+
/* set the default USB model to none for s390 unless an address is found */
if (dev->type == VIR_DOMAIN_DEVICE_CONTROLLER &&
dev->data.controller->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
10 years, 11 months
[libvirt] [PATCH v2]virsh: track alias option and improve error message when option duplicates its alias
by Chen Hanxiao
From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
commit 2b172a8effa712aee97a21a64d2d02060958f9b2 allow
alias to expand to opt=value pair.
That means alias may not look alike since then.
With this patch we will also track alias.
If we type command with one option and another marked
as its alias, we will get an error message like:
error: option '--AA' duplicates its alias '--AAA'
Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
---
v2: do not depend on orders of options in array.
Alias could be anywhere except after the default one.
tools/virsh.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/tools/virsh.c b/tools/virsh.c
index bad78c9..ffead84 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1071,6 +1071,7 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name,
size_t i;
const vshCmdOptDef *ret = NULL;
char *alias = NULL;
+ char *tmp_name = NULL;
if (STREQ(name, helpopt.name)) {
return &helpopt;
@@ -1101,6 +1102,13 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name,
if (VIR_STRDUP(*optstr, value + 1) < 0)
goto cleanup;
}
+ tmp_name = vshMalloc(NULL, strlen(name) + 3);
+ snprintf(tmp_name, strlen(name) + 3, "--%s", name);
+ if (strstr(rl_line_buffer, tmp_name)) {
+ vshError(ctl, _("option '--%s' duplicates its alias '--%s'"),
+ cmd->opts[i].name, name);
+ goto cleanup;
+ }
continue;
}
if ((*opts_seen & (1 << i)) && opt->type != VSH_OT_ARGV) {
@@ -1119,6 +1127,7 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name,
cmd->name, name);
}
cleanup:
+ VIR_FREE(tmp_name);
VIR_FREE(alias);
return ret;
}
--
1.8.2.1
10 years, 11 months
[libvirt] [PATCH] virsh-domain: Mark --live and --config mutually exclusive in vcpucount
by Peter Krempa
The 'vcpucount' command is a getter command for the vCPUu count. When
one or more of the filtering flags are specified the command returns the
value only for the selected combination. In this case the --live and
--config combination isn't valid. This however didn't cause errors as
the combination of flags was rejected by the libvirt API but then the
fallback code kicked in and requested the count in a way where the clash
of the flags didn't matter.
Mark the flag combination mutually exclusive so that user's aren't
confused.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1024245
---
tools/virsh-domain.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 59e3d8d..60abd3d 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -5331,6 +5331,7 @@ cmdVcpucount(vshControl *ctl, const vshCmd *cmd)
if (!maximum && !active && current)
current = false;
+ VSH_EXCLUSIVE_OPTIONS_VAR(live, config)
VSH_EXCLUSIVE_OPTIONS_VAR(current, live);
VSH_EXCLUSIVE_OPTIONS_VAR(current, config);
VSH_EXCLUSIVE_OPTIONS_VAR(active, maximum);
--
1.8.4.2
10 years, 11 months
[libvirt] [PATCH] use -w flag if supported by iptables
by Serge Hallyn
This will properly lock libvirt's usage of iptables with
others (like ufw).
(See https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1245322)
Signed-off-by: Serge Hallyn <serge.hallyn(a)ubuntu.com>
---
src/util/viriptables.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/src/util/viriptables.c b/src/util/viriptables.c
index 16f571e..30d59b6 100644
--- a/src/util/viriptables.c
+++ b/src/util/viriptables.c
@@ -50,19 +50,25 @@
#include "virstring.h"
#include "virutil.h"
+bool iptables_supports_xlock = false;
+
#if HAVE_FIREWALLD
static char *firewall_cmd_path = NULL;
+#endif
static int
virIpTablesOnceInit(void)
{
+ virCommandPtr cmd;
+ int status;
+
+#if HAVE_FIREWALLD
firewall_cmd_path = virFindFileInPath("firewall-cmd");
if (!firewall_cmd_path) {
VIR_INFO("firewall-cmd not found on system. "
"firewalld support disabled for iptables.");
} else {
- virCommandPtr cmd = virCommandNew(firewall_cmd_path);
- int status;
+ virCommandNew(firewall_cmd_path);
virCommandAddArgList(cmd, "--state", NULL);
if (virCommandRun(cmd, &status) < 0 || status != 0) {
@@ -74,13 +80,26 @@ virIpTablesOnceInit(void)
}
virCommandFree(cmd);
}
+
+ if (firewall_cmd_path)
+ return 0;
+
+#endif
+
+ cmd = virCommandNew(IPTABLES_PATH);
+ virCommandAddArgList(cmd, "-w", "-L", "-n", NULL);
+ if (virCommandRun(cmd, &status) < 0 || status != 0) {
+ VIR_INFO("xtables locking not supported by your iptables");
+ } else {
+ VIR_INFO("using xtables locking for iptables");
+ iptables_supports_xlock = true;
+ }
+ virCommandFree(cmd);
return 0;
}
VIR_ONCE_GLOBAL_INIT(virIpTables)
-#endif
-
#define VIR_FROM_THIS VIR_FROM_NONE
enum {
@@ -104,6 +123,9 @@ iptablesCommandNew(const char *table, const char *chain, int family, int action)
if (cmd == NULL) {
cmd = virCommandNew((family == AF_INET6)
? IP6TABLES_PATH : IPTABLES_PATH);
+
+ if (iptables_supports_xlock)
+ virCommandAddArgList(cmd, "-w", NULL);
}
virCommandAddArgList(cmd, "--table", table,
--
1.8.3.2
10 years, 11 months
