- Devel - libvirt List Archives

[Libvir] RFC: requesting APIs for host physical resource discovery
by Daniel P. Berrange 29 Mar '06

29 Mar '06

The current libvirt APIs allow the host's physical resources to be split up and allocated to guest domains, however, there is no way to discover what the available host resources actually are. Thus I would like to suggest the inclusion of new APIs to enable host resource discovery. As a starting point I'd like to be able to query the following information: * Number of physical CPUs - ability to enumerate the CPUs in the host, both those currently present, and theoretical maximum (to take account of hotplug). * Amount of RAM - actual physical RAM present, and that available for guest usage (eg discounting that reserved by a hypervisor or equiv) * CPU relationship - ie ability to distinguish between CPUs which are hyperthread siblings, on same core, or on separate sockets Alonside these basic queries it would be desirable to add a further resource resource management API to allow for setting of a guest domain's CPU affinity. ie ability control what CPUs the VMM is allowed to schedule a domain on. Once this first basic set of caapbilties for resource discovery are provided for, then I believe it will be neccessary to provide some more advanced queries, in particular: * NUMA topology - ability to enumerate NUMA nodes, the CPUs associated with each node & the RAM range mapped to that node 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 -=|

3 3

[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