[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU 3.0 ?

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] QEMU 3.0 ?
Date: Thu, 23 Nov 2017 13:57:09 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, Nov 23, 2017 at 02:51:51PM +0100, Paolo Bonzini wrote:
> On 23/11/2017 14:13, Peter Maydell wrote:
> > On 23 November 2017 at 13:02, Paolo Bonzini <address@hidden> wrote:
> >> In theory I don't like it either (and I hadn't thought about it until
> >> today).  In practice, qemu-kvm is not going away from
> >> blogs/scripts/tutorials in a decade, so we might as well embrace it...
> > Isn't this distro-specific? In ubuntu by default there isn't
> > any wrapper, and if you do install the optional 'qemu-kvm' package
> > the wrapper it provides is /usr/bin/kvm, not /usr/bin/qemu-kvm.
> Fedora also has no wrapper in the qemu-system-x86 package, and only
> "qemu-kvm" installs one.  In practice if you install the virtualization
> package group you get it.  What about Ubuntu?

Actually not quite correct. Historically '/usr/bin/qemu-kvm' is provided
by whichever 'qemu-system-$ARCH'  RPM matches your name arch. With recent
modularization, its now provided by 'qemu-system-$ARCH-core'. So everyone
will have qemu-kvm if they've installed the sub-RPM matching their host

The 'qemu-kvm' RPM is just an empty RPM that depends on whichever
'qemu-system-$ARCH' matches your host, and thus provides '/usr/bin/qemu-kvm'
This is just convenience to let downstream app RPMs depend on qemu-kvm
instead of a big set of per-arch conditionals.

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]