(apologies if you've already seen this, my SMTP was a little confused this morning when i sent it initially.)
yesterday, in my ongoing quest to turn my brain to yogurt, i was playing with richard jones' guestfish and libguestfs, and tried to mount the root filesystem from the disk image that's now sitting in my home directory so i can get at it without needing root permissions.
$ guestfish
<fs> add f1164.img <fs> run
... wait wait wait ...
<fs> mount /dev/f1164guest/lv_root /
libguestfs: error: mount: /dev/f1164guest/lv_root on /: mount: unknown filesystem type 'ext4'
i mentioned this off-line to richard, who said he was just getting a newer version of the libguestfs packages together, so i just upgraded to 1.0,6 and:
$ guestfish
<fs> run
open /dev/kvm: Permission denied Could not initialize KVM, will disable KVM support qemu: loading initrd (0x13acad0 bytes) at 0x0000000016c43000
<fs> pvs
/dev/sda2
<fs> lvs
/dev/f1164guest/home /dev/f1164guest/lv_root /dev/f1164guest/lv_swap
<fs> mount /dev/f1164guest/lv_root / <fs> mounts
/dev/mapper/f1164guest-lv_root
<fs>
in short, ext4 filesystem support now appears to work, but there's still the issue (perhaps addressed earlier) that non-root users don't have access to KVM support but, from the perspective of libguestfs, does that really matter?
anyway, ext4 support is in there so things are working, at least to the extent that i've tested it.
rday --
p.s. i could have sworn i didn't get that /dev/kvm perms error yesterday. did something about that change since version 1.0.4?
$ ls -l /dev/kvm crw-rw---- 1 root root 10, 232 2009-04-22 05:16 /dev/kvm $
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ========================================================================
On Wed, Apr 22, 2009 at 03:20:14PM -0400, Robert P. J. Day wrote:
in short, ext4 filesystem support now appears to work, but there's still the issue (perhaps addressed earlier) that non-root users don't have access to KVM support but, from the perspective of libguestfs, does that really matter?
KVM makes things do a lot faster, which is always nice. You can do the following:
# chmod o+rw /dev/kvm
You have to do (just) that command as root, but after that qemu-kvm and guestfish itself can all be run as non-root, and will benefit from KVM acceleration.
There is the question of whether it's safe to allow non-root users to use KVM. Generally the answer seems to be that it's OK. But if you are running a production service, or have lots of untrusted users or guests, then maybe it's better not to turn this on just yet.
anyway, ext4 support is in there so things are working, at least to the extent that i've tested it.
p.s. i could have sworn i didn't get that /dev/kvm perms error yesterday. did something about that change since version 1.0.4?
Yes, libguestfs changed to detect and enable KVM by default. Before today it wasn't using KVM at all.
Rich.
On Wed, 22 Apr 2009, Richard W.M. Jones wrote:
On Wed, Apr 22, 2009 at 03:20:14PM -0400, Robert P. J. Day wrote:
in short, ext4 filesystem support now appears to work, but there's still the issue (perhaps addressed earlier) that non-root users don't have access to KVM support but, from the perspective of libguestfs, does that really matter?
KVM makes things do a lot faster, which is always nice.
which inspires the obvious question -- is kvm *required* for any libquestfs functionality? speed is always nice, but it's important to know that, even if things are slow, they will still work equally well.
You can do the following:
# chmod o+rw /dev/kvm
You have to do (just) that command as root, but after that qemu-kvm and guestfish itself can all be run as non-root, and will benefit from KVM acceleration.
or, for permanence, add the appropriate udev rule, which is what i prefer, since it persists across reboots.
p.s. i could have sworn i didn't get that /dev/kvm perms error yesterday. did something about that change since version 1.0.4?
Yes, libguestfs changed to detect and enable KVM by default. Before today it wasn't using KVM at all.
gotcha, thanks.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ========================================================================
On Wed, Apr 22, 2009 at 05:27:12PM -0400, Robert P. J. Day wrote:
On Wed, 22 Apr 2009, Richard W.M. Jones wrote:
On Wed, Apr 22, 2009 at 03:20:14PM -0400, Robert P. J. Day wrote:
in short, ext4 filesystem support now appears to work, but there's still the issue (perhaps addressed earlier) that non-root users don't have access to KVM support but, from the perspective of libguestfs, does that really matter?
KVM makes things do a lot faster, which is always nice.
which inspires the obvious question -- is kvm *required* for any libquestfs functionality? speed is always nice, but it's important to know that, even if things are slow, they will still work equally well.
Short answer: No. It just makes things go faster.
Longer answer: The QEMU and KVM codebases are slightly different (although converging). This means that by using QEMU versus KVM you may tickle a bug in one which is not in the other. So it goes.
You can do the following:
# chmod o+rw /dev/kvm
You have to do (just) that command as root, but after that qemu-kvm and guestfish itself can all be run as non-root, and will benefit from KVM acceleration.
or, for permanence, add the appropriate udev rule, which is what i prefer, since it persists across reboots.
Indeed. I never worked out udev, so I tend to add the required chmod commands into my /etc/rc.local. Luckily no one employs me as a sys-admin any more ...
Rich.
On Wed, Apr 22, 2009 at 09:17:29PM +0100, Richard W.M. Jones wrote:
On Wed, Apr 22, 2009 at 03:20:14PM -0400, Robert P. J. Day wrote:
in short, ext4 filesystem support now appears to work, but there's still the issue (perhaps addressed earlier) that non-root users don't have access to KVM support but, from the perspective of libguestfs, does that really matter?
KVM makes things do a lot faster, which is always nice. You can do the following:
Thanks for this update, but autodetection does not work for me. I have an fedora.i386 system installed on my machine and autodetection tests only x86_64. Can you please add i386 or x86 arch?
I think betted detection is for qemu-kvm binary. Using qemu-kvm on systems without hardware virtualization display:
open /dev/kvm: No such file or directory Could not initialize KVM, will disable KVM support
but works well as normal qemu without accelerated virtualization.
Another problem. Using:
/autogen.sh --with-java-home=no --with-qemu=/usr/bin/qemu-kvm
displays: checking for /usr/bin/qemu-kvm... no configure: error: qemu must be installed
even if I have qemu-kvm binary in this path:
[ondrejj@work libguestfs]$ ls /usr/bin/qemu-kvm /usr/bin/qemu-kvm*
But --with-qemu=qemu-kvm works.
SAL
On Thu, Apr 23, 2009 at 08:22:13AM +0200, Ján ONDREJ (SAL) wrote:
Thanks for this update, but autodetection does not work for me. I have an fedora.i386 system installed on my machine and autodetection tests only x86_64. Can you please add i386 or x86 arch?
You've actually got an i386 machine which supports KVM? They are very rare. In fact I have one too, but they were only produced for a few months (a tiny number of Intel Core 1 microprocessors).
Upstream KVM has stopped supporting i386 and now only supports x86-64, which is why I didn't bother detecting KVM on anything which isn't x86-64.
Or are you running an i386 kernel on an x86-64 machine? Not sure whether or not KVM can work in this case.
/autogen.sh --with-java-home=no --with-qemu=/usr/bin/qemu-kvm
[...]
But --with-qemu=qemu-kvm works.
This seems to be a problem with the AC_PATH_PROG macro. Just use the latter and it should be OK.
You can also do things like:
./configure --with-qemu="qemu-kvm qemu"
which will try looking for qemu-kvm first, and qemu second.
Rich.
On Thu, Apr 23, 2009 at 07:29:33AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 23, 2009 at 08:22:13AM +0200, Ján ONDREJ (SAL) wrote: You've actually got an i386 machine which supports KVM? They are very rare. In fact I have one too, but they were only produced for a few months (a tiny number of Intel Core 1 microprocessors).
Agree. My current hardware is x86_64 capable, but my notebook isn't and notebook has hardware virtualization support.
Upstream KVM has stopped supporting i386 and now only supports x86-64, which is why I didn't bother detecting KVM on anything which isn't x86-64.
Hmm.
Or are you running an i386 kernel on an x86-64 machine? Not sure whether or not KVM can work in this case.
Yes, I need to upgrade to x86_64 (or reinstall) but no time now. And I think with Fedora 11 it will update my kernel to 64-bit, what is enough for my workstation. There are still lots of programs, which are not 64-bit and I don't need both i386 and x86_64 libraries on my system. I know about limitations, but it's working well this way for me.
/autogen.sh --with-java-home=no --with-qemu=/usr/bin/qemu-kvm
[...]
But --with-qemu=qemu-kvm works.
This seems to be a problem with the AC_PATH_PROG macro. Just use the latter and it should be OK.
This was with current git version.
You can also do things like:
./configure --with-qemu="qemu-kvm qemu"
which will try looking for qemu-kvm first, and qemu second.
OK, this works too.
May be autodetection for java and kvm as default can be good for testers. Now I still have to add these options: ./configure --with-qemu="qemu-kvm qemu" --with-java-home=no
SAL
On Thu, Apr 23, 2009 at 07:29:33AM +0100, Richard W.M. Jones wrote:
Upstream KVM has stopped supporting i386 and now only supports x86-64, which is why I didn't bother detecting KVM on anything which isn't x86-64.
I'm wrong about this, and upstream KVM is alive and well and supporting many different platforms:
i386, x86_64, ia64, s390, ppc
Rich.
-
Ján ONDREJ (SAL) -
Richard W.M. Jones -
Robert P. J. Day