[libvirt] "invalid connection pointer in virConnectClose" from Python bindings
by Charles Duffy
Howdy.
I'm calling libvirt from a program which occasionally has cause to
fork() without an immediate exec(). For the sake of simplicity, I
presently call close() on all my virConnect objects [which I then
delete] before forking and create new ones later. (I'm not forcing an
explicit pre-fork garbage collection at present -- hopefully the close()
should make one unnecessary).
However, libvirt complains (and very occasionally segfaults) as I try to
close the connections:
libvir: error : invalid connection pointer in virConnectClose
libvir: error : invalid connection pointer in virConnectClose
Are there any practices I should be following to avoid this?
Alternatively, if it is likely to be related to an issue in the Python
bindings, is there something I could do to diagnose?
Thanks!
15 years, 1 month
[libvirt] ANNOUNCE: Perl binding Sys-Virt release 0.2.0
by Daniel P. Berrange
I've made a long overdue update to the Perl binding for libvirt, Sys-Virt.
http://search.cpan.org/CPAN/authors/id/D/DA/DANBERR/Sys-Virt-0.2.0.tar.gz
The major changes since last time
- Fix network create API, and UUID lookups
- Implement storage pool, storage vol, node device, security model,
domain events and event loop APIs
- Improve way constants are exposed to Perl layer
- Fix horrible memory leak in methods returning a hash
- Fix integer overflow in APIs using 64-bit ints (aka 'long long')
- Minimum required libvirt C library for building is 0.6.1
There is comprehensive API documentation available online
http://search.cpan.org/dist/Sys-Virt/
As well as a number of example scripts
http://cpansearch.perl.org/src/DANBERR/Sys-Virt-0.2.0/examples/
The master source repository for the Perl binding is now at
http://libvirt.org/hg/libvirt-perl/
Thanks to everyone who reported bugs, tested the snapshots and sent patches
for this release
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 1 month
[libvirt] [PATCH 2/2] VirtualBox support to libvirt
by Pritesh Kothari
Hi All,
I have attached a patch which when applied on the HEAD as of today would
allow virtualbox support in libvirt.
The patch works very well with the VirtualBox OSE version and the 2.2 Beta
release.
[PATCH 1/2] contains diff of files already in libvirt.
[PATCH 2/2] contains new files needed for VirtualBox support.
Regards,
-pritesh
15 years, 1 month
[libvirt] libvirt Centos4
by Gian Mario
Hi to all,
i need to compile libvirt-3.3.0 to Centos 4.7. Searching in mailing list
i have seen a tread that help me to solve few problems. Actually i face
with a error concern glibc, when i run make in libvirt directory, I
obtain:
/usr/lib64/libgcrypt.so.11: undefined reference to
`__read_chk(a)GLIBC_2.4'
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libgnutls.so:
undefined reference to `__stack_chk_fail(a)GLIBC_2.4'
collect2: ld returned 1 exit status
make[2]: *** [virsh] Error 1
make[2]: Leaving directory `/root/XEN/libvirt-0.3.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/XEN/libvirt-0.3.3'
make: *** [all] Error 2
Any one have some experience on compile libvirt on centos4?
there is any possibilities to build it without upgrade glibc?
tnks to any help.
Ciao e statevi bene.
GMario
15 years, 1 month
[libvirt] PATCH: Support memory ballooning for QEMU
by Daniel P. Berrange
This patch implements full support for memory ballooning in the QEMU
driver.
- Fix qemudBuildCommandLine() to set the initial boot time VM memory
allocation based off the 'maxmem' config field.
- Add call to 'qemudDomainSetMemoryBalloon' immediately at startup
to make the guest balloon to initial requested allocation.
- In the qemudDomainGetInfo() and qemudDomainDumpXML calls, query
the monitor to find current balloon allocation and update config
- Implement qemudDomainSetMemory() for running guests using the
monitor balloon command
In all of these scenarios, if the QEMU being used is too old to support
the memory balloon device, the user will get a suitable error or it'll
report the statically defined memory allocation from boot time.
Daniel
diff -r 4bfef84f4d6f src/qemu_conf.c
--- a/src/qemu_conf.c Tue Mar 10 12:09:41 2009 +0000
+++ b/src/qemu_conf.c Tue Mar 10 16:16:59 2009 +0000
@@ -870,7 +870,11 @@ int qemudBuildCommandLine(virConnectPtr
} \
} while (0)
- snprintf(memory, sizeof(memory), "%lu", vm->def->memory/1024);
+ /* Set '-m MB' based on maxmem, because the lower 'memory' limit
+ * is set post-startup using the balloon driver. If balloon driver
+ * is not supported, then they're out of luck anyway
+ */
+ snprintf(memory, sizeof(memory), "%lu", vm->def->maxmem/1024);
snprintf(vcpus, sizeof(vcpus), "%lu", vm->def->vcpus);
snprintf(domid, sizeof(domid), "%d", vm->def->id);
pidfile = virFilePid(driver->stateDir, vm->def->name);
diff -r 4bfef84f4d6f src/qemu_driver.c
--- a/src/qemu_driver.c Tue Mar 10 12:09:41 2009 +0000
+++ b/src/qemu_driver.c Tue Mar 10 16:16:59 2009 +0000
@@ -122,6 +122,9 @@ static int qemudMonitorCommandExtra(cons
const char *extra,
const char *extraPrompt,
char **reply);
+static int qemudDomainSetMemoryBalloon(virConnectPtr conn,
+ virDomainObjPtr vm,
+ unsigned long newmem);
static struct qemud_driver *qemu_driver = NULL;
@@ -1480,6 +1483,7 @@ static int qemudStartVMDaemon(virConnect
(qemudDetectVcpuPIDs(conn, vm) < 0) ||
(qemudInitCpus(conn, vm, migrateFrom) < 0) ||
(qemudInitPasswords(conn, driver, vm) < 0) ||
+ (qemudDomainSetMemoryBalloon(conn, vm, vm->def->memory) < 0) ||
(qemudSaveDomainStatus(conn, qemu_driver, vm) < 0)) {
qemudShutdownVMDaemon(conn, driver, vm);
return -1;
@@ -2409,6 +2413,98 @@ cleanup:
return ret;
}
+
+#define BALLOON_PREFIX "balloon: actual="
+
+/*
+ * Returns: 0 if balloon not supported, +1 if balloon query worked
+ * or -1 on failure
+ */
+static int qemudDomainGetMemoryBalloon(virConnectPtr conn,
+ virDomainObjPtr vm,
+ unsigned long *currmem) {
+ char *reply = NULL;
+ int ret = -1;
+ char *offset;
+
+ if (qemudMonitorCommand(vm, "info balloon", &reply) < 0) {
+ qemudReportError(conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ "%s", _("could not query memory balloon allocation"));
+ goto cleanup;
+ }
+
+ /* If the command failed qemu prints:
+ * device not found, device is locked ...
+ * No message is printed on success it seems */
+ DEBUG ("balloon reply: '%s'", reply);
+ if ((offset = strstr(reply, BALLOON_PREFIX)) != NULL) {
+ unsigned int memMB;
+ char *end;
+ offset += strlen(BALLOON_PREFIX);
+ if (virStrToLong_ui(offset, &end, 10, &memMB) < 0) {
+ qemudReportError(conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ "%s", _("could not parse memory balloon allocation"));
+ goto cleanup;
+ }
+ *currmem = memMB * 1024;
+ ret = 1;
+ } else {
+ /* We don't raise an error here, since its to be expected that
+ * many QEMU's don't support ballooning
+ */
+ ret = 0;
+ }
+
+cleanup:
+ VIR_FREE(reply);
+ return ret;
+}
+
+/*
+ * Returns: 0 if balloon not supported, +1 if balloon query worked
+ * or -1 on failure
+ */
+static int qemudDomainSetMemoryBalloon(virConnectPtr conn,
+ virDomainObjPtr vm,
+ unsigned long newmem) {
+ char *cmd;
+ char *reply = NULL;
+ int ret = -1;
+
+ /*
+ * 'newmem' is in KB, QEMU monitor works in MB, and we all wish
+ * we just worked in bytes with unsigned long long everywhere.
+ */
+ if (virAsprintf(&cmd, "balloon %lu", (newmem / 1024)) < 0) {
+ virReportOOMError(conn);
+ goto cleanup;
+ }
+
+ if (qemudMonitorCommand(vm, cmd, &reply) < 0) {
+ qemudReportError(conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ "%s", _("could not balloon memory allocation"));
+ VIR_FREE(cmd);
+ goto cleanup;
+ }
+ VIR_FREE(cmd);
+
+ /* If the command failed qemu prints:
+ * device not found, device is locked ...
+ * No message is printed on success it seems */
+ DEBUG ("balloon reply: %s", reply);
+ if (strstr(reply, "\nunknown command:")) {
+ /* Don't set error - it is expected memory balloon fails on many qemu */
+ ret = 0;
+ } else {
+ ret = 1;
+ }
+
+cleanup:
+ VIR_FREE(reply);
+ return ret;
+}
+
+
static int qemudDomainSetMemory(virDomainPtr dom, unsigned long newmem) {
struct qemud_driver *driver = dom->conn->privateData;
virDomainObjPtr vm;
@@ -2426,20 +2522,21 @@ static int qemudDomainSetMemory(virDomai
goto cleanup;
}
+ if (newmem > vm->def->maxmem) {
+ qemudReportError(dom->conn, dom, NULL, VIR_ERR_INVALID_ARG,
+ "%s", _("cannot set memory higher than max memory"));
+ goto cleanup;
+ }
+
if (virDomainIsActive(vm)) {
- qemudReportError(dom->conn, dom, NULL, VIR_ERR_NO_SUPPORT,
- "%s", _("cannot set memory of an active domain"));
- goto cleanup;
- }
-
- if (newmem > vm->def->maxmem) {
- qemudReportError(dom->conn, dom, NULL, VIR_ERR_INVALID_ARG,
- "%s", _("cannot set memory higher than max memory"));
- goto cleanup;
- }
-
- vm->def->memory = newmem;
- ret = 0;
+ ret = qemudDomainSetMemoryBalloon(dom->conn, vm, newmem);
+ if (ret == 0)
+ qemudReportError(dom->conn, dom, NULL, VIR_ERR_NO_SUPPORT,
+ "%s", _("cannot set memory of an active domain"));
+ } else {
+ vm->def->memory = newmem;
+ ret = 0;
+ }
cleanup:
if (vm)
@@ -2452,6 +2549,8 @@ static int qemudDomainGetInfo(virDomainP
struct qemud_driver *driver = dom->conn->privateData;
virDomainObjPtr vm;
int ret = -1;
+ int err;
+ unsigned long balloon;
qemuDriverLock(driver);
vm = virDomainFindByUUID(&driver->domains, dom->uuid);
@@ -2473,8 +2572,15 @@ static int qemudDomainGetInfo(virDomainP
}
}
+ err = qemudDomainGetMemoryBalloon(dom->conn, vm, &balloon);
+ if (err < 0)
+ goto cleanup;
+
info->maxMem = vm->def->maxmem;
- info->memory = vm->def->memory;
+ if (err == 0) /* Balloon not supported */
+ info->memory = vm->def->memory;
+ else
+ info->memory = balloon;
info->nrVirtCpu = vm->def->vcpus;
ret = 0;
@@ -3169,16 +3275,25 @@ static char *qemudDomainDumpXML(virDomai
struct qemud_driver *driver = dom->conn->privateData;
virDomainObjPtr vm;
char *ret = NULL;
-
- qemuDriverLock(driver);
- vm = virDomainFindByUUID(&driver->domains, dom->uuid);
- qemuDriverUnlock(driver);
-
- if (!vm) {
- qemudReportError(dom->conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
- "%s", _("no domain with matching uuid"));
- goto cleanup;
- }
+ unsigned long balloon;
+ int err;
+
+ qemuDriverLock(driver);
+ vm = virDomainFindByUUID(&driver->domains, dom->uuid);
+ qemuDriverUnlock(driver);
+
+ if (!vm) {
+ qemudReportError(dom->conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
+ "%s", _("no domain with matching uuid"));
+ goto cleanup;
+ }
+
+ /* Refresh current memory based on balloon info */
+ err = qemudDomainGetMemoryBalloon(dom->conn, vm, &balloon);
+ if (err < 0)
+ goto cleanup;
+ if (err > 0)
+ vm->def->memory = balloon;
ret = virDomainDefFormat(dom->conn,
(flags & VIR_DOMAIN_XML_INACTIVE) && vm->newDef ?
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 1 month
[libvirt] Libvirt - Problems in different Versions
by Artur Baruchi
Hi Guys.
Im writing a program that connects to Xen and gets some information
(scheduller and memory informations). When executing the program using
the libvirt 0.3.3 its working fine, BUT when running using libvirt
0.4.4 it doesnt work. I dont get any error message when compiling or
executing, but the informations doesnt come.
-> Using libvirt 0.3.3
# gcc -Wall -lxenstore `pkg-config --cflags --libs libvirt` test.c -o test
# ./test
DOMAINS IDENTIFIED
2
DomID: 0
Max Mem: 4294967292
Sched: 256
DomID: 3
Max Mem: 262144
Sched: 256
# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 616 2 r----- 4751.9
vm01 3 256 2 -b---- 379.7
-> Using libvirt 0.4.4
# gcc -Wall -lxenstore `pkg-config --cflags --libs libvirt` test.c -o test
# ./test
DOMAINS IDENTIFIED
0
# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 481 2 r----- 89.8
linuxprv01 1 512 1 -b---- 10.8
I executed the same program in other server, with 0.4.4 version, and
got the same problem. Is there any difference between those versions?
Thanks in advance.
Att.
Artur Baruchi
15 years, 1 month
[libvirt] Using libvirt from PHP
by Radek Hladik
Hi,
I am developing wimple web application in PHP to monitor and control
VMs using libvirt. I hope it could become simple library for doing basic
things with VMs. And I would like to ask for your opinion about
different possibilities of calling libvirt.
Option 1) I am calling virsh via exec command now (one virsh for every
libvirt command). This can be used for local libvirt but it is very
inefficient. The overhead for remote libvirt would be unbearable. I
could run one virsh per page and use it "interactively" so the overhead
gets lower.
Option 2) The other option is to create Zend extension which should be
able to call libvirt directly from C. However I've never done anything
like that so I do not know, whether it is reasonable or not.
Option 3) I could also create some "wrapper daemon" in C or other
language with libvirt binding. But I think that this is an ugly way :-)
Option 4) I could "talk" directly to the libvirt socket. But I am not
sure how the communication goes there and whether it is stable or
changes with every version. And I consider the socket to be internal
thing of libvirt...
Is there any other option I missed? And which one would you suggest?
Radek
15 years, 1 month
[libvirt] Monitoring VMs via java application
by Daniel Halle
Hello all,
I want to monitor my VMs with a Java application.
Is there a possibility to register an observer or the like which is triggered e.g. after the state of a VM has changed?
Or is the only way to use a timer which polls all VMs every xy minutes?
Thanks,
Daniel
--
Infinis GmbH - Taläckerstr. 30 - D-70437 Stuttgart
Geschäftsführer: Daniel Schwager, Stefan Hörz - HRB Stuttgart 20964
Tel: 0711-849910-23 - Fax: 0711-849910-923 - daniel.halle(a)infinis.de
15 years, 1 month
[libvirt] Restoring from a largish 'virsh save' file
by Matt McCowan
Running into an issue where, if I/O is hampered by load for example,
reading a largish state file (created by 'virsh save') is not allowed to
complete.
qemudStartVMDaemon in src/qemu_driver.c has a loop that waits 10 seconds
for the VM to be brought up. An strace against libvirt when doing a
'virsh restore' against a largish state file shows the VM being sent a
kill when it's still happily reading from the file.
inotify is used in the xen and uml drivers, so I thought it would be a
suitable mechanism to delay the timeout loop if the state file was still
being read.
Is this the right way to solve this problem?
I've inlined some (flimsy) mods for comment
Regards
Matt McCowan
--- libvirt.orig/src/qemu_driver.c 2009-03-20 11:17:57.000000000 +0900
+++ libvirt-0.6.1.1/src/qemu_driver.c 2009-03-22 18:36:06.000000000
+0900
@@ -43,6 +43,7 @@
#include <stdio.h>
#include <sys/wait.h>
#include <sys/ioctl.h>
+#include <sys/inotify.h>
#if HAVE_NUMACTL
#define NUMA_VERSION1_COMPATIBILITY 1
@@ -1310,6 +1309,11 @@
pid_t child;
int pos = -1;
char ebuf[1024];
+ char rpathname[PATH_MAX];
+ int fd = 0;
+ int wd = 0;
+ int got = 0;
+ char buf[1024];
struct gemudHookData hookData;
hookData.conn = conn;
@@ -1430,6 +1434,19 @@
qemudSecurityHook, &hookData);
/* wait for qemu process to to show up */
+
+ /* Times out if using a restore file and that file
+ is big. Use inotify */
+ if (stdin_fd > 0) {
+ fd = inotify_init();
+
+ if (snprintf(rpathname, sizeof(rpathname), "/proc/self/fd/%d",
+ stdin_fd) >= (int)sizeof(rpathname)) {
+ return -1;
+ }
+ wd = inotify_add_watch(fd, rpathname, IN_ACCESS);
+ }
+
if (ret == 0) {
int retries = 100;
int childstat;
@@ -1442,7 +1459,15 @@
if ((ret = virFileReadPid(driver->stateDir,
vm->def->name, &vm->pid)) == 0)
break;
usleep(100*1000);
- retries--;
+
+ /* Is state file being accessed? */
+ got = read(fd, buf, sizeof(buf));
+ if (got < 1)
+ retries--;
+ }
+ if (stdin_fd > 0) {
+ inotify_rm_watch(fd, wd);
+ close(fd);
}
if (ret) {
qemudReportError(conn, NULL, NULL,
VIR_ERR_INTERNAL_ERROR,
15 years, 1 month
Re: [libvirt] Using libvirt from PHP
by Russell Haering
* Sorry, I somehow sent this to the wrong address *
Radek,
Not to advertise blatantly, but how attached are you to PHP? I'm
currently working on a Django (python) WebApp that (although its *very*
pre-release) could probably be adapted to what you're doing. If you are
interested in assisting in development you'd be welcome to, or if you
just wanted to fork off the code into your own thing you could do that
too. My system consists of a python daemon used for actual libvirt
interaction and a separate django web interface that interacts with the
daemon via AMF over https.
If you want to stick with what you have now, you could try doing
something similar with a python daemon (you really need something like
that for the sake of efficiency anyway, unless you can come up with a
better way of maintaining libvirt connections from a stateless webapp)
that your PHP frontend connects to. Or you could just steal my daemon
code, although at the moment all it really does is monitoring and (as of
yesterday) live migrations.
What I have so far: http://trac.osuosl.org/trac/virtadmin
--
Russell Haering
Systems Administrator
OSU Open Source Lab
Radek Hladik wrote:
> > Hi,
> > I am developing wimple web application in PHP to monitor and control
> > VMs using libvirt. I hope it could become simple library for doing basic
> > things with VMs. And I would like to ask for your opinion about
> > different possibilities of calling libvirt.
> >
> > Option 1) I am calling virsh via exec command now (one virsh for every
> > libvirt command). This can be used for local libvirt but it is very
> > inefficient. The overhead for remote libvirt would be unbearable. I
> > could run one virsh per page and use it "interactively" so the overhead
> > gets lower.
> > Option 2) The other option is to create Zend extension which should be
> > able to call libvirt directly from C. However I've never done anything
> > like that so I do not know, whether it is reasonable or not.
> > Option 3) I could also create some "wrapper daemon" in C or other
> > language with libvirt binding. But I think that this is an ugly way
:-)
> > Option 4) I could "talk" directly to the libvirt socket. But I am not
> > sure how the communication goes there and whether it is stable or
> > changes with every version. And I consider the socket to be internal
> > thing of libvirt...
> >
> > Is there any other option I missed? And which one would you suggest?
> >
> > Radek
> >
> > --
> > Libvir-list mailing list
> > Libvir-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
15 years, 1 month
