Re: qemu - some confusions
Hi.
On Fri, Sep 11, 2020 at 09:46:54PM +0200, Kamil Jońca wrote:
> Dan Ritter <dsr@randomstring.org> writes:
>
> > Kamil Jo?ca wrote:
> >> Dan Ritter <dsr@randomstring.org> writes:
> >>
> >>
> >> Sorry, I do not understand.
> >> If LSI 53c810 / 53c895a is not supported, how output
> >> "qemu-system-x86_64 -device help" should be interpreted?
> >>
> >> KJ
> >
> > Read Reco's message.
>
> Sorry, still does not understand that: "LSI 53c810 / 53c895a is not
> supported by qemu"
Long story short.
There was (and still is) QEMU. It does many things (and most of them
aren't restricted to x86), and it's a truly community project. Many
projects say "anyone can contribute", but in the case of the QEMU it's
actually true. That was a bright side, but there is a dark side of QEMU
- it says it can do many things, but quality of doing them varies.
On the other hand, there's libvirt, which is a Red Hat-controlled
project. These days people see it as a glorified QEMU wrapper, but
actually it can do more (but again, the quality of doing so varies).
Contrary to the QEMU, libvirt does best what Red Hat needs it to do, no
more, no less.
It's hardly surprising that Red Hat cherry-picks certain QEMU
capabilities and declares them "supported" (i.e. - "worked for our
paying customers"), and deems everything else as "not supported" (i.e. -
"you're on your own").
What (probably) Dan meant is "you're trying to use QEMU feature that is
not approved by Red Hat". By itself it does not mean that the feature in
question is somehow bad, or incomplete, or will corrupt your data or
whatever. It means exactly what's stated above, no more and no less.
Here, at this list, people are rarely using QEMU directly, without the
kludges like libvirt. The reason being - one of the few mature programs
to deal with QEMU is called virt-manager, and it's built on top of
libvirt. So, unless specified otherwise, here QEMU = libvirt, and
restrictions of the latter apply to the former.
Reco
Reply to: