guestfish kicks ass .. maybe

Glauber “glommer” Costa says guestfish is “the most kicking ass software ever”. Cheers Glauber. I wrote virt-rescue for glommer because he wanted to “fsck” interactively to fix his broken virtual machine. Libguestfs wasn’t designed for making ad-hoc interactive changes, but glommer gave me the idea that we could reuse the libguestfs appliance quite easily to make an interactive rescue shell for virtual machines, analogous to the rescue CDs that are common for physical machines. And so virt-rescue came about.

Another couple of articles have appeared about libguestfs recently. This article [pdf] is the better one written by Red Hat’s Sadique Puthen for Linux For You magazine.

The not so good one appeared in SearchEnterpriseLinux.com and is little more than blogspam, and I speak as someone who used to write similar trash (it’s very attractive to Google, and before Red Hat I used to work in SEO). I don’t think the author actually tried guestfish or libguestfs, it seems he just copied stuff out from our manpages. I doubt SearchEnterpriseLinux care since it is my opinion that they exist to make widely syndicated spam articles just to attract page views by misleading users of search engines.

11 Comments

Filed under Uncategorized

11 responses to “guestfish kicks ass .. maybe

  1. Shane Falco

    I agree that guestfish does rule, but I wish I could use it on systems other than Fedora. Under my RHEL5 Xen servers (using the EPEL repository) I get this form of message when running guestfish or virt commands such as virt-df:

    [root@xenhost2 /]# guestfish -i /dev/vg_xen/lv_mysqlhost
    external command failed: PATH=’/usr/lib64/guestfs’:$PATH libguestfs-supermin-helper ‘/usr/lib64/guestfs’ x86_64 epel-5 /tmp/libguestfsjwZwA8/kernel /tmp/libguestfsjwZwA8/initrd at /usr/bin/virt-inspector line 217.

    It’s these hosts where I need it most!

    • rich

      Shane, please try the latest package from the epel-testing repository:

      yum --enablerepo=epel-testing install libguestfs
      

      (or download the latest el5 package from here)

      If that doesn’t work can you run libguestfs-test-tool and copy the complete output into a new bug report at http://bugzilla.redhat.com/

      • Shane Falco

        Thanks. Right now that’s missing the /usr/lib/libmagic.so.1 but I’m sure I’ll be able to track it down.

  2. Moshe

    Hi,

    I am running CentOS 5.5 x64 (2.6.18-194.3.1.el5xen #1 SMP Thu May 13 13:49:53 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux)

    tried to install using EPEL:

    “yum install ‘*guestf*'”

    Missing libmagic.so.1 dependency error (/usr/lib/libmagic.so.1 missing)

    libmagic.so.1 lives in /usr/lib64/libmagic.so.1
    so I made a sym link from /usr/lib to the file in /usr/lib64. same dependency missing error.

    then i copied the libmagic.so.1 to /usr/lib
    ditto…

    I then installed guestfish alone

    yum install guestfish.

    installs fine…until i run guestfish:

    error:

    libguestfs-supermin-helper: failed to find a suitable kernel.

    Although it obviously looks like a kernel issue to be thorough I downloaded/installed the latest rpms (1.2.9-1.el5.1.x86_64)

    same error…

    Thank you. Any advise?

    • rich

      Please don’t copy files around. If it doesn’t install from ‘yum’ then there’s something wrong that copying files around at random won’t help with.

      In this case, please try the update from epel-testing:

      yum --enablerepo=epel-testing install '*guestf*'
      

      Actually the libmagic error is caused by multilib brokenness. Try:

      yum --enablerepo=epel-testing install '*guestf*.x86_64'
      

      This error:

      libguestfs-supermin-helper: failed to find a suitable kernel.
      

      is usually caused because you’re trying this on a Xen guest. The workaround is just to install an ordinary (non-Xen) kernel in the guest. For more information, see: https://bugzilla.redhat.com/show_bug.cgi?id=539746#c9

      If you’re still having problems, take a look at this: http://libguestfs.org/guestfs.3.html#bugs

  3. Moshe

    Hi Rich,

    This ‘*guestf*.x86_64′ fixed the install issues.

    Unfortunately i am still receiving the following error message when I try and run the virt-inspector or guestfish. Error message is below.

    This is a xen host machine.

    libguestfs-supermin-helper: failed to find a suitable kernel.
    I looked for kernels in /boot and modules in /lib/modules.
    If this is a Xen guest, and you only have Xen domU kernels
    installed, try installing a fullvirt kernel (only for
    libguestfs use, you shouldn’t boot the Xen guest with it).
    external command failed: PATH=’/usr/lib64/guestfs’:$PATH libguestfs-supermin-helper ‘/usr/lib64/guestfs’ x86_64 epel-5 /tmp/libguestfsUQXVXk/kernel /tmp/libguestfsUQXVXk/initrd at /usr/bin/virt-inspector line 215.

    Any further ideas?

    ~Moshe

    • rich

      You need to install a non-Xen kernel, ie. any kernel which isn’t named “*xen*”. You don’t need to boot from it, it just has to exist under /boot and /lib/modules.

  4. Moshe

    Hi Rich,

    That worked! Thank you!

    just as an FYI I am getting one more error after i kick off any command.

    Could not open ‘/dev/kqemu’ – QEMU acceleration layer not activated: No such file or directory

    /dev/kqemu device does not exist.

    It does not seem to be affecting operations at all.

    ~Moshe

  5. moshe

    Thanks again!

  6. Sig

    any debian 5 love?

    Attempting to backport the packages from testing to lenny is proving to be a NIGHTMARE!

    =/

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