March 2006 - Devel - libvirt List Archives

[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 10 Mar '06

10 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