- Devel - libvirt List Archives

[libvirt] [PATCH] Initialize gcrypt threading
by Daniel P. Berrange 17 Dec '09

17 Dec '09

GNUTLS uses gcrypt for its crypto functions. gcrypt requires that the app/library initializes threading before using it. We don't want to force apps using libvirt to know about gcrypt, so we make virInitialize init threading on their behalf. This location also ensures libvirtd has initialized it correctly. This initialization is required even if libvirt itself were only using one thread, since another non-libvirt library (eg GTK-VNC) could also be using gcrypt from another thread * src/libvirt.c: Register thread functions for gcrypt * configure.in: Add -lgcrypt to linker flags --- build-aux/.gitignore | 2 + configure.in | 4 ++- src/libvirt.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 58 insertions(+), 1 deletions(-) diff --git a/build-aux/.gitignore b/build-aux/.gitignore index 72e8ffc..a1b5d3b 100644 --- a/build-aux/.gitignore +++ b/build-aux/.gitignore @@ -1 +1,3 @@ * +/link-warning.h +/mktempd diff --git a/configure.in b/configure.in index 6ed2efd..c86ee97 100644 --- a/configure.in +++ b/configure.in @@ -547,7 +547,9 @@ if test "$GNUTLS_FOUND" = "no"; then test $fail = 1 && AC_MSG_ERROR([You must install the GnuTLS library in order to compile and run libvirt]) - GNUTLS_LIBS=$LIBS + dnl Not all versions of gnutls include -lgcrypt, and so we add + dnl it explicitly for the calls to gcry_control/check_version + GNUTLS_LIBS="$LIBS -lgcrypt" LIBS="$old_libs" fi diff --git a/src/libvirt.c b/src/libvirt.c index 103b331..cad33c2 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -22,6 +22,7 @@ #include <sys/wait.h> #endif #include <time.h> +#include <gcrypt.h> #include <libxml/parser.h> #include <libxml/xpath.h> @@ -251,6 +252,55 @@ winsock_init (void) } #endif +static int virTLSMutexInit (void **priv) +{ \ + virMutexPtr lock = NULL; + + if (VIR_ALLOC(lock) < 0) + return ENOMEM; + + if (virMutexInit(lock) < 0) { + VIR_FREE(lock); + return errno; + } + + *priv = lock; + return 0; +} + +static int virTLSMutexDestroy(void **priv) +{ + virMutexPtr lock = *priv; + virMutexDestroy(lock); + VIR_FREE(lock); + return 0; +} + +static int virTLSMutexLock(void **priv) +{ + virMutexPtr lock = *priv; + virMutexLock(lock); + return 0; +} + +static int virTLSMutexUnlock(void **priv) +{ + virMutexPtr lock = *priv; + virMutexUnlock(lock); + return 0; +} + +static struct gcry_thread_cbs virTLSThreadImpl = { + (GCRY_THREAD_OPTION_PTHREAD | (GCRY_THREAD_OPTION_VERSION << 8)), + NULL, + virTLSMutexInit, + virTLSMutexDestroy, + virTLSMutexLock, + virTLSMutexUnlock, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL +}; + + /** * virInitialize: * @@ -273,6 +323,9 @@ virInitialize(void) virRandomInitialize(time(NULL) ^ getpid())) return -1; + gcry_control(GCRYCTL_SET_THREAD_CBS, &virTLSThreadImpl); + gcry_check_version(NULL); + virLogSetFromEnv(); DEBUG0("register drivers"); -- 1.6.5.2

2 3

[libvirt] [PATCH 0/10] Convert over to use new -device args everywhere
by Daniel P. Berrange 17 Dec '09

17 Dec '09

QEMU has introduced a new command line arg called -device for specifying the guest device config. This allows separation from the host device config. libvirt needs to use this new syntax so that we can specify static PCI addresses for devices (the old syntax did not allow this). This patch series is the quick conversion I've done so far. The most obvious thing still lacking here is new test cases. I want to wait until this series merges with the device addressing series before adding those, since one set of tests can cover both patch series. In addition the handling of disk drivers is not quite correct. We need the disk controller patches myself/Wolfgang have worked on in order to specify the disk bus/unit instead of index.

2 22

[libvirt] Cannot start domain w/xenner emulator
by Gerry Reno 16 Dec '09

16 Dec '09

# virsh start Ubuntu-domU-x86-1 Connecting to uri: qemu:///system error: Failed to start domain Ubuntu-domU-x86-1 error: internal error unable to start guest: libvir: error : cannot execute binary /usr/bin/xenner: Permission denied # ls -l /usr/bin/xenner -rwxr-xr-x 1 root root 118936 2009-12-14 17:05 /usr/bin/xenner Sure looks executable. And there's no SELinux on the box. libvirt is 0.7.0 What the..? -Gerry

2 10

[libvirt] ANNOUNCE: Starting a libvirt application developer guide effort
by Daniel P. Berrange 16 Dec '09

16 Dec '09

This is a quick mail to announce that we have started an effort to write a libvirt application developer guide. The guide is intended to introduce programmers to the libvirt API and its concepts and demonstrate best practice along the way. The initial focus is on the C API, but once that's matured, further info on language bindings can be added. As is common with all work done in the libvirt project, the guide is being made available under an open license, specifically the Creative Commons AttributionâShare Alike 3.0 Unported license ("CC-BY-SA") The reason for this choice is that it has become the defacto license choice for documentation under Fedora, GNOME, and content from Wikipedia, etc.[1] The application developer guide is written in DocBook and is processed using the Publican toolset to generate the HTML and PDF output. Again this choice was made because it is the same toolset used in Fedora & Red Hat docs NB, this is using Publican 1.x series of releases which is available starting in Fedora 12 or later. The build config/styling is not compatible with the older Public 0.x series from earlier Fedora. There are two new GIT repositories for this work - A repository containing the libvirt brand. This is essentially CSS and graphics required to make the docs use the same style as the libvirt website does http://libvirt.org/git/?p=libvirt-publican.git - A repository containing the application developer doc. This is the actual interesting content. http://libvirt.org/git/?p=libvirt-appdev-guide.git Assuming you have Publican >= 1.0 installed, then the first step is to build and install the libvirt brand. This involves getting a checkout of the libvirt-publican.git repo, typing 'make rpm' and then installing the RPM it generates. Once the brand is installed, then you can get a checkout of the actual docs from 'libvirt-appdev-guide.git'. The content is all under the directory en-US/ in docbook format. To generate html, from the top level directory just type 'make html', likewise pdfs with 'make pdf'. If you just type 'make' you get html and pdfs. I have put up example copies generated from current available content http://berrange.fedorapeople.org/libvirt/appdev-guide/html/ http://berrange.fedorapeople.org/libvirt/appdev-guide/pdf/ If you look at these, you'll notice of course that while there is a nice big table of contents, most of the actual content is missing. We are continuing to write content and will update it periodically. If anyone is interested in contributing content, then simply send patches against the docbook XML in the libvirt-appdev-guide.git to this list as per the normal review & commit process. Regards, Daniel [1] http://iquaid.org/2009/07/06/why-relicense-fedora-documentation-and-wiki-co… -- |: 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 :|

1 0

[libvirt] [PATCH] esx_util.c: avoid NULL deref for invalid inputs
by Jim Meyering 16 Dec '09

16 Dec '09

The trouble here is that "goto failure" would run this code: failure: VIR_FREE(*datastoreName); VIR_FREE(*directoryName); VIR_FREE(*fileName); result = -1; goto cleanup; And thus if any of those 3 input variables was NULL, that deref would probably provoke a segfault. By the way, that interface should be changed, because it encourages risky behavior: int esxUtil_ParseDatastoreRelatedPath(virConnectPtr conn, const char *datastoreRelatedPath, char **datastoreName, char **directoryName, char **fileName) Note how it takes a buffer, datastoreRelatedPath, but with no length parameter. Then this function writes into the buffer with this code: if (sscanf(datastoreRelatedPath, "[%a[^]%]] %a[^\n]", datastoreName, &directoryAndFileName) != 2) { which cannot even check for buffer overrun because it doesn't know the length. You might want to add a new parameter, buf_len: int esxUtil_ParseDatastoreRelatedPath(virConnectPtr conn, const char *datastoreRelatedPath, size_t buf_len, char **datastoreName, char **directoryName, char **fileName) >From aba304e07835c123bd63f1d5d6777a898916349f Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 15 Dec 2009 19:08:49 +0100 Subject: [PATCH] esx_util.c: avoid NULL deref for invalid inputs * src/esx/esx_util.c (esxUtil_ParseDatastoreRelatedPath): Return right away, rather than trying to clean up and dereference NULL pointers, if any input is invalid. --- src/esx/esx_util.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/esx/esx_util.c b/src/esx/esx_util.c index 3e53921..8703ac2 100644 --- a/src/esx/esx_util.c +++ b/src/esx/esx_util.c @@ -277,7 +277,7 @@ esxUtil_ParseDatastoreRelatedPath(virConnectPtr conn, directoryName == NULL || *directoryName != NULL || fileName == NULL || *fileName != NULL) { ESX_ERROR(conn, VIR_ERR_INTERNAL_ERROR, "Invalid argument"); - goto failure; + return -1; } /* @@ -299,7 +299,7 @@ esxUtil_ParseDatastoreRelatedPath(virConnectPtr conn, ESX_ERROR(conn, VIR_ERR_INTERNAL_ERROR, "Datastore related path '%s' doesn't have expected format " "'[<datastore>] <path>'", datastoreRelatedPath); - goto failure; + return -1; } /* Split <path> into <directory>/<file>, where <directory> is optional */ -- 1.6.6.rc2.275.g51e2d

2 5

[libvirt] [PATCH] esx_vmx.c: don't dereference a NULL virtualDev
by Jim Meyering 16 Dec '09

16 Dec '09

The offending code starts here: int esxVMX_ParseSCSIController(virConnectPtr conn, virConfPtr conf, int controller, int *present, char **virtualDev) { char present_name[32]; char virtualDev_name[32]; if (virtualDev == NULL || *virtualDev != NULL) { ESX_ERROR(conn, VIR_ERR_INTERNAL_ERROR, "Invalid argument"); goto failure; } If the virtualDev parameter is NULL, then we'd issue the diagnostic and take the "goto", and (below), dereference NULL. >From 79283ba1d667534175d4c48079e6b500feba6480 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 15 Dec 2009 16:07:10 +0100 Subject: [PATCH] esx_vmx.c: don't dereference NULL for a NULL virtualDev * src/esx/esx_vmx.c (esxVMX_ParseSCSIController): Don't deref "virtualDev" when it is NULL. --- src/esx/esx_vmx.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/esx/esx_vmx.c b/src/esx/esx_vmx.c index f5b4544..404617e 100644 --- a/src/esx/esx_vmx.c +++ b/src/esx/esx_vmx.c @@ -1204,7 +1204,8 @@ esxVMX_ParseSCSIController(virConnectPtr conn, virConfPtr conf, int controller, return 0; failure: - VIR_FREE(*virtualDev); + if (virtualDev) + VIR_FREE(*virtualDev); return -1; } -- 1.6.6.rc2.275.g51e2d

4 5

[libvirt] [PATCH] Fix memory leak in qemudBuildCommandLine
by Matthias Bolte 15 Dec '09

15 Dec '09

--- src/qemu/qemu_conf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 86172c6..2ee2042 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1893,7 +1893,7 @@ int qemudBuildCommandLine(virConnectPtr conn, } ADD_ARG_LIT("-monitor"); - ADD_ARG_LIT(virBufferContentAndReset(&buf)); + ADD_ARG(virBufferContentAndReset(&buf)); } if (def->localtime) -- 1.6.0.4

2 2

[libvirt] the <filesystem> tag (WAS: simple LXC/libvirt busybox container (Unable to get cgroup))
by Tony Risinger 15 Dec '09

15 Dec '09

wow! i was starting to think i would never get past this problem! [root@PHS-001 ~]# echo $VIRSH_DEFAULT_CONNECT_URI lxc:/// [root@PHS-001 ~]# virsh create /vps/def/exec/sys/arch-nano.xml Domain arch-nano created from /vps/def/exec/sys/arch-nano.xml [root@PHS-001 ~]# virsh console arch-nano Connected to domain arch-nano Escape character is ^] # [root@PHS-001 ~]# grep cgroup /proc/mounts none /cgroup cgroup rw,relatime,devices,memory,cpuacct,cpu 0 0 everything seems to be working fine now after disabling "ns" from cgroup mount; thank you very much Ryota and Daniel for you time and assistance. i must have sunk 40+ hours into this, but i learned a tremendous amount, so nothing is lost. :-) this is somewhat of a digression, and i can submit a new thread if need be, but my last remaining question is about the <filesystem> tag/root mounting. i have not found any mention of the <filesystem> tag in the docs or how to work with it... i want to have libvirt mount a specified device (a btrfs subvolume) and use it for the root filesystem of the created LXC container. is there a way to do this? perhaps <source dev="/dev/sdb" options="subvol....."/>, or do i need to use the storage XML? i didnt see a way to use a storage/device definition as the rootfs. im eager to get working with python bindings, just trying to see it all work with XML first. thanks++ On Thu, Dec 10, 2009 at 6:45 AM, Ryota Ozaki <ozaki.ryota(a)gmail.com> wrote: > On Thu, Dec 10, 2009 at 9:36 PM, Daniel P. Berrange <berrange(a)redhat.com> wrote: >> On Thu, Dec 10, 2009 at 09:26:39PM +0900, Ryota Ozaki wrote: >>> On Thu, Dec 10, 2009 at 9:03 PM, Daniel P. Berrange <berrange(a)redhat.com> wrote: >>> > On Thu, Dec 10, 2009 at 02:22:37AM -0600, Tony Risinger wrote: >>> >> i'm trying to get even the simplest busybox container with libvirt+LXC >>> >> with very limited success. I feel l am missing something supremely >>> >> simple for me to be hung on this for weeks. >>> >> >>> >> i dont see anything interesting in domain log, but getting this error >>> >> from "LIBVIRT_DEBUG=1 libvirtd": >>> >> >>> >> 05:27:56.113: error : lxcDomainGetInfo:462 : internal error Unable to >>> >> get cgroup for arch-nano >>> >> 05:27:56.113: debug : virDomainFree:2004 : domain=0x81d8e68 >>> >> 05:27:56.113: debug : virUnrefDomain:422 : unref domain 0x81d8e68 arch-nano 1 >>> >> 05:27:56.113: debug : virReleaseDomain:376 : release domain 0x81d8e68 arch-nano >>> >> 05:27:56.113: debug : virReleaseDomain:392 : unref connection 0x81dc0f0 2 >>> >> 05:27:56.113: debug : remoteSerializeError:141 : prog=536903814 ver=1 >>> >> proc=16 type=1 serial=4, msg=internal error Unable to get cgroup for >>> >> arch-nano >>> >> >>> >> i've been using this root filesystem layout: >>> >> >>> >> [root@PHS-001 arch-nano]# tree >>> >> . >>> >> |-- bin >>> >> | |-- cat -> ../sbin/busybox >>> >> | |-- chdir -> ../sbin/busybox >>> >> | |-- chmod -> ../sbin/busybox >>> >> | |-- ls -> ../sbin/busybox >>> >> | |-- rm -> ../sbin/busybox >>> >> | |-- sh -> ../sbin/busybox >>> >> | `-- vi -> ../sbin/busybox >>> >> |-- dev >>> >> | `-- pts >>> >> |-- etc >>> >> |-- proc >>> >> |-- sbin >>> >> | |-- busybox >>> >> | `-- init -> busybox >>> >> `-- sys >>> >> >>> >> all folders besides /bin and /sbin were created by libvirt. i tried >>> >> using the /sbin/init script previously suggested: >>> >> >>> >> #!/sbin/busybox >>> >> sh >>> > >>> > >>> > Sorry, my suggestion was wrong. I forgot that if you have #!/sbin/busybox >>> > it will attempt to execute the command matching the name of the script. >>> > So it will in fact try to run 'init', rather than 'sh'. >>> > >>> > Just make the libvirt XML point directly to /bin/sh instead and it >>> > should work. I even tested it this time :-) >>> >>> Hem, I still have a problem with ns subsystem enabled. Yes, I can launch >>> a container however the cgroup hierarchy is wrong from libvirtd expecting >>> like: >>> >>> /: libvirtd --daemon >>> /5345: /usr/libexec/libvirt_lxc --name >>> >>> Daniel, could you confirm how about your cgroup hierarchy? >> >> What you do mean by 'ns' subsystem ? > > 'ns' is one of functions of cgroups like such as devices, memory, > cpu, etc. and it is enabled if you mount cgroup without any options > that Tony is doing. > >> >> >> # grep cgroup /proc/mounts >> cgroup /dev/cgroups/cpu cgroup rw,relatime,cpuacct,cpu 0 0 >> cgroup /dev/cgroups/memory cgroup rw,relatime,memory 0 0 >> cgroup /dev/cgroups/devices cgroup rw,relatime,devices 0 0 > > Oh, you don't enable 'ns', so yes, things go fine in your environment. > > >> >> # cat /proc/`pgrep libvirtd`/cgroup >> 32:devices:/sysdefault >> 16:memory:/sysdefault >> 12:cpuacct,cpu:/sysdefault >> >> # cat /proc/`pgrep libvirt_lxc`/cgroup >> 32:devices:/sysdefault/libvirt/lxc/vm1 >> 16:memory:/sysdefault/libvirt/lxc/vm1 >> 12:cpuacct,cpu:/sysdefault/libvirt/lxc/vm1 >> >> >> And the process inside the contanier is PID 12309 >> >> # cat /proc/12309/cgroup >> 32:devices:/sysdefault/libvirt/lxc/vm1 >> 16:memory:/sysdefault/libvirt/lxc/vm1 >> 12:cpuacct,cpu:/sysdefault/libvirt/lxc/vm1 >> >> >> Which all appears to be correct to me >> >> This is on a Fedora 12 host 2.6.31.6-145.fc12.i686.PAE with >> >> CONFIG_UTS_NS=y >> CONFIG_IPC_NS=y >> CONFIG_USER_NS=y >> CONFIG_PID_NS=y >> CONFIG_NET_NS=y >> CONFIG_CGROUP_SCHED=y >> CONFIG_CGROUPS=y >> # CONFIG_CGROUP_DEBUG is not set >> CONFIG_CGROUP_NS=y > > This is the function I'm mentioning. > > ozaki-r > >> CONFIG_CGROUP_FREEZER=y >> CONFIG_CGROUP_DEVICE=y >> CONFIG_CGROUP_CPUACCT=y >> CONFIG_CGROUP_MEM_RES_CTLR=y >> CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y >> CONFIG_NET_CLS_CGROUP=y >> >> >> 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 :| >> >

2 2

[libvirt] [PATCH] esx_vi.c: avoid NULL deref for invalid inputs
by Jim Meyering 15 Dec '09

15 Dec '09

The first statement in this function tests for freeFunc == NULL, and if that's true, it does "goto failure" where it proceeds to call through that NULL function pointer: if (list == NULL || *list != NULL || castFromAnyTypeFunc == NULL || freeFunc == NULL) { ESX_VI_ERROR(conn, VIR_ERR_INTERNAL_ERROR, "Invalid argument"); return -1; } ... failure: freeFunc(&item); freeFunc(list); >From 97c5e9c87eb99d881ee84c4f09bb943f3410d3b1 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 15 Dec 2009 19:22:31 +0100 Subject: [PATCH] esx_vi.c: avoid NULL deref for invalid inputs * src/esx/esx_vi.c (esxVI_List_CastFromAnyType): For invalid inputs, fail right away. Do not "goto failure" where a NULL input pointer would be dereferenced. --- src/esx/esx_vi.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index 5725b2f..1138e8c 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -935,7 +935,7 @@ esxVI_List_CastFromAnyType(virConnectPtr conn, esxVI_AnyType *anyType, if (list == NULL || *list != NULL || castFromAnyTypeFunc == NULL || freeFunc == NULL) { ESX_VI_ERROR(conn, VIR_ERR_INTERNAL_ERROR, "Invalid argument"); - goto failure; + return -1; } if (anyType == NULL) { @@ -946,7 +946,7 @@ esxVI_List_CastFromAnyType(virConnectPtr conn, esxVI_AnyType *anyType, ESX_VI_ERROR(conn, VIR_ERR_INTERNAL_ERROR, "Expecting type to begin with 'ArrayOf' but found '%s'", anyType->other); - goto failure; + return -1; } for (childNode = anyType->_node->xmlChildrenNode; childNode != NULL; -- 1.6.6.rc2.275.g51e2d

2 1

[libvirt] [PATCH] libvirt.c: don't let a NULL "cpumaps" argument provoke a NULL-deref
by Jim Meyering 15 Dec '09

15 Dec '09

>From 94923b161a9d066146271bb533b78ab7877e4501 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Mon, 14 Dec 2009 17:17:53 +0100 Subject: [PATCH] libvirt.c: don't let a NULL "cpumaps" argument provoke a NULL-deref * src/libvirt.c (virDomainGetVcpus): Update spec to say that maplen is ignored when "cpumaps" is NULL. Set maplen to 0 in that case. --- src/libvirt.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 008e322..4325aa4 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -4753,6 +4753,7 @@ error: * virDomainPinVcpu() API. * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). + * Ignored when cpumaps is NULL. * * Extract information about virtual CPUs of domain, store it in info array * and also in cpumaps if this pointer isn't NULL. @@ -4776,6 +4777,12 @@ virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } + + /* Ensure that domainGetVcpus (aka remoteDomainGetVcpus) does not + try to memcpy anything into a NULL pointer. */ + if (cpumaps == NULL) + maplen = 0; + if (cpumaps != NULL && maplen < 1) { virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; -- 1.6.6.rc2.275.g51e2d

3 4