[Slackbuilds-users] RFC: qemu and aqemu

Matteo Bernardini matteo.bernardini at gmail.com
Fri Feb 3 21:16:55 UTC 2012


hope anybody don't mind if I share some thoughts on this :D

2012/2/3 Robby Workman <robby at rlworkman.net>:
> First, how about a symlink at /usr/bin/qemu-kvm pointing to
> /usr/bin/qemu-system-x86_64, i.e.:
>  ( cd $PKG/usr/bin ; ln -s qemu-system-x86_64 qemu-kvm )
> This is so that e.g. aqemu can easily find it without the user
> having to manually tell it where the KVM-equivalent binary is
> located.  I don't think there's any downside to this, and in fact,
> if it were the only change I had, I'd just make it in our repo and
> be done with it.  However...

I have the qemu-system-x86_64 binary linked to just "kvm", for using
it with libvirt: I know it's another example of Red Hat
customizations, but I remember a discussion of not much time ago on
LKML in which Pekka Enberg renamed his new in-kernel kvm emulator
kvm-tool to follow this "standard"...

this way is also automatically found

http://ompldr.org/vY20xaA/screen.png

> The second suggested change is to strip the package down quite a
> bit.  Basically, I'd like to remove everything that's also shipped
> with the regular qemu package so that there's no overlap.  This
> would mean that our qemu-kvm would (optionally) depend on our qemu
> package.  Any thoughts on this?

I think the present state is optimal: qemu-kvm should be used in every
case kvm processor extensions are available, while qemu can be useful
in the few cases of needing virtualization on old processors (it's
very uncommon today to have x86 processors with no virtualization
extensions); frankly, I see no cases in which the use of both can be
useful...

my 2 cts :)

Matteo


More information about the SlackBuilds-users mailing list