- Devel - libvirt List Archives

[Libvir] python/libvir.html example needs adjustment
by Jim Meyering 28 Mar '06

28 Mar '06

Hello, Trying a variant of this example from python/libvir.html: import libvirt import sys conn = libvirt.openReadOnly(None) if conn == None: print 'Failed to open connection to the hypervisor' sys.exit(1) dom0 = conn.lookupByName("Domain-0") if dom0 == None: print 'Failed to find the main domain' sys.exit(1) print "Domain 0: id %d running %s" % (dom0.ID(), dom0.OSType()) print dom0.info() I found that conn.lookupByName throws an exception when the specified name is not found. If the example is just out of date, it should use try:/except: instead of comparing dom0 to None, shouldn't it? You can demonstrate it like this: $ python -c 'import libvirt; libvirt.openReadOnly(None).lookupByName("x")' libvir: Xen Daemon error : GET operation failed: No such domain x Traceback (most recent call last): File "<string>", line 1, in ? File "/usr/lib/python2.4/site-packages/libvirt.py", line 213, in lookupByName if ret is None:raise libvirtError('virDomainLookupByName() failed') libvirt.libvirtError: virDomainLookupByName() failed [Exit 1] Jim

2 1

[Libvir] use gcc's printf __attribute__
by Jim Meyering 27 Mar '06

27 Mar '06

Hello, I noticed that there are a few printf-like functions here, but that they don't benefit from gcc's format-string vs. arg-type checking. Here's a patch to enable that: However, to make it portable to non-gcc systems, this block of cpp directives needs to go somewhere (maybe libvirt.h?) so it'll be used from both files. #ifndef __attribute__ /* This feature is available in gcc versions 2.5 and later. */ # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) # define __attribute__(Spec) /* empty */ # endif /* The __-protected variants of `format' and `printf' attributes are accepted by gcc versions 2.6.4 (effectively 2.7) and later. */ # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 7) # define __format__ format # define __printf__ printf # endif #endif 2006-03-25 Jim Meyering <jim(a)meyering.net> * src/virsh.c (vshPrint, vshError): Add gcc's __printf__ attribute. * src/xml.h (virBufferVSprintf): Likewise. Index: src/xml.h =================================================================== RCS file: /data/cvs/libvirt/src/xml.h,v retrieving revision 1.3 diff -u -p -r1.3 xml.h --- src/xml.h 15 Mar 2006 12:13:25 -0000 1.3 +++ src/xml.h 25 Mar 2006 10:56:27 -0000 @@ -25,7 +25,8 @@ extern "C" { }; int virBufferAdd(virBufferPtr buf, const char *str, int len); - int virBufferVSprintf(virBufferPtr buf, const char *format, ...); + int virBufferVSprintf(virBufferPtr buf, const char *format, ...) + __attribute__ ((__format__ (__printf__, 2, 3))); char *virDomainParseXMLDesc(const char *xmldesc, char **name); #ifdef __cplusplus Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.21 diff -u -p -r1.21 virsh.c --- src/virsh.c 15 Mar 2006 12:13:25 -0000 1.21 +++ src/virsh.c 25 Mar 2006 10:56:28 -0000 @@ -177,8 +177,8 @@ typedef struct __vshControl { static vshCmdDef commands[]; -static void vshError(vshControl * ctl, int doexit, const char *format, - ...); +static void vshError(vshControl * ctl, int doexit, const char *format, ...) + __attribute__ ((__format__ (__printf__, 3, 4))); static int vshInit(vshControl * ctl); static int vshDeinit(vshControl * ctl); static void vshUsage(vshControl * ctl, const char *cmdname); @@ -198,8 +198,9 @@ static virDomainPtr vshCommandOptDomain( const char *optname, char **name); -static void vshPrint(vshControl * ctl, vshOutType out, const char *format, - ...); +static void vshPrint(vshControl * ctl, vshOutType out, const char *format, ...) + __attribute__ ((__format__ (__printf__, 3, 4))); + ; static const char *vshDomainStateToString(int state);

2 1

[Libvir] Patch for include file syntax
by Daniel P. Berrange 25 Mar '06

25 Mar '06

When doing an out-of-tree build of code which uses virterror.h, one gets a build failure, because when deployed virterror.h lives in subdir of the include directory rather than the top level In file included from Virt.xs:25: /usr/include/libvirt/virterror.h:17:21: error: libvirt.h: No such file or directory In file included from Virt.xs:25: /usr/include/libvirt/virterror.h:62: error: expected specifier-qualifier-list before âvirConnectPtrâ /usr/include/libvirt/virterror.h:122: error: expected â)â before âconnâ /usr/include/libvirt/virterror.h:123: error: expected â)â before âconnâ /usr/include/libvirt/virterror.h:129: error: expected â)â before âconnâ /usr/include/libvirt/virterror.h:132: error: expected â)â before âconnâ This is fixable by making virterror.h use "..." instead of <...> to include libvirt.h. Attaching a patch to fix this Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 6

[Libvir] Patch for pkg-config file cflags
by Daniel P. Berrange 24 Mar '06

24 Mar '06

The libvirt.pc.in file has an empty field for the cflags variable, so if you install libvirt into any prefix which is not in the compiler's default include file search path the header files won't be found when compiling applications. Attching a patch which corrects the pkg-config file for libvirt Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Fix to makefile for VPATH builds
by Daniel P. Berrange 24 Mar '06

24 Mar '06

The src/Makefile.am file use the incorrect variable for subsitution when setting up the INCLUDE variable. The result is that when attempting to do a VPATH build the directory ../../src/include is passed to the compiler instead of the desired ../../include directory. The result is that the virterror.h file will not be in the compiler's include path. Attaching a patch which fixes the Makefile variable setup Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

Réf. : Re: [Libvir] Libvir on Itanium ?
by jean-paul.pigache＠bull.net 17 Mar '06

17 Mar '06

Anthony, you are right, but this will be done in a few monthes. So I think it is worth having the Itanium support in mind now. Is there anything in the current version which could prevent it to be used on itanium ? Regards Jean-Paul Anthony Liguori <aliguori(a)us.ibm.com> Envoyé par : libvir-list-bounces(a)redhat.com 17/03/2006 18:15 Pour : jean-paul.pigache(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Libvir on Itanium ? jean-paul.pigache(a)bull.net wrote: > > Hello libvir developpers, > > libvir is certainly a good initiative that will facilitate the > administration of Xen. Could you tell if libvir can be used on Itanium > or is intended to be used on Itanium in the near future ? I don't see anything that would prevent libvirt from working on the Itanium. AFAIK, the Itanium Xen port is still under development and I don't think that all the domain management functionality is there (although I'm totally not sure). Regards, Anthony Liguori > Jean-Paul Pigache > ------------------------------------------------------------------------ > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[Libvir] Libvir on Itanium ?
by jean-paul.pigache＠bull.net 17 Mar '06

17 Mar '06

Hello libvir developpers, libvir is certainly a good initiative that will facilitate the administration of Xen. Could you tell if libvir can be used on Itanium or is intended to be used on Itanium in the near future ? Jean-Paul Pigache

2 1

[Libvir] Wiki?
by Anthony Liguori 11 Mar '06

11 Mar '06

Hi Daniel, What do you think about setting up a wiki for libvirt? I know there are a number of people (especially in the CIM community) interested in being able to request features/requirements from the API. A wiki is a pretty easy way to allow that sort of contribution. I also like using wiki's a lot for active design documents. Regards, Anthony Liguori

6 9

[Libvir] XML-RPC support for libvirt
by Anthony Liguori 11 Mar '06

11 Mar '06

Howdy, I'm about to checkin some XML-RPC code into CVS. The code I'm checking in won't compile by default (for now) as there's still a little work to do but I wanted to get something into the tree. Here are the tasks left: 1) Convert from dict to s-expressions to handle config returns. Right now, the Xend XML-RPC code returns S-Expressions in the form of a tuple. We just need a little code to convert from these tuples to struct sexpr's. 2) Integrate my unit tests. I've got a number of unit tests that stress the various bits of parsing code. I'd like to add a make check that runs these unit tests and a make fullcheck that runs these unit tests under valgrind. 3) Support XML-RPC over a domain socket. Right now I'm using nanohttp which doesn't appear to allow different transports. There is some HTTP PUT code already in the tree so I could use that if there isn't a more clever solution. 4) Plumb the xend backend functions to XML-RPC. This is really straight forward. It's just a matter of converting: int xend_pause(virConnectPtr xend, const char *name) { return xend_op(xend, name, "op", "pause", NULL); } To: int xend_pause(virConnectPtr xend, const char *name) { if (xend->xmlrpc) return xmlRpcCall(xend->xmlrpc, "xend.domain.pause", "", "s", name) else return xend_op(xend, name, "op", "pause", NULL); } Of course, using the xml-rpc code, we now have access to rich fault information. Xend never actually returns errors for things and instead throws exceptions. For the S-Expression/HTTP protocol, you just get a 501 and have to return a meaningless error. With XML-RPC, those exceptions are actually serialized and sent over the wire. We may want to explore how we can make that information available to the user. My current understanding, btw, is that the basic XML-RPC support for Xend is going into the tree sometime this week (Ewan is looking at the code now) and will be a part of the 3.0.2 release. This means that for the 3.0.3 cycle, we'll be defining a standard API. This process will be starting soon (within the next couple of weeks hopefully). Regards, Anthony Liguori

4 6

[Libvir] Questions about the future of libvirt
by David Anderson 06 Mar '06

06 Mar '06

Hi, I've spent the last few hours going over the code of libvirt, trying to work out how I could use it. As far as I can tell, there are a few things missing from it that I would need. I'm willing to submit the patches for these features, but I'd like a little guidance from the expert(s), to make sure I'm not missing something vital about the organization of libvirt. * Support for pure remote connections At the moment, virConnectOpen only supports connecting to a local hypervisor, and does so in three different ways (xenHypervisorOpen to get a local handle to the hypervisor, xs_daemon_open to get access to the XenStore, and xend_setup to connect to the running xend instance). For security reasons, the application I'm writing should run outside of dom0, which pretty much reduces the possible access paths to Xend via TCP. How much work would it be to alter the libvirt API to allow for pure remote connections? As far as I can tell, most if not all of the functions currently implemented can be called entirely through Xend, so it'd just be a matter of changing virConnectOpen to take a name argument and not opening the store/hypervisor connections when given a name like "http://dom0.whatever.net:8000/xend/". Once that is done, all functions need to be checked to verify that they all check the existence of the hypervisor/xenstore handle before trying to use them, and that they all have a gracious xend fallback if not. Am I missing something absolutely vital here? Hopefully I'm not, which leads me to... * Accessing and modifying the memory/vcpu settings for domains Currently, from the API you can change the maxmem parameter of a domain, but not the memory parameter. Also, access to the vcpu configuration is not at all implemented afaict. The memory parameter is a simple matter of adding the right public API to drive the xend_backend functions; for vcpu support, the xend_internal API would have to be extended, at least to feature the equivalent of xen.xend.XendClient.Xend.xen_domain_set_vcpus() in the legacy python API, so that clients can alter the number of vcpus allocated to a domain. Again, am I missing anything completely, hopelessly vital? :-) If I have not completely missed the point of libvirt, my intuition tells me I'll be submitting a lot more patches after these two, if things work out. Let me know if I'm on the right tracks, so that I can start hacking away :) Regards, - Dave.

3 12