[libvirt] [PATCH] Stop calling virAllocN directly from ESX code
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The ESX code has a method esxVI_Alloc which would call
virAllocN directly, instead of using the VIR_ALLOC_N
macro. Remove this method and make the callers just
use VIR_ALLOC as is normal practice.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/esx/esx_vi.c | 25 ++++++++-----------------
src/esx/esx_vi.h | 3 ---
src/esx/esx_vi_types.c | 11 +++++++----
3 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
index 1187bf3..255d0f4 100644
--- a/src/esx/esx_vi.c
+++ b/src/esx/esx_vi.c
@@ -51,8 +51,14 @@
int \
esxVI_##_type##_Alloc(esxVI_##_type **ptrptr) \
{ \
- return esxVI_Alloc((void **)ptrptr, sizeof(esxVI_##_type), \
- __FILE__, __FUNCTION__, __LINE__); \
+ if (ptrptr == NULL || *ptrptr != NULL) { \
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Invalid argument")); \
+ return -1; \
+ } \
+ \
+ if (VIR_ALLOC(*ptrptr) < 0) \
+ return -1; \
+ return 0; \
}
@@ -1736,21 +1742,6 @@ esxVI_List_Deserialize(xmlNodePtr node, esxVI_List **list,
*/
int
-esxVI_Alloc(void **ptrptr, size_t size, const char *file,
- const char *function, size_t linenr)
-{
- if (ptrptr == NULL || *ptrptr != NULL) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Invalid argument"));
- return -1;
- }
-
- return virAllocN(ptrptr, size, 1, true, VIR_FROM_THIS,
- file, function, linenr);
-}
-
-
-
-int
esxVI_BuildSelectSet(esxVI_SelectionSpec **selectSet,
const char *name, const char *type,
const char *path, const char *selectSetNames)
diff --git a/src/esx/esx_vi.h b/src/esx/esx_vi.h
index c1612e2..aeee953 100644
--- a/src/esx/esx_vi.h
+++ b/src/esx/esx_vi.h
@@ -330,9 +330,6 @@ int esxVI_List_Deserialize(xmlNodePtr node, esxVI_List **list,
* - 'get' functions get information from a local object
*/
-int esxVI_Alloc(void **ptrptr, size_t size, const char *file,
- const char *function, size_t linenr);
-
int esxVI_BuildSelectSet
(esxVI_SelectionSpec **selectSet, const char *name,
const char *type, const char *path, const char *selectSetNames);
diff --git a/src/esx/esx_vi_types.c b/src/esx/esx_vi_types.c
index 14caeeb..03df444 100644
--- a/src/esx/esx_vi_types.c
+++ b/src/esx/esx_vi_types.c
@@ -43,10 +43,13 @@
int \
esxVI_##__type##_Alloc(esxVI_##__type **ptrptr) \
{ \
- if (esxVI_Alloc((void **)ptrptr, sizeof(esxVI_##__type), \
- __FILE__, __FUNCTION__, __LINE__) < 0) { \
- return -1; \
- } \
+ if (ptrptr == NULL || *ptrptr != NULL) { \
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Invalid argument")); \
+ return -1; \
+ } \
+ \
+ if (VIR_ALLOC(*ptrptr) < 0) \
+ return -1; \
\
(*ptrptr)->_type = esxVI_Type_##__type; \
\
--
1.8.3.1
11 years, 2 months
[libvirt] [PATCH] Add missing 'libvirt_lxc_api' variable in pkg-config file
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The 'libvirt_lxc_api' variable is intended to allow apps to
query the location of the API XML file for libvirt_lxc.so
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
libvirt.pc.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/libvirt.pc.in b/libvirt.pc.in
index 616575d..d456a88 100644
--- a/libvirt.pc.in
+++ b/libvirt.pc.in
@@ -6,6 +6,7 @@ datarootdir=@datarootdir@
libvirt_api=@datadir(a)/libvirt/api/libvirt-api.xml
libvirt_qemu_api=@datadir(a)/libvirt/api/libvirt-qemu-api.xml
+libvirt_lxc_api=@datadir(a)/libvirt/api/libvirt-lxc-api.xml
Name: libvirt
Version: @VERSION@
--
1.8.3.1
11 years, 2 months
[libvirt] [PATCH] Don't call VIR_ALLOC on def->uuid in parallels storage driver
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The 'uuid' field in virDomainDefPtr is not a pointer, it is a
fixed length array. Calling VIR_ALLOC on it is thus wrong and
leaks memory.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/parallels/parallels_storage.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/parallels/parallels_storage.c b/src/parallels/parallels_storage.c
index 3e254ce..44246a7 100644
--- a/src/parallels/parallels_storage.c
+++ b/src/parallels/parallels_storage.c
@@ -173,9 +173,6 @@ parallelsPoolCreateByPath(virConnectPtr conn, const char *path)
if (!(def->name = parallelsMakePoolName(conn, path)))
goto error;
- if (VIR_ALLOC_N(def->uuid, VIR_UUID_BUFLEN))
- goto error;
-
if (virUUIDGenerate(def->uuid)) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Can't generate UUID"));
--
1.8.3.1
11 years, 2 months
[libvirt] [PATCH 0/5]qemu: add usb-bot scsi controller support
by Guannan Ren
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=917702
qemu patch:http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg02200.html
These patch aims to add usb-bot SCSI controller support for libvirt.
As usb-storage libvirt already supported, usb-bot only supports one
SCSI target with SCSI ID 0.
The difference is that usb-storage creates SCSI HBA and additionaly
either a scsi-disk or a scsi-generic device, usb-bot only creates the
SCSI HBA. we can attach a SCSI device to it with another -device.
usb-bot supports a single target and a number of luns. The limit is
15 luns (0~15 LUN ID) and they must be contiguous(using lun 0 and 2
without 1 doesn't work).
Athought usb-bot is a SCSI controller it needs to be attached to a
exsiting USB controller for work. So it has to use address of usb type.
Libvirt XML:
<devices>
...
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/disk.qcow2'/>
<target dev='sdc' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='usb' index='0'/>
<controller type='scsi' index='0' model='usb-bot'>
<address type='usb' bus='0' port='1'/>
</controller>
...
</devices>
The QEMU commandline:
qemu ${other_vm_args} \
-device piix3-usb-uhci,id=usb \
-device usb-bot,id=scsi0,bus=usb.0,port=1 \
-drive file=/var/lib/libvirt/images/disk.qcow2,if=none,id=drive-scsi0-0-0-0,format=raw \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
As the usb-storage creates scsi disk automatically which doesn't let
you set scsi-disk properties such as vendor, product, wwn, channel,
scsi-id and lun. So QEMU guys prefer usb-bot to usb-storage.
So this is the first part of the whole work. Next step will replace
usb-storage with usb-bot when disk in xml uses usb bus like
<disk ...>
<...>
<target bus='usb'>
</disk>
Guannan Ren(5)
qemu: add usb-bot qemu cap flag
qemu: add usb-bot model scsi controller support
qemu: add usb-bot support from disks points of view
qemu: refactor out function to build scsi device qemu commandline
tests: add xml2argv test for usb-bot scsi controller
docs/formatdomain.html.in | 4 +--
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
src/conf/domain_conf.h | 5 +++
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 3 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 124 ++++++++++++++++++++++++++++++++++++++++++-------------------------------
src/vmx/vmx.c | 3 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-usbbot.args | 10 ++++++
tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-usbbot.xml | 33 ++++++++++++++++++++
tests/qemuxml2argvtest.c | 3 ++
12 files changed, 242 insertions(+), 57 deletions(-)
11 years, 2 months
[libvirt] [PATCH] Fix crash in virDomainGetVcpuPinInfo python wrapper
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
It is possible to jump to the cleanup block before the cpumaps
variable gets initialized. This will result in a VIR_FREE of
an uninitializer pointer
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
python/libvirt-override.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/python/libvirt-override.c b/python/libvirt-override.c
index d16b9a2..cc76c47 100644
--- a/python/libvirt-override.c
+++ b/python/libvirt-override.c
@@ -1769,7 +1769,7 @@ libvirt_virDomainGetVcpuPinInfo(PyObject *self ATTRIBUTE_UNUSED,
virDomainPtr domain;
PyObject *pyobj_domain, *pycpumaps = NULL;
virDomainInfo dominfo;
- unsigned char *cpumaps;
+ unsigned char *cpumaps = NULL;
size_t cpumaplen, vcpu, pcpu;
unsigned int flags;
int i_retval, cpunum;
--
1.8.3.1
11 years, 2 months
[libvirt] [PATCH] build: only create virt-login-shell for lxc builds
by Eric Blake
I noticed from an ./autobuild.sh run that we were installing a
virt-login-shell.exe binary when cross-building for mingw,
even though such a binary is necessarily worthless since the
code depends on lxc which is a Linux-only concept.
* tools/Makefile.am (conf_DATA, bin_PROGRAMS, dist_man1_MANS):
Make virt-login-shell installation conditional.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
I'm debating about pushing this under the build-breaker rule.
tools/Makefile.am | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 74fae2d..4a3338f 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -60,10 +60,10 @@ EXTRA_DIST = \
DISTCLEANFILES =
confdir = $(sysconfdir)/libvirt
-conf_DATA = virt-login-shell.conf
+conf_DATA =
bin_SCRIPTS = virt-xml-validate virt-pki-validate
-bin_PROGRAMS = virsh virt-host-validate virt-login-shell
+bin_PROGRAMS = virsh virt-host-validate
libexec_SCRIPTS = libvirt-guests.sh
if WITH_SANLOCK
@@ -71,12 +71,20 @@ sbin_SCRIPTS = virt-sanlock-cleanup
DISTCLEANFILES += virt-sanlock-cleanup
endif
+if WITH_LXC
+conf_DATA += virt-login-shell.conf
+bin_PROGRAMS += virt-login-shell
+endif WITH_LXC
+
+
dist_man1_MANS = \
virt-host-validate.1 \
virt-pki-validate.1 \
virt-xml-validate.1 \
- virt-login-shell.1 \
virsh.1
+if WITH_LXC
+dist_man1_MANS += virt-login-shell.1
+endif WITH_LXC
if WITH_SANLOCK
dist_man8_MANS = virt-sanlock-cleanup.8
endif
--
1.8.3.1
11 years, 2 months
Re: [libvirt] [PATCHv3 2/6] virsh: Add vshCmdCompleter and vshOptCompleter
by Eric Blake
[re-adding the list, which was accidentally omitted]
On 08/28/2013 05:26 AM, Tomas Meszaros wrote:
>> Per-option completions make sense. For example, 'virsh vol-key --pool
>> <TAB>' wants to use a pool completer, while 'virsh vol-key --vol <TAB>'
>> wants to use a volume completer; furthermore, 'virsh vol-key <TAB>'
>> should be the combination of the option completer (showing --vol and
>> --pool) AND the volume completer filtered to names not starting with '-'
>> (since virsh has the semantics that arguments are positional, where the
>> option '--vol' is implied if the argument that appears in that position
>> does not resemble an option).
>
> So If I get it right, you are suggesting that it should work like this:
>
> virsh # vol-key <TAB>
> vol1 vol2 pool1 pool2
>
> as you said, combination of --vol and --pool completers.
No, it should work like this:
virsh# vol-key <TAB>
vol1 vol2 --vol --pool
the combination of all (non-option) completions for the current
available mandatory option (volume completer), and of all possible
options that still make sense at this point in the command line.
Likewise:
virsh# vol-key vol <TAB>
pool1 pool2 --pool
virsh# vol-key -<TAB>
--vol --pool
virsh# vol-key v<TAB>
vol1 vol2
virsh# vol-key --pool <TAB>
pool1 pool2
virsh# vol-key --pool pool1 <TAB>
vol1 vol2 --vol
and so forth.
>
>
> I was initially thinking that completion should work like this:
>
> virsh # vol-key <TAB>
> vol1 vol2
>
> It is completing <vol> first becasue <vol> is only mandatory argument
> for this command.
It is a mandatory option, but mandatory options need not come first.
Remember, our option parser allows mandatory options to occur
positionally without an option name, OR to be interleaved in any other
order by including the option string.
>
>
> Only if someone type:
>
> virsh # vol-key --pool <TAB>
> pool1 pool2
>
> then call --pool completer.
This is correct - once an option is awaiting an argument, then the
option completer must return nothing at that point in time. But if you
look at it as the union of two completers - the set of options that are
still valid in the current context, and the set of strings that are
valid assuming positional semantics of the current option, you will
always get the right answer, without needing a per-command completer
(just per-option completers).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
11 years, 2 months
[libvirt] [PATCH] examples: Add script to parse topology from capabilities output
by Peter Krempa
Add a demo script originally written by Amador Pahim to parse topology
of the host from data provided in the capabilities XML.
---
examples/python/topology.py | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100755 examples/python/topology.py
diff --git a/examples/python/topology.py b/examples/python/topology.py
new file mode 100755
index 0000000..1b678bc
--- /dev/null
+++ b/examples/python/topology.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python
+# Parse topology information from the capabilities XML and use
+# them to calculate host topology
+#
+# Authors:
+# Amador Pahim <apahim(a)redhat.com>
+# Peter Krempa <pkrempa(a)redhat.com>
+
+import libvirt
+import sys
+from xml.dom import minidom
+
+try:
+ conn = libvirt.openReadOnly(None)
+except libvirt.libvirtError:
+ print 'Failed to connect to the hypervisor'
+ sys.exit(1)
+
+try:
+ capsXML = conn.getCapabilities()
+except libvirt.libvirtError:
+ print 'Failed to request capabilities'
+ sys.exit(1)
+
+caps = minidom.parseString(capsXML)
+host = caps.getElementsByTagName('host')[0]
+cells = host.getElementsByTagName('cells')[0]
+total_cpus = cells.getElementsByTagName('cpu').length
+
+socketIds = []
+siblingsIds = []
+
+socketIds = [ proc.getAttribute('socket_id')
+ for proc in cells.getElementsByTagName('cpu')
+ if proc.getAttribute('socket_id') not in socketIds ]
+
+siblingsIds = [ proc.getAttribute('siblings')
+ for proc in cells.getElementsByTagName('cpu')
+ if proc.getAttribute('siblings') not in siblingsIds ]
+
+print "Host topology"
+print "NUMA nodes:", cells.getAttribute('num')
+print " Sockets:",len(set(socketIds))
+print " Cores:",len(set(siblingsIds))
+print " Threads:",total_cpus
--
1.8.3.2
11 years, 2 months
[libvirt] RFC: Splitting python binding out into a separate repo & ading to PyPi
by Daniel P. Berrange
As everyone knows, we have historically always shipped the python binding
as part of the libvirt primary tar.gz distribution. In some ways that has
simplified life for people, since we know they'll always have a libvirt
python that matches their libvirt C library.
At the same time though, this policy of ours is causing increasing amounts
of pain for a number of our downstream users.
In OpenStack, in particular, their development and test environments aim
to be able to not rely on any system installed python packages. They use
a virtualenv and pip to install all python deps from PyPi (equivalent of
Perl's CPAN in Python world). This approach works for everything except
the libvirt Python code which is not available standalone on PyPi. This
is causing so much pain that people have suggested taking the libvirt
python code we ship and just uploading it to PyPi themselves[1]. This
would obviously be a somewhat hostile action to take, but the way we
distribute libvirt python is forcing OpenStack to consider such things.
In RHEL world too, bundling of libvirt + its python binding is causing
pain with the fairly recent concept of "software collections"[2]. This
allows users to install multiple versions of languages like Python, Perl,
etc on the same box in parallel. To use libvirt python with thse alternate
python installs though, requires that they recompile the entire libvirt
distribution just to get the Python binding. This is obviously not an
approach that works for most people, particularly if they're looking to
populate their software collection using 'pip' rather than RPM.
Looking on google there are a number of other people asking for libvirt
python as a separate module, eg on Stackoverflow[3].
I don't think these issues are going to go away, in fact I think they
will likely become more pressing, until the point where some 3rd party
takes the step of providing libvirt python bindings themselves. I don't
think we want to let ourselves drift into the situation where we loose
control over releasing libvirt python bindings.
IMHO we should / must listen to our users here before it is too late.
We can still release libvirt python at the same time as normal libvirt
releases, and require that people update the bindings whenever adding
new APIs (if the generator doesn't cope with them). We should simply
distribute python as a separate tar.gz, as we do for all other languages,
and upload it to PyPi, as well as libvirt.org FTP when doing a release.
Obviously there will be some work to separate things out, but I don't
see that being insurmountable, since all other language bindings manage
to be separate, even when doing code generation. We'd also want to
change to use distutils, rather than autoconf, since that's what the
python world wants.
Regards,
Daniel
[1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013187.html
[2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Tool...
[3] http://stackoverflow.com/questions/14924460/is-there-any-way-to-install-l...
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
11 years, 2 months
[libvirt] Is it a problem that after virEventRegisterDefaultImpl we have handlers leaked
by Wangyufei (A)
Hello,
When I ran programme event-test compiled from event-test.c, I found a problem that, after virEventRegisterDefaultImpl I do virConnectOpenAuth and virConnectClose, there will be handlers of socket and pipe opened by virConnectOpenAuth leaked after virConnectClose. So I did some analysis, and I found the fact following:
In the condition that we only have one connection here
int virNetSocketAddIOCallback(virNetSocketPtr sock,
int events,
virNetSocketIOFunc func,
void *opaque,
virFreeCallback ff)
{
int ret = -1;
virObjectRef(sock); //Here we add sock refers once, then we will get refers equal 2 after
virObjectLock(sock);
if (sock->watch > 0) {
VIR_DEBUG("Watch already registered on socket %p", sock);
goto cleanup;
}
if ((sock->watch = virEventAddHandle(sock->fd, //If we have called virEventRegisterDefaultImpl, then here we'll get a sock watch non negative and will not go to cleanup.
events,
virNetSocketEventHandle,
sock,
virNetSocketEventFree)) < 0) {
VIR_DEBUG("Failed to register watch on socket %p", sock);
goto cleanup;
}
sock->func = func;
sock->opaque = opaque;
sock->ff = ff;
ret = 0;
cleanup:
virObjectUnlock(sock);
if (ret != 0)
virObjectUnref(sock); //If we haven't called virEventRegisterDefaultImpl, we'll be here after virEventAddHandle, and sock refers will decrease to 1
return ret;
}
Condition with virEventRegisterDefaultImpl, we'll do unrefer action in two places:
1. virEventRunDefaultImpl ->virEventPollRunOnce ->virEventRunDefaultImpl ->virEventPollRunOnce ->virEventPollCleanupHandles -> virNetSocketEventFree -> virObjectUnref
2. virConnectClose ->virObjectUnref ->virConnectDispose ->remoteConnectClose ->doRemoteClose ->virNetClientClose ->virNetClientCloseInternal -> virNetClientIOEventLoopPassTheBuck -> virNetClientCloseLocked -> virObjectUnref
When event dealing loop is alive, everything work fine, we'll get sock refers 2 after virConnectOpenAuth and unrefer twice in two places above after virConnectClose. But If some accidents happened like we quit event dealing loop or virEventRunDefaultImpl suspended, then sock refers will never be zero, and handlers will never be freed.
In a particular condition we have two threads, thread one doing event dealing loop, thread two doing something like virConnectOpenAuth and virConnectClose ceaselessly, then we'll get a big trouble that handlers available will be ate up soon.
I consider to add something like virEventDeregisterDefaultImpl to set addHandleImpl and his buddy NULL. Apparently it is far away from fixing it completely.
At last I have two questions here:
1. Is it a problem that after virEventRegisterDefaultImpl we have handlers leaked?
2. If it is a problem, is there anybody any good idea to help me out?
Best Regards,
-WangYufei
11 years, 2 months