[Libvir] autogen.sh error

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/