August 2009 - Devel - libvirt List Archives

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

[libvirt] race between qemu monitor startup and blocking migrate -incoming
by Charles Duffy 19 Nov '09

19 Nov '09

Howdy, 'yall. I'm having issues with virDomainRestore failing, particularly under load -- even in 0.7.0, when there's no need to parse through qemu's output to find the monitor PTY. Digging through strace output of libvirtd and the qemu processes it spawns, this is happening when qemu blocks on the migrate -incoming and ceases to respond to the monitor socket -- though some versions of qemu can go into this state before the monitor socket is even opened, leading to libvirt timing out either while attempting to open the monitor socket or while trying to read therefrom, and subsequently killing the qemu instance it spawned while that instance is still attempting to migrate in its old saved state. Both of qemu-0.11.0-rc1 and qemu-kvm master have some form of blocking in -incoming exec: which can prevent libvirt from successfully carrying through a resume; I have reproduced the issue (and maintain logs from strace, available on request) irrespective of the state of Chris Lalancette's "Fix detached migration with exec" and "Allow monitor interaction when using migrate -exec" patches. The qemu binaries being used _appear_ to correctly allow monitor interaction prior to -incoming exec:... completion when interactively invoked in the trivial case shown below: $ qemu-system-x86_64 \ -monitor stdio \ -nographic \ -serial file:/dev/null \ -incoming 'exec:sleep 5; echo DONE >&2; kill $PPID' \ /dev/null QEMU 0.10.91 monitor - type 'help' for more information (qemu) DONE $ ...however, whether these same binaries work as-expected when invoked from libvirt by our automated test system under load is nondeterministic. (I have yet to reproduce the issue in a low-load environment using "virsh restore"). Is someone else working on this? Is a known-good (or believed-good) libvirt/qemu pair available? What can I do to help in getting this issue resolved? Thanks! --- libvirt-0.7.0 + qemu-kvm-0.11.0-rc1 qemudReadMonitorOutput:728 : internal error Timed out while reading monitor startup output libvirt-0.6.5 + qemu-kvm-0.11.0-rc1 error : qemudReadMonitorOutput:705 : internal error Timed out while reading monitor startup output error : qemudWaitForMonitor:1003 : internal error unable to start guest: char device redirected to /dev/pts/9 libvir: QEMU error : internal error unable to start guest: char device redirected to /dev/pts/9 ^^ particularly interesting, as the above line should have been eaten by qemudExtractMonitorPath rather than emitted as error text --- <aliguori> -incoming is blocking <aliguori> you cannot interact with the monitor during -incoming <mDuff> ...shouldn't we always be opening the monitor before starting the blocking -incoming bits, though? I don't always see that happening (and have an strace handy where it certainly doesn't). <aliguori> no <aliguori> well, i think they added some patches for that <aliguori> but originally, that's not how it worked <aliguori> and i think it's silly to work that way <aliguori> -incoming should mean, wait patiently for an incoming migration <aliguori> there's no point in interfacing with the monitor in the interim <mDuff> I agree that interacting may not be called for, but at least connect()ing -- if it's a UNIX socket, the other side won't be able to connect at all until qemu goes first... <aliguori> heh, well.... <aliguori> that particular race condition is addressed by -daemonize <aliguori> because that's generally true <aliguori> you don't know how long qemu will take to open the monitor <aliguori> but -daemonize makes gives you notification because it doesn't daemonize the process until you've gotten to the point where all sockets are open <aliguori> but IIRC, libvirt doesn't use -daemonize

3 2

[libvirt] [PATCH 00/11] Generic data stream handling
by Daniel P. Berrange 02 Oct '09

02 Oct '09

The following series of patches introduce support for generic data streams in the libvirt API, the remote protocol, client & daemon. The public API takes the form of a new object virStreamPtr and methods to read/write/close it The remote protocol was the main hard bit. Since the protocol allows multiple concurrent API calls on a single connection, this needed to also allow concurrent data streams. It is also not acceptable for a large data stream to block other traffic while it is transferring. Thus, we introduce a new protocol message type 'REMOTE_STREAM' to handle transfer for the stream data. A method involving a data streams starts off in the normal way with a REMOTE_CALL to the server, and a REMOTE_REPLY response message. If this was successful, there now follows the data stream traffic. For outgoing streams (data from client to server), the client will send zero or more REMOTE_STREAM packets containing the data with status == REMOTE_CONTINUE. These are asynchronous and not acknowledged by the server. At any time the server may send an async message with a type of REMOTE_STREAM and status of REMOTE_ERROR. This indicates to the client that the transfer is aborting at server request. If the client wishes to abort, it can send the server a REMOTE_STREAM+REMOTE_ERROR message. If the client finishes its data transfer, it will send a final REMOTE_STREAM+REMOTE_OK message, and the server will respond with the same. This full roundtrip handshake ensures any async error messages are guarenteed to be flushed For incoming data streams (data from server to client), the server sends zero or more REMOTE_STREAM packets containing the data with status == REMOTE_CONTINUE. These are asynchronous and not acknowledged by the client. At any time the client may send an async message with a type of REMOTE_STREAM and status of REMOTE_ERROR. This indicates to the server that the transfer is aborting at client request. If the server wishes to abort, it can send the server a REMOTE_STREAM+REMOTE_ERROR message. When the server finishes its data transfer, it will send a final REMOTE_STREAM+REMOTE_CONTINUE message ewith a data length of zero (ie EOF). The client will then send a REMOTE_STREAM+REMOTE_OK packet and the server will respond with the same. This full roundtrip handshake ensures any async error messages are guarenteed to be flushed This all ensures that multiple data streams can be active in parallel, and with a maximum data packet size of 256 KB, no single stream can cause too much latency on the connection for other API calls/streams. The only thing it does not allow for is one API method to use two or more streams. These may be famous last words, but I don't think that use case will be neccessary for any of our APIs... The last 5 patches with a subject of [DEMO] are *NOT* intended to be committed to the repository. They merely demonstrate the use of data streams for a couple of hypothetical file upload and download APIs. Actually they were mostly to allow me to test the code streams code without messing around with the QEMU migration code. The immediate use case for this data stream code is Chris' QEMU migration patchset. The next use case is to allow serial console access to be tunnelled over libvirtd, eg to make 'virsh console GUEST' work remotely. This use case is why I included the support for non-blocking data streams and event loop integration (not required for Chris' migration use case) Anyway, assuming Chris confirms that I've not broken his code, then patches 1-6 are targetted for this next release. .x-sc_avoid_write | 3 include/libvirt/libvirt.h | 101 ++++ include/libvirt/libvirt.h.in | 101 ++++ po/POTFILES.in | 1 qemud/Makefile.am | 1 qemud/dispatch.c | 131 ++++++ qemud/dispatch.h | 17 qemud/event.c | 54 +- qemud/qemud.c | 56 +- qemud/qemud.h | 33 + qemud/remote.c | 237 ++++++++++- qemud/remote.h | 1 qemud/remote_dispatch_args.h | 2 qemud/remote_dispatch_prototypes.h | 153 +++++++ qemud/remote_dispatch_table.h | 10 qemud/remote_generate_stubs.pl | 1 qemud/remote_protocol.c | 18 qemud/remote_protocol.h | 20 qemud/remote_protocol.x | 57 ++ qemud/stream.c | 605 +++++++++++++++++++++++++++++ qemud/stream.h | 53 ++ src/datatypes.c | 59 ++ src/datatypes.h | 33 + src/driver.h | 40 + src/esx/esx_driver.c | 2 src/libvirt.c | 769 +++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 2 src/libvirt_public.syms | 18 src/lxc_driver.c | 2 src/opennebula/one_driver.c | 2 src/openvz_driver.c | 2 src/qemu_driver.c | 2 src/remote_internal.c | 601 ++++++++++++++++++++++++++++ src/test.c | 477 ++++++++++++++++++++++ src/uml_driver.c | 2 src/vbox/vbox_tmpl.c | 3 src/virsh.c | 164 +++++++ src/xen_unified.c | 2 tests/eventtest.c | 19 39 files changed, 3783 insertions(+), 71 deletions(-) Regards, Daniel

5 43

[libvirt] [PATCH] Power Hypervisor now with libssh2
by Eduardo Otubo 21 Sep '09

21 Sep '09

Hello friends, This is the new version of phyp driver now using libssh2. I also did some other changes: * Added some debug information. Sometimes its worth to know which command is being executed and where. So I added the PHYP_CMD_DEBUG macro. * All the connection startup is now "hard coded" in libssh2. For example, I need to open the socket and start the connection all by myself. Not a big deal, but in a near future I am planning to send a patch to libssh2 to encapsulate all these procedures into functions, hence, less code, probably less bugs :) * There is a lot of "out of scope" functions in the bottom of the file. In the next patch I may put all those together in a phyp_config.[ch] in order to get things clearer. What's up next: * The problem of handling the UUID in a centralized way still remains. I started to handle this by opening a sftp connection to the HMC system and transfer my UUID database. But there is an odd behavior that makes the driver connect OR NOT to some HMC systems. * CPU management: this feature planned to be released in this version is not ready yet due to the issue above. * Storage management. Vacations: I'll be on vacations from 26th/august to 14th/september. I'll check my emails in the meanwhile, but no so often. Anyway, any comments on this patch are always welcome :) []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 otubo(a)linux.vnet.ibm.com

2 3

[libvirt] [PATCH] Fix handling of Xen(ner) detection
by Daniel P. Berrange 10 Sep '09

10 Sep '09

Latest upstream QEMU can be built with Xen support, which introduces a -xen-domid argument. This was mistakenly detected as -domid due to old Xenner support. Adapt to cope with both syntax. Also only set domid if the virt type is xen, or the guest type is xen * src/qemu_conf.c, src/qemu_conf.h: Detect new -xen-domid flag in preference to -domid. * tests/qemuxml2argvdata/qemuxml2argv-bootloader.args, tests/qemuxml2argvdata/qemuxml2argv-input-xen.args: Add missing -domid param * tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args: Remove bogus -boot param. * tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml: Fix domain type to be xen * tests/qemuxml2argvtest.c: Add missing QEMUD_CMD_FLAG_DOMID params --- src/qemu_conf.c | 31 +++++++++++++++---- src/qemu_conf.h | 1 + .../qemuxml2argvdata/qemuxml2argv-bootloader.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-input-xen.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml | 3 +- tests/qemuxml2argvtest.c | 4 +- 7 files changed, 31 insertions(+), 14 deletions(-) diff --git a/src/qemu_conf.c b/src/qemu_conf.c index 22f5edd..e8414c3 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -769,7 +769,9 @@ static unsigned int qemudComputeCmdFlags(const char *help, flags |= QEMUD_CMD_FLAG_NAME; if (strstr(help, "-uuid")) flags |= QEMUD_CMD_FLAG_UUID; - if (strstr(help, "-domid")) + if (strstr(help, "-xen-domid")) + flags |= QEMUD_CMD_FLAG_XEN_DOMID; + else if (strstr(help, "-domid")) flags |= QEMUD_CMD_FLAG_DOMID; if (strstr(help, "-drive")) { flags |= QEMUD_CMD_FLAG_DRIVE; @@ -1594,9 +1596,22 @@ int qemudBuildCommandLine(virConnectPtr conn, ADD_ARG_LIT("-uuid"); ADD_ARG_LIT(uuid); } - if (qemuCmdFlags & QEMUD_CMD_FLAG_DOMID) { - ADD_ARG_LIT("-domid"); - ADD_ARG_LIT(domid); + if (def->virtType == VIR_DOMAIN_VIRT_XEN || + STREQ(def->os.type, "xen") || + STREQ(def->os.type, "linux")) { + if (qemuCmdFlags & QEMUD_CMD_FLAG_DOMID) { + ADD_ARG_LIT("-domid"); + ADD_ARG_LIT(domid); + } else if (qemuCmdFlags & QEMUD_CMD_FLAG_XEN_DOMID) { + ADD_ARG_LIT("-xen-attach"); + ADD_ARG_LIT("-xen-domid"); + ADD_ARG_LIT(domid); + } else { + qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _("qemu emulator '%s' does not support xen"), + def->emulator); + goto error; + } } /* @@ -1649,9 +1664,11 @@ int qemudBuildCommandLine(virConnectPtr conn, break; } } - boot[def->os.nBootDevs] = '\0'; - ADD_ARG_LIT("-boot"); - ADD_ARG_LIT(boot); + if (def->os.nBootDevs) { + boot[def->os.nBootDevs] = '\0'; + ADD_ARG_LIT("-boot"); + ADD_ARG_LIT(boot); + } if (def->os.kernel) { ADD_ARG_LIT("-kernel"); diff --git a/src/qemu_conf.h b/src/qemu_conf.h index a126dac..99aac81 100644 --- a/src/qemu_conf.h +++ b/src/qemu_conf.h @@ -67,6 +67,7 @@ enum qemud_cmd_flags { QEMUD_CMD_FLAG_HOST_NET_ADD = QEMUD_CMD_FLAG_0_10, /* host_net_add monitor command */ QEMUD_CMD_FLAG_PCIDEVICE = (1 << 17), /* PCI device assignment only supported by qemu-kvm */ + QEMUD_CMD_FLAG_XEN_DOMID = (1 << 18), /* -xen-domid (new style xen integration) */ }; /* Main driver state */ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-bootloader.args b/tests/qemuxml2argvdata/qemuxml2argv-bootloader.args index 8a15524..bcae18a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-bootloader.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-bootloader.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/xenner -S -M xenner -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -bootloader /usr/bin/pygrub -cdrom /dev/cdrom -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/xenner -S -M xenner -m 214 -smp 1 -domid 6 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -bootloader /usr/bin/pygrub -cdrom /dev/cdrom -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-input-xen.args b/tests/qemuxml2argvdata/qemuxml2argv-input-xen.args index 64c0e1c..65fb073 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-input-xen.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-input-xen.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/xenner -S -M xenner -m 214 -smp 1 -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -bootloader /foo -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb -vnc 127.0.0.1:3 +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/xenner -S -M xenner -m 214 -smp 1 -domid 6 -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -bootloader /foo -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb -vnc 127.0.0.1:3 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args b/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args index c735dc7..c4df9ae 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -name QEMUGuest1 -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 -domid 6 -nographic -monitor unix:/tmp/test-monitor,server,nowait -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -name QEMUGuest1 -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 -domid 6 -nographic -monitor unix:/tmp/test-monitor,server,nowait -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml index 1b37bdc..7f77e01 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml @@ -5,8 +5,7 @@ <currentMemory>219200</currentMemory> <vcpu>1</vcpu> <os> - <type arch='i686' machine='pc'>hvm</type> - <boot dev='hd'/> + <type arch='x86_64' machine='pc'>xen</type> </os> <features> <acpi/> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 6f25e7d..ad7a690 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -186,7 +186,7 @@ mymain(int argc, char **argv) DO_TEST("boot-cdrom", 0); DO_TEST("boot-network", 0); DO_TEST("boot-floppy", 0); - DO_TEST("bootloader", 0); + DO_TEST("bootloader", QEMUD_CMD_FLAG_DOMID); DO_TEST("clock-utc", 0); DO_TEST("clock-localtime", 0); DO_TEST("disk-cdrom", 0); @@ -236,7 +236,7 @@ mymain(int argc, char **argv) DO_TEST("graphics-sdl-fullscreen", 0); DO_TEST("input-usbmouse", 0); DO_TEST("input-usbtablet", 0); - DO_TEST("input-xen", 0); + DO_TEST("input-xen", QEMUD_CMD_FLAG_DOMID); DO_TEST("misc-acpi", 0); DO_TEST("misc-no-reboot", 0); DO_TEST("misc-uuid", QEMUD_CMD_FLAG_NAME | -- 1.6.2.5

2 2

[libvirt] [PATCH] Fix several memory leaks
by Ryota Ozaki 05 Sep '09

05 Sep '09

Hi, This patch fixes several memory leaks being scattered over libvirt. Thanks, ozaki-r >From 6fc282eae5192cccda208d8d4fd14c5c0676992b Mon Sep 17 00:00:00 2001 From: Ryota Ozaki <ozaki.ryota(a)gmail.com> Date: Tue, 1 Sep 2009 01:34:40 +0900 Subject: [PATCH] Fix several memory leaks --- qemud/qemud.c | 2 +- src/domain_conf.c | 1 + src/network_conf.c | 5 +++-- src/qemu_conf.c | 13 ++++++++----- src/storage_backend_fs.c | 5 +++++ 5 files changed, 18 insertions(+), 8 deletions(-) diff --git a/qemud/qemud.c b/qemud/qemud.c index df275e6..17ba44a 100644 --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -1733,7 +1733,7 @@ readmore: /* Possibly need to create another receive buffer */ if ((client->nrequests < max_client_requests && - VIR_ALLOC(client->rx) < 0)) { + !client->rx && VIR_ALLOC(client->rx) < 0)) { qemudDispatchClientFailure(client); } else { if (client->rx) diff --git a/src/domain_conf.c b/src/domain_conf.c index 1d2cc7c..4b64219 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -4361,6 +4361,7 @@ int virDomainSaveXML(virConnectPtr conn, cleanup: if (fd != -1) close(fd); + VIR_FREE(configFile); return ret; } diff --git a/src/network_conf.c b/src/network_conf.c index bb649a4..58a4f32 100644 --- a/src/network_conf.c +++ b/src/network_conf.c @@ -820,6 +820,7 @@ int virNetworkDeleteConfig(virConnectPtr conn, { char *configFile = NULL; char *autostartLink = NULL; + int ret = -1; if ((configFile = virNetworkConfigFile(conn, configDir, net->def->name)) == NULL) goto error; @@ -836,12 +837,12 @@ int virNetworkDeleteConfig(virConnectPtr conn, goto error; } - return 0; + ret = 0; error: VIR_FREE(configFile); VIR_FREE(autostartLink); - return -1; + return ret; } char *virNetworkConfigFile(virConnectPtr conn, diff --git a/src/qemu_conf.c b/src/qemu_conf.c index 22f5edd..32d6a48 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -1034,7 +1034,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn, virDomainNetDefPtr net, int qemuCmdFlags) { - char *brname; + char *brname = NULL; int err; int tapfd = -1; int vnet_hdr = 0; @@ -1053,7 +1053,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn, if (brname == NULL) return -1; } else if (net->type == VIR_DOMAIN_NET_TYPE_BRIDGE) { - brname = net->data.bridge.brname; + brname = strdup(net->data.bridge.brname); } else { qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, _("Network type %d is not supported"), net->type); @@ -1063,7 +1063,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn, if (!driver->brctl && (err = brInit(&driver->brctl))) { virReportSystemError(conn, err, "%s", _("cannot initialize bridge support")); - return -1; + goto cleanup; } if (!net->ifname || @@ -1072,7 +1072,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn, VIR_FREE(net->ifname); if (!(net->ifname = strdup("vnet%d"))) { virReportOOMError(conn); - return -1; + goto cleanup; } /* avoid exposing vnet%d in dumpxml or error outputs */ template_ifname = 1; @@ -1100,9 +1100,12 @@ qemudNetworkIfaceConnect(virConnectPtr conn, } if (template_ifname) VIR_FREE(net->ifname); - return -1; + tapfd = -1; } +cleanup: + VIR_FREE(brname); + return tapfd; } diff --git a/src/storage_backend_fs.c b/src/storage_backend_fs.c index ca6d329..222e591 100644 --- a/src/storage_backend_fs.c +++ b/src/storage_backend_fs.c @@ -856,6 +856,8 @@ virStorageBackendFileSystemRefresh(virConnectPtr conn, vol->type = VIR_STORAGE_VOL_FILE; vol->target.format = VIR_STORAGE_VOL_FILE_RAW; /* Real value is filled in during probe */ + if (vol->target.path) + VIR_FREE(vol->target.path); if (virAsprintf(&vol->target.path, "%s/%s", pool->def->target.path, vol->name) == -1) @@ -1022,6 +1024,9 @@ virStorageBackendFileSystemVolCreate(virConnectPtr conn, vol->type = VIR_STORAGE_VOL_FILE; + if (vol->target.path) + VIR_FREE(vol->target.path); + if (virAsprintf(&vol->target.path, "%s/%s", pool->def->target.path, vol->name) == -1) { -- 1.6.0.6

4 7

[libvirt] [PATCH] little bit cleanup
by Pritesh Kothari 04 Sep '09

04 Sep '09

Hi All, Just cleaned up some code to make the it more readable. The patch is attached here with. Directly applies to the HEAD as of today. Regards, Pritesh

3 2

[libvirt] [PATCH] Minor comment changes.
by Laine Stump 04 Sep '09

04 Sep '09

Fix some minor grammer (and one other) nits in comments that end up in generated API reference documentation. No functional/binary differences. --- src/libvirt.c | 24 ++++++++++++------------ 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index ca8e003..ce3d6ba 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -592,9 +592,9 @@ virRegisterNetworkDriver(virNetworkDriverPtr driver) /** * virRegisterInterfaceDriver: - * @driver: pointer to a interface driver block + * @driver: pointer to an interface driver block * - * Register a interface virtualization driver + * Register an interface virtualization driver * * Returns the driver priority or -1 in case of error. */ @@ -5365,7 +5365,7 @@ error: /** * virNetworkGetXMLDesc: * @network: a network object - * @flags: and OR'ed set of extraction flags, not used yet + * @flags: an OR'ed set of extraction flags, not used yet * * Provide an XML description of the network. The description may be reused * later to relaunch the network with virNetworkCreateXML(). @@ -5545,7 +5545,7 @@ error: /** * virInterfaceGetConnect: - * @iface: pointer to a interface + * @iface: pointer to an interface * * Provides the connection pointer associated with an interface. The * reference counter on the connection is not increased by this @@ -5819,7 +5819,7 @@ error: /** * virInterfaceGetName: - * @iface: a interface object + * @iface: an interface object * * Get the public name for that interface * @@ -5842,9 +5842,9 @@ virInterfaceGetName(virInterfacePtr iface) /** * virInterfaceGetMACString: - * @iface: a interface object + * @iface: an interface object * - * Get the MAC for a interface as string. For more information about + * Get the MAC for an interface as string. For more information about * MAC see RFC4122. * * Returns a pointer to the MAC address (in null-terminated ASCII @@ -5867,11 +5867,11 @@ virInterfaceGetMACString(virInterfacePtr iface) /** * virInterfaceGetXMLDesc: - * @iface: a interface object - * @flags: and OR'ed set of extraction flags, not used yet + * @iface: an interface object + * @flags: an OR'ed set of extraction flags, not used yet * * Provide an XML description of the interface. The description may be reused - * later to recreate the interface with virInterfaceCreateXML(). + * later to redefine the interface with virInterfaceDefineXML(). * * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case of error. * the caller must free() the returned value. @@ -6100,7 +6100,7 @@ error: * This method is typically useful for applications where multiple * threads are using a connection, and it is required that the * connection remain open until all threads have finished using - * it. ie, each new thread using a interface would increment + * it. ie, each new thread using an interface would increment * the reference count. * * Returns 0 in case of success, -1 in case of failure. @@ -6121,7 +6121,7 @@ virInterfaceRef(virInterfacePtr iface) /** * virInterfaceFree: - * @iface: a interface object + * @iface: an interface object * * Free the interface object. The interface itself is unaltered. * The data structure is freed and should not be used thereafter. -- 1.6.2.5

3 2

[libvirt] [PATCH] Fix a memory leak in virsh.
by Laine Stump 04 Sep '09

04 Sep '09

I found this while looking for examples of using virNodeDeviceGetXMLDesc(). AFAIK, *all* of the *GetXMLDesc() functions return a newly allocated chunk of memory that is owned by the caller, who must free it when they're done... --- src/virsh.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/src/virsh.c b/src/virsh.c index 15e0cef..910d860 100644 --- a/src/virsh.c +++ b/src/virsh.c @@ -5521,6 +5521,7 @@ cmdNodeDeviceDumpXML (vshControl *ctl, const vshCmd *cmd) { const char *name; virNodeDevicePtr device; + char *xml; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) return FALSE; @@ -5531,7 +5532,14 @@ cmdNodeDeviceDumpXML (vshControl *ctl, const vshCmd *cmd) return FALSE; } - vshPrint(ctl, "%s\n", virNodeDeviceGetXMLDesc(device, 0)); + xml = virNodeDeviceGetXMLDesc(device, 0); + if (!xml) { + virNodeDeviceFree(device); + return FALSE; + } + + vshPrint(ctl, "%s\n", xml); + free(xml); virNodeDeviceFree(device); return TRUE; } -- 1.6.2.5

3 2

[libvirt] [PATCH] Fix sexpr2string() to handle empty list
by Jim Fehlig 04 Sep '09

04 Sep '09

Finally have some time to submit this small patch for a bug I'm seeing with Xen 3.3.1. If s-expression returned by xend contains an empty list, sexpr2string() failed to serialize it. E.g. sexpr containing (cpus (()())) would cause sexpr2string() to fail. I spoke with danpb on IRC about this bug and he suggested adding a XML/sexpr pair that exhibits the problem to tests/xml2sexprtest.c. I can easily produce the sexpr but not the case with XML. The empty cpus lists indicate no explicit affinity and AFAIK the only way to express this in XML is absence of cpuset attribute in vcpu element. But IMO we should not produce the (cpus (()()...)) sexpr in this case. It should only be produced when user has explicitly specified affinity. Does this sound reasonable? Regards, Jim

2 1