December 2008 - 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] adding bandwidth control support
by Max Zhen 27 Feb '09

27 Feb '09

My last post failed, resend... Max Zhen at 2008-12-24 18:39 wrote: > Hi, > > I'm working on adding bandwidth control support in > virt-install/virsh/libvirt on Xen. > This support can allow setting bandwidth control in dom0 (I'm working on > Solaris dom0 now) for virtual nic devices used in a domU. > I've attached my design in this email. > Basically, this design is about how to represent bandwidth limit > information in command line for virsh/virt-install and how to represent > it in current XML configuration file for a domU. > > Your comments will be highly appreciated :). > > Thanks, > Max > > There are a few things to do to achieve this goal: 1. extend current command line syntax of 'virsh attach-interface' 2. extend current command line syntax of 'virt-install' 3. define bandwidth representation in XML format For 1. I will change the current command line syntax to: virsh attach-interface <domain> <type> <source> [--target <target>] [--mac <mac>] [--script <script>] [--rate <rate-string>] So that we are able to specify bandwidth as "--rate 100M" in command line, like: #virsh attach-interface domu bridge bge0 --rate 100M In this case, bandwidth is specified as an integer with one of the scale suffixes K, M, or G for Kbps, Mbps, or Gbps. For 2. I will add one more option "--rate=rate-string" to current option set of virt-install command. Users can repeatedly add more than one 'rate' options to set bandwidth for multiple nic devices respectively, if needed. For example, with below command line, we start installing a domain with two nic devices whose bandwidth are set to 100Mb/s and 200Mb/s respectively: #virt-install -n snv105 -r 2048 -p --file=/root/snv105 --location=/solarisdvd.iso -b bge0 --rate=100M -b bge1 --rate=200M In this case, bandwidth is specified as an integer with one of the scale suffixes K, M, or G for Kbps, Mbps, or Gbps. For 3. All user specified bandwidth will be represented as part of interface element currently defined in XML configuration file. The new format looks like: <interface type='bridge'> <source bridge='e1000g1'/> <flowcontrol> <rate unit='megabit' period='second' value='100'/> </flowcontrol> </interface> So, I create a new element, "flowcontrol", inside "interface" element. Inside "flowcontrol", I provide bandwidth by setting "rate" element with three attributes, "unit", "period" and "value" to express the bandwidth limit. The supported unit can be 'gigabit', 'megabit' and 'kilobit'. The supported period can be 'second', 'millisecond' and 'microsecond'. And value is an integer to express the amount of data in unit allowed to be transfered in period of time. More elements can be added inside "flowcontrol" element, if we want to add more flow control policies in the future.

2 5

[libvirt] Adding VirtualBox support to libvirt
by Pritesh Kothari 26 Feb '09

26 Feb '09

Hi, I am in the process of adding support for virtualbox in libvirt. Basically Virtualbox exports its API through XPCOM. Now to simplify things I was thinking of using C++ and already existing xpcom component in virtualbox but since libvirt exports C API i am not sure if i should use C++ or stick to plain C. I would like to request the libvirt community for its comment on this. Regards, Pritesh

4 10

[libvirt] [PATCH ] (type ioem) adding qemu nic configuration option in to libvirt (XEN)
by Gihan Munasinghe 09 Feb '09

09 Feb '09

Guys I have added a new attribute with with in <interface > tag called "qemu" which can be either true or false.. Indicating if the user wants XEN to create qeum net device or not.. This will fix the problem with PV net drivers with XEN.. Check the following examples e.g 1) Interface tag with qemu attribute set to false <interface type='bridge' qemu='false'> <mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> </interface> qemu-dm output --------------------- /usr/lib64/xen/bin/qemu-dm -d 60 -domain-name benchmark1 -k en-gb -vnc 0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net none -M xenfv XEND has configured the hvm guest not to have network card via qemu e.g 2) Interface tag with qemu attribute set to true with qemu supported nic model <interface type='bridge' qemu='true'> <mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> <model type='e1000'/> </interface> qemu-dm output --------------------- /usr/lib64/xen/bin/qemu-dm -d 61 -domain-name benchmark1 -k en-gb -vnc 0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net nic,vlan=1,macaddr=00:16:3e:00:a5:01,model=e1000 -net tap,vlan=1,ifname=tap61.0,bridge=eth0 -M xenfv Now XEND have configured the hvm guest to have emulated nic of the model "e1000" Therefore now, via libvirt configuration I have the ability ask xen to either to configure qemu network card or not (when I have pv divers installed with in my VM ) I have attached the patch files, Let me know what you guys think. Thanks Gihan -- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com --- domain_conf.h.back 2008-12-04 15:31:38.000000000 +0000 +++ domain_conf.h 2008-12-04 20:28:16.000000000 +0000 @@ -127,9 +127,17 @@ VIR_DOMAIN_NET_TYPE_NETWORK, VIR_DOMAIN_NET_TYPE_BRIDGE, - VIR_DOMAIN_NET_TYPE_LAST, + VIR_DOMAIN_NET_TYPE_LAST }; +/*Holds the values that can be passed as qemu attribute in <inteface >*/ +enum virDomainNetQemuAllocateType{ + VIR_DOMAIN_NET_QEMU_ALLOC_TRUE, + VIR_DOMAIN_NET_QEMU_ALLOC_FALSE, + + VIR_DOMAIN_NET_QEMU_ALLOC_LAST + +}; /* Stores the virtual network interface configuration */ typedef struct _virDomainNetDef virDomainNetDef; @@ -156,6 +164,8 @@ } bridge; } data; char *ifname; + int qemu_allocate;/* This is set so that the users can ask xen not give vm's a network card + maily to with the (type none)/(type ieoum) tags wchi will be send to xend*/ }; enum virDomainChrSrcType { @@ -608,5 +618,5 @@ VIR_ENUM_DECL(virDomainInput) VIR_ENUM_DECL(virDomainInputBus) VIR_ENUM_DECL(virDomainGraphics) - +VIR_ENUM_DECL(virDomainNetQemuAllocate) #endif /* __DOMAIN_CONF_H */ --- domain_conf.c.back 2008-12-04 15:31:40.000000000 +0000 +++ domain_conf.c 2008-12-04 20:30:31.000000000 +0000 @@ -142,6 +142,10 @@ "usb", "pci") +VIR_ENUM_IMPL(virDomainNetQemuAllocate, VIR_DOMAIN_NET_QEMU_ALLOC_LAST, + "true", + "false") + #define virDomainReportError(conn, code, fmt...) \ virReportErrorHelper(conn, VIR_FROM_DOMAIN, code, __FILE__, \ __FUNCTION__, __LINE__, fmt) @@ -787,6 +791,7 @@ char *address = NULL; char *port = NULL; char *model = NULL; + char *qemu_alloc = NULL; if (VIR_ALLOC(def) < 0) { virDomainReportError(conn, VIR_ERR_NO_MEMORY, NULL); @@ -800,6 +805,17 @@ _("unknown interface type '%s'"), type); goto error; } + qemu_alloc = virXMLPropString(node, "qemu"); + if( qemu_alloc!=NULL){ + if ((def->qemu_allocate = virDomainNetQemuAllocateTypeFromString(qemu_alloc)) < 0) { + virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, + _("unknown qemu alloc '%s'"), qemu_alloc); + goto error; + } + + }else{ + def->qemu_allocate = VIR_DOMAIN_NET_QEMU_ALLOC_TRUE; // by default the aloocation will be true + } } else { def->type = VIR_DOMAIN_NET_TYPE_USER; } @@ -818,6 +834,7 @@ (def->type == VIR_DOMAIN_NET_TYPE_BRIDGE) && (xmlStrEqual(cur->name, BAD_CAST "source"))) { bridge = virXMLPropString(cur, "bridge"); + } else if ((dev == NULL) && (def->type == VIR_DOMAIN_NET_TYPE_ETHERNET) && xmlStrEqual(cur->name, BAD_CAST "source")) { --- xend_internal.c.back 2008-12-04 15:31:38.000000000 +0000 +++ xend_internal.c 2008-12-04 21:05:49.000000000 +0000 @@ -1773,10 +1773,9 @@ if (VIR_ALLOC(net) < 0) goto no_memory; - if ((tmp2 && strstr(tmp2, "bridge")) || tmp) { - net->type = VIR_DOMAIN_NET_TYPE_BRIDGE; - /* XXX virtual network reverse resolve */ - + if ((tmp2 && (strstr(tmp2, "bridge") )) || tmp) { + net->type = VIR_DOMAIN_NET_TYPE_BRIDGE; + /* XXX virtual network reverse resolve */ if (tmp && !(net->data.bridge.brname = strdup(tmp))) goto no_memory; @@ -5153,10 +5152,15 @@ /* * apparently (type ioemu) breaks paravirt drivers on HVM so skip this - * from Xen 3.1.0 + * from Xen 3.1.0 This happence as XEN try to allocate a network card via qemu */ - if ((hvm) && (xendConfigVersion < 4)) - virBufferAddLit(buf, "(type ioemu)"); +// if ((hvm) && (xendConfigVersion < 4) ) + if ((hvm) && (def->qemu_allocate==VIR_DOMAIN_NET_QEMU_ALLOC_FALSE)){ /* If we have asked the qemu not to allocte a net work for hvm guest. + This way you would not have a problem with PV drivers on HVM guests*/ + virBufferAddLit(buf, "(type none)"); + }else { + virBufferAddLit(buf, "(type ioemu)"); + } if (!isAttach) virBufferAddLit(buf, ")");

5 8

[libvirt] [PATCH 0/7 RFC] RHEL-5 support, and a few preparatory fixes
by Markus Armbruster 19 Jan '09

19 Jan '09

This patch series attempts to make libvirt just work on RHEL-5. Right now it doesn't, mostly because libvirt relies on version number checks in a couple of places, and RHEL-5's version numbers aren't the whole truth due to various backports of later stuff. The first two patches are plain bug fixes: [PATCH 1/7] Fix network device inconsistency between xm and sxpr [PATCH 2/7] Fix graphics configuration inconsistency between xm and sxpr The next three add a few special cases for RHEL-5: [PATCH 3/7] New configure option --with-rhel5-api [PATCH 4/7] Fix HVM network device configuration for RHEL-5 [PATCH 5/7] Fix PVFB device configuration for RHEL-5 [PATCH 6/7] Enable NUMA support for RHEL-5 The last one drops a counter-productive error check: [PATCH 7/7] Don't treat missing topology information as error See the patches for more detailed descriptions. I'm not proposing this for immediate commit, as I'm still testing. But I'd appreciate review: is this the right way to do it? Thanks, Markus

4 15

[libvirt] kvm: save / restore
by Matthias Pfafferodt 17 Jan '09

17 Jan '09

Hallo, I use kvm-81 and libvirt 0.5.1. I can save a kvm donain but if I want to restore it I get the following error in the log file: unknown migration protocol: stdio I tried it using only kvm and got the same error. How can I save / restore a VM to / from a file? Kind regards Matthias Pfafferodt -- Matthias Pfafferodt - http://www.mapfa.de Matthias.Pfafferodt <at> mapfa.de

3 3

[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] 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] 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] [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