Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Is debian support planned, or is libguestfs designed to be a fedora-only project?
Bye Tim
On Thu, Jun 11, 2009 at 6:09 PM, Tim Tassonistimtas@cubic.ch wrote:
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Is debian support planned, or is libguestfs designed to be a fedora-only project?
I also want to package libguestfs for our distro, Pardus, but unable to do so due to this dependency.
On Thu, Jun 11, 2009 at 08:46:19PM +0200, Emre Erenoglu wrote:
On Thu, Jun 11, 2009 at 6:09 PM, Tim Tassonistimtas@cubic.ch wrote:
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Is debian support planned, or is libguestfs designed to be a fedora-only project?
I also want to package libguestfs for our distro, Pardus, but unable to do so due to this dependency.
You can just compile yum on pretty much any distro. The only major dependencies are Python and rpm (which just needs a C compiler). Debian ship a yum package and have been doing so for quite a long time.
febootstrap is little more than a shell script which wraps around yum.
Rich.
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Even though Debian/Ubunut use APT for their package mgmt system, there should not be any problem installing the YUM + RPM libraries. This should allow febootstrap to be built & run, and not impact your host OS package mgmt
Is debian support planned, or is libguestfs designed to be a fedora-only project?
It is certainly intended to be able to build libguestfs on any Linux host with new enough fakeroot/fakechroot + YUM/RPM libraries. IMHO it doesn't make sense to try and use different OS for its internal appliance image, since that's not really a distro you need to interface with at all as a user of libguestfs.
Regards, Daniel
Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Even though Debian/Ubunut use APT for their package mgmt system, there should not be any problem installing the YUM + RPM libraries. This should allow febootstrap to be built & run, and not impact your host OS package mgmt
Yes, of course....but since it is mentioned that febootstrap is based on debootstrap, is there a technical reason for not just supporting debootstrap alternatively. I haven't got enough background regarding debootstrap/febootstrap and libguestfs to make a judgement about this though.
But to require any distribution to install yum/rpm just for this library seems a bit intrusive to me. Requiring a specific distro packaging system for a package seems a bit distribution dependant to me.
Regards Tim
On Thu, Jun 11, 2009 at 9:11 PM, Tim Tassonistimtas@cubic.ch wrote:
Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Even though Debian/Ubunut use APT for their package mgmt system, there should not be any problem installing the YUM + RPM libraries. This should allow febootstrap to be built & run, and not impact your host OS package mgmt
Yes, of course....but since it is mentioned that febootstrap is based on debootstrap, is there a technical reason for not just supporting debootstrap alternatively. I haven't got enough background regarding debootstrap/febootstrap and libguestfs to make a judgement about this though.
But to require any distribution to install yum/rpm just for this library seems a bit intrusive to me. Requiring a specific distro packaging system for a package seems a bit distribution dependant to me.
This is exactly my problem. I didn't really analyze why febootstrap or debootstrap might be technically needed, but I appreciate if there's an alternative way to this requirement. Our distro, possibly some others out there, do not have any {fe,de]bootstrap packages.
Thanks,
Emre
On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Even though Debian/Ubunut use APT for their package mgmt system, there should not be any problem installing the YUM + RPM libraries. This should allow febootstrap to be built & run, and not impact your host OS package mgmt
Yes, of course....but since it is mentioned that febootstrap is based on debootstrap, is there a technical reason for not just supporting debootstrap alternatively. I haven't got enough background regarding debootstrap/febootstrap and libguestfs to make a judgement about this though.
They are conceptually the same, but different implementations. debootstrap takes a APT repository and uses a chroot to setup a distro install based off the Debian packages in that repo. febootstrap takes a YUM repository and uses a chroot to setup a distro install based off the RPM packages in that repo. libguestfs uses a febootstrap to install a custom Fedora 11 appliance which it boots within QEMU in order to access the filesystems. You can't use debootstrap to build a Fedora 11 appliance, and vica-verca. So if you wanted to use debootstrap you'd have to come up with a recipe that provided the same functionality as the febootstrap recipe. That's doable, but more work than just installing RPM/YUM libraries IMHO.
Regards, Daniel
On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrangeberrange@redhat.com wrote:
that repo. libguestfs uses a febootstrap to install a custom Fedora 11 appliance which it boots within QEMU in order to access the filesystems.
If the sole purpose of febootstrap is to install a custom F11 appliance to boot in qemu, why don't we prepare this image beforehand, put it somewhere on the web, so that libguestfs can just use it without needing to build this appliance again in each machine with febootstrap or debootstrap?
I read the documentation of libguestfs, but still didn't understand very well why we need to boot an OS within qemu for accessing guest file systems. Can't we just use loop devices, kpartx and lvm tools?
Am i missing something here?
Thanks a lot,
On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrangeberrange@redhat.com wrote:
that repo. libguestfs uses a febootstrap to install a custom Fedora 11 appliance which it boots within QEMU in order to access the filesystems.
If the sole purpose of febootstrap is to install a custom F11 appliance to boot in qemu, why don't we prepare this image beforehand, put it somewhere on the web, so that libguestfs can just use it without needing to build this appliance again in each machine with febootstrap or debootstrap?
We want you to be able to build everything from source. Also it allows you to customize the appliance by editing the script that builds it (eg. leaving out a feature or adding other kernel modules).
In any case, febootstrap can build the appliance in under 3 minutes on my machine, so this is hardly a problem for libguestfs.
I read the documentation of libguestfs, but still didn't understand very well why we need to boot an OS within qemu for accessing guest file systems. Can't we just use loop devices, kpartx and lvm tools?
Because this would require root, and the point of libguestfs is that nothing needs to be root. 'libguestfs.so' is a plain library - you could link it to your webserver running as nobody.nobody, and it still works. Using loop devices has other disadvantages: it's liable to leave temporary mounts & devices around if something fails, and it doesn't work at all if there are conflicting VG names.
Rich.
On Fri, Jun 12, 2009 at 10:34 AM, Richard W.M. Jones rjones@redhat.comwrote:
On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrangeberrange@redhat.com
wrote:
that repo. libguestfs uses a febootstrap to install a custom Fedora 11 appliance which it boots within QEMU in order to access the
filesystems.
If the sole purpose of febootstrap is to install a custom F11 appliance to boot in qemu, why don't we prepare this image beforehand, put it somewhere on the web, so that libguestfs can just use it without needing to build this appliance again in each machine with febootstrap or debootstrap?
We want you to be able to build everything from source. Also it allows you to customize the appliance by editing the script that builds it (eg. leaving out a feature or adding other kernel modules).
In any case, febootstrap can build the appliance in under 3 minutes on my machine, so this is hardly a problem for libguestfs.
OK I see now. I would wish that if the configure script is not able to find febootstrap, it would fall back into using a pre-cooked generic swiss army knife image file instead. That would make libguestfs pretty trivial to package for our distro or others, without needing to package yum and febootstrap etc.
I read the documentation of libguestfs, but still didn't understand
very well why we need to boot an OS within qemu for accessing guest file systems. Can't we just use loop devices, kpartx and lvm tools?
Because this would require root, and the point of libguestfs is that nothing needs to be root. 'libguestfs.so' is a plain library - you could link it to your webserver running as nobody.nobody, and it still works. Using loop devices has other disadvantages: it's liable to leave temporary mounts & devices around if something fails, and it doesn't work at all if there are conflicting VG names.
OK, thanks a lot for this insight. I would say "why not use policykit when privilege is needed, or mount images with fuse etc. ", but the possibility to link to a webserver may not work this way :) Anyway, I'm sure you considered all these options previously, sorry for taking your time to ask these again :) You know, my only problem is with febootstrap and I'm trying to find a way out of this dependency.
Thanks again,
On Fri, Jun 12, 2009 at 10:51:09AM +0200, Emre Erenoglu wrote:
OK I see now. I would wish that if the configure script is not able to find febootstrap, it would fall back into using a pre-cooked generic swiss army knife image file instead. That would make libguestfs pretty trivial to package for our distro or others, without needing to package yum and febootstrap etc.
In one sense we do offer that. You can go to Koji[1], download the latest build from here:
http://koji.fedoraproject.org/koji/packageinfo?packageID=8391
and extract the appliance directly from those RPMs. (This can even be automated because Koji has an XML-RPC interface).
rpm2cpio libguestfs-<version>.rpm | cpio -id
The appliance is the two files found in usr/lib{,64}/guestfs/*
However most Linux distros have strict rules about building from source, so this isn't an appropriate method for them.
Rich.
[1] http://koji.fedoraproject.org/koji/
On Fri, Jun 12, 2009 at 11:18:38AM +0100, Richard W.M. Jones wrote:
(This can even be automated because Koji has an XML-RPC interface).
BTW here's some OCaml code for extracting RPMs from Koji using the XML-RPC interface. Ought to give you a start:
http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-mem--devel/fil...
Rich.
On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrangeberrange@redhat.com wrote:
that repo. libguestfs uses a febootstrap to install a custom Fedora 11 appliance which it boots within QEMU in order to access the filesystems.
If the sole purpose of febootstrap is to install a custom F11 appliance to boot in qemu, why don't we prepare this image beforehand, put it somewhere on the web, so that libguestfs can just use it without needing to build this appliance again in each machine with febootstrap or debootstrap?
Providing pre-built binary OS images gets you into potentially complicated license compliance issues. You as distributor of the binary have to comply with the license of every single piece of software that went into the binary. For the Fedora Project distributing a binary image of a Fedora distro, compliance is easy because Fedora already ships all source RPMs. If a non-Fedora entity wants to ships binaries of Fedora it needs to make sure it can provide the corresponding source. It is not clearcut that it can rely on Fedora to always ship the sources for it. The safe option is to always build from source and distribute everything you used to build yourself. This is actually an argument *for* Debian using debootstrap against a Debian repo, rather Debian using feboiotstrap+YUM + Fedora repos.
Regards, Daniel
On Fri, Jun 12, 2009 at 12:29 PM, Daniel P. Berrange berrange@redhat.comwrote:
On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrangeberrange@redhat.com
wrote:
that repo. libguestfs uses a febootstrap to install a custom Fedora 11 appliance which it boots within QEMU in order to access the
filesystems.
If the sole purpose of febootstrap is to install a custom F11 appliance to boot in qemu, why don't we prepare this image beforehand, put it somewhere on the web, so that libguestfs can just use it without needing to build this appliance again in each machine with febootstrap or debootstrap?
Providing pre-built binary OS images gets you into potentially complicated license compliance issues. You as distributor of the binary have to comply with the license of every single piece of software that went into the binary. For the Fedora Project distributing a binary image of a Fedora distro, compliance is easy because Fedora already ships all source RPMs. If a non-Fedora entity wants to ships binaries of Fedora it needs to make sure it can provide the corresponding source. It is not clearcut that it can rely on Fedora to always ship the sources for it. The safe option is to always build from source and distribute everything you used to build yourself. This is actually an argument *for* Debian using debootstrap against a Debian repo, rather Debian using feboiotstrap+YUM + Fedora repos.
I see the situation. This binary distro download may also create a licensing problem for our Pardus distro. I guess this leaves the following options: 1- package yum and febootstrap for Pardus and use them 2- create a "pabootstrap" package compatible with febootstrap and build a Pardus appliance instead of fedora appliance 3- create a pre-cooked "compatible" pardus appliance image and use this one
For the last option, does it make any difference which distro is inside the appliance? Is there anything specific to Fedora? say, if we support all possible file system drivers as well as raid/lvm, would it still be needed to have Fedora inside? Is there a requirements documents for this appliance?
Thanks a lot again for your patience for my never-ending questions, I really appreciate and learn a lot from you guys.
Br, Emre
On Fri, Jun 12, 2009 at 12:37:11PM +0200, Emre Erenoglu wrote:
On Fri, Jun 12, 2009 at 12:29 PM, Daniel P. Berrange berrange@redhat.comwrote:
Providing pre-built binary OS images gets you into potentially complicated license compliance issues. You as distributor of the binary have to comply with the license of every single piece of software that went into the binary. For the Fedora Project distributing a binary image of a Fedora distro, compliance is easy because Fedora already ships all source RPMs. If a non-Fedora entity wants to ships binaries of Fedora it needs to make sure it can provide the corresponding source. It is not clearcut that it can rely on Fedora to always ship the sources for it. The safe option is to always build from source and distribute everything you used to build yourself. This is actually an argument *for* Debian using debootstrap against a Debian repo, rather Debian using feboiotstrap+YUM + Fedora repos.
I see the situation. This binary distro download may also create a licensing problem for our Pardus distro. I guess this leaves the following options: 1- package yum and febootstrap for Pardus and use them 2- create a "pabootstrap" package compatible with febootstrap and build a Pardus appliance instead of fedora appliance 3- create a pre-cooked "compatible" pardus appliance image and use this one
For the last option, does it make any difference which distro is inside the appliance? Is there anything specific to Fedora? say, if we support all possible file system drivers as well as raid/lvm, would it still be needed to have Fedora inside? Is there a requirements documents for this appliance?
Check out Richard's architecture diagram
http://libguestfs.org/guestfs.3.html#state_machine_and_low_level_event_api
AFAIK, the only critical thing for the appliance is that it runs the custom guestfsd daemon talking to over QMEMU's vmchannel device. If you get that setup correctly then the choice of distro really shouldn't make any real difference. It is mostly just a tools problem to build yourself a image with the right pieces present.
Daniel
On Fri, Jun 12, 2009 at 12:37:11PM +0200, Emre Erenoglu wrote:
I see the situation. This binary distro download may also create a licensing problem for our Pardus distro. I guess this leaves the following options: 1- package yum and febootstrap for Pardus and use them 2- create a "pabootstrap" package compatible with febootstrap and build a Pardus appliance instead of fedora appliance
Is Pardus rpm based, or in general what packaging format does it use?
3- create a pre-cooked "compatible" pardus appliance image and use this one
For the last option, does it make any difference which distro is inside the appliance? Is there anything specific to Fedora? say, if we support all possible file system drivers as well as raid/lvm, would it still be needed to have Fedora inside? Is there a requirements documents for this appliance?
Dan is right - it doesn't make any difference what distro is used inside the appliance. The only requirement is that guestfsd is running inside the appliance, and that guestfsd has access to all the other programs it uses. Common ones like sfdisk, lvm, mount, etc and some not-so-common ones too - you can find a big list in the source code, in 'appliance/make-initramfs.sh.in'.
Rich.
On Fri, Jun 12, 2009 at 12:20:14PM +0100, Richard W.M. Jones wrote:
code, in 'appliance/make-initramfs.sh.in'.
Here:
http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/make-initramfs...
Rich.
On Fri, Jun 12, 2009 at 12:21:38PM +0100, Richard W.M. Jones wrote:
On Fri, Jun 12, 2009 at 12:20:14PM +0100, Richard W.M. Jones wrote:
code, in 'appliance/make-initramfs.sh.in'.
Here:
http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/make-initramfs...
Just so you know, in the latest changeset I've renamed this file from the rather obscure 'make-initramfs.sh.in' to just 'appliance/make.sh.in':
http://git.et.redhat.com/?p=libguestfs.git;a=commit;h=2e25c4255746b144932f84...
RIch.
On Fri, Jun 12, 2009 at 5:37 AM, Emre Erenoglu erenoglu@gmail.com wrote:
I see the situation. This binary distro download may also create a licensing problem for our Pardus distro. I guess this leaves the following options: 1- package yum and febootstrap for Pardus and use them 2- create a "pabootstrap" package compatible with febootstrap and build a Pardus appliance instead of fedora appliance 3- create a pre-cooked "compatible" pardus appliance image and use this one
To chime in --
It may also be possible to come up with alternate distro-independent code for building the appliance with Buildroot from the uClibc project [ http://buildroot.uclibc.org/]; I worked on a project similar to libguestfs in the past, and buildroot worked reasonably well for me. One concern -- libraries used on host and guest may well not be compatible, so the libguestfs daemon will probably need to be built within the buildroot framework when building with this option.
(I have a very simple makefile sitting around somewhere which checks out a known-good revision of buildroot from SVN, applies a few patches, and runs an appliance build [my own appliance, not the libguestfs one]; I'm not offering to duplicate the work for libguestfs, but I can try to dig it up for reference).
Richard explained some reasons why he chose to use febootstrap as a response to my first email to this list, which I remember only inasmuch as recalling that I found those arguments compelling -- but if 'yall are interested in putting together a distribution-independent build option which doesn't require yum or friends, Buildroot might be one approach.
On Fri, Jun 12, 2009 at 07:37:01AM -0500, Charles Duffy wrote:
Richard explained some reasons why he chose to use febootstrap as a response to my first email to this list,
Here ...
http://rwmj.wordpress.com/2009/03/20/why-not-use-a-minimal-distribution/
Rich.
On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
Even though Debian/Ubunut use APT for their package mgmt system, there should not be any problem installing the YUM + RPM libraries. This should allow febootstrap to be built & run, and not impact your host OS package mgmt
Yes, of course....but since it is mentioned that febootstrap is based on debootstrap, is there a technical reason for not just supporting debootstrap alternatively. I haven't got enough background regarding debootstrap/febootstrap and libguestfs to make a judgement about this though.
I summarised the options here:
http://www.redhat.com/archives/fedora-virt/2009-May/msg00003.html
For the Debian package I went with option (1), since Debian already has yum and rpm packaged.
But to require any distribution to install yum/rpm just for this library seems a bit intrusive to me. Requiring a specific distro packaging system for a package seems a bit distribution dependant to me.
It's not like that. Just because Debian ship yum doesn't mean that anyone has to abandon apt. yum under Debian is only used where someone wants to install an RPM-based distro from a Debian host, eg. as a chroot, or in a virtual machine, or (as in this case) to build an appliance.
Rich.
Richard W.M. Jones wrote:
On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Yes, of course....but since it is mentioned that febootstrap is based on debootstrap, is there a technical reason for not just supporting debootstrap alternatively. I haven't got enough background regarding debootstrap/febootstrap and libguestfs to make a judgement about this though.
I summarised the options here:
http://www.redhat.com/archives/fedora-virt/2009-May/msg00003.html
For the Debian package I went with option (1), since Debian already has yum and rpm packaged.
Thanks, I guess in an ideal world the best solution would be to have a configure option like
--image=[febootstrap|debootstrap|fixed]
or so, and then the package would be setup to use febootstrap on redhat-based systems, debootstrap on debian-based system and fixed to use a pre-build image.
As you say, it won't be too difficult, but clearly the patch doesn't write itself ...
But such a patch to libguestfs would be accepted in your opinion?
But to require any distribution to install yum/rpm just for this library seems a bit intrusive to me. Requiring a specific distro packaging system for a package seems a bit distribution dependant to me.
It's not like that. Just because Debian ship yum doesn't mean that anyone has to abandon apt. yum under Debian is only used where someone wants to install an RPM-based distro from a Debian host, eg. as a chroot, or in a virtual machine, or (as in this case) to build an appliance.
Sorry, I didn't mean that, it was clear to me that yum/rpm wouldn't replace apt/dpkg, it's just that I think the requirement of febootsrap / yum on a debian distribution is a bit problematic.
Rich.
On Fri, Jun 12, 2009 at 11:48:41AM +0200, Tim Tassonis wrote:
Richard W.M. Jones wrote:
On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Yes, of course....but since it is mentioned that febootstrap is based on debootstrap, is there a technical reason for not just supporting debootstrap alternatively. I haven't got enough background regarding debootstrap/febootstrap and libguestfs to make a judgement about this though.
I summarised the options here:
http://www.redhat.com/archives/fedora-virt/2009-May/msg00003.html
For the Debian package I went with option (1), since Debian already has yum and rpm packaged.
Thanks, I guess in an ideal world the best solution would be to have a configure option like
--image=[febootstrap|debootstrap|fixed]
Better if it was:
--appliance=...
or so, and then the package would be setup to use febootstrap on redhat-based systems, debootstrap on debian-based system and fixed to use a pre-build image.
As you say, it won't be too difficult, but clearly the patch doesn't write itself ...
But such a patch to libguestfs would be accepted in your opinion?
Definitely yes, but you'll also want to liase with Guido Gunter as well, since he expressed an interest in doing this too.
Rich.
On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
Hi all
Just came across libguestfs and, as a qemu user, this project really sound fantastic to me.
However, when I tried to compile the latest tarball, I failed, mainly because of the inavalability of febootstrap, which obviously does not exist under ubuntu, and cannot be installed due to the lack of yum under ubuntu at least.
yum, rpm and febootstrap _are_ in Debian (as of last week), so it'll be in Ubuntu soon enough.
I've got some packages of febootstrap and libguestfs which you can try here:
http://www.annexia.org/tmp/debian/
The febootstrap package is reasonable. The libguestfs packaging is a bit crap, although it does work.
Is debian support planned, or is libguestfs designed to be a fedora-only project?
We definitely want to support other distros (not just Debian).
Guido Gunter, who I think is on this list, contacted me about doing a pure Debian port of libguestfs using debootstrap.
Rich.
BTW if anyone is confused about the architecture of libguestfs, it's all explained in the manual:
http://libguestfs.org/guestfs.3.html#state_machine_and_low_level_event_api
Rich.
-
Charles Duffy -
Daniel P. Berrange -
Emre Erenoglu -
Richard W.M. Jones -
Tim Tassonis