[libvirt] [PATCH] remote_driver.c: also zero out ->saslDecodedOffset member
by Jim Meyering
Technically, the initialization of ->saslDecodedOffset is not required, but...
What could go wrong if saslDecodedOffset is left with some positive
value in the if-block below?
Well, in that same if-block priv->saslDecoded is set to NULL, and in that
case, the code above *usually* sets priv->saslDecodedOffset to 0, but not
if we hit one of the intervening returns.
In that case, you have to wonder if priv->saslDecoded can be set to non-NULL,
yet with priv->saslDecodedOffset still left with the now-bogus positive
value. In that case, with an initial saslDecodedLength of 0, we'd
compute this:
wantData = (priv->saslDecodedLength - priv->saslDecodedOffset
and that would be negative.
The very next statement would cause trouble, as the
negative value treated-as-size_t would wreak havoc:
memcpy(priv->buffer + priv->bufferOffset,
priv->saslDecoded + priv->saslDecodedOffset,
wantData);
Luckily, the semantics of sasl_decode ensure that does not happen.
Hence, an alternate (though riskier) patch would be to skip
that of priv->saslDecodedOffset altogether.
>From a3578fc03714a210678e6bcf62d162d92c9d07c0 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Mon, 14 Dec 2009 13:00:01 +0100
Subject: [PATCH] remote_driver.c: also zero out ->saslDecodedOffset member
* src/remote/remote_driver.c (remoteIOReadMessage): ...rather than
zeroing out priv->saslDecodedLength twice.
---
src/remote/remote_driver.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index affeb0f..77962fe 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -7782,7 +7782,7 @@ remoteIOReadMessage(virConnectPtr conn, struct private_data *priv,
priv->saslDecodedOffset += wantData;
priv->bufferOffset += wantData;
if (priv->saslDecodedOffset == priv->saslDecodedLength) {
- priv->saslDecodedLength = priv->saslDecodedLength = 0;
+ priv->saslDecodedOffset = priv->saslDecodedLength = 0;
priv->saslDecoded = NULL;
}
--
1.6.6.rc2.275.g51e2d
15 years
[libvirt] problem connecting to vbox
by anuj rampal
Hi,
I have installed VBOX 3.0.12 on fc12 which is running libvirt-0.7.1.
Now when i try to connect using virsh using uri "virsh -c
vbox+tcp:///system"
this is the error i get:
error: internal error unable to initialize VirtualBox driver API
error: failed to connect to the hypervisor
But it connects successfully with this ur:
"virsh -c vbox:///system"
i have also qemu installed on the same machine and connects successfully
with uri "virsh -c qemu+tcp:///system"
Libvirt is listening on tcp port:16509
any idea what am i doing wrong?
Here is a detailed message:
LIBVIRT_DEBUG=1 virsh -c vbox+tcp:///system
11:10:45.469: debug : virInitialize:279 : register drivers
11:10:45.495: debug : virRegisterDriver:776 : registering Test as driver 0
11:10:45.495: debug : virRegisterNetworkDriver:614 : registering Test as
network driver 0
11:10:45.495: debug : virRegisterInterfaceDriver:645 : registering Test as
interface driver 0
11:10:45.495: debug : virRegisterStorageDriver:676 : registering Test as
storage driver 0
11:10:45.495: debug : virRegisterDeviceMonitor:707 : registering Test as
device driver 0
11:10:45.495: debug : virRegisterSecretDriver:738 : registering Test as
secret driver 0
11:10:45.496: debug : virRegisterDriver:776 : registering Xen as driver 1
11:10:45.496: debug : virRegisterDriver:776 : registering OPENVZ as driver 2
11:10:45.496: debug : virRegisterDriver:776 : registering PHYP as driver 3
11:10:45.506: debug : vboxRegister:80 : VBoxCGlueInit found API version:
3.0.12 (3000012)
11:10:45.506: debug : vboxRegister:92 : VirtualBox API version: 3.0
11:10:45.506: debug : virRegisterDriver:776 : registering VBOX as driver 4
11:10:45.506: debug : virRegisterNetworkDriver:614 : registering VBOX as
network driver 1
11:10:45.506: debug : virRegisterStorageDriver:676 : registering VBOX as
storage driver 1
11:10:45.506: debug : virRegisterDriver:776 : registering ESX as driver 5
11:10:45.506: debug : virRegisterDriver:776 : registering remote as driver 6
11:10:45.506: debug : virRegisterNetworkDriver:614 : registering remote as
network driver 2
11:10:45.506: debug : virRegisterInterfaceDriver:645 : registering remote as
interface driver 1
11:10:45.506: debug : virRegisterStorageDriver:676 : registering remote as
storage driver 2
11:10:45.506: debug : virRegisterDeviceMonitor:707 : registering remote as
device driver 1
11:10:45.506: debug : virRegisterSecretDriver:738 : registering remote as
secret driver 1
11:10:45.506: debug : virConnectOpenAuth:1273 : name=vbox+tcp:///system,
auth=0x43d940, flags=0
11:10:45.506: debug : do_open:1042 : name "vbox+tcp:///system" to URI
components:
scheme vbox+tcp
opaque (null)
authority (null)
server (null)
user (null)
port 0
path /system
11:10:45.506: debug : do_open:1052 : trying driver 0 (Test) ...
11:10:45.506: debug : do_open:1058 : driver 0 Test returned DECLINED
11:10:45.506: debug : do_open:1052 : trying driver 1 (Xen) ...
11:10:45.506: debug : do_open:1058 : driver 1 Xen returned DECLINED
11:10:45.506: debug : do_open:1052 : trying driver 2 (OPENVZ) ...
11:10:45.506: debug : do_open:1058 : driver 2 OPENVZ returned DECLINED
11:10:45.506: debug : do_open:1052 : trying driver 3 (PHYP) ...
11:10:45.506: debug : do_open:1058 : driver 3 PHYP returned DECLINED
11:10:45.506: debug : do_open:1052 : trying driver 4 (VBOX) ...
11:10:45.506: debug : do_open:1058 : driver 4 VBOX returned DECLINED
11:10:45.506: debug : do_open:1052 : trying driver 5 (ESX) ...
11:10:45.506: debug : do_open:1058 : driver 5 ESX returned DECLINED
11:10:45.506: debug : do_open:1052 : trying driver 6 (remote) ...
11:10:45.506: debug : doRemoteOpen:535 : proceeding with name =
vbox:///system
11:10:45.508: debug : remoteIO:7421 : Do proc=66 serial=0 length=28
wait=(nil)
11:10:45.508: debug : remoteIO:7483 : We have the buck 66 0xb75df008
0xb75df008
11:10:45.509: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 64 total (60 more)
11:10:45.509: debug : remoteIOEventLoop:7347 : Giving up the buck 66
0xb75df008 (nil)
11:10:45.509: debug : remoteIO:7514 : All done with our call 66 (nil)
0xb75df008
11:10:45.509: debug : remoteIO:7421 : Do proc=1 serial=1 length=56
wait=(nil)
11:10:45.509: debug : remoteIO:7483 : We have the buck 1 0x9fb2ea8 0x9fb2ea8
11:10:45.510: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 208 total (204 more)
11:10:45.510: debug : remoteIOEventLoop:7347 : Giving up the buck 1
0x9fb2ea8 (nil)
11:10:45.510: debug : remoteIO:7514 : All done with our call 1 (nil)
0x9fb2ea8
11:10:45.510: debug : do_open:1058 : driver 6 remote returned ERROR
11:10:45.510: debug : virUnrefConnect:257 : unref connection 0x9fb0b30 1
11:10:45.510: debug : virReleaseConnect:214 : release connection 0x9fb0b30
error: internal error unable to initialize VirtualBox driver API
error: failed to connect to the hypervisor
Regards
Anuj
15 years
Re: [libvirt] getSchedulerParameters() always returning nullpointerexception in JAVA
by Marc Gonzalez Mateo
Hi Bryan,
I've applied and tested the PATCH and still does not work.
Here is the console output:
-> [chipiron04, Domain-0, XenTest, XenTest2, chipiron03]
Dec 15, 2009 9:49:14 AM net.emotivecloud.virtmonitor.VirtMonitor
getCPUPriority
SEVERE: Error: getting CPU priority of "XenTest".class
java.lang.NullPointerException
java.lang.NullPointerException
at org.libvirt.SchedParameter.create(Unknown Source)
at org.libvirt.Domain.getSchedulerParameters(Unknown Source)
at
net.emotivecloud.virtmonitor.VirtMonitor.getCPUPriority(VirtMonitor.java:495)
at net.emotivecloud.virtmonitor.VirtMonitor.main(VirtMonitor.java:775)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:636)
-1
Dec 15, 2009 9:49:14 AM net.emotivecloud.virtmonitor.VirtMonitor
getCPUCapacity
SEVERE: Error: getting CPU capacity of "XenTest".
java.lang.NullPointerException
at org.libvirt.SchedParameter.create(Unknown Source)
at org.libvirt.Domain.getSchedulerParameters(Unknown Source)
at
net.emotivecloud.virtmonitor.VirtMonitor.getCPUCapacity(VirtMonitor.java:470)
at net.emotivecloud.virtmonitor.VirtMonitor.main(VirtMonitor.java:776)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:636)
-1
Both GetCPUCapacity and GetCPUPriority use the schedparameter type. Here is
the code and the main.
getDomain method just returns the domain object itself and I've also tested
it's not null value at this point of the code:
public int getCPUCapacity(String name) {
int ret = -1;
try {
Domain d = getDomain(name);
SchedParameter[] pars= d.getSchedulerParameters();
for (SchedParameter pri : pars) {
if (pri.field=="cap")
ret=Integer.parseInt(pri.getValueAsString());
}
} catch (Exception e) {
log.error(" Error: getting CPU capacity of \""+name+"\".");
e.printStackTrace();
}
return ret;
}
/**
* Returns CPU Priority assigned to VM name
* @param name
* @return
*/
public int getCPUPriority(String name) {
int res=-1;
try {
Domain d = getDomain(name);
SchedParameter[] pars = d.getSchedulerParameters();
for (SchedParameter pri : pars) {
if (pri.field=="weight")
res=Integer.parseInt(pri.getValueAsString());
}
} catch (Exception e) {
log.error(" Error: getting CPU priority of \""+name+"\"." +
e.getClass());
e.printStackTrace();
}
return res;
}
public static void main(String args[]) {
VirtMonitor virt = new VirtMonitor();
System.out.println(" -> " + virt.getDomains());
System.out.println(virt.getCPUPriority("XenTest"));
System.out.println(virt.getCPUCapacity("XenTest"));
}
Thanks in advance,
Marc Gonzalez Mateo
marcg(a)ac.upc.edu
Universitat Politècnica de Catalunya
El 14/12/2009, a las 16:41, Bryan Kearney escribió:
Can you send me more info on the use case.. and I will try and recreate it?
In the mean time.. tell me if the patched jar file at:
http://bkearney.fedorapeople.org/libvirt-0.4.0-PATCH.jar
works. You will need to download this and copy it into
/usr/share/java/libvirt-0.4.0.jar
-- bk
On 12/14/2009 04:22 AM, Marc Gonzalez Mateo wrote:
OK, let's see if Bryan has an idea/solution about this.
Thanks guys!
MARC
El 11/12/2009, a las 14:29, Daniel Veillard escribió:
On Fri, Dec 11, 2009 at 02:01:36PM +0100, Marc Gonzalez Mateo wrote:
Hi everyvody,
I'm developing a new API based on libvirt.
I'm currently stucked using getSchedulerParameters, always is returning a
nullpointerexception, no matter which Xen Domain I'm passing to the
function.
Enclosing both the code and the error console:
public int getCPUPriority(String name) {
int res=-1;
try {
Domain d = getDomain(name);
SchedParameter[] pars = d.getSchedulerParameters();
Hum, it seems
Domain.getSchedulerParameters()
does
SchedParameter[] returnValue = new SchedParameter[0];
and
public static SchedParameter create(virSchedParameter vParam) {
SchedParameter returnValue = null;
switch (vParam.type) {
case (1):
and the create method getting there gets a null pointer as the
initialization argument, which it first dereference ...
so not surprizing looking at the code, maybe Bryan has an idea of what
is going on there, I'm a bit lost in this initialization process ...
Daniel
for (SchedParameter pri : pars) {
if (pri.field=="weight")
res=Integer.parseInt(pri.getValueAsString());
}
} catch (LibvirtException e) {
log.error(" Error: getting CPU priority of \""+name+"\"." +
e.getClass());
e.printStackTrace();
}
return res;
}
Dec 11, 2009 1:04:18 PM net.emotivecloud.virtmonitor.VirtMonitor
getCPUCapacity
SEVERE: Error: getting CPU capacity of "XenTest".
java.lang.NullPointerException
at org.libvirt.SchedParameter.create(Unknown Source)
at org.libvirt.Domain.getSchedulerParameters(Unknown Source)
at
net.emotivecloud.virtmonitor.VirtMonitor.getCPUCapacity(VirtMonitor.java:462)
at net.emotivecloud.virtmonitor.VirtMonitor.main(VirtMonitor.java:763)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:636)
Any ideas?
Thanks in advance,
Marc Gonzalez Mateo
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
15 years
[libvirt] [PATCH v2 00/13] CPU selection patches
by Jiri Denemark
Hi,
This is a second version of CPU selection patchset.
Changes in version 2:
- virConnectGetHostCPU() API call was completely removed
- 'CPU driver implementation' (11/14) patch was dropped
- virConnectCompareCPU() API call is implemented directly by hypervisor
drivers
- new cpuCompareXML() internal function to make virConnectCompareCPU()
simpler
Jirka
Jiri Denemark (13):
XML schema for CPU flags
XML parsing/formating code for CPU flags
Public API
Internal driver API
Public API implementation
Wire protocol format
Remote driver
Server side dispatcher
CPU selection infrastructure
CPU map for models and features
Set cpuCompare handler in drivers
Implement CPU selection in QEMU driver
Implement virsh commands
configure.in | 20 +
daemon/remote.c | 22 +
docs/schemas/capability.rng | 46 ++-
docs/schemas/domain.rng | 62 +++
include/libvirt/libvirt.h.in | 13 +
include/libvirt/virterror.h | 1 +
src/Makefile.am | 23 +-
src/conf/capabilities.c | 31 ++-
src/conf/capabilities.h | 6 +
src/conf/cpu_conf.c | 366 ++++++++++++++
src/conf/cpu_conf.h | 116 +++++
src/conf/domain_conf.c | 15 +
src/conf/domain_conf.h | 2 +
src/cpu/cpu.c | 242 +++++++++
src/cpu/cpu.h | 129 +++++
src/cpu/cpu_generic.c | 123 +++++
src/cpu/cpu_generic.h | 32 ++
src/cpu/cpu_map.c | 130 +++++
src/cpu/cpu_map.h | 41 ++
src/cpu/cpu_map.xml | 304 +++++++++++
src/cpu/cpu_x86.c | 1142 ++++++++++++++++++++++++++++++++++++++++++
src/cpu/cpu_x86.h | 31 ++
src/cpu/cpu_x86_data.h | 45 ++
src/driver.h | 5 +
src/esx/esx_driver.c | 1 +
src/libvirt.c | 41 ++
src/libvirt_private.syms | 19 +
src/libvirt_public.syms | 5 +
src/lxc/lxc_driver.c | 1 +
src/openvz/openvz_driver.c | 1 +
src/qemu/qemu_conf.c | 401 ++++++++++++++-
src/qemu/qemu_conf.h | 7 +
src/qemu/qemu_driver.c | 43 ++-
src/remote/remote_driver.c | 27 +
src/remote/remote_protocol.x | 12 +-
src/test/test_driver.c | 1 +
src/uml/uml_driver.c | 1 +
src/util/virterror.c | 3 +
src/vbox/vbox_tmpl.c | 1 +
tools/virsh.c | 65 +++
40 files changed, 3541 insertions(+), 35 deletions(-)
create mode 100644 src/conf/cpu_conf.c
create mode 100644 src/conf/cpu_conf.h
create mode 100644 src/cpu/cpu.c
create mode 100644 src/cpu/cpu.h
create mode 100644 src/cpu/cpu_generic.c
create mode 100644 src/cpu/cpu_generic.h
create mode 100644 src/cpu/cpu_map.c
create mode 100644 src/cpu/cpu_map.h
create mode 100644 src/cpu/cpu_map.xml
create mode 100644 src/cpu/cpu_x86.c
create mode 100644 src/cpu/cpu_x86.h
create mode 100644 src/cpu/cpu_x86_data.h
15 years
[libvirt] getSchedulerParameters() always returning nullpointerexception in JAVA
by Marc Gonzalez Mateo
Hi everyvody,
I'm developing a new API based on libvirt.
I'm currently stucked using getSchedulerParameters, always is returning a
nullpointerexception, no matter which Xen Domain I'm passing to the
function.
Enclosing both the code and the error console:
public int getCPUPriority(String name) {
int res=-1;
try {
Domain d = getDomain(name);
SchedParameter[] pars = d.getSchedulerParameters();
for (SchedParameter pri : pars) {
if (pri.field=="weight")
res=Integer.parseInt(pri.getValueAsString());
}
} catch (LibvirtException e) {
log.error(" Error: getting CPU priority of \""+name+"\"." +
e.getClass());
e.printStackTrace();
}
return res;
}
Dec 11, 2009 1:04:18 PM net.emotivecloud.virtmonitor.VirtMonitor
getCPUCapacity
SEVERE: Error: getting CPU capacity of "XenTest".
java.lang.NullPointerException
at org.libvirt.SchedParameter.create(Unknown Source)
at org.libvirt.Domain.getSchedulerParameters(Unknown Source)
at
net.emotivecloud.virtmonitor.VirtMonitor.getCPUCapacity(VirtMonitor.java:462)
at net.emotivecloud.virtmonitor.VirtMonitor.main(VirtMonitor.java:763)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
at java.lang.Thread.run(Thread.java:636)
Any ideas?
Thanks in advance,
Marc Gonzalez Mateo
15 years
[libvirt] [PATCH 00/14] CPU selection patches
by Jiri Denemark
Hi,
Here it is, finally.
Jirka
Jiri Denemark (14):
XML schema for CPU flags
XML parsing/formating code for CPU flags
Public API
Internal driver API
Public API implementation
Wire protocol format
Remote driver
Server side dispatcher
CPU selection infrastructure
CPU map for models and features
CPU driver implementation
Set getHostCPU handler in drivers
Implement CPU selection in QEMU driver
Implement virsh commands
configure.in | 20 +
daemon/Makefile.am | 2 +
daemon/libvirtd.c | 3 +
daemon/remote.c | 42 ++
daemon/remote_dispatch_prototypes.h | 16 +
docs/schemas/capability.rng | 46 ++-
docs/schemas/domain.rng | 62 ++
include/libvirt/libvirt.h.in | 15 +
include/libvirt/virterror.h | 2 +
src/Makefile.am | 43 ++-
src/conf/capabilities.c | 31 +-
src/conf/capabilities.h | 6 +
src/conf/cpu_conf.c | 366 +++++++++++
src/conf/cpu_conf.h | 116 ++++
src/conf/domain_conf.c | 15 +
src/conf/domain_conf.h | 2 +
src/cpu/cpu.c | 206 +++++++
src/cpu/cpu.h | 124 ++++
src/cpu/cpu_driver.c | 190 ++++++
src/cpu/cpu_driver.h | 40 ++
src/cpu/cpu_generic.c | 123 ++++
src/cpu/cpu_generic.h | 32 +
src/cpu/cpu_map.c | 130 ++++
src/cpu/cpu_map.h | 41 ++
src/cpu/cpu_map.xml | 304 ++++++++++
src/cpu/cpu_x86.c | 1142 +++++++++++++++++++++++++++++++++++
src/cpu/cpu_x86.h | 31 +
src/cpu/cpu_x86_data.h | 45 ++
src/datatypes.h | 2 +
src/driver.h | 20 +
src/esx/esx_driver.c | 1 +
src/libvirt.c | 129 ++++
src/libvirt_private.syms | 19 +
src/libvirt_public.syms | 6 +
src/lxc/lxc_driver.c | 1 +
src/openvz/openvz_driver.c | 1 +
src/qemu/qemu_conf.c | 401 ++++++++++++-
src/qemu/qemu_conf.h | 7 +
src/qemu/qemu_driver.c | 37 +-
src/remote/remote_driver.c | 125 ++++
src/remote/remote_protocol.c | 27 +
src/remote/remote_protocol.x | 18 +-
src/test/test_driver.c | 1 +
src/uml/uml_driver.c | 1 +
src/util/virterror.c | 8 +
src/vbox/vbox_tmpl.c | 1 +
tools/virsh.c | 65 ++
47 files changed, 4029 insertions(+), 36 deletions(-)
create mode 100644 src/conf/cpu_conf.c
create mode 100644 src/conf/cpu_conf.h
create mode 100644 src/cpu/cpu.c
create mode 100644 src/cpu/cpu.h
create mode 100644 src/cpu/cpu_driver.c
create mode 100644 src/cpu/cpu_driver.h
create mode 100644 src/cpu/cpu_generic.c
create mode 100644 src/cpu/cpu_generic.h
create mode 100644 src/cpu/cpu_map.c
create mode 100644 src/cpu/cpu_map.h
create mode 100644 src/cpu/cpu_map.xml
create mode 100644 src/cpu/cpu_x86.c
create mode 100644 src/cpu/cpu_x86.h
create mode 100644 src/cpu/cpu_x86_data.h
15 years
[libvirt] [PATCH] libvirtd: avoid a NULL dereference on error path
by Jim Meyering
>From f124b132913884ced6e9fbae8233056e0e97cd0a Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Mon, 14 Dec 2009 16:45:11 +0100
Subject: [PATCH] libvirtd: avoid a NULL dereference on error path
* daemon/libvirtd.c (qemudDispatchServer): Since "client" may be
NULL in the "cleanup:" block, free client->rx only when it's not.
---
daemon/libvirtd.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 6b7e33d..de6fc27 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -1422,7 +1422,8 @@ static int qemudDispatchServer(struct qemud_server *server, struct qemud_socket
if (client &&
client->tlssession) gnutls_deinit (client->tlssession);
close (fd);
- VIR_FREE(client->rx);
+ if (client)
+ VIR_FREE(client->rx);
VIR_FREE(client);
return -1;
}
--
1.6.6.rc2.275.g51e2d
15 years
[libvirt] libvirt -0.7.4 on fc8 gives "Starting libvirtd daemon: error: Unable to initialize network sockets"
by Nimal Prabudoss I
Hi,
I'm trying to use the libvirt 0.7.4 in fc8. I have configured and done
with make, make install. Virsh command also displays the version
correctly as 0.7.4 But when I try to start the libvirtd service, I get
the following error.
"Starting libvirtd daemon: error: Unable to initialize network sockets
[Failed]"
My machine details is given below
"2.6.21-2950.fc8xen #1 SMP Tue Oct 23 12:24:34 EDT 2007 i686 i686 i386
GNU/Linux"
Have anybody encountered the same kind of error? Please help me on this.
Thanks,
Nimal.I
15 years
[libvirt] [PATCH] Fix and improve domain xml video element description
by Matthias Bolte
The description mismatched the actual structure since the video element
was introduced. The nvram attribute is actually called vram. Specify the
unit of the vram attribute.
---
docs/formatdomain.html.in | 30 ++++++++++++++++++++++--------
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 5b7aa10..3d418b9 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -768,20 +768,34 @@ qemu-kvm -net nic,model=? /dev/null
<pre>
...
- <video type='vga' nvram='8192' heads='1'>
- <acceleration accel3d='yes' accel3d='yes' />
+ <video>
+ <model type='vga' vram='8192' heads='1'>
+ <acceleration accel3d='yes' accel3d='yes'/>
+ </model>
</video>
...</pre>
<dl>
<dt><code>video</code></dt>
- <dd>The <code>video</code> element has a mandatory <code>type</code>
- attribute which takes the value "vga", "cirrus", "vmvga", "xen" or "vbox".
- You can also provide the amount of video memory using <code>nvram</code>,
- the number of screen with <code>heads</code>, and whether acceleration
- should be enabled (if supported) using the <code>accel3d</code> and
- <code>accel2d</code> attributes in the <code>acceleration</code> element.
+ <dd>
+ The <code>video</code> element is the a container for describing
+ video devices.
+ </dd>
+
+ <dt><code>model</code></dt>
+ <dd>
+ The <code>model</code> element has a mandatory <code>type</code>
+ attribute which takes the value "vga", "cirrus", "vmvga", "xen" or "vbox".
+ You can also provide the amount of video memory in kilobytes using
+ <code>vram</code> and the number of screen with <code>heads</code>.
+ </dd>
+ <dt><code>acceleration</code></dt>
+ <dd>
+ If acceleration should be enabled (if supported) using the
+ <code>accel3d</code> and <code>accel2d</code> attributes in the
+ <code>acceleration</code> element.
+ </dd>
</dl>
<h4><a name="elementsConsole">Consoles, serial, parallel & channel devices</a></h4>
--
1.6.0.4
15 years
[libvirt] Python script and extension module directory handling
by Matthias Bolte
Commit 66137344feb488ea87b0d92f3c03844d9a7a7786 changed the Python
detection mechanism in configure. This results in a changed install
location for the Python bindings at least on Fedora 12 64bit systems.
For the explanation below I assume a Fedora 12 64bit systems, libvirt
is configured with prefix /usr and Python 2.6 is installed.
Before this commit libvirt.py and libvirtmod.so were installed to
/usr/lib64/python2.6/site-packages. After this commit both are
installed to /usr/lib/python2.6/site-packages. This is at least wrong
for libvirtmod.so, as it should be installed to
/usr/lib64/python2.6/site-packages on a 64bit system.
Before this commit pythondir was set manually to
/usr/lib64/python2.6/site-packages and python/Makefile.am contains
'python_LTLIBRARIES = libvirtmod.la' that results in installing
libvirtmod.so to pythondir.
AM_PATH_PYTHON defines two variables: pythondir and pyexecdir. But
according to the AM_PATH_PYTHON documentation [1] pythondir is the
directory where Python scripts should be installed.
/usr/lib/python2.6/site-packages in this case, because Python scripts
are not architecture dependent in general. pyexecdir is the directory
where Python extension modules (shared libraries) should be installed.
AM_PATH_PYTHON detects pyexecdir correctly as
/usr/lib64/python2.6/site-packages, but python/Makefile.am contains
'python_LTLIBRARIES = libvirtmod.la' that results in installing
libvirtmod.so to pythondir.
So python/Makefile.am must be changed:
diff --git a/python/Makefile.am b/python/Makefile.am
index 736631e..04342b7 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -32,7 +32,7 @@ mylibs = $(top_builddir)/src/libvirt.la
all-local: libvirt.py
-python_LTLIBRARIES = libvirtmod.la
+pyexec_LTLIBRARIES = libvirtmod.la
libvirtmod_la_SOURCES = libvirt-override.c typewrappers.c libvirt.c libvirt.h
# Python <= 2.4 header files contain a redundant decl, hence we
Now libvirtmod.so is installed to the correct directory:
/usr/lib64/python2.6/site-packages
But libvirt.py gets installed to /usr/lib/python2.6/site-packages,
this is different from the installation directory before the commit.
A default Fedora 12 64bit installation has *.py files installed to
/usr/lib/python2.6/site-packages and
/usr/lib64/python2.6/site-packages. By looking at both directories the
policy it pretty obvious: Packages that are pure Python go to
/usr/lib/python2.6/site-packages and packages that are mixed (Python
and shared libraries) go completely to
/usr/lib64/python2.6/site-packages.
So we restore the behavior from before the commit completely by
applying this additional patch:
diff --git a/python/Makefile.am b/python/Makefile.am
index 736631e..04342b7 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -60,14 +60,14 @@ $(GENERATED): generated.stamp
$(libvirtmod_la_OBJECTS): $(GENERATED)
install-data-local:
- $(mkinstalldirs) $(DESTDIR)$(pythondir)
- @INSTALL@ -m 0644 libvirt.py $(DESTDIR)$(pythondir)
+ $(mkinstalldirs) $(DESTDIR)$(pyexecdir)
+ @INSTALL@ -m 0644 libvirt.py $(DESTDIR)$(pyexecdir)
$(mkinstalldirs) $(DESTDIR)$(DOCS_DIR)
@(for doc in $(DOCS) ; \
do @INSTALL@ -m 0644 $$doc $(DESTDIR)$(DOCS_DIR) ; done)
uninstall-local:
- rm -f $(DESTDIR)$(pythondir)/libvirt.py
+ rm -f $(DESTDIR)$(pyexecdir)/libvirt.py
CLEANFILES= $(GENERATED) generated.stamp
I discussed this with Daniel Veillard on IRC and there was some
confusion what the actual problem was and how to solve it, so I wanted
to recap it here.
Also thanks to Daniel Hokka Zakrisson, who gave the important hint
about pythondir vs pyexecdir on IRC.
[1] http://www.gnu.org/software/hello/manual/automake/Python.html
Matthias
15 years
