[libvirt] race between qemu monitor startup and blocking migrate -incoming
by Charles Duffy
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
14 years, 11 months
[libvirt] [PATCH 00/11] Generic data stream handling
by Daniel P. Berrange
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
15 years, 1 month
[libvirt] [PATCH] Power Hypervisor now with libssh2
by Eduardo Otubo
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
15 years, 1 month
[libvirt] [PATCH] Fix handling of Xen(ner) detection
by Daniel P. Berrange
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
15 years, 1 month
[libvirt] [PATCH] Fix several memory leaks
by Ryota Ozaki
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
15 years, 1 month
[libvirt] [PATCH] little bit cleanup
by Pritesh Kothari
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
15 years, 1 month
[libvirt] [PATCH] Minor comment changes.
by Laine Stump
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
15 years, 1 month
[libvirt] [PATCH] Fix a memory leak in virsh.
by Laine Stump
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
15 years, 1 month
[libvirt] [PATCH] Fix sexpr2string() to handle empty list
by Jim Fehlig
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
15 years, 1 month
[libvirt] [PATCH] Fix ID field in virDomainPtr after starting Xen guest
by Daniel P. Berrange
* src/xend_internal.c: Lookup guest after starting persistent
config in order to refresh the domain ID field
---
src/xend_internal.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/xend_internal.c b/src/xend_internal.c
index 7bcee7d..459b6bc 100644
--- a/src/xend_internal.c
+++ b/src/xend_internal.c
@@ -4537,6 +4537,8 @@ virDomainPtr xenDaemonDomainDefineXML(virConnectPtr conn, const char *xmlDesc) {
int xenDaemonDomainCreate(virDomainPtr domain)
{
xenUnifiedPrivatePtr priv;
+ int ret;
+ virDomainPtr tmp;
if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL)) {
virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG,
@@ -4549,7 +4551,17 @@ int xenDaemonDomainCreate(virDomainPtr domain)
if (priv->xendConfigVersion < 3)
return(-1);
- return xend_op(domain->conn, domain->name, "op", "start", NULL);
+ ret = xend_op(domain->conn, domain->name, "op", "start", NULL);
+
+ if (ret != -1) {
+ /* Need to force a refresh of this object's ID */
+ tmp = virDomainLookupByName(domain->conn, domain->name);
+ if (tmp) {
+ domain->id = tmp->id;
+ virDomainFree(tmp);
+ }
+ }
+ return ret;
}
int xenDaemonDomainUndefine(virDomainPtr domain)
--
1.6.4
15 years, 1 month
