Using guestfs.kill_subprocess()
by Chris Lalancette
Hey Rich,
In the past I know you have mentioned that using
guestfs.kill_subprocess() isn't strictly necessary after you are finished
using libguestfs. I believe you said that in the python bindings, that
step would happen automatically when the object goes out of scope and the
__del__ method is called. However, since it never seemed to harm anything
and I wanted to be extra safe, I always called guestfs.kill_subprocess() in
Oz, without apparent harm.
However, Richard Su has been investigating an issue where
guestfs.kill_subprocess() actually does cause harm. I believe the
situation is that running Oz (and hence libguestfs) simultaneously from two
threads in the same process causes the entire process to hang. If we
remove the guestfs.kill_subprocess(), the problem goes away. rwsu, can you
please fill in a bit more detail here, as I'm not intimately familiar with
the issue? Things like host OS, libguestfs version, etc etc would be
helpful. Also confirmation that the problem is indeed in the
multi-threaded environment of the image factory like I think it is.
rjones, do you have any ideas here? I'm going to merge rwsu's patch
to remove the call to kill_subprocess(), but I thought it would be worth a
little more digging into why it was happening.
Thanks,
Chris Lalancette
13 years
Building PXE Bootable images using the libguestfs toolchain
by Jeff Schroeder
As part of the oVirt Node[1] project, I'm going to P.O.C. a version of
the node using febootstrap 2.x instead of livecd-creator. The main
reasons in doing this is for allowing a r/w root filesystem without
some hacky overlayfs and just to see if it can be done. On IRC,
rwmjones mentioned a few issues he ran into with febootstrap 2.x where
some rpms had %post scripts which aren't really safe inside a chroot.
It would be nice to get some more detail as to what problems exactly
have been encountered and what is the best solution for mitigating
this. It is a lot trickier to setup, but perhaps lxc would be better
than chroot for this type of thing?
The Node project is also interested in creating nodes using other
Linux distributions such as Debian or Ubuntu. That is why febootstrap
3.x really excited me until realizing it is for supermin appliances
only. What issues and challenges have you already encountered doing
something like this? It would be nice, but perhaps impossible to find
a mostly distribution neutral way of doing these things. Creating a
"chrootable" filesystem and then running image-minimizer seems like a
decent plan of attack for me.
[1] https://fedoraproject.org/wiki/Ovirt_Node
--
Jeff Schroeder
Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com
13 years
libguestfs and md devices
by Matthew Booth
We've recently discovered that libguestfs can't handle guests which use
md. There are (at least) 2 reasons for this: Firstly, the appliance
doesn't include mdadm. Without this, md devices aren't detected during
the boot process. Simply adding mdadm to the appliance package list
fixes this.
Secondly, md devices referenced in fstab as, e.g. /dev/md0, aren't
handled correctly by inspection. This looks a bit more complicated. In
my test guest, the guestfs appliance automatically creates the 2 md
devices as:
* /dev/md/localhost:localdomain:0
* /dev/md/localhost:localdomain:1
These are symlinks to ../md126 and ../md127 respectively. I haven't yet
worked out why they aren't created as md0 and md1 as in the guest. I
think here we need to either work out how to make the appliance detect
and use their names (if this is even possible), or to map the names
appropriately using information from /dev/md/md-device-map in the
appliance's root, and /etc/mdadm.conf in the guest's root.
I don't currently think we'll need any new apis for this. I'm not
convinced we need apis for creating and managing md devices, for
example. We could do with a test for inspection of a guest which uses md
devices, which would obviously require creating that guest. However, we
can frig that for the test using debug sh "mdadm ...".
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
13 years
Python API for Resizing the disk
by vipul borikar
Is there Python Binding for Resizing the Image just like "virt-resize" does?
--
Thanks
Vipul Borikar
"Our task must be to free ourselves...by widening our circle of compassion
to embrace all living creatures and the whole of nature and its beauty."
13 years
