4:12 a.m.
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.
4:28 a.m.
On Thu, Mar 09, 2006 at 11:12:45AM +0100, Ronald Aigner wrote:
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?
At this point you need to have Xen installed, at least to be able to
compile even if you don't run it. Depending on your environment it may be
as simple as "yum install xen", or a bit more painful.
How do I implement support for another hypervisor? Where do I have
to
turn which screws?
Currently there is only Xen support, I'm starting to work on glue for
QEmu, but this requires first modification on QEmu and I'm working
on that. As discussed last week (see the list archive) we will need some
code refactoring to really implement access to other hypervisors/emulators.
What do you have in mind ?
My current plan at the moment is the following:
1/ get pending patches from Anthony Liguori
2/ cleanup the code base to have unified code formatting at least
3/ provide a back-end to be able to access QEmu
4/ based on that refactor the internals to better integrate new engines
Now if you want to help, explain what you would like to add and maybe we
can start the refactoring earlier, I just wanted to make progresses on
a different engine first before trying to redesign the internals.
makes sense ?
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:06 a.m.
Daniel Veillard wrote on 03/09/2006 11:28 AM this:
On Thu, Mar 09, 2006 at 11:12:45AM +0100, Ronald Aigner wrote:
>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?
At this point you need to have Xen installed, at least to be able to
compile even if you don't run it. Depending on your environment it may be
as simple as "yum install xen", or a bit more painful.
Ok. I downloaded
and build Xen 3.0.1. After that I ran 'make dist'
because I did not (yet) wanted to install Xen.
However, I couldn't build libvirt just yet. I added the attached patch
to configure.in and ran 'autogen.sh
--with-xen-distdir=$(HOME)/src/xen-3.0-testing/dist'
I also needed to install libxml2-dev and libreadline5-dev on my Debian
(stable) system for a successful configure run. After that I could
compiler libvirt.
>How do I implement support for another hypervisor? Where do I have
to
>turn which screws?
Currently there is only Xen support, I'm starting to work on glue for
QEmu, but this requires first modification on QEmu and I'm working
on that. As discussed last week (see the list archive) we will need some
code refactoring to really implement access to other hypervisors/emulators.
What do you have in mind ?
I am part of the L4 group in Dresden (www.l4hq.org
and
www.tudos.org/L4). It seems reasonable to combine efforts to provide
some hypervisor management facilities. Some collegue pointed me to the
libvirt project. I am well aware that there is more to the
virtualization effort than 'just' providing another backend to libvirt.
So, we think that it is a good idea to integrate our facilities to
manage (para-)virtualized operating systems on L4 into libvirt. What do
you think?
My current plan at the moment is the following:
1/ get pending patches from Anthony Liguori
2/ cleanup the code base to have unified code formatting at least
3/ provide a back-end to be able to access QEmu
4/ based on that refactor the internals to better integrate new engines
Now if you want to help, explain what you would like to add and maybe we
can start the refactoring earlier, I just wanted to make progresses on
a different engine first before trying to redesign the internals.
makes sense ?
Sure does.
I will have a look at the functionality currently required by libvirt
and try to match it to infrastructure we have here (it's basically a
decomposed dom0).
Thanks for the help and insights,
Ron.
Index: configure.in
===================================================================
RCS file: /data/cvs/libvirt/configure.in,v
retrieving revision 1.27
diff -u -r1.27 configure.in
--- configure.in 28 Feb 2006 14:22:33 -0000 1.27
+++ configure.in 10 Mar 2006 08:42:19 -0000
@@ -79,6 +79,18 @@
fi
dnl
+dnl Specify the xen-distribution directory to be able to compile on a
+dnl non-xenified host
+dnl
+AC_ARG_WITH(xen-distdir, AC_HELP_STRING([--with-xen-distdir=path],
+ [distribution directory of Xen, default /usr]))
+if test "x$with_xen_distdir" != "x"
+then
+CPPFLAGS="$CPPFLAGS -I$withval/install/usr/include"
+LDFLAGS="$LDFLAGS -L$withval/install/usr/lib"
+fi
+
+dnl
dnl To be able to make dist on a non-xenified host
dnl
AC_ARG_WITH(depends,
4:24 a.m.
On Fri, Mar 10, 2006 at 10:06:41AM +0100, Ronald Aigner wrote:
Ok. I downloaded and build Xen 3.0.1. After that I ran 'make
dist'
because I did not (yet) wanted to install Xen.
However, I couldn't build libvirt just yet. I added the attached patch
to configure.in and ran 'autogen.sh
--with-xen-distdir=$(HOME)/src/xen-3.0-testing/dist'
okay, applied it make sense.
I think once we have cleaned up the code to separate clearly the various
hypervisor core entry points and the corresponding accessor, it will be
trivial to not break if the xentore lib is missing and just not compile
in that part.
I also needed to install libxml2-dev and libreadline5-dev on my
Debian
(stable) system for a successful configure run. After that I could
compiler libvirt.
yes libxml2-devel is needed to process the XML format description
look at http://libvirt.org/format.html and keep in mind you will
probably need something similar to start a new OS on top of l4
>>How do I implement support for another hypervisor? Where do I
have to
>>turn which screws?
>
>
> Currently there is only Xen support, I'm starting to work on glue for
> QEmu, but this requires first modification on QEmu and I'm working
> on that. As discussed last week (see the list archive) we will need some
> code refactoring to really implement access to other hypervisors/emulators.
> What do you have in mind ?
I am part of the L4 group in Dresden (www.l4hq.org and
www.tudos.org/L4). It seems reasonable to combine efforts to provide
some hypervisor management facilities. Some collegue pointed me to the
libvirt project. I am well aware that there is more to the
virtualization effort than 'just' providing another backend to libvirt.
Well that's a first step for sure, somehow libvirt is at the bottom of the
stack, very close to the hypervisor. There will be layers over it, my goal
is to try to provide as much as possible a common accessor and a stable
API limiting the amount of tweaking at upper layers.
So, we think that it is a good idea to integrate our facilities to
manage (para-)virtualized operating systems on L4 into libvirt. What do
you think?
Sure. It's been a while I haven't done micro-kernel work (Mach3 urgh!)
some of the concept will be easy to map, the harder in my opinion will
as usual be how to drive a new OS/service instance, that's why the Create
API use an XML description
http://libvirt.org/html/libvirt-libvirt.html#virDomainCreateLinux
I will have a look at the functionality currently required by
libvirt
and try to match it to infrastructure we have here (it's basically a
decomposed dom0).
Again, I think creation will be the harder part. Suspend/Resume/Resources
are clearly common canonical concepts, the hardest is describing the
bootstrap informations for a new instance, that's where I expect the most
variation from engine to engine.
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/
10:43 a.m.
On Fri, Mar 10, 2006 at 10:06:41AM +0100, Ronald Aigner wrote:
> Currently there is only Xen support, I'm starting to work
on glue for
> QEmu, but this requires first modification on QEmu and I'm working
> on that. As discussed last week (see the list archive) we will need some
> code refactoring to really implement access to other hypervisors/emulators.
> What do you have in mind ?
I am part of the L4 group in Dresden (www.l4hq.org and
www.tudos.org/L4). It seems reasonable to combine efforts to provide
some hypervisor management facilities. Some collegue pointed me to the
libvirt project. I am well aware that there is more to the
virtualization effort than 'just' providing another backend to libvirt.
So, we think that it is a good idea to integrate our facilities to
manage (para-)virtualized operating systems on L4 into libvirt. What do
you think?
Resurrecting that old thread.
I think that the new architecture of libvirt, as in 0.1.0 should make
the work of adding a driver for something like l4 quite easier. The
main libvirt.c code may still call directly the Xen drivers, but that
should now be easy to tidy up and plug new modules.
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/
6800
days inactive
6832
days old
4 comments
2 participants
participants (2)
-
Daniel Veillard -
Ronald Aigner