libguestfs python bindings

libguestfs (previous posts) now has python bindings, for the all too many Pythonistas out there.

Actually, I need some advice. Is the best way to have a module called guestfs containing a class called guestfs? Or is there a more natural way to do this in python? [Edit: See comments]

Anyhow, here is what the bindings look like at the moment:

import os
import guestfs

g = guestfs.guestfs()
g = guestfs.GuestFS() # See comments
f = open ("test.img", "w")
f.truncate (500 * 1024 * 1024)
f.close ()
g.add_drive ("test.img")
g.launch ()
g.wait_ready ()
g.pvcreate ("/dev/sda")
g.vgcreate ("VG", ["/dev/sda"])
g.lvcreate ("LV1", "VG", 200)
g.lvcreate ("LV2", "VG", 200)
if (g.lvs () != ["/dev/VG/LV1", "/dev/VG/LV2"]):
    raise "Error: g.lvs() returned incorrect result"
g.sync ()
del g

os.unlink ("test.img")

Of course we also have Perl, OCaml, C, C++ and shell script bindings too.

About these ads

6 Comments

Filed under Uncategorized

6 responses to “libguestfs python bindings

  1. guestfs.GuestFS is more natural I think.

  2. rich

    Thanks Nathaniel. I’ll change that before I upload it.

  3. loupgaroublond

    Does a GuestFS normally take multiple images on the filesystem? namely, do you normally call add_drive more than once ever? Or is GuestFS in a way just a wrapper over the file like object that is a single .img file on the filesystem?

    If it’s always one, then you might want the code to look like this:

    g = GuestFS(‘foo.img’)

    with the possible alternatives

    g_file = file(‘foo.img’, ‘rwb’)
    g = GuestFS(g_file)

    g_handle = os.open(‘foo.img’, os.RW)
    g = GuestFS(g_handle)

    Furthermore, you might consider this:

    pvcreate returns a PV instance, that can be passed to vgcreate; that returns a VG instance, that can be used in lvcreate, etc…

    then:

    some_pv = g.pv(‘/dev/sda1′)
    type(some_pv) == PV

  4. rich

    loupgaroublond, kind of ..

    The Python binding isn’t very natural Python, because it slavishly follows the C API.

    It’s possible to make a more natural binding, but not at the same time (a) following changes in the C API, and (b) remaining sane. The reason is that we autogenerate the bindings for multiple languages (C, Perl, OCaml, Python, shell and maybe “documentation” if that counts as a language).

  5. rich

    I should add:

    pvcreate returns a PV instance, that can be passed to vgcreate; that returns a VG instance, that can be used in lvcreate, etc…

    This can’t happen. The design of the library prevents us from implementing something like this.

  6. loupgaroublond

    That’s what i figured. This is something that would be in the Python layer only, and not inherent to the library itself. If anything, it would be a wrapper on top of the C-like API that got imported.

    Since you’re using strings as identifier, the object would contain a string that it ‘hides’ from the programmer. It’s just a slightly different way to do things that fits a more object oriented model.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s