January 2009 - Devel - libvirt List Archives

[libvirt] [PATCH] Add copy-on-write image support
by Miloslav Trmač 14 Jan '09

14 Jan '09

Hello, the attached patch adds support for copy-on-write images: creating them, deleting them, identifying them. Mirek

3 5

[libvirt] [PATCH] Mark Xen PV CD-ROM devices as such
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User John Levon <john.levon(a)sun.com> # Date 1231946129 28800 # Node ID 53c621a65055f4752abef748c0ad15cbb1d8013d # Parent bde7017c447cf36451194e64179b60e1c8d9f039 Mark Xen PV CD-ROM devices as such Add a ':cdrom' marker for PV as well as HVM devices. Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -5025,6 +5025,8 @@ xenDaemonFormatSxprDisk(virConnectPtr co virBufferVSprintf(buf, "(dev '%s:%s')", def->dst, def->device == VIR_DOMAIN_DISK_DEVICE_CDROM ? "cdrom" : "disk"); + } else if (def->device == VIR_DOMAIN_DISK_DEVICE_CDROM) { + virBufferVSprintf(buf, "(dev '%s:cdrom')", def->dst); } else { virBufferVSprintf(buf, "(dev '%s')", def->dst); }

2 1

[libvirt] [PATCH] Fix oversized stack allocation
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User John Levon <john.levon(a)sun.com> # Date 1231946129 28800 # Node ID c7538cb7fab4e6f3aa6714fdd4126dcf2f0371b4 # Parent cfe04caba5de61620fa6d1c2bff85cfd62255c1d Fix oversized stack allocation REMOTE_MESSAGE_MAX is a whopping 262Kb and shouldn't be allocated on the stack. Signed-off-by: Ryan Scott <ryan.scott(a)sun.com> diff --git a/src/remote_internal.c b/src/remote_internal.c --- a/src/remote_internal.c +++ b/src/remote_internal.c @@ -4797,10 +4797,11 @@ call (virConnectPtr conn, struct private xdrproc_t args_filter, char *args, xdrproc_t ret_filter, char *ret) { - char buffer[REMOTE_MESSAGE_MAX]; + char *buffer = NULL; char buffer2[4]; struct remote_message_header hdr; XDR xdr; + int err = -1; int len; struct remote_error rerror; @@ -4814,18 +4815,23 @@ call (virConnectPtr conn, struct private hdr.serial = serial; hdr.status = REMOTE_OK; + if ((buffer = malloc(REMOTE_MESSAGE_MAX)) == NULL) { + error (conn, VIR_ERR_SYSTEM_ERROR, strerror (errno)); + goto out; + } + /* Serialise header followed by args. */ - xdrmem_create (&xdr, buffer, sizeof buffer, XDR_ENCODE); + xdrmem_create (&xdr, buffer, REMOTE_MESSAGE_MAX, XDR_ENCODE); if (!xdr_remote_message_header (&xdr, &hdr)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("xdr_remote_message_header failed")); - return -1; + goto out; } if (!(*args_filter) (&xdr, args)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("marshalling args")); - return -1; + goto out; } /* Get the length stored in buffer. */ @@ -4842,25 +4848,25 @@ call (virConnectPtr conn, struct private if (!xdr_int (&xdr, &len)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("xdr_int (length word)")); - return -1; + goto out; } xdr_destroy (&xdr); /* Send length word followed by header+args. */ if (really_write (conn, priv, flags & REMOTE_CALL_IN_OPEN, buffer2, sizeof buffer2) == -1 || really_write (conn, priv, flags & REMOTE_CALL_IN_OPEN, buffer, len-4) == -1) - return -1; + goto out; retry_read: /* Read and deserialise length word. */ if (really_read (conn, priv, flags & REMOTE_CALL_IN_OPEN, buffer2, sizeof buffer2) == -1) - return -1; + goto out; xdrmem_create (&xdr, buffer2, sizeof buffer2, XDR_DECODE); if (!xdr_int (&xdr, &len)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("xdr_int (length word, reply)")); - return -1; + goto out; } xdr_destroy (&xdr); @@ -4870,20 +4876,25 @@ retry_read: if (len < 0 || len > REMOTE_MESSAGE_MAX) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("packet received from server too large")); - return -1; } /* Read reply header and what follows (either a ret or an error). */ if (really_read (conn, priv, flags & REMOTE_CALL_IN_OPEN, buffer, len) == -1) - return -1; + goto out; /* Deserialise reply header. */ xdrmem_create (&xdr, buffer, len, XDR_DECODE); if (!xdr_remote_message_header (&xdr, &hdr)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("invalid header in reply")); - return -1; - } + goto out; + } + + /* + * Although the previous lines were the last references to buffer in this + * function, we can't free it yet, as the xdr struct still has some + * pointers to it. + */ /* Check program, version, etc. are what we expect. */ if (hdr.prog != REMOTE_PROGRAM) { @@ -4892,7 +4903,7 @@ retry_read: VIR_ERR_RPC, VIR_ERR_ERROR, NULL, NULL, NULL, 0, 0, _("unknown program (received %x, expected %x)"), hdr.prog, REMOTE_PROGRAM); - return -1; + goto out; } if (hdr.vers != REMOTE_PROTOCOL_VERSION) { virRaiseError (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, @@ -4900,7 +4911,7 @@ retry_read: VIR_ERR_RPC, VIR_ERR_ERROR, NULL, NULL, NULL, 0, 0, _("unknown protocol version (received %x, expected %x)"), hdr.vers, REMOTE_PROTOCOL_VERSION); - return -1; + goto out; } if (hdr.proc == REMOTE_PROC_DOMAIN_EVENT && @@ -4923,7 +4934,7 @@ retry_read: VIR_ERR_RPC, VIR_ERR_ERROR, NULL, NULL, NULL, 0, 0, _("unknown procedure (received %x, expected %x)"), hdr.proc, proc_nr); - return -1; + goto out; } if (hdr.direction != REMOTE_REPLY) { virRaiseError (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, @@ -4931,14 +4942,14 @@ retry_read: VIR_ERR_RPC, VIR_ERR_ERROR, NULL, NULL, NULL, 0, 0, _("unknown direction (received %x, expected %x)"), hdr.direction, REMOTE_REPLY); - return -1; + goto out; } if (hdr.serial != serial) { virRaiseError (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, NULL, NULL, VIR_FROM_REMOTE, VIR_ERR_RPC, VIR_ERR_ERROR, NULL, NULL, NULL, 0, 0, _("unknown serial (received %x, expected %x)"), hdr.serial, serial); - return -1; + goto out; } /* Status is either REMOTE_OK (meaning that what follows is a ret @@ -4950,17 +4961,18 @@ retry_read: if (!(*ret_filter) (&xdr, ret)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("unmarshalling ret")); - return -1; + goto out; } xdr_destroy (&xdr); - return 0; + err = 0; + goto out; case REMOTE_ERROR: memset (&rerror, 0, sizeof rerror); if (!xdr_remote_error (&xdr, &rerror)) { error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("unmarshalling remote_error")); - return -1; + goto out; } xdr_destroy (&xdr); /* See if caller asked us to keep quiet about missing RPCs @@ -4970,11 +4982,12 @@ retry_read: rerror.code == VIR_ERR_RPC && rerror.level == VIR_ERR_ERROR && STRPREFIX(*rerror.message, "unknown procedure")) { - return -2; + err = -2; + goto out; } server_error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, &rerror); xdr_free ((xdrproc_t) xdr_remote_error, (char *) &rerror); - return -1; + goto out; default: virRaiseError (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, NULL, NULL, VIR_FROM_REMOTE, @@ -4982,8 +4995,12 @@ retry_read: _("unknown status (received %x)"), hdr.status); xdr_destroy (&xdr); - return -1; - } + goto out; + } + +out: + VIR_FREE (buffer); + return err; } static int @@ -5551,7 +5568,7 @@ remoteDomainEventFired(int watch, int event, void *opaque) { - char buffer[REMOTE_MESSAGE_MAX]; + char *buffer = NULL; char buffer2[4]; struct remote_message_header hdr; XDR xdr; @@ -5566,22 +5583,22 @@ remoteDomainEventFired(int watch, DEBUG("%s : VIR_EVENT_HANDLE_HANGUP or " "VIR_EVENT_HANDLE_ERROR encountered", __FUNCTION__); virEventRemoveHandle(watch); - return; + goto out; } if (fd != priv->sock) { virEventRemoveHandle(watch); - return; + goto out; } /* Read and deserialise length word. */ if (really_read (conn, priv, 0, buffer2, sizeof buffer2) == -1) - return; + goto out; xdrmem_create (&xdr, buffer2, sizeof buffer2, XDR_DECODE); if (!xdr_int (&xdr, &len)) { error (conn, VIR_ERR_RPC, _("xdr_int (length word, reply)")); - return; + goto out; } xdr_destroy (&xdr); @@ -5590,20 +5607,25 @@ remoteDomainEventFired(int watch, if (len < 0 || len > REMOTE_MESSAGE_MAX) { error (conn, VIR_ERR_RPC, _("packet received from server too large")); - return; + goto out; + } + + if ((buffer = malloc(REMOTE_MESSAGE_MAX)) == NULL) { + error (conn, VIR_ERR_SYSTEM_ERROR, strerror (errno)); + goto out; } /* Read reply header and what follows (either a ret or an error). */ if (really_read (conn, priv, 0, buffer, len) == -1) { error (conn, VIR_ERR_RPC, _("error reading buffer from memory")); - return; + goto out; } /* Deserialise reply header. */ xdrmem_create (&xdr, buffer, len, XDR_DECODE); if (!xdr_remote_message_header (&xdr, &hdr)) { error (conn, VIR_ERR_RPC, _("invalid header in event firing")); - return; + goto out; } if (hdr.proc == REMOTE_PROC_DOMAIN_EVENT && @@ -5614,6 +5636,9 @@ remoteDomainEventFired(int watch, DEBUG0("invalid proc in event firing"); error (conn, VIR_ERR_RPC, _("invalid proc in event firing")); } + +out: + VIR_FREE (buffer); } void

2 1

[libvirt] [PATCH] Improve compiler flag checking
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User john.levon(a)sun.com # Date 1229789393 28800 # Node ID a158bbc6df6fb8b15af875d08e73cfd3ca75f907 # Parent 34706075e6c801cd9532490c11b20b64dfcf464b Improve compiler flag checking Some compilers (including GCC) don't set the return value consistently if an erroneous option is passed on the command line. Account for that. Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/acinclude.m4 b/acinclude.m4 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -45,21 +45,9 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[ ;; esac - compiler_flags= + COMPILER_FLAGS= for option in $try_compiler_flags; do - SAVE_CFLAGS="$CFLAGS" - CFLAGS="$CFLAGS $option" - AC_MSG_CHECKING([whether gcc understands $option]) - AC_TRY_LINK([], [], - has_option=yes, - has_option=no,) - CFLAGS="$SAVE_CFLAGS" - AC_MSG_RESULT($has_option) - if test $has_option = yes; then - compiler_flags="$compiler_flags $option" - fi - unset has_option - unset SAVE_CFLAGS + gl_COMPILER_FLAGS($option) done unset option unset try_compiler_flags @@ -85,7 +73,7 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[ fi AC_MSG_RESULT($complCFLAGS) - WARN_CFLAGS="$compiler_flags $complCFLAGS" + WARN_CFLAGS="$COMPILER_FLAGS $complCFLAGS" AC_SUBST(WARN_CFLAGS) dnl Needed to keep compile quiet on python 2.4 diff --git a/m4/compiler-flags.m4 b/m4/compiler-flags.m4 --- a/m4/compiler-flags.m4 +++ b/m4/compiler-flags.m4 @@ -25,10 +25,16 @@ AC_DEFUN([gl_COMPILER_FLAGS], AC_SUBST(COMPILER_FLAGS) ac_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $1" - AC_TRY_COMPILE(, - [int x;], - COMPILER_FLAGS="$COMPILER_FLAGS $1" - AC_MSG_RESULT(yes), - AC_MSG_RESULT(no)) - CFLAGS="$ac_save_CFLAGS" + AC_TRY_LINK([], [], has_option=yes, has_option=no,) + echo 'int x;' >conftest.c + $CC $CFLAGS -c conftest.c 2>conftest.err + ret=$? + if test $ret != 0 -o -s conftest.err -o $has_option = "no"; then + AC_MSG_RESULT(no) + else + AC_MSG_RESULT(yes) + COMPILER_FLAGS="$COMPILER_FLAGS $1" + fi + CFLAGS="$ac_save_CFLAGS" + rm -f conftest* ])

2 1

[libvirt] libvirtd shutdown script patches
by Sir Woody Hackswell 14 Jan '09

14 Jan '09

Here is a small patch for libvirtd init and sysconfig script. Before killing libvirtd, we virsh shutdown any running domains. We also have a maximum time limit for shutdown (300 sec default), just in case the VM will not shut down. Any thoughts as to whether this is the right place to put this functionality? Is the shutdown script proper, or since libvirtd handles autostarts domains internally, should libvirtd shut down active domains upon SIGTERM all by itself? -Richard --- /etc/init.d/libvirtd.orig 2009-01-13 19:31:47.000000000 -0500 +++ /etc/init.d/libvirtd 2009-01-13 19:53:25.000000000 -0500 @@ -47,6 +47,11 @@ LIBVIRTD_CONFIG_ARGS="--config $LIBVIRTD_CONFIG" fi +if [ -z "$LIBVIRTD_SHUTDOWN_TIMEOUT" ] +then + LIBVIRTD_SHUTDOWN_TIMEOUT=300 +fi + RETVAL=0 start() { @@ -62,6 +67,15 @@ stop() { echo -n $"Stopping $SERVICE daemon: " + starttime=`date '+%s'` + for VM in $(virsh list | grep running | gawk '{print $2}'); do virsh -q shutdown $VM; done + while ( virsh list | grep -qc running ); do + sleep 5; + nowtime=`date '+%s'` + elapsed=$(($nowtime-$starttime)) + [[ $elapsed -ge $LIBVIRTD_SHUTDOWN_TIMEOUT ]] && break + done + killproc $PROCESS RETVAL=$? echo --- /etc/sysconfig/libvirtd.orig 2009-01-13 19:56:09.000000000 -0500 +++ /etc/sysconfig/libvirtd 2009-01-13 19:41:27.000000000 -0500 @@ -8,4 +8,7 @@ # Override Kerberos service keytab for SASL/GSSAPI #KRB5_KTNAME=/etc/libvirt/krb5.tab +# Shutdown timeout in seconds - Default is 300 seconds (or 5 minutes) +#LIBVIRTD_SHUTDOWN_TIMEOUT=300 -- -Sir Woody Hackswell

3 3

[libvirt] QEMU link on libvirt.org needs updated
by Michael Schenck 13 Jan '09

13 Jan '09

Maintainer of libvirt.org, Currently the QEMU link under "libvirt supports" on http://libvirt.org/index.html points to http://fabrice.bellard.free.fr/qemu/, which should be updated to http://bellard.org/qemu/ Best Regards, Michael Schenck -- Michael Schenck - www.tek-ops.com Karma police, arrest this man He talks in maths He buzzes like a fridge He's like a detuned radio

2 1

[libvirt] proposal: allow use of "bool": HACKING: discuss C types
by Jim Meyering 13 Jan '09

13 Jan '09

Hello, I don't want to make waves, but I do care about certain aspects of code quality, so... I propose to allow (encourage, even) the use of the standard C99 type, bool, in libvirt, but not in public interfaces[1]. There are already uses in cgroup.c and xmlrpc.c, as well as those in the gnulib "c-ctype.h" header which is included from many of libvirt's .c files. The motivation is to make the code as readable as possible. When you see the declaration of an "int" variable, member, or function, that type gives you no clue whether it is used as a boolean. If you see a few uses that treat it as boolean, that's still no guarantee, and it may be non-trivial to ensure that there isn't some non-boolean value with a special meaning. However, if you see a "bool" variable, you do have that guarantee. This is one reason to using the tighter, more descriptive type. In addition, if ever you need to go back to using "int", it's trivial to automate the substitution, e.g., -Dint=bool or sed s/int/bool/. On the other hand, it is very hard to automatically identify "int" variables that may safely be converted to "bool". Portability is no problem whatsoever, thanks to gnulib's stdbool module, which ensures that there is a working <stdbool.h> header in the compiler's include path. libvirt even includes/runs a test to ensure that the <stdbool.h> in use (from gnulib or from the system) works properly. Of course, if you agree on principle, we should update HACKING to reflect the policy, so I've taken a shot at that. But if we start talking about using the right type for boolean variables, we can't avoid the more general question of scalars, signedness, etc. And once you mention scalars, you have to mention pointers and const-correctness, so it got longer still. Patch below. Jim [1]: We can use "bool" reliably in libvirt-internal code, due to the fact that it is guaranteed to be compiled with a usable <stdbool.h> header. We cannot make such a guarantee for all applications that compile code including libvirt's public headers, <libvirt.h> and <virterror.h>. P.S. I confess I have a vested interested. I wrote a patch recently that declares a local to be of type "bool", and would like to ensure that policy permits doing that. >From 3c6a9bc0fd043ce9f84e5aaba3cfbc1db0359eb7 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Fri, 12 Dec 2008 09:45:31 +0100 Subject: [PATCH] HACKING: use the right type --- HACKING | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 46 insertions(+), 0 deletions(-) diff --git a/HACKING b/HACKING index 3945833..511c8cc 100644 --- a/HACKING +++ b/HACKING @@ -91,6 +91,52 @@ Usually they're in macro definitions or strings, and should be converted anyhow. +C types +======= +Use the right type. + +Scalars +------- +If you're using "int" or "long", odds are good that there's a better type. +If a variable is counting something, be sure to declare it with an +unsigned type. +If it's memory-size-related, use size_t (use ssize_t only if required). +If it's file-size related, use uintmax_t, or maybe off_t. +If it's file-offset related (i.e., signed), use off_t. +If it's just counting small numbers use "unsigned int"; +(on all but oddball embedded systems, you can assume that that +type is at least four bytes wide). +If a variable has boolean semantics, give it the "bool" type +and use the corresponding "true" and "false" macros. It's ok +to include <stdbool.h>, since libvirt's use of gnulib ensures +that it exists and is usable. +In the unusual event that you require a specific width, use a +standard type like int32_t, uint32_t, uint64_t, etc. + +Of course, take all of the above with a grain of salt. If you're about +to use some system interface that requires a type like int or ssize_t, +use types for your own variables that match. + +Also, if you try to use e.g., "unsigned int" as a type, and that +conflicts with the signedness of a related variable, sometimes +it's best just to use the *wrong* type, if "pulling the thread" +and fixing all related variables would be too invasive. + +Finally, while using descriptive types is important, be careful not to +go overboard. If whatever you're doing causes warnings, or requires +casts, then reconsider or ask for help. + +Pointers +-------- +Ensure that all of your pointers are "const-correct". +Unless a pointer is used to modify the pointed-to storage, +give it the "const" attribute. That way, the reader knows +up-front that this is a read-only pointer. Perhaps more +importantly, if we're diligent about this, when you see a non-const +pointer, you're guaranteed that it is used to modify the storage +it points to, or it is aliased to another pointer that is. + + Low level memory management =========================== -- 1.6.1.rc2.299.gead4c.dirty

3 8

[libvirt] Bridge interface and script
by John Levon 12 Jan '09

12 Jan '09

With current libvirt, it's not possible to specify a script for VIR_DOMAIN_NET_TYPE_BRIDGE. Is this just an oversight, or intentional? We use the bridge type with Solaris virtual NICs, and need to specify the correct script to use. Suggestions on how to fix this? Should I just add script handling to this net type? thanks john

2 4

[libvirt] [PATCH] Fix remote_protocol header for Solaris
by john.levon＠sun.com 12 Jan '09

12 Jan '09

# HG changeset patch # User john.levon(a)sun.com # Date 1229367889 28800 # Node ID 46a487775d4b35c32455a5ca8eb3009d10a02c5b # Parent a1f24e9f8a1fbf191c71172ae986110b7e98fc32 Fix remote_protocol header for Solaris quad_t is not a portable type, but rather than force rpcgen every build, we just patch in the fixes needed. Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/qemud/Makefile.am b/qemud/Makefile.am --- a/qemud/Makefile.am +++ b/qemud/Makefile.am @@ -47,6 +47,7 @@ if GLIBC_RPCGEN chmod 444 $@-t mv $@-t $@ endif + patch < rpcgen-solaris.diff endif remote_protocol.c: remote_protocol.h diff --git a/qemud/rpcgen-solaris.diff b/qemud/rpcgen-solaris.diff new file mode 100644 --- /dev/null +++ b/qemud/rpcgen-solaris.diff @@ -0,0 +1,19 @@ +diff ./remote_protocol.h ./remote_protocol.h +--- ./remote_protocol.h ++++ ./remote_protocol.h +@@ -11,6 +11,15 @@ + + #ifdef __cplusplus + extern "C" { ++#endif ++ ++#if defined(__sun) ++#include <rpc/xdr.h> ++#define u_quad_t uint64_t ++#define quad_t int64_t ++#define xdr_u_quad_t xdr_uint64_t ++#define xdr_quad_t xdr_int64_t ++#define IXDR_GET_LONG IXDR_GET_INT32 + #endif + + #include <config.h>

5 9

[libvirt] [PATCH] Fix invocation of rpcgen
by Richard W.M. Jones 12 Jan '09

12 Jan '09

Currently if rpcgen != glibc's rpcgen, then it gets a bit confused with the temporary files. Also it's best to call the rpcgen that configure detected and not some random rpcgen that happens to be in the path. The attached patch fixes this. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

2 1