- Devel - libvirt List Archives

[Libvir] Proposal for new Libvirt functions about virtual CPUs
by michel.ponceau＠bull.net 26 Jun '06

26 Jun '06

1) Currently the NULL virDomainPtr (meaning Domain0) is only specified in the 3 virDomain*Memory functions (GetMax, SetMax, Set). The other virDomain* functions need the actual virDomainPtr for Domain0. What is the reason for this Memory-specific option? Is it applicable to virtual CPUs? 2) For "xm vcpu-list" equivalent function (suggested virDomainGetVcpus) I propose to return in a new structure all the information provided by Xen Daemon. I am trying the following addition in libvirt.h : typedef struct _virVcpuInfo virVcpuInfo; struct _virVcpuInfo { int number; /* virtual CPU number */ unsigned char state; /* 'r'=running, 'b'=blocked, 'p'=offline */ unsigned long long cpuTime; /* CPU time used, in nanoseconds */ int cpu; /* last real CPU number allocated */ char cpumap[128]; /* affinity map of real CPUs which can be allocated */ }; typedef virVcpuInfo *virVcpuInfoPtr; For cpumap, the xm command displays a string "x,y-z..." more compact than the list of all possible CPUs "x y y+1 y+2...z..." provided by xend. But the routines for this reformatting are not easy, so I propose to keep the xend format in virCpuInfo. What is your opinion? 3) For "xm vcpu-pin" equivalent function (suggested virDomainPinVcpu) I propose a CPU list argument in same format as virCpuInfo cpumap. Do you agree? Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Proposal for a new Libvirt function: change number of virtual CPUs On Fri, Jun 23, 2006 at 05:48:40PM +0200, michel.ponceau(a)bull.net wrote: > For our administration, we need to dynamically reduce the number of virtual > CPUs in each domain, in same way as Xen command "xm vcpu-set". It seems > that no Libvirt function is currently provided for that purpose. I > successfully tried some simple changes in libvirt.c an xend_internal.c, > mainly the following: > snprintf(buf, sizeof(buf), "%d", vcpus); > return xend_op(domain->conn, domain->name, "op", "set_vcpus", "vcpus", > buf, NULL); > We suggest to add this new function "virDomainSetVcpus" to Libvirt. Hum, let's see. We expose the number of virtual CPUs in the info structure so yes that's something which is part of what we expose. So that would be /** * virDomainSetVcpus: * @domain: a domain object or NULL * @nvcpus: the new number of virtual CPUs for this domain * * Dynamically change the number of virtual CPUs used by the domain. * Note that this call may fail if the underlying virtualization hypervisor * does not support it or if growing the number is arbitrary limited. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success and -1 in case of failure. */ int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) { } > I have not tried the hypervisor and xen store accesses for this function. > Do you think they would be necessary? It would be preferable to go though Xend first at least. I don't think xenstore is a good idea at this point. Now for the direct hypervisor, I'm uncertain, it could be a good idea to provide redundancy over xend, I assume it should not be hard to do that at the hypervisor level, the risk is introducing incoherence between what xend thinks and what the hypervisor atually implement :-) > I am also working on two other functions to reproduce "xm vcpu-pin" and "xm > vcpu-list" from Libvirt. vcpu-list might be a bit subtle as an API design level. Better not allocate the array in libvirt, but have the user pass an array. Also how much information would you extract per CPU, just on/off ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

3 4

[Libvir] Request for changing #include directives to conform to Linux standard
by Philippe Berthault 26 Jun '06

26 Jun '06

The 'virterror.h' file has an #include directive to "libvirt.h" which isn't correct because libvirt include files are installed on a sub-directory named 'libvirt'. i.e. when libvirt is compiled with configure --script=/usr, then libvirt files are installed in /usr/include/libvirt/.* To be standard with Linux usage of include files, the correct directive in virterror.h will be: #include <libvirt/libvirt.h> instead of: #include "libvirt.h" and in C/C++ source files using libvirt, there is just to include libvirt with: #include <libvirt/libvirt.h> #include <libvirt/virterror.h> This is conform to Linux usage of include files and this permit to simplify Makefile(s) because there is no need to add option -I/usr/include/libvirt to compile sources files. Regards.

2 2

[Libvir] Proposal for a new Libvirt function: change number of virtual CPUs
by michel.ponceau＠bull.net 23 Jun '06

23 Jun '06

For our administration, we need to dynamically reduce the number of virtual CPUs in each domain, in same way as Xen command "xm vcpu-set". It seems that no Libvirt function is currently provided for that purpose. I successfully tried some simple changes in libvirt.c an xend_internal.c, mainly the following: snprintf(buf, sizeof(buf), "%d", vcpus); return xend_op(domain->conn, domain->name, "op", "set_vcpus", "vcpus", buf, NULL); We suggest to add this new function "virDomainSetVcpus" to Libvirt. I have not tried the hypervisor and xen store accesses for this function. Do you think they would be necessary? I am also working on two other functions to reproduce "xm vcpu-pin" and "xm vcpu-list" from Libvirt.

2 1

[Libvir] libvirt documentation
by Philippe Berthault 23 Jun '06

23 Jun '06

You will find, joined with this mail, your libvirt v0.1.1 documentation in Windows CHM format which is very useful for users who have both Linux and Windows stations. Regards.

2 1

[Libvir] Release of libvir-0.1.1
by Daniel Veillard 21 Jun '06

21 Jun '06

I realized yesterday that Xen unstable changeset 10277 broke the hypervisor API on i686, which led to some interesting debugging and hopefully a clean solution for this problem. I think it is worth making a release then even if the 4 new APIs for defined but non-running domains are not complete (pending more information on Xend API changes). There is still some meat in this release. ftp://libvirt.org/libvirt/ One notable improvement is that it should be fairly simple to add support for new virtualization back-end now that the driver code has been cleaned up, the new test driver to do regression test from Daniel Berrange is a good example: * building fixes: - ncurses fallback (Jim Fehlig) - VPATH builds (Daniel P. Berrange) * driver cleanups: - new entry points - cleanup of libvirt.c (with Daniel P. Berrange) * Cope with API change introduced in Xen changeset 10277 * new test driver for regression checks (Daniel P. Berrange) * improvements: - added UUID to XML serialization - buffer usage (Karel Zak) - --connect argument to virsh (Daniel P. Berrange), * bug fixes: - uninitialized memory access in error reporting - S-Expr parsing (Jim Fehlig, Jeremy Katz) - virConnectOpen bug - remove a TODO in xs_internal.c * documentation: - Python examples (David Lutterkort) - new Perl binding URL - man page update (Karel Zak) thanks to everybody who helped with this release, with code, patches, bug reports, etc... Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] bug in the virSetErrorFunc() function
by Philippe Berthault 16 Jun '06

16 Jun '06

I've written a program based on libvirt (release 0.1.0) in which I uses the virSetErrorFunc() function to avoid messages on the screen but one message is always displayed (on stderr) and isn't trapped by the virSetErrorFunc() function. This message is "Unimplemented block at xs_internal.c:255" Thanks,

2 2

[Libvir] State of driver backend infrastructure
by Daniel P. Berrange 14 Jun '06

14 Jun '06

I'm looking to get more of the test driver backend working, and so decided it was time to audit the state of the driver backend infrastructure. There are a couple of areas which could do with some work: * Driver specific data. The virConnect & virDomain structs have explicit fields for Xen related data: virConnect: int handle; /* internal handle used for hypercall */ struct xs_handle *xshandle; /* handle to talk to the xenstore */ virDomain: int handle; /* internal handle for the domnain ID */ One idea for resolving this is to have an array of slots, one per drivers in which drivers can store data they need. void **handles Or perhaps, to allow simple int type too void union { int num; void *ptr } *handles * Connect URIs. The 'virDomainOpen' and 'virDomainOpenReadOnly' methods have an optional parameter 'name'. The Xen drivers currently ignore this, or expect it to be NULL / the string "Xen". For sake of back-compat we'll ned to preserve existing behaviour for NULL, but we should hook up URI parsing for the XenD backend to allow non local connections to work. This gives the question of what format should the URI be for Xen domains ? Although 'http://' is the protocol XenD uses, this isn't likely a good idea, because a later VMWare driver might also use a http based protocol. So, perhaps we should use generic URIs:? xend://somehost:port/ * Driver method hookup. The libvirt.c file has alot of methods which are either not hooked up to the driver backend, or hooked up, but still have duplicated (redundant?) Xen specific calls. Here is the complete status: virGetVersion: - Hardcodes support for Xen HV. No virConnectPtr handle, so how would we call out to driver backends ? virConnectOpen - OK virConnectOpenReadOnly - OK virConnectClose: - Does not call out to driver backends, simply free's struct virConnectGetType: - Does not call out to driver backends, hardcodes Xen HV virConnectGetVersion - Does not call out to driver backends, hardcodes Xen HV virConnectListDomains - Calls out to drivers, but also has duplicated code for XenD & XenStore virConnectNumOfDomains - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainCreateLinux - Does not call out to driver backends, hardcodes XenD virDomainLookupByID - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainLookupByUUID - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainLookupByUUIDString - OK (but delegates to virDomainLookupByUUID) virDomainLookupByName - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainDestroy - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainFree - Does not call out to driver backends, simply free's struct virDomainSuspend - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainResume - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainSave - Does not call out to driver backends, hardcodes XenD virDomainRestore - Does not call out to driver backends, hardcodes XenD virDomainShutdown - Does not call out to driver backends, hardcodes XenD virDomainReboot - Does not call out to driver backends, hardcodes XenD virDomainGetName - OK virDomainGetUUID - Does not call out to driver backends, hardcodes XenD virDomainGetUUIDString - OK (but delegates to virDomainGetUUID) virDomainGetOSType - Does not call out to driver backends, calls function in XenStore driver virDomainGetMaxMemory - Does not call out to driver backends, hardcodes XenD, Xen HV, XenStore virDomainSetMaxMemory - OK virDomainSetMemory - OK virDomainGetInfo - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainGetXMLDesc - Does not call out to driver backends, hardcodes XenD virNodeGetInfo - OK virDomainDefineXML - OK virDomainUndefineXML - OK virDomainListDefinedDomains - No implemented virDomainCreate - No implemented My immediate needs for testing, are to hook up more of the methods which aren't connected to the driver backends. 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 6

[Libvir] A question about libvirt usage
by Philippe Berthault 13 Jun '06

13 Jun '06

Is there a notion of session in libvirt ? In other words, is it possible, between virConnectOpen() and virConnectClose(), that some Xen domains will be started, stopped, destroyed, etc.. by another operator using the xm command ou by another binary command based on libvirt. If the response is yes, is it possible to introduce a global lock in Xen (or in libvirt ?) to avoid conflict between libvirt and xm command or between several libvirt based commands. Thanks, Philippe Berthault.

2 1

[Libvir] Patch to 'ping' XenD when opening connection
by Daniel P. Berrange 13 Jun '06

13 Jun '06

Currently the XenD driver's implementation of the 'open' method will return success, regardless of whether XenD is even present. The attached patch makes the open method do a 'ping' to see if XenD is actually there, returning failure if it is not. This ensures that the XenD driver backend doesn't get activated when connecting to alternate non-Xen backends, such as the test backend I committed last week. The current 'ping' is simply to call the xenDaemonGetVersion() method since that's a pretty simle & low-overhead way to testing livliness of XenD. Any suggestions for a better ping - if not I'll go ahead & commit this change 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 3

[Libvir] A 'mock' driver enabling application unit testing
by Daniel P. Berrange 06 Jun '06

06 Jun '06

The attached patch adds a new driver which provides a 'mock' hypervisor connection. The idea behind this is to provide a completely predictable and isolated hypervisor implementation, which will facilitate creation of unit tests in applications using libvirt. The code attached is not a complete implementation, providing support only for connecting, listing domains, getting a domain by id/uuid/name, getting domain info, getting node info. Further work will hook up methods for creating domains, exporting XML & the other various libvirt APIs. The driver is intended to operate as a black box, closed system - the only interaction an application will have is via the libVirt entry points. It starts off with a single domain present, and fixed node info, and updates domain CPU time based on elapsed wall clock time. When the domain create API is hooked up this will let apps create new dummy domains within the context of the process. As I said, I delibrately implemented this driver to only have process local state. When the process shuts down all state is discarded. This keeps application usage very simple. Longer term I think it would be useful to have a 2nd, dynamic, which would allow fault injection, cross-process interaction & more to allow advanced scripting of a test scenario. I don't have time to create such a driver myself though, so I stuck with the simplest possible impl which will allow 95% of application unit testing needs to be satisfied. To use this driver, simply pass 'TestSimple' as the name parameter to virConnectOpen / virConnectOpenReadonly instead of NULL. If you are using 'virsh' then my previous patch will let you call 'virsh --connect TestSimple' I've also tested this with the 'gnome-vm-applet' panel applet. The only problem I have found is that the 'xend_internal.c' driver will always return success from its 'xenDaemonOpen' method, regardless of whether there is actually a Xen Daemon present. So when using the test driver, every method will first try to ue the XenD driver impl, fail (printing an error message) and then go onto use the test driver. The xenDaemonOpen method really needs to be fixed to only succeed when Xen is actually present. Or perhaps it should only try to run when the 'name' passed to virConnectOpen is NULL or 'Xen' - ie be a no op if the name is 'TestSimple' / QEMU / any other driver implementation. I'm not sure whether we want to commit this to the libvirt codebae just, since there is a fair bit more work to be done to hook up additional methods. 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 4

[Libvir] Added 'domuuid' to virsh & --connect command lin arg
by Daniel P. Berrange 31 May '06

31 May '06

The attached patch makes two changes to the virsh command: * Adds a 'domuuid' command to display the printable UUID of a domain * Adds a '--connect NAME' argument allowing the name of a hypervisor to be passed through to 'virConnect' / 'virConnectReadOnly' Although libvirt only has a Xen backend at the moment, I'm working on a 'mock' hypervisor backend to enable unit testing of applications built on libvirt without requiring the test suite to interface with the real Xen hypervisor. 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 2

[Libvir] Connect up more internal driver methods
by Daniel P. Berrange 29 May '06

29 May '06

The attached patch connects up more of the internal driver methods, as the final step preparing for a minimally operational test driver. * src/hash.c, src/internal.h: Switch the uuid parameter in virGetDomain to be of type 'unsigned char' since its a raw UUID we're passing in, not a printable one. * src/libvirt.c: Remove bogus "unsigned char" -> "char" type casts. Hook up the "domainLookupByID", "domainLookupByUUID", "domainLookupByName" and "domainGetInfo" driver backend functions. 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] A few bug fix patches
by Daniel P. Berrange 29 May '06

29 May '06

Attached are two small bug fix patches: - libvirt-vpath.patch - fix test suite include path for VPATH builds - libvirt-symbols.patch - add some missing symbols to the libraries exported symbol table to make the python bindings work again 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] uuid string format
by Karel Zak 23 May '06

23 May '06

Hello, I've found that we use in our XML dump: <uuid>%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x</uuid> it's strange format of the UUID string representation. Is there any reason for this format? I think normal (rfc4122) is format: "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" it means with '-'. Karel -- Karel Zak <kzak(a)redhat.com>

3 3

[Libvir] BUG: virDomainLookupByID fails in libvirt-0.1.0
by Michel Gauthier 05 May '06

05 May '06

Hi, I tried to execute the info1 C code example on my redhat distribution with Xen installed. It fails due to the virDomainLookupByID API wich returns NULL. The problem seems to be in the internal function xenDaemonListDomains called after xs_get_domain_path inside the API. For the domain 0, xs_get_domain_path returns path=/local/domain/0. Then, the call to xenDaemonListDomains function logs the error message: "libvir: Xen Daemon error : could not connect to Xen Daemon" and returns names=NULL. A bug present in the release 0.0.6 has been fixed for the release 0.1.0. But this bug seems still present! Regards.

3 2

[Libvir] Re: support for hvm guests
by Jim Fehlig 04 May '06

04 May '06

>>>> Anthony Liguori <aliguori(a)us.ibm.com> 05/03/06 6:47 PM >>> > >>>> Currently I can get info on hvm domains but unable to create them. >>>> The create request is sent to xend but then blocks reading from xend >>>> in xend_req(). No problem creating the domain using xm. I have >>>> looked at the config coming into xend and it is identical between xm >>>> and virsh/libvirt. Need to poke around xend and see why there is no >>>> response to the virsh/libvirt create request for hvm domains. >>>> >>> >>> Hum, basically to debug this kind of things I spend my time in >>> /var/log/xend.log especially since it prints what it received at >>> creation >>> time, you can at least check the informations coming from libvirt and >>> from xm look alike. >>> Unfortunately I won't be able to help you, first because I'm about to >>> take vacations for 3 weeks :-), second because I don't have one of those >>> new Intel CPUs, but I am sure others will give an hand if needed. >>> >>> >> >> Well, I have found the problem but not a fix :-). When posting the >> create op to xend, the libvirt code currently waits for a response >> from xend (xend_req() is called after posting in xend_post()). For >> hvm guests, xend does not respond and libvirt blocks indefinitely on >> read. If I skip over the call to xend_req() for the create operation, >> wait_for_devices() and subsequently unpause() are called and the hvm >> guest is launched. > >What do you mean by Xend does not respond? I post a request such as: op=create&config=(vm%20(name%20'j_sles10b9_full')(memory%20512)(vcpus%201)(on_poweroff%20'destroy')(on_reboot%20'destroy')(on_crash%20'destroy')(image%20(hvm%20(kernel%20'/usr/lib/xen/boot/hvmloader')(device_model%20'/usr/lib/xen/bin/qemu-dm')(boot%20c)(sdl%201)(stdvga%201)(vcpus%201)))(device%20(vbd%20(dev%20'ioemu:hda')(uname%20'file:/var/lib/xen/images/j_sles10b9_full/hda')(mode%20'w')))(device%20(vif%20(mac%20'00:16:3e:b2:68:1d')(bridge%20'xenbr0')(script%20'vif-bridge')(type%20'ioemu')))) to xend from xend_post() in libvirt's xend_internal.c, which then expects to read a response from xend but it never arrives and blocks the read in libvirt. >Can you give me a very concrete test case for this? The exact >parameters being passed to domain_create() (it should just be an >S-Expression config). The sexpr is: (vm (name 'j_sles10b9_full')(memory 512)(vcpus 1)(on_poweroff 'destroy')(on_reboot 'destroy')(on_crash 'destroy')(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(device_model '/usr/lib/xen/bin/qemu-dm')(boot c)(sdl 1)(stdvga 1)(vcpus 1)))(device (vbd (dev 'ioemu:hda')(uname 'file:/var/lib/xen/images/j_sles10b9_full/hda')(mode 'w')))(device (vif (mac '00:16:3e:b2:68:1d')(bridge 'xenbr0')(script 'vif-bridge')(type 'ioemu')))) The url-encoded request sent from libvirt is also provided above. Below is the relevent content in xend.log. Thanks, Jim [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:180) XendDomainInfo.create(['vm', ['name', 'j_sles10b9_full'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['boot', 'c'], ['cdrom', '/tests/iso/SLES-10-i386-Beta9.iso'], ['sdl', '1'], ['stdvga', '1'], ['vcpus', '1']]], ['device', ['vbd', ['dev', 'ioemu:hda'], ['uname', 'file:/var/lib/xen/images/j_sles10b9_full/hda'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:b2:68:1d'], ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']]]]) [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:286) parseConfig: config is ['vm', ['name', 'j_sles10b9_full'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['boot', 'c'], ['cdrom', '/tests/iso/SLES-10-i386-Beta9.iso'], ['sdl', '1'], ['stdvga', '1'], ['vcpus', '1']]], ['device', ['vbd', ['dev', 'ioemu:hda'], ['uname', 'file:/var/lib/xen/images/j_sles10b9_full/hda'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:16:3e:b2:68:1d'], ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']]]] [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:382) parseConfig: result is {'ssidref': None, 'uuid': None, 'on_crash': 'destroy', 'on_reboot': 'destroy', 'localtime': None, 'image': ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['boot', 'c'], ['cdrom', '/tests/iso/SLES-10-i386-Beta9.iso'], ['sdl', '1'], ['stdvga', '1'], ['vcpus', '1']], 'on_poweroff': 'destroy', 'cpus': None, 'name': 'j_sles10b9_full', 'backend': [], 'cpu': None, 'vcpus': 1, 'cpu_weight': None, 'vcpu_avail': None, 'memory': 512, 'device': [('vbd', ['vbd', ['dev', 'ioemu:hda'], ['uname', 'file:/var/lib/xen/images/j_sles10b9_full/hda'], ['mode', 'w']]), ('vif', ['vif', ['mac', '00:16:3e:b2:68:1d'], ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']])], 'bootloader': None, 'root': None, 'bootentry': None, 'maxmem': 512} [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:1189) XendDomainInfo.construct: None 0 [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:1221) XendDomainInfo.initDomain: 29 1.0 [2006-05-02 10:58:13 xend] DEBUG (image:266) args: cdrom, val: /tests/iso/SLES-10-i386-Beta9.iso [2006-05-02 10:58:13 xend] DEBUG (image:266) args: boot, val: c [2006-05-02 10:58:13 xend] DEBUG (image:266) args: fda, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: fdb, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: nic-ne2000, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: enable-audio, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: localtime, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: serial, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: std-vga, val: 1 [2006-05-02 10:58:13 xend] DEBUG (image:266) args: isa, val: None [2006-05-02 10:58:13 xend] DEBUG (image:266) args: vcpus, val: 1 [2006-05-02 10:58:13 xend] DEBUG (balloon:177) Balloon: free 2267; need 518; done. [2006-05-02 10:58:13 xend] INFO (image:135) buildDomain os=hvm dom=29 vcpus=1 [2006-05-02 10:58:13 xend] DEBUG (image:224) dom = 29 [2006-05-02 10:58:13 xend] DEBUG (image:225) image = /usr/lib/xen/boot/hvmloader [2006-05-02 10:58:13 xend] DEBUG (image:226) store_evtchn = 1 [2006-05-02 10:58:13 xend] DEBUG (image:227) memsize = 512 [2006-05-02 10:58:13 xend] DEBUG (image:228) vcpus = 1 [2006-05-02 10:58:13 xend] DEBUG (image:229) pae = 0 [2006-05-02 10:58:13 xend] DEBUG (image:230) acpi = 0 [2006-05-02 10:58:13 xend] DEBUG (image:231) apic = 0 [2006-05-02 10:58:13 xend] DEBUG (image:409) hvm shutdown watch registered [2006-05-02 10:58:13 xend] DEBUG (blkif:24) exception looking up device number for hda: [Errno 2] No such file or directory: '/dev/hda' [2006-05-02 10:58:13 xend] DEBUG (DevController:103) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vbd/29/768'} to /local/domain/29/device/vbd/768. [2006-05-02 10:58:13 xend] DEBUG (DevController:105) DevController: writing {'domain': 'j_sles10b9_full', 'frontend': '/local/domain/29/device/vbd/768', 'dev': 'ioemu:hda', 'state': '1', 'params': '/var/lib/xen/images/j_sles10b9_full/hda', 'mode': 'w', 'frontend-id': '29', 'type': 'file'} to /local/domain/0/backend/vbd/29/768. [2006-05-02 10:58:13 xend] DEBUG (DevController:103) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vif/29/0'} to /local/domain/29/device/vif/0. [2006-05-02 10:58:13 xend] DEBUG (DevController:105) DevController: writing {'bridge': 'xenbr0', 'domain': 'j_sles10b9_full', 'handle': '0', 'script': '/etc/xen/scripts/vif-bridge', 'state': '1', 'frontend': '/local/domain/29/device/vif/0', 'mac': '00:16:3e:b2:68:1d', 'frontend-id': '29', 'type': 'ioemu'} to /local/domain/0/backend/vif/29/0. [2006-05-02 10:58:13 xend] INFO (image:355) spawning device models: /usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '29', '-m', '512', '-cdrom', '/tests/iso/SLES-10-i386-Beta9.iso', '-boot', 'c', '-std-vga', '-vcpus', '1', '-domain-name', 'j_sles10b9_full', '-hda', '/var/lib/xen/images/j_sles10b9_full/hda', '-macaddr', '00:16:3e:b2:68:1d', '-bridge', 'xenbr0', '-nics', '1'] [2006-05-02 10:58:13 xend] INFO (image:357) device model pid: 3496 [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:675) Storing VM details: {'ssidref': '0', 'uuid': 'a3fc6694-3959-b4bf-85b3-0364c231c504', 'on_reboot': 'destroy', 'start_time': '1146589093.41', 'on_poweroff': 'destroy', 'name': 'j_sles10b9_full', 'vcpus': '1', 'vcpu_avail': '1', 'memory': '512', 'on_crash': 'destroy', 'image': '(hvm (kernel /usr/lib/xen/boot/hvmloader) (device_model /usr/lib/xen/bin/qemu-dm) (boot c) (cdrom /tests/iso/SLES-10-i386-Beta9.iso) (sdl 1) (stdvga 1) (vcpus 1))', 'maxmem': '512'} [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:700) Storing domain details: {'console/port': '2', 'name': 'j_sles10b9_full', 'console/limit': '1048576', 'vm': '/vm/a3fc6694-3959-b4bf-85b3-0364c231c504', 'domid': '29', 'cpu/0/availability': 'online', 'memory/target': '524288', 'store/ring-ref': '682307', 'store/port': '1'} [2006-05-02 10:58:13 xend] DEBUG (image:432) hvm_shutdown fired, shutdown reason=None [2006-05-02 10:58:13 xend.XendDomainInfo] DEBUG (XendDomainInfo:881) XendDomainInfo.handleShutdownWatch

1 0

Re: [Libvir] Request for additional entry points
by Bret McMillan 27 Apr '06

27 Apr '06

On Thu, 2006-04-13 at 12:00 -0400, libvir-list-request(a)redhat.com wrote: > We've discussed this before and I think the most compelling argument for > passive domain support in libvirt (and even at a lower level such as > Xend) is the following scenario: > > Let's say a user creates a virtual FC6 virtual machine that she is going > to use to test her apps under Gnome (she's a KDE user). The machine > isn't always there b/c she rarely needs it. She created it with some > nifty KDE tool that has yet to be written. > > Of course, she finds out about this neat applet that you can use to > managing running domains. If there isn't a common way of accessing > passive domains then she won't see the FC6 VM. > > Now, I don't think that *all* domains should have to have passive > equivalents (which is a requirement in the CIM provider today) because > of some of the scenarios you outlined. However, I think not attempting > to have a common API for passive domains is going to creative a mess as > we get a larger number of management tools. I think we're confusing the notion of what a passive domain is with what config files happen to be sitting on / exposed to the dom0 machine. I could very easily look at having an rdbms store the info about the passive domain, hand that down to the dom0 via rpc, and directly call the createLinux call. To me, that's still a passive domain, even though it's configs haven't touched disk yet. I guess I'm also struggling to understand why you'd toss this into xenstore... it just seems this is a higher level concept that needs to be tracked in too specific a way by management systems. --Bret

6 12

[Libvir] Perl API for using libvirt
by Daniel P. Berrange 26 Apr '06

26 Apr '06

Hi Folks, I had a couple of hours spare, so I put together a set of Perl bindings for libvirt. I'm currently calling the module Sys::Virt which seems to be the most appropriate location in the CPAN namespace, but I'm open to suggestions if people think that sucks. I've currently got near 100% coverage of the C APIs, but not exposed all the static constants yet. There are a couple of trivial example programs illustrating use of the API for extracting info about domains.=20 For now you can grab a snapshot of the source for the binding using=20 Mercurial from the URL: http://hg.berrange.com/libraries/sys-virt When I've tested it more completely I'll upload it to CPAN 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 3

RE: [Libvir] Problems installing libvir
by Subrahmanian, Raj 25 Apr '06

25 Apr '06

Daniel, This was more of a hurried hack just changing all curses to ncurses :-) I know it's no excuse, but I was in a hurry to start linking to libvirt. I will work on a cleaner change to configure.in and forward it to you later today? Thanks Raj PS. Didn't Jim Fehlig mention that he has already fixed this? -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com] Sent: Tuesday, April 25, 2006 4:06 AM To: Subrahmanian, Raj Cc: libvir-list(a)redhat.com Subject: Re: [Libvir] Problems installing libvir On Mon, Apr 24, 2006 at 09:25:45PM -0400, Subrahmanian, Raj wrote: > > ncurses vs. curses ? > Ohh, and I was looking right at it! > Sorry folks. > I hacked the configure file to look for ncurses and sure enough it > worked. Can you send the diff you made to configure.in so we can fix configure to work with both libraries ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

3 2

RE: [Libvir] Problems installing libvir
by Subrahmanian, Raj 25 Apr '06

25 Apr '06

> ncurses vs. curses ? Ohh, and I was looking right at it! Sorry folks. I hacked the configure file to look for ncurses and sure enough it worked. Thanks for the help. Raj

3 3

[Libvir] Re: [Xen-cim] LTC provider working on SLES/openwbem
by Jim Fehlig 25 Apr '06

25 Apr '06

Daniel Veillard wrote: >On Thu, Apr 20, 2006 at 04:24:28PM -0600, Jim Fehlig wrote: > > >>FYI, >> >>I have managed to get one of the LTC providers (Xen_ComputerSystem) >>working on SLES using openwbem cimom, the xm shim, and libvirt. The >>following changes were made: >> >>libvirt >>- changed xend_parse_sexp_desc() to not fail if kernel not found. sexp >>from xend does not contain kernel for domain 0. >> >> > > Makes sense, could you send that patch ? > > thanks, > >Daniel > > Attached. Jim

2 1

[Libvir] Problems installing libvir
by Subrahmanian, Raj 25 Apr '06

25 Apr '06

All, I am trying to install libvir on my SUSE box. The .configure command halts with the following message. ibxml2 xml2-config ... yes ('') checking for initscr in -lcurses... no configure: error: curses library not found But, I have installed curses, and cdk. linux:~/xen/libvirt-0.1.0 # whereis curses curses: /usr/include/curses.h /usr/include/curses What am I missing out here? thanks Raj

4 3

[Libvir] FC5 bug with kernel/initrd paths
by Daniel Hiltgen 21 Apr '06

21 Apr '06

I just started experimenting with libvirt on FC5 and ran into something that doesn't seem quite right. I've created a VM using the xenguest-install.py script. I've tried grabbing the XML from virsh using dumpxml, but the kernel and initrd paths are invalid. Specifically: ... <os> <type>linux</type> <kernel>/var/lib/xen/vmlinuz.276riA</kernel> <initrd>/var/lib/xen/initrd.z1bslj</initrd> <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline> </os> ... (I see the same bogus paths in xm list --long) If I shut down the VM and attempt to power it back on using the API and this XML definition, it fails with: libvir: Xen Daemon error : POST operation failed: No such domain guest1i Failed to get devices for domain guest1 error: Failed to create domain If I boot up the VM, and copy the kernel and initrd image out of it's /boot partition onto the main filesystem, and tweak the XML to point to those paths, I can boot the system through libvirt, but the files are automatically deleted after I boot. Also, every time I boot using xm create, I get a different bogus kernel/initrd path. Is this expected behavior, or is there a bug/mismatch between libvirt and the underlying Xen modules in FC5? Thanks, Daniel

2 1

[Libvir] Add a timestamp to virDomainInfo ?
by Daniel P. Berrange 19 Apr '06

19 Apr '06

The primary use of the virDomainInfo data is in calculating resource utilization over time. The CPU runtime data, however, is represented as a counter, so to calulate utilization requires some transformations. Basically subtract the CPU runtime value for time X, from the value at time Y, and divide the result by Y-X. Obviously this requires us to know the times X & Y. Currently the virDomainInfo structure does not contain this information though, so apps have to call something like gettimeofday() before virDomainGetInfo(), to record the timestamp of each virDomainInfo record. The problem is that this is a pretty poor approximation - particularly if libvirt is talking via XenD, a non-trivial period of time can pass between the call to gettimeofday() and the values for virDomainInfo actually sampled. Thus I would like to suggest that the virtDomainInfo structure be expanded to add an extra data field of type 'struct timeval' to record a high resolution timestamp. Now currently this wouldn't help accuracy all that much, since libvirt would still be filling this in much the same way as the app did. It does however, open the door to having Xen itself provide an accurate timestamp back to libvirt, which would in turn benefit apps without requiring further code change. 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 6

[Libvir] libvirt.org is down
by Daniel Veillard 18 Apr '06

18 Apr '06

I will try to get it restarted tomorrow morning, sorry for the annoyance. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Request for additional entry points
by Jim Fehlig 13 Apr '06

13 Apr '06

As discussed on the xen-cim call on 3/31, the Xen CIM provider needs some additional entry points in libvirt. I would like to open a discussion about adding the following entry points to libvirt. virDomainSetConfig(virConnectPtr conn, const char *xmlDesc) Stores the domU config data in xenstore. The domU is not running yet but enumerating domains would return the config for the domain as well as any running domains. This would support the notion of a defined but inactive virtual machine. Daniel noted that the config could be cached in libvirt, preventing (to some degree) modifying the config out-of-band prior to activating the domain. Note that the current virConnectListDomains() implies enumerating only running domains since a list of domain IDs is returned. Perhaps virConnectListDomains() will have to be expanded to include defined domains or another entry point to enumerate defined domains. Related would be activating a defined domain. Would clients get the domain config (via virDomainGetXMLDesc()) and subsequently pass it to virDomainCreateLinux() or another entry point to create a defined domain? virDomainDeleteConfig(virConnectPtr conn, const char *name) Removed domU config from xenstore (or cache). DomU no longer "exists". What if domain is active upon invocation? virDomainSetCurrentMemory(virDomainPtr domain, unsigned long memory) Adjust the current memory usage for a domain. virDomainReboot(virDomainPtr domain) Reboot the domain. virDomainMigrate(virDomainPtr domain, const char *host) ?? Not sure what can of worms might be opened by this one :-). Thoughts? BTW, I can certainly help with the effort if an agreement is reached on adding this functionality. Regards, Jim

7 14

[Libvir] man page for virsh
by andrew puch 11 Apr '06

11 Apr '06

Enclosed is the man and the html page that were generated from POD Plain Old Doc from perl. pod2man virsh.pod.1 > virsh.1 pod2html virsh.pod.1 > virsh.html Behold the power of perl :)

3 3

[Libvir] autogen.sh error
by Ronald Aigner 10 Apr '06

10 Apr '06

Hi all, I downloaded libvirt from CVS and tried to run autogen.sh which stops with the following error message: configure: error: Xen store library not found What else do I need? How do I implement support for another hypervisor? Where do I have to turn which screws? Thanks, Ron.

2 4

[Libvir] Release of libvirt-0.1.0
by Daniel Veillard 10 Apr '06

10 Apr '06

I mostly finished the big internal code revamp over the week-end, this with the addition of the latest contributions makes it a good time for a new release, I also bumped up the medium release numbers, with the cleanup in the code internals I feel better now having people relying on libvirt, and while we are still far away from an 1.0.0 release, it's important to indicate the change :-) Available at the usual place i.e. ftp://libvirt.org/libvirt/ * building fixes: - --with-xen-distdir option (Ronald Aigner) - out of tree build and pkginfo cflag fix (Daniel Berrange) * enhancement and fixes of the XML description format (David Lutterkort and Jim Fehlig) * new APIs: - for Node information - Reboot * internal code cleanup: - refactoring internals into a driver model - more error handling - structure sharing - thread safety and ref counting * bug fixes: - error message (Jim Meyering) - error allocation in virsh (Jim Meyering) - virDomainLookupByID (Jim Fehlig) * documentation: - updates on architecture, and formatr - typo fix (Jim Meyering) * bindings: - exception handling in examples (Jim Meyering) - perl ones out of tree (Daniel Berrange) * virsh: - more options, create, nodeinfo (Karel Zak) - renaming of some options (Karel Zak) - use stderr only for errors (Karel Zak) - man page (Andrew Puch) Thanks to everybody who contributed to this release ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Re: virsh outputs to stderr(?!) why not stdout
by Karel Zak 06 Apr '06

06 Apr '06

On Thu, Apr 06, 2006 at 08:40:17AM -0400, Daniel Veillard wrote: > On Thu, Apr 06, 2006 at 02:37:37PM +0200, Karel Zak wrote: > > On Thu, Apr 06, 2006 at 11:46:57AM +0200, Jim Meyering wrote: > > > So, now I can use something like this to get a list of domain names: > > > > > > virsh list | tail -n +4 | awk '{print $2}' > > > > > > Is there some easier way? > > > > I think we can add some options to the list command: > > > > --noheader > > --nodom0 > > --cols=name,id,state,maxmem,usemem,.... > > > > without these options it will use default (current) format. I've > > already thought about this solution for the others commands (e.g. > > dominfo). I think this is a way how make it useful in scripts. > > Hum, why not discussing this on the libvir list ? Others may have > soem ideas too and this may promote virsh usage a bit ;-) Fixed :-) -- Karel Zak <kzak(a)redhat.com>

2 3

Re: [Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
by Jim Fehlig 05 Apr '06

05 Apr '06

>>> "Bryan D. Payne" <bryan(a)thepaynes.cc> 04/04/06 6:23 PM >>> >> I'm just not seeing it included in path returned by >> xs_get_domain_path(), only see /local/domain/<num> > For what it's worth, I was trying to put a patch together for this, >but I kept getting memory corruption errors. I was trying to access >the name through the xenstore as shown below... > > /* lookup is easier with the Xen store so try it first */ > if (conn->xshandle != NULL) { > char *namepath = NULL; > path = xs_get_domain_path(conn->xshandle, (unsigned int) id); > namepath = strdup(path); > strcat(namepath, "/name"); > name = xs_read(conn->xshandle, NULL, namepath, NULL); > if (namepath) free(namepath); > } My brain is not working today :-). Don't know why I didn't consider xs_read(). I'll fix up your patch and test/submit it tomorrow. I think the only problem is concatenating "/name" on the end of namepath, which has only been allocated enough memory to hold path via strdup(). Thanks, Jim

2 1

[Libvir] BUG: virDomainLookupByID fails after XenStore path discovery
by Bryan D. Payne 05 Apr '06

05 Apr '06

I just updated to the latest CVS version of libvir. It looks like there's a bug in virDomainLookupByID. The behavior that I'm seeing is that the path variable is set and so the code never enters the block to find the value for name. Therefore, at the end of the function, the condition (ret->name == NULL) is true and it jumps into the error code and returns NULL. If I comment out the code that sets the path variable, things seem to work normally. Although, I presume that the idea was to extract the name from the path information... -bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org

3 5

[Libvir] Change of server
by Daniel Veillard 03 Apr '06

03 Apr '06

So far libvirt.org was hosted on my home server (IP 82.67.66.12), but I really needed to fix this as my home ADSL connectivity isn't that great. I moved all services to a new server (colocated on the same box as xmlsoft.org in a public research institute here in France), hopefully the transition to this new server (IP 194.199.20.115) will be transparent as DNS changes propagates, but some of you mays still access the old services for a little while. Tell me if you experience troubles with the new server, and if you don't see updates from libvirt.org CVS that may be related still using the old server. Hopefully bandwidth and relibaility should be quite higher now, thanks, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Patch to make reading of HTTP response more efficient
by Daniel P. Berrange 30 Mar '06

30 Mar '06

When processing the header of HTTP responses from Xend, libvirt currently reads data a single byte at a time. Since its using lowlevel UNIX read() function there is no buffering, which results in a large number of system calls. The attached patch re-factors the code so that it reads data in 4k chunks whenever possible. Since most rsponses are < 4k in size processing the response now only takes two read() syscalls, rather than several hundred. Of course most (90%) of the CPU overhead is still on the Xend/XenStored end of the channel, but that's out of our control until the XML-RPC API comes along. 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] unchecked `malloc' calls
by Jim Meyering 30 Mar '06

30 Mar '06

Hello, In browsing through the code, I noticed that there are many places in which the code doesn't check for malloc returning NULL. E.g., ./virsh.c: ids = malloc(sizeof(int) * maxid); ./virsh.c- virConnectListDomains(ctl->conn, &ids[0], maxid); ./virsh.c: *res = malloc(sz + 1); ./virsh.c- memcpy(*res, tkstr, sz); ./virsh.c: res = malloc(strlen(name) + 3); ./virsh.c- sprintf(res, "--%s", name); ./xmlrpc.c: buf = malloc(sizeof(*buf)); ./xmlrpc.c- buf->size = 1024; ./xmlrpc.c: xmlRpcValueDictElementPtr ret = malloc(sizeof(*ret)); ./xmlrpc.c- xmlNodePtr cur; ./xmlrpc.c- ./xmlrpc.c- memset(ret, 0, sizeof(*ret)); At first, seeing so many, I thought there must be a wrapper that handles the case of a NULL return value. But there are many places where the code *does* check for NULL. This may be a clue. Maybe it's planned... ./libvirt.c: * TODO: ... ./libvirt.c: * - memory wrappers for malloc/free ? Jim

3 3

[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

[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

[Libvir] suspend/resume == pause/unpause?
by Diwaker Gupta 05 Mar '06

05 Mar '06

'xm' uses pause/unpause. libvirt uses suspend/resume. It seems they are the same. IMHO this should be made explicit in the documentation (I'm looking at the python help for libvirt). Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

3 3

[Libvir] Simple python examples
by David Lutterkort 04 Mar '06

04 Mar '06

Attached are a few simple python scripts that might be nice to add to CVS as examples on using the python API for libvirt. The examples also contain some XML files that describe domains; obviously users will have to modify them. David

2 1

[Libvir] [PATCH] Virtual block devices
by David Lutterkort 04 Mar '06

04 Mar '06

Because of a small typo in virDomainParseXMLDiskDesc, domU's can't receive virtual block devices from dom0. Patch to fix this is attached. David

2 1

[Libvir] Minimal specfile addition
by David Lutterkort 04 Mar '06

04 Mar '06

I just tried to rebuild the libvirt RPM on a rawhide box; the specfile is missing a BuildRequires for readline-devel (and probably a Requires for readline). Trivial patch attached. David

2 1

[Libvir] virDomainKernelPtr
by Bryan D. Payne 02 Mar '06

02 Mar '06

I noticed that there's a struct virDomainKernel in libvirt.h, but there aren't any functions that populate the struct yet. Could anyone comment on how close such a function is to becoming available. If it's underway, great :-) Otherwise, would the developers be interested in someone else working on a patch? -bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org

2 2

[Libvir] Release of libvirt-0.0.6
by Daniel Veillard 28 Feb '06

28 Feb '06

This release focuses on error handling. There are new APIs defined in <virterror.h> defining synchronous and asynchronous error access, I augmented the docs, and fixed a few minor bugs. I din't had time to extend the XML format with various thing requested like uuid but hopefully that will be in next release: * add error handling APIs both synchronous and asynchronous * added minimal hook for error handling at the python level, improved the python bindings * augment the documentation and tests to cover error handling See http://libvirt.org/errors.html and http://libvir.org/html/libvirt-virterror.html for more informations, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 1

[Libvir] IP address and MAC info in XMLDesc
by Diwaker Gupta 28 Feb '06

28 Feb '06

Are there plans to include IP address and MAC info in XMLDesc? I'm interested because I would like to move to libvirt for VM management, but currently my scripts use a lot of options in 'xm create' that are not yet supported by libvirt. Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

2 3

[Libvir] Report UUID in XMLDesc
by Diwaker Gupta 26 Feb '06

26 Feb '06

Since we have a lookupByUUID() method, I thought it would be nice to report UUID in XMLDesc as well. It could be ignored while creating a VM, just like the 'id' attribute is currently ignored. What do people think about this? Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

2 1

[Libvir] xmldump doesn't work
by Diwaker Gupta 24 Feb '06

24 Feb '06

Hi, I'm running libvirt from CVS. I'm unable to get xmldump to work: o virsh dumpxml <domain-id> doesn't work. Neither does <domain-name> instead of domain-id. (Aside: the documentation at http://libvirt.org/format.html needs fixing -- virsh reports a dumpxml command, but no xmldump command) o I can't get an XML dump from the Python bindings either. Looking at the code, it seems the XML description is built using the sexpr output from xend. On my machine, "xm list -l <domain-id>" prints out the correct sexpr, so it seems Xend is working fine. Am I missing something? Thanks, Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

3 6

[Libvir] devhelp missing
by Diwaker Gupta 24 Feb '06

24 Feb '06

After the latest pull tonight, I'm getting errors regarding a missing docs/devhelp/Makefile. Just FYI Diwaker PS: since the website has moved to libvirt.org, and the library is being called libvirt, perhaps its a better idea to rename the mailing list as well to libvirt-list? -- Web/Blog/Gallery: http://floatingsun.net/blog

2 2

[Libvir] Release of libvirt-0.0.5
by Daniel Veillard 23 Feb '06

23 Feb '06

This one has more substance: - adds an implementation of the virDomainCreateLinux() based on an XML description - adds 2 APIs to lookup by UUID and retrieving the UUID of a domain - augments the Python bindings accordingly - also add docs and examples - adds some regression test and a few bug fixes Availble from ftp://libvirt.org/ and hopefully soon in Fedora Core 5. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] libver-python fix & test script
by Angus Thomas 10 Feb '06

10 Feb '06

Against the current CVS version, the python method libvir.open() is failing because it requires "name" as a parameter, but in src/libvir.c, virConnectOpen returns NULL if name is set. Very simple patch attached. Also attached is a simple script to test reporting of domain state via the python bindings. Hopefully useful as a test of the python bindings/simple example of how to use them. It generates output like this: [root@chaka ~]# ./libver-python-test Attached to a hypervisor of type - Xen There are currently 2 domains running Domain ID 0 is named Domain-0 State is Running maxMem is -4 memory is 262224 nrVirtCpu is 1 cpuTime is 2294771524162 Domain ID 2 is named guest1 State is Blocked maxMem is 131072 memory is 131052 nrVirtCpu is 1 cpuTime is 34682760385 --- libvir-pristine/src/libvir.c 2006-01-27 08:59:42.000000000 +0000 +++ libvir-0.0.2/src/libvir.c 2006-02-07 12:59:17.000000000 +0000 @@ -89,8 +89,8 @@ struct xs_handle *xshandle = NULL; /* we can only talk to the local Xen supervisor ATM */ - if (name != NULL) - return(NULL); +/* if (name != NULL) + return(NULL); */ handle = xenHypervisorOpen(); if (handle == -1) #!/usr/bin/env python # # Simple script to test libver-python reporting # # Copyright 2005-2006 Red Hat, Inc. # Angus Thomas <athomas(a)redhat.com> # # This software may be freely redistributed under the terms of the GNU # general public license. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. domain_states="No State", "Running", "Blocked", "Paused", "Shutdown", "Shutoff", "Crashed" import libvir virt=libvir.open("Xen"); print ("Attached to a hypervisor of type - %s" % (virt.getType())); print ("There are currently %s domains running" % (virt.numOfDomains())); id_list=virt.listDomainsID(); for dom_id in id_list: dom=virt.lookupByID(dom_id); print ("\nDomain ID %s is named %s" % (dom_id, dom.name())); dom_info=dom.info(); # print ("\tState is %s" % (dom_info[0])); print ("\tState is %s" % (domain_states[dom_info[0]])); print ("\tmaxMem is %s" % (dom_info[1])); print ("\tmemory is %s" % (dom_info[2])); print ("\tnrVirtCpu is %s" % (dom_info[3])); print ("\tcpuTime is %s" % (dom_info[4]));

2 1

[Libvir] Release of libvirt-0.0.4
by Daniel Veillard 10 Feb '06

10 Feb '06

Change of name, it's now libvirt due to negative feedback on the shorter name, but I don't intend to change the mailing-list name at this point. There was an intermediary libvirt-0.0.3 release but it was too broken I needed to rerelease. Except the change of names, it mostly consists of a couple of bug fixes and completion of the python bindings. Available at ftp://libvirt.org/libvirt/ The CVS checkouts should still be working, the update is just a bit intrusive, and I fixed the hourly snapshot from CVS generation which broke in december. Sorry for the mess ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

Re: [Libvir] Errors while running make
by dasari dakshina 02 Feb '06

02 Feb '06

Hello, I have tried writing a simple program. I have compiled it with cc xmlist.c -L /usr/src/redhat/BUILD/libvir-0.0.1/src/.libs -lvir -o xmlist But am getting an error on trying after the virConnectOpen call . Any help would be appreciated . Rgds, Dakshina Here is the code :xmlist.c #include <stdio.h> #include <libvir.h> main(){ virConnectPtr conn; int *domids ; int maxids = 20; int numDoms=-1; conn=virConnectOpen(""); if(conn == NULL){ printf("Error : Could not open a connection \n"); return(-1); } numDoms=virConnectListDomains(conn,domids,maxids); printf("The number of domains %d\n",numDoms); printf("The number of domains %d\n", virConnectNumOfDomains(conn)); } cc xmlist.c -L /usr/src/redhat/BUILD/libvir-0.0.1/src/.libs -lvir -o xmlist Daniel Veillard <veillard(a)redhat.com> wrote: On Tue, Jan 24, 2006 at 08:46:07PM -0800, dasari dakshina wrote: > Hello Daniel, > Thanks so much for the info .I downloaded the Xen > 3 source and was able to compile without any issues. > Is there any link where I can look at simple examples > of the API usage ? not yet, check http://libvir.org/html/libvir-libvir.html Please keep discussion on the list, thanks, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ --------------------------------- What are the most popular cars? Find out at Yahoo! Autos

2 5

[Libvir] Release of libvir 0.0.2
by Daniel Veillard 29 Jan '06

29 Jan '06

A new release is availble on libvir.org: The main change is the mode of operation for most function, now going though Xend HTTP remote procedure calls instead of hypervisor and xenstore operations. * Update of the documentation, web site redesign (Diana Fong) * integration of HTTP xend RPC based on libxend by Anthony Liquori * Adding Save and Restore APIs * extended the virsh command line tool (Karel Zak) * remove xenstore transactions (Anthony Liguori) * fix the Python bindings bug when domain and connections where freed Enjoy ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] [PATCH] Remove XenStore transactions
by Anthony Liguori 27 Jan '06

27 Jan '06

XenStore transactions aren't actually needed for our current uses of XenStore. Moreover, the type of transactions changed recently from an opaque pointer to an integer type. This breaks the build for newer changesets. The change also introduced an XBT_NULL type but instead of using that (which would break older builds), we can just pass 0. Regards, Anthony Liguori # HG changeset patch # User Anthony Liguori <anthony(a)codemonkey.ws> # Node ID 9fe0c1f3379e06054ff66a572daad59bbfac3292 # Parent c028398d53b98baf08eb97192d599fbd311e3dd1 Remove transactions as the type has changed recently breaking the build and more importantly they aren't actually needed here. diff -r c028398d53b9 -r 9fe0c1f3379e src/libvir.c --- a/src/libvir.c Thu Jan 26 18:11:32 2006 +0000 +++ b/src/libvir.c Thu Jan 26 17:27:36 2006 -0500 @@ -307,7 +307,6 @@ */ int virConnectListDomains(virConnectPtr conn, int *ids, int maxids) { - struct xs_transaction_handle* t = NULL; int ret = -1; unsigned int num, i; long id; @@ -330,11 +329,7 @@ goto done; } if (conn->xshandle != NULL) { - t = xs_transaction_start(conn->xshandle); - if (t == NULL) - goto done; - - idlist = xs_directory(conn->xshandle, t, "/local/domain", &num); + idlist = xs_directory(conn->xshandle, 0, "/local/domain", &num); if (idlist == NULL) goto done; @@ -351,8 +346,6 @@ } done: - if ((t != NULL) && (conn->xshandle != NULL)) - xs_transaction_end(conn->xshandle, t, 0); if (idlist != NULL) free(idlist); @@ -369,7 +362,6 @@ */ int virConnectNumOfDomains(virConnectPtr conn) { - struct xs_transaction_handle* t; int ret = -1; unsigned int num; char **idlist = NULL; @@ -391,14 +383,10 @@ } } else if (conn->xshandle != NULL) { - t = xs_transaction_start(conn->xshandle); - if (t) { - idlist = xs_directory(conn->xshandle, t, "/local/domain", &num); - if (idlist) { - free(idlist); - ret = num; - } - xs_transaction_end(conn->xshandle, t, 0); + idlist = xs_directory(conn->xshandle, 0, "/local/domain", &num); + if (idlist) { + free(idlist); + ret = num; } } return(ret); @@ -445,23 +433,11 @@ */ static char ** virConnectDoStoreList(virConnectPtr conn, const char *path, unsigned int *nb) { - struct xs_transaction_handle* t; - char **ret = NULL; - if ((conn == NULL) || (conn->xshandle == NULL) || (path == NULL) || (nb == NULL)) return(NULL); - t = xs_transaction_start(conn->xshandle); - if (t == NULL) - goto done; - - ret = xs_directory(conn->xshandle, t, path, nb); - -done: - if (t != NULL) - xs_transaction_end(conn->xshandle, t, 0); - return(ret); + return xs_directory(conn->xshandle, 0, path, nb); } /** @@ -475,9 +451,7 @@ */ static char * virDomainDoStoreQuery(virDomainPtr domain, const char *path) { - struct xs_transaction_handle* t; char s[256]; - char *ret = NULL; unsigned int len = 0; if (!VIR_IS_CONNECTED_DOMAIN(domain)) @@ -488,16 +462,7 @@ snprintf(s, 255, "/local/domain/%d/%s", domain->handle, path); s[255] = 0; - t = xs_transaction_start(domain->conn->xshandle); - if (t == NULL) - goto done; - - ret = xs_read(domain->conn->xshandle, t, &s[0], &len); - -done: - if (t != NULL) - xs_transaction_end(domain->conn->xshandle, t, 0); - return(ret); + return xs_read(domain->conn->xshandle, 0, &s[0], &len); } @@ -514,7 +479,6 @@ static int virDomainDoStoreWrite(virDomainPtr domain, const char *path, const char *value) { - struct xs_transaction_handle* t; char s[256]; int ret = -1; @@ -529,16 +493,9 @@ snprintf(s, 255, "/local/domain/%d/%s", domain->handle, path); s[255] = 0; - t = xs_transaction_start(domain->conn->xshandle); - if (t == NULL) - goto done; - - if (xs_write(domain->conn->xshandle, t, &s[0], value, strlen(value))) + if (xs_write(domain->conn->xshandle, 0, &s[0], value, strlen(value))) ret = 0; -done: - if (t != NULL) - xs_transaction_end(domain->conn->xshandle, t, 0); return(ret); } @@ -553,7 +510,6 @@ char * virDomainGetVM(virDomainPtr domain) { - struct xs_transaction_handle* t; char *vm; char query[200]; unsigned int len; @@ -563,18 +519,11 @@ if (domain->conn->xshandle == NULL) return(NULL); - t = xs_transaction_start(domain->conn->xshandle); - if (t == NULL) - return(NULL); - snprintf(query, 199, "/local/domain/%d/vm", virDomainGetID(domain)); query[199] = 0; - vm = xs_read(domain->conn->xshandle, t, &query[0], &len); - - if (t != NULL) - xs_transaction_end(domain->conn->xshandle, t, 0); + vm = xs_read(domain->conn->xshandle, 0, &query[0], &len); return(vm); } @@ -593,7 +542,6 @@ char * virDomainGetVMInfo(virDomainPtr domain, const char *vm, const char *name) { - struct xs_transaction_handle* t; char s[256]; char *ret = NULL; unsigned int len = 0; @@ -606,15 +554,8 @@ snprintf(s, 255, "%s/%s", vm, name); s[255] = 0; - t = xs_transaction_start(domain->conn->xshandle); - if (t == NULL) - goto done; - - ret = xs_read(domain->conn->xshandle, t, &s[0], &len); - -done: - if (t != NULL) - xs_transaction_end(domain->conn->xshandle, t, 0); + ret = xs_read(domain->conn->xshandle, 0, &s[0], &len); + return(ret); } @@ -696,7 +637,6 @@ */ virDomainPtr virDomainLookupByName(virConnectPtr conn, const char *name) { - struct xs_transaction_handle* t = NULL; virDomainPtr ret = NULL; unsigned int num, i, len; long id = -1; @@ -722,11 +662,7 @@ /* then though the XenStore */ if (conn->xshandle != NULL) { - t = xs_transaction_start(conn->xshandle); - if (t == NULL) - goto done; - - idlist = xs_directory(conn->xshandle, t, "/local/domain", &num); + idlist = xs_directory(conn->xshandle, 0, "/local/domain", &num); if (idlist == NULL) goto done; @@ -739,7 +675,7 @@ continue; snprintf(prop, 199, "/local/domain/%s/name", idlist[i]); prop[199] = 0; - tmp = xs_read(conn->xshandle, t, prop, &len); + tmp = xs_read(conn->xshandle, 0, prop, &len); if (tmp != NULL) { found = !strcmp(name, tmp); free(tmp); @@ -768,8 +704,6 @@ done: if (xenddomain != NULL) free(xenddomain); - if (t != NULL) - xs_transaction_end(conn->xshandle, t, 0); if (idlist != NULL) free(idlist); @@ -1121,7 +1055,6 @@ virDomainSetMaxMemory(virDomainPtr domain, unsigned long memory) { int ret; char s[256], v[30]; - struct xs_transaction_handle* t; if (!VIR_IS_CONNECTED_DOMAIN(domain)) return(-1); @@ -1146,12 +1079,8 @@ snprintf(v, 29, "%lu", memory); v[30] = 0; - t = xs_transaction_start(domain->conn->xshandle); - if (t == NULL) - return(0); - - xs_write(domain->conn->xshandle, t, &s[0], &v[0], strlen(v)); - xs_transaction_end(domain->conn->xshandle, t, 0); + if (!xs_write(domain->conn->xshandle, 0, &s[0], &v[0], strlen(v))) + ret = -1; return(ret); } diff -r c028398d53b9 -r 9fe0c1f3379e src/xml.c --- a/src/xml.c Thu Jan 26 18:11:32 2006 +0000 +++ b/src/xml.c Thu Jan 26 17:27:36 2006 -0500 @@ -146,25 +146,14 @@ static char * virDomainGetXMLDeviceInfo(virDomainPtr domain, const char *sub, long dev, const char *name) { - struct xs_transaction_handle* t; char s[256]; - char *ret = NULL; unsigned int len = 0; snprintf(s, 255, "/local/domain/0/backend/%s/%d/%ld/%s", sub, domain->handle, dev, name); s[255] = 0; - t = xs_transaction_start(domain->conn->xshandle); - if (t == NULL) - goto done; - - ret = xs_read(domain->conn->xshandle, t, &s[0], &len); - -done: - if (t != NULL) - xs_transaction_end(domain->conn->xshandle, t, 0); - return(ret); + return xs_read(domain->conn->xshandle, 0, &s[0], &len); } /** @@ -240,7 +229,6 @@ */ static int virDomainGetXMLDevices(virDomainPtr domain, virBufferPtr buf) { - struct xs_transaction_handle* t; int ret = -1; unsigned int num, i; long id; @@ -253,14 +241,10 @@ conn = domain->conn; - t = xs_transaction_start(conn->xshandle); - if (t == NULL) - goto done; - snprintf(backend, 199, "/local/domain/0/backend/vbd/%d", virDomainGetID(domain)); backend[199] = 0; - list = xs_directory(conn->xshandle, t, backend, &num); + list = xs_directory(conn->xshandle, 0, backend, &num); ret = 0; if (list == NULL) goto done; @@ -275,8 +259,6 @@ } done: - if (t != NULL) - xs_transaction_end(conn->xshandle, t, 0); if (list != NULL) free(list); @@ -343,7 +325,6 @@ */ static int virDomainGetXMLInterfaces(virDomainPtr domain, virBufferPtr buf) { - struct xs_transaction_handle* t; int ret = -1; unsigned int num, i; long id; @@ -356,14 +337,10 @@ conn = domain->conn; - t = xs_transaction_start(conn->xshandle); - if (t == NULL) - goto done; - snprintf(backend, 199, "/local/domain/0/backend/vif/%d", virDomainGetID(domain)); backend[199] = 0; - list = xs_directory(conn->xshandle, t, backend, &num); + list = xs_directory(conn->xshandle, 0, backend, &num); ret = 0; if (list == NULL) goto done; @@ -378,8 +355,6 @@ } done: - if (t != NULL) - xs_transaction_end(conn->xshandle, t, 0); if (list != NULL) free(list);

2 1

[Libvir] Errors while running make
by dasari dakshina 23 Jan '06

23 Jan '06

Hello, I wish to use the Xen API. I downloaded the tar and extracted it as was told. The configure script also went through. But when I ran make ,I came across these errors. Could you please help ? Rgds, Dakshina make make all-recursive make[1]: Entering directory `/downloads/libvir-0.0.1' Making all in src make[2]: Entering directory `/downloads/libvir-0.0.1/src' if /bin/sh ../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I./include -g -O -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wall -MT libvir.lo -MD -MP -MF ".deps/libvir.Tpo" -c -o libvir.lo libvir.c; \ then mv -f ".deps/libvir.Tpo" ".deps/libvir.Plo"; else rm -f ".deps/libvir.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I./include -g -O -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wall -MT libvir.lo -MD -MP -MF .deps/libvir.Tpo -c libvir.c -fPIC -DPIC -o .libs/libvir.o In file included from /usr/include/xen/xen.h:13, from /usr/include/xen/dom0_ops.h:14, from xen_internal.h:17, from libvir.c:13: /usr/include/xen/arch-x86_32.h:74: error: syntax error before 'u8' /usr/include/xen/arch-x86_32.h:76: error: syntax error before 'cs' /usr/include/xen/arch-x86_32.h:78: error: syntax error before '}' token /usr/include/xen/arch-x86_32.h:81: error: syntax error before 'u32' /usr/include/xen/arch-x86_32.h:83: error: syntax error before 'edx' /usr/include/xen/arch-x86_32.h:84: error: syntax error before 'esi' /usr/include/xen/arch-x86_32.h:85: error: syntax error before 'edi' /usr/include/xen/arch-x86_32.h:86: error: syntax error before 'ebp' /usr/include/xen/arch-x86_32.h:87: error: syntax error before 'eax' /usr/include/xen/arch-x86_32.h:88: error: syntax error before 'error_code' /usr/include/xen/arch-x86_32.h:89: error: syntax error before 'entry_vector' /usr/include/xen/arch-x86_32.h:90: error: syntax error before 'eip' /usr/include/xen/arch-x86_32.h:91: error: syntax error before 'cs' /usr/include/xen/arch-x86_32.h:92: error: syntax error before 'saved_upcall_mask' /usr/include/xen/arch-x86_32.h:93: error: syntax error before '_pad0' /usr/include/xen/arch-x86_32.h:94: error: syntax error before 'eflags' /usr/include/xen/arch-x86_32.h:95: error: syntax error before 'esp' /usr/include/xen/arch-x86_32.h:96: error: syntax error before 'ss' /usr/include/xen/arch-x86_32.h:97: error: syntax error before 'es' /usr/include/xen/arch-x86_32.h:98: error: syntax error before 'ds' ............. libvir.c: At top level: libvir.c:967: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainGetInfo': libvir.c:1018: error: syntax error before 'dominfo' libvir.c:1020: error: 'dominfo' undeclared (first use in this function) make[2]: *** [libvir.lo] Error 1 make[2]: Leaving directory `/downloads/libvir-0.0.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/downloads/libvir-0.0.1' make: *** [all] Error 2 # --------------------------------- Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

2 1

[Libvir] Error while running make
by dasari dakshina 23 Jan '06

23 Jan '06

Hello, I wish to use the Xen API. I have downloaded the tar libvir-0.0.1.tar.gz i extracted the files and Ran ./configure --in the libvir directory .It went through. On running make however ,I have come across these errors. Any help would be appreciated. Rgds, Dakshina Entering directory `/downloads/libvir-0.0.1' Making all in src make[2]: Entering directory `/downloads/libvir-0.0.1/src' if /bin/sh ../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I./include -g -O -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wall -MT libvir.lo -MD -MP -MF ".deps/libvir.Tpo" -c -o libvir.lo libvir.c; \ then mv -f ".deps/libvir.Tpo" ".deps/libvir.Plo"; else rm -f ".deps/libvir.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I./include -g -O -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wall -MT libvir.lo -MD -MP -MF .deps/libvir.Tpo -c libvir.c -fPIC -DPIC -o .libs/libvir.o In file included from /usr/include/xen/xen.h:13, from /usr/include/xen/dom0_ops.h:14, from xen_internal.h:17, from libvir.c:13: /usr/include/xen/arch-x86_32.h:74: error: syntax error before 'u8' /usr/include/xen/arch-x86_32.h:76: error: syntax error before 'cs' /usr/include/xen/arch-x86_32.h:78: error: syntax error before '}' token /usr/include/xen/arch-x86_32.h:81: error: syntax error before 'u32' /usr/include/xen/arch-x86_32.h:83: error: syntax error before 'edx' /usr/include/xen/arch-x86_32.h:84: error: syntax error before 'esi' /usr/include/xen/arch-x86_32.h:85: error: syntax error before 'edi' /usr/include/xen/arch-x86_32.h:86: error: syntax error before 'ebp' /usr/include/xen/arch-x86_32.h:87: error: syntax error before 'eax' /usr/include/xen/arch-x86_32.h:88: error: syntax error before 'error_code' /usr/include/xen/arch-x86_32.h:89: error: syntax error before 'entry_vector' /usr/include/xen/arch-x86_32.h:90: error: syntax error before 'eip' /usr/include/xen/arch-x86_32.h:91: error: syntax error before 'cs' /usr/include/xen/arch-x86_32.h:92: error: syntax error before 'saved_upcall_mask' /usr/include/xen/arch-x86_32.h:93: error: syntax error before '_pad0' /usr/include/xen/arch-x86_32.h:94: error: syntax error before 'eflags' /usr/include/xen/arch-x86_32.h:95: error: syntax error before 'esp' /usr/include/xen/arch-x86_32.h:96: error: syntax error before 'ss' /usr/include/xen/arch-x86_32.h:97: error: syntax error before 'es' /usr/include/xen/arch-x86_32.h:98: error: syntax error before 'ds' /usr/include/xen/arch-x86_32.h:99: error: syntax error before 'fs' /usr/include/xen/arch-x86_32.h:100: error: syntax error before 'gs' /usr/include/xen/arch-x86_32.h:101: error: syntax error before '}' token /usr/include/xen/arch-x86_32.h:103: error: syntax error before 'tsc_timestamp_t' /usr/include/xen/arch-x86_32.h:116: error: syntax error before 'cpu_user_regs_t' /usr/include/xen/arch-x86_32.h:128: error: syntax error before '}' token /usr/include/xen/arch-x86_32.h:132: error: syntax error before 'u64' In file included from /usr/include/xen/dom0_ops.h:14, from xen_internal.h:17, from libvir.c:13: /usr/include/xen/xen.h:245: error: syntax error before 'domid_t' /usr/include/xen/xen.h:278: error: syntax error before 'u64' /usr/include/xen/xen.h:325: error: syntax error before 'u8' /usr/include/xen/xen.h:327: error: syntax error before 'evtchn_pending_sel' /usr/include/xen/xen.h:343: error: syntax error before 'u32' /usr/include/xen/xen.h:345: error: syntax error before 'system_time' /usr/include/xen/xen.h:352: error: syntax error before 'tsc_to_system_mul' /usr/include/xen/xen.h:353: error: syntax error before 'tsc_shift' /usr/include/xen/xen.h:361: error: syntax error before 'vcpu_info_t' /usr/include/xen/xen.h:365: error: syntax error before 'n_vcpu' /usr/include/xen/xen.h:398: error: syntax error before 'evtchn_pending' /usr/include/xen/xen.h:399: error: syntax error before 'evtchn_mask' /usr/include/xen/xen.h:405: error: syntax error before 'wc_version' /usr/include/xen/xen.h:406: error: syntax error before 'wc_sec' /usr/include/xen/xen.h:407: error: syntax error before 'wc_nsec' /usr/include/xen/xen.h:409: error: syntax error before 'arch' /usr/include/xen/xen.h:443: error: syntax error before 'u32' /usr/include/xen/xen.h:451: error: syntax error before 'cmd_line' /usr/include/xen/xen.h:453: error: syntax error before 'store_evtchn' /usr/include/xen/xen.h:463: error: syntax error before '*' token /usr/include/xen/xen.h:465: error: syntax error before 'cpumap_t' In file included from /usr/include/xen/dom0_ops.h:15, from xen_internal.h:17, from libvir.c:13: /usr/include/xen/sched_ctl.h:23: error: syntax error before 'u32' /usr/include/xen/sched_ctl.h:27: error: syntax error before 'u32' /usr/include/xen/sched_ctl.h:29: error: syntax error before '}' token /usr/include/xen/sched_ctl.h:30: error: syntax error before '}' token /usr/include/xen/sched_ctl.h:33: error: syntax error before 'u32' /usr/include/xen/sched_ctl.h:35: error: syntax error before 'domain' /usr/include/xen/sched_ctl.h:39: error: syntax error before 'u32' /usr/include/xen/sched_ctl.h:41: error: syntax error before 'warpvalue' /usr/include/xen/sched_ctl.h:44: error: syntax error before '}' token /usr/include/xen/sched_ctl.h:48: error: syntax error before 'u64' /usr/include/xen/sched_ctl.h:50: error: syntax error before 'latency' /usr/include/xen/sched_ctl.h:51: error: syntax error before 'extratime' /usr/include/xen/sched_ctl.h:52: error: syntax error before 'weight' /usr/include/xen/sched_ctl.h:55: error: syntax error before '}' token /usr/include/xen/sched_ctl.h:56: error: syntax error before '}' token In file included from xen_internal.h:17, from libvir.c:13: /usr/include/xen/dom0_ops.h:29: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:34: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:47: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:56: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:62: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:68: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:74: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:89: error: syntax error before 'cpu_time' /usr/include/xen/dom0_ops.h:90: error: syntax error before 'n_vcpu' /usr/include/xen/dom0_ops.h:91: error: syntax error before 'vcpu_to_cpu' /usr/include/xen/dom0_ops.h:92: error: syntax error before 'cpumap' /usr/include/xen/dom0_ops.h:93: error: syntax error before 'ssidref' /usr/include/xen/dom0_ops.h:99: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:102: error: syntax error before '*' token /usr/include/xen/dom0_ops.h:103: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:108: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:110: error: syntax error before 'msr' /usr/include/xen/dom0_ops.h:111: error: syntax error before 'in1' /usr/include/xen/dom0_ops.h:112: error: syntax error before 'in2' /usr/include/xen/dom0_ops.h:114: error: syntax error before 'out1' /usr/include/xen/dom0_ops.h:115: error: syntax error before 'out2' /usr/include/xen/dom0_ops.h:121: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:123: error: syntax error before 'in1' /usr/include/xen/dom0_ops.h:124: error: syntax error before 'in2' /usr/include/xen/dom0_ops.h:125: error: syntax error before 'in3' /usr/include/xen/dom0_ops.h:126: error: syntax error before 'in4' /usr/include/xen/dom0_ops.h:128: error: syntax error before 'status' /usr/include/xen/dom0_ops.h:129: error: syntax error before 'out1' /usr/include/xen/dom0_ops.h:130: error: syntax error before 'out2' /usr/include/xen/dom0_ops.h:140: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:142: error: syntax error before 'system_time' /usr/include/xen/dom0_ops.h:159: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:171: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:173: error: conflicting types for 'buffer' /usr/include/xen/dom0_ops.h:31: error: previous declaration of 'buffer' was here /usr/include/xen/dom0_ops.h:174: error: syntax error before 'count' /usr/include/xen/dom0_ops.h:183: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:185: error: syntax error before '*' token /usr/include/xen/dom0_ops.h:185: error: conflicting types for 'cpumap' /usr/include/xen/dom0_ops.h:92: error: previous declaration of 'cpumap' was here /usr/include/xen/dom0_ops.h:186: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:195: error: syntax error before 'u8' /usr/include/xen/dom0_ops.h:197: error: conflicting types for 'cpu_mask' /usr/include/xen/dom0_ops.h:109: error: previous declaration of 'cpu_mask' was here /usr/include/xen/dom0_ops.h:198: error: syntax error before 'evt_mask' /usr/include/xen/dom0_ops.h:201: error: syntax error before 'size' /usr/include/xen/dom0_ops.h:209: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:211: error: syntax error before 'sockets_per_node' /usr/include/xen/dom0_ops.h:212: error: syntax error before 'nr_nodes' /usr/include/xen/dom0_ops.h:213: error: syntax error before 'cpu_khz' /usr/include/xen/dom0_ops.h:216: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:224: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:243: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:245: error: syntax error before 'dirty_net_count' /usr/include/xen/dom0_ops.h:246: error: syntax error before 'dirty_block_count'/usr/include/xen/dom0_ops.h:251: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:257: error: syntax error before 'stats' /usr/include/xen/dom0_ops.h:263: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:265: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:270: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:274: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:288: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:291: error: syntax error before 'reg' /usr/include/xen/dom0_ops.h:304: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:312: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:316: error: syntax error before 'type' /usr/include/xen/dom0_ops.h:325: error: syntax error before 'u8' /usr/include/xen/dom0_ops.h:327: error: syntax error before 'vals' /usr/include/xen/dom0_ops.h:328: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:331: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:334: error: syntax error before '*' token /usr/include/xen/dom0_ops.h:335: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:341: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:346: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:348: error: syntax error before 'nr_ports' /usr/include/xen/dom0_ops.h:349: error: syntax error before 'allow_access' /usr/include/xen/dom0_ops.h:354: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:356: error: syntax error before '*' token /usr/include/xen/dom0_ops.h:357: error: syntax error before 'cpu_time' /usr/include/xen/dom0_ops.h:363: error: syntax error before 'domid_t' /usr/include/xen/dom0_ops.h:365: error: syntax error before '*' token /usr/include/xen/dom0_ops.h:365: error: conflicting types for 'buffer' /usr/include/xen/dom0_ops.h:31: error: previous declaration of 'buffer' was here /usr/include/xen/dom0_ops.h:368: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:378: error: syntax error before 'u32' /usr/include/xen/dom0_ops.h:381: error: syntax error before 'dom0_createdomain_t' /usr/include/xen/dom0_ops.h:383: error: syntax error before 'unpausedomain' /usr/include/xen/dom0_ops.h:384: error: syntax error before 'destroydomain' /usr/include/xen/dom0_ops.h:385: error: syntax error before 'getmemlist' /usr/include/xen/dom0_ops.h:388: error: syntax error before 'setdomaininfo' /usr/include/xen/dom0_ops.h:389: error: syntax error before 'getdomaininfo' /usr/include/xen/dom0_ops.h:390: error: syntax error before 'getpageframeinfo' /usr/include/xen/dom0_ops.h:391: error: syntax error before 'msr' /usr/include/xen/dom0_ops.h:392: error: syntax error before 'debug' /usr/include/xen/dom0_ops.h:393: error: syntax error before 'settime' /usr/include/xen/dom0_ops.h:394: error: syntax error before 'readconsole' /usr/include/xen/dom0_ops.h:395: error: syntax error before 'pincpudomain' /usr/include/xen/dom0_ops.h:396: error: syntax error before 'tbufcontrol' /usr/include/xen/dom0_ops.h:397: error: syntax error before 'physinfo' /usr/include/xen/dom0_ops.h:398: error: syntax error before 'sched_id' /usr/include/xen/dom0_ops.h:399: error: syntax error before 'shadow_control' /usr/include/xen/dom0_ops.h:400: error: syntax error before 'setdomainmaxmem' /usr/include/xen/dom0_ops.h:401: error: syntax error before 'getpageframeinfo2'/usr/include/xen/dom0_ops.h:402: error: syntax error before 'add_memtype' /usr/include/xen/dom0_ops.h:403: error: syntax error before 'del_memtype' /usr/include/xen/dom0_ops.h:404: error: syntax error before 'read_memtype' /usr/include/xen/dom0_ops.h:405: error: syntax error before 'perfccontrol' /usr/include/xen/dom0_ops.h:406: error: syntax error before 'microcode' /usr/include/xen/dom0_ops.h:407: error: syntax error before 'ioport_permission'/usr/include/xen/dom0_ops.h:408: error: syntax error before 'getvcpucontext' /usr/include/xen/dom0_ops.h:409: error: syntax error before 'getdomaininfolist'/usr/include/xen/dom0_ops.h:411: error: syntax error before '}' token /usr/include/xen/dom0_ops.h:412: error: syntax error before '}' token In file included from libvir.c:13: xen_internal.h:24: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:25: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:26: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:27: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here xen_internal.h:28: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:29: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here xen_internal.h:30: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:31: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here xen_internal.h:32: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:33: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here xen_internal.h:34: error: syntax error before 'dom0_getdomaininfo_t' xen_internal.h:34: warning: function declaration isn't a prototype xen_internal.h:35: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here xen_internal.h:36: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here In file included from /usr/include/xc.h:26, from /usr/include/xs_lib.h:25, from /usr/include/xs.h:23, from libvir.c:18: /usr/include/xen/event_channel.h:20: error: syntax error before 'domid_t' /usr/include/xen/event_channel.h:23: error: syntax error before '}' token /usr/include/xen/event_channel.h:48: error: syntax error before 'domid_t' /usr/include/xen/event_channel.h:51: error: syntax error before '}' token /usr/include/xen/event_channel.h:108: error: syntax error before 'domid_t' /usr/include/xen/event_channel.h:111: error: syntax error before '}' token /usr/include/xen/event_channel.h:135: error: syntax error before 'domid_t' /usr/include/xen/event_channel.h:144: error: conflicting types for 'status' /usr/include/xen/dom0_ops.h:128: error: previous declaration of 'status' was here /usr/include/xen/event_channel.h:145: error: conflicting types for 'vcpu' /usr/include/xen/dom0_ops.h:355: error: previous declaration of 'vcpu' was here/usr/include/xen/event_channel.h:148: error: syntax error before 'domid_t' /usr/include/xen/event_channel.h:151: error: syntax error before 'domid_t' /usr/include/xen/event_channel.h:153: error: syntax error before '}' token /usr/include/xen/event_channel.h:156: error: syntax error before '}' token /usr/include/xen/event_channel.h:157: error: syntax error before '}' token /usr/include/xen/event_channel.h:179: error: syntax error before 'evtchn_alloc_unbound_t' /usr/include/xen/event_channel.h:184: error: syntax error before 'close' /usr/include/xen/event_channel.h:186: error: syntax error before 'status' /usr/include/xen/event_channel.h:188: error: syntax error before '}' token /usr/include/xen/event_channel.h:189: error: syntax error before '}' token In file included from /usr/include/xs_lib.h:25, from /usr/include/xs.h:23, from libvir.c:18: /usr/include/xc.h:137: error: syntax error before 'cpumap_t' /usr/include/xc.h:140: error: syntax error before 'xc_domaininfo_t' /usr/include/xc.h:186: error: syntax error before 'cpumap_t' /usr/include/xc.h:205: error: syntax error before 'xc_dominfo_t' /usr/include/xc.h:223: error: syntax error before 'xc_domaininfo_t' /usr/include/xc.h:239: error: syntax error before 'vcpu_guest_context_t' /usr/include/xc.h:245: error: syntax error before 'domid_t' /usr/include/xc.h:249: error: syntax error before 'xc_shadow_control_stats_t' /usr/include/xc.h:255: error: syntax error before 'xc_shadow_control_stats_t' /usr/include/xc.h:344: error: syntax error before 'xc_evtchn_status_t' /usr/include/xc.h:419: error: syntax error before 'xc_evtchn_status_t' /usr/include/xc.h:433: error: syntax error before 'xc_physinfo_t' /usr/include/xc.h:435: error: syntax error before 'xc_physinfo_t' /usr/include/xc.h:448: error: syntax error before 'xc_perfc_desc_t' /usr/include/xc.h:452: error: syntax error before 'xc_perfc_desc_t' /usr/include/xc.h:547: error: syntax error before 'dom0_op_t' In file included from /usr/include/xs.h:23, from libvir.c:18: /usr/include/xs_lib.h:39: error: syntax error before 'domid_t' /usr/include/xs_lib.h:41: error: syntax error before '}' token In file included from libvir.c:18: /usr/include/xs.h:128: error: syntax error before 'domid_t' /usr/include/xs.h:134: error: syntax error before 'domid_t' In file included from internal.h:8, from libvir.c:19: hash.h:39: warning: declaration of 'size' shadows a global declaration /usr/include/xen/dom0_ops.h:201: warning: shadowed declaration is here In file included from libvir.c:19: internal.h:105: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here internal.h:106: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:47: warning: declaration of 'type' shadows a global declaration /usr/include/xen/dom0_ops.h:316: warning: shadowed declaration is here libvir.c: In function 'virConnectOpen': libvir.c:84: warning: declaration of 'handle' shadows a global declaration /usr/include/xen/dom0_ops.h:290: warning: shadowed declaration is here libvir.c: In function 'virConnectCheckStoreID': libvir.c:175: error: syntax error before 'dominfo' libvir.c:178: error: 'dominfo' undeclared (first use in this function) libvir.c:178: error: (Each undeclared identifier is reported only once libvir.c:178: error: for each function it appears in.) libvir.c: At top level: libvir.c:195: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virConnectListDomains': libvir.c:288: warning: declaration of 'num' shadows a global declaration /usr/include/xen/dom0_ops.h:271: warning: shadowed declaration is here libvir.c:298: error: too few arguments to function 'xs_transaction_start' libvir.c:302: warning: passing argument 2 of 'xs_directory' from incompatible pointer type libvir.c:302: warning: passing argument 3 of 'xs_directory' from incompatible pointer type libvir.c:302: error: too many arguments to function 'xs_directory' libvir.c:320: error: too many arguments to function 'xs_transaction_end' libvir.c: In function 'virConnectNumOfDomains': libvir.c:339: warning: declaration of 'num' shadows a global declaration /usr/include/xen/dom0_ops.h:271: warning: shadowed declaration is here libvir.c:345: error: too few arguments to function 'xs_transaction_start' libvir.c:347: warning: passing argument 2 of 'xs_directory' from incompatible pointer type libvir.c:347: warning: passing argument 3 of 'xs_directory' from incompatible pointer type libvir.c:347: error: too many arguments to function 'xs_directory' libvir.c:352: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:376: warning: declaration of 'flags' shadows a global declaration /usr/include/xen/dom0_ops.h:85: warning: shadowed declaration is here libvir.c: In function 'virConnectDoStoreList': libvir.c:431: error: too few arguments to function 'xs_transaction_start' libvir.c:435: warning: passing argument 2 of 'xs_directory' from incompatible pointer type libvir.c:435: warning: passing argument 3 of 'xs_directory' from incompatible pointer type libvir.c:435: error: too many arguments to function 'xs_directory' libvir.c:439: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:453: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainDoStoreQuery': libvir.c:465: error: too few arguments to function 'xs_transaction_start' libvir.c:469: warning: passing argument 2 of 'xs_read' from incompatible pointer type libvir.c:469: warning: passing argument 3 of 'xs_read' from incompatible pointer type libvir.c:469: error: too many arguments to function 'xs_read' libvir.c:473: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:489: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainDoStoreWrite': libvir.c:504: error: too few arguments to function 'xs_transaction_start' libvir.c:508: warning: passing argument 2 of 'xs_write' from incompatible pointer type libvir.c:508: warning: passing argument 4 of 'xs_write' makes integer from pointer without a cast libvir.c:513: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:526: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainGetVM': libvir.c:536: error: too few arguments to function 'xs_transaction_start' libvir.c:544: warning: passing argument 2 of 'xs_read' from incompatible pointer type libvir.c:544: warning: passing argument 3 of 'xs_read' from incompatible pointer type libvir.c:544: error: too many arguments to function 'xs_read' libvir.c:547: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:564: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainGetVMInfo': libvir.c:577: error: too few arguments to function 'xs_transaction_start' libvir.c:581: warning: passing argument 2 of 'xs_read' from incompatible pointer type libvir.c:581: warning: passing argument 3 of 'xs_read' from incompatible pointer type libvir.c:581: error: too many arguments to function 'xs_read' libvir.c:585: error: too many arguments to function 'xs_transaction_end' libvir.c: In function 'virDomainLookupByID': libvir.c:608: warning: implicit declaration of function 'xs_get_domain_path' libvir.c:608: warning: nested extern declaration of 'xs_get_domain_path' libvir.c:608: warning: assignment makes pointer from integer without a cast libvir.c: In function 'virDomainLookupByName': libvir.c:644: warning: declaration of 'num' shadows a global declaration /usr/include/xen/dom0_ops.h:271: warning: shadowed declaration is here libvir.c:655: error: too few arguments to function 'xs_transaction_start' libvir.c:659: warning: passing argument 2 of 'xs_directory' from incompatible pointer type libvir.c:659: warning: passing argument 3 of 'xs_directory' from incompatible pointer type libvir.c:659: error: too many arguments to function 'xs_directory' libvir.c:672: warning: passing argument 2 of 'xs_read' from incompatible pointer type libvir.c:672: warning: passing argument 3 of 'xs_read' from incompatible pointer type libvir.c:672: error: too many arguments to function 'xs_read' libvir.c:687: warning: assignment makes pointer from integer without a cast libvir.c:693: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:713: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:735: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:761: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:778: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:797: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:824: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:839: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:854: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c:879: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainGetMaxMemory': libvir.c:894: error: syntax error before 'dominfo' libvir.c:897: error: 'dominfo' undeclared (first use in this function) libvir.c: At top level: libvir.c:919: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainSetMaxMemory': libvir.c:945: error: too few arguments to function 'xs_transaction_start' libvir.c:949: warning: passing argument 2 of 'xs_write' from incompatible pointer type libvir.c:949: warning: passing argument 4 of 'xs_write' makes integer from pointer without a cast libvir.c:950: error: too many arguments to function 'xs_transaction_end' libvir.c: At top level: libvir.c:967: warning: declaration of 'domain' shadows a global declaration /usr/include/xen/dom0_ops.h:50: warning: shadowed declaration is here libvir.c: In function 'virDomainGetInfo': libvir.c:1018: error: syntax error before 'dominfo' libvir.c:1020: error: 'dominfo' undeclared (first use in this function) make[2]: *** [libvir.lo] Error 1 make[2]: Leaving directory `/downloads/libvir-0.0.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/downloads/libvir-0.0.1' --------------------------------- What are the most popular cars? Find out at Yahoo! Autos

1 0

[Libvir] Persistent Configurations?
by Anthony Liguori 11 Jan '06

11 Jan '06

Howdy, Thought I'd try to start up a discussion on a topic that I know I've discussed a lot with people in the past. Xend currently stores its configurations in python files somewhere on the file system (usually in /etc/xen). This is problematic from a management tool perspective because the python files may contain arbitrary python code (requiring a python interpreter to read) and there's no central location which makes enumerating possible domains quite difficult. If you think about a typical use-case (or at least, my typical use-case :-)), a user is likely to have a larger number of domains than what are running (say a domain for a bunch of different distros for testing). It would be nice if any management tools could see those domains and easily start them up. I think we could achieve this with the following requirements: 1) Allow domain creation based on an opaque configuration object 2) Allow storing and retrieval of these configuration objects from the XenStore (using a user-specified path) I think this isolates the state well enough that it leaves the majority of the library stateless. Just some random thoughts... Regards, Anthony Liguori

3 4

[Libvir] ruby bindings
by Fraser Campbell 05 Jan '06

05 Jan '06

Hi, Is there any chance you are considering the addition of ruby bindings for libvir? I have been considering writing my own ruby wrappers around Xen's lowlevel libraries but if libvir is a higher-level more stable API perhaps it would make more sense for me to wrap around libvir. If you are not working on ruby bindings I will do so myself and eventually provide patches. Are you in a position to state yet whether libvir is likely to be continually developed and a key part of the Fedora/RHEL virtualization? I immediately see some missing functionality (migration), I assume the eventual goal is to support all features of Xen and that it is just missing because of the very young state of the project? Thanks!

2 3

[Libvir] Release of libvir-0.0.1
by Daniel Veillard 19 Dec '05

19 Dec '05

First release based on today's CVS snapshot is available for download from http://libvir.org/downloads.html I just added python bindings before the release, unfortunately I noticed only after that the destructor for the virDomain and virConnect classes were broken <grin/>. Well it is definitely a Work in Progress and sticking with CVS might be a good idea at the moment. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Re: [Fedora-xen] Libvir: a simple C virtualization control library
by Daniel Veillard 15 Dec '05

15 Dec '05

On Thu, Dec 15, 2005 at 10:19:17AM -0500, Bryan D. Payne wrote: > Interesting. Can you expand on how this is different than the > services currently provided by libxc? Is the idea to simply have a > wrapper around libxc that can be LGPL and, possibly, be extended to > work with other virtualization mechanisms? Or does libvir provide > services not found in libxc? It is not using libxc for a couple of reasons: - to decouple the API from Xen, with the hope it will help provide API stability with an intermediate abstraction - due to the licence: if the LGPL library requires to link with a GPL library well the resulting programs can only be used under the GPL licence. It is smaller than libxc in term of capabilities, the goal is not to try to match those exactly, it can be expanded if there is demand though but it's more about providing generic services. For example there is an API do dump running domain informations as an XML chunk that could be used as well for different kind of virtualization engine, and is more high level than what libxc provides. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] test
by Daniel Veillard 07 Dec '05

07 Dec '05

test of the list and archives, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0