[Libvir] Fix to makefile for VPATH builds
by Daniel P. Berrange
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 -=|
18 years, 8 months
Réf. : Re: [Libvir] Libvir on Itanium ?
by jean-paul.pigache＠bull.net
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
18 years, 8 months
[Libvir] Libvir on Itanium ?
by jean-paul.pigache＠bull.net
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
18 years, 8 months
[Libvir] Wiki?
by Anthony Liguori
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
18 years, 8 months
[Libvir] XML-RPC support for libvirt
by Anthony Liguori
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
18 years, 8 months
[Libvir] Questions about the future of libvirt
by David Anderson
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.
18 years, 8 months
[Libvir] Simple python examples
by David Lutterkort
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
18 years, 8 months
[Libvir] [PATCH] Virtual block devices
by David Lutterkort
Because of a small typo in virDomainParseXMLDiskDesc, domU's can't
receive virtual block devices from dom0. Patch to fix this is attached.
David
18 years, 8 months
[Libvir] Minimal specfile addition
by David Lutterkort
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
18 years, 8 months
