Solved get into qemu

[Deleted member 43773]

Post-Edition December 27th, 2022:
you may skip to last post.

***************************************

hi.

Since I've read a lot about many of you guys are running vm (seems to me people running os really natively on actual hw are going to be extincted soon. )

At the very moment I'm just trying to "simply" get some sound out of the thing.
(seems not to be the main task, since most issues are about networking)

With '-soundhw help' I receive a list - but this option is 'deprecated'.
With '-device help' I get even more sounddevices, but neither of them gives me sound if I load them as I understood the man/doc/output.
Only '-soundhw all' does. But the result is not really enjoyable.
I cannot figure out which device is actually used. I don't find neither a log nor an option (such as -v verbose) that gives me more info what's happening...

Since I not wanna 'tune' the sound, only, I also want to play a bit with the vm... cpus, corenumbers... - get a bit into it.

I'm trying for several days now.
I reached the point when trial & error stops being fun.
I want/need something more systematically to dig into.

Frankly the official doc/man page is ... insufficient, at least for a newb - at least for me ?.
I also have the feeling the doc lags behind its software.
(I hate that. Software ain't finished when the doc isn't!)

Since I cannot make much of the given examples (they include common placeholders like 'example'... )
and nearly anything I find on the internet so far is deprecated.
There are sides where people made an effort to write an introduction to get into qemu. But quite all of those are deprecated (some are >10y old, not updated since) producing errormessages only, or be just a copy of the doc again, or being useless in other ways....
(Even freebsd-wiki/qemu in my eyes is nearly useless while outdated. e.g. there seems to be no kqemu anymore.)

However:
I understood the condition to use qemu is you know qemu.
or at least vm (.... what is numa?, what is smp?, what is node?, what is...? what is...? what is..... ?????? ...)

Anybody any suggestions/recommondations something (really) useful to get into vm/qemu?

Thanks in advance!

 

[jardows]

I've not used qemu, but if you want to start with virtualization, first ask what you want to accomplish? Then you can determine the best tool for the job.

If you just want to get started and learn a bit about virtualization, or simply want to try out different operating systems, I would recommend by starting with emulators/virtualbox-ose. It comes with a nice graphical interface and pretty much "just works" without much configuration.

 

[_martin]

Qemu is like a swiss knife of virtualization. But that doesn't mean it should be your goto hypervisor, especially on FreeBSD (no kvm support). And yeah, qemu's (ever-changing) syntax can be pain. I heard good things about virtsh but never used it myself.

I agree with jardows, if you are starting with the virtualization and you want to see "what are those VMs about" use VirtualBox. It has a nice GUI, you can setup VM comfortably from there. You can even try FreeBSD's native hypervisor - bhyve.

Also, what is your goal? What do you want to install, what are you running (guest) from qemu now?

 

[Deleted member 43773]

Thanks for the answers.
I will check out bhyve, too.


Post-Edition December 27th, 2022:
No recommendation on using qemu on FreeBSD.
On FreeBSD qemu is not really useful.

I am a user.
I'm no developer. (Well, I am, but not on software, nor operating systems.)
To me a virtual machine is not a crossplatform development tool, neither an experimental toy fun just to have and tinker with it.
Frankly I neither really care which to use,
if it's a virtual machine, a runtime environment, a hypervisor, a monitor, an emulator, whatever...
I don't care as long as the software I want to use works -
- smoothly, not gooey, with crystal sound, not laggy, not noisy...

To me simply those are helpers, only to run software that does not run natively on my system.
I need to use software, not the environment.
The environment that makes it run is a necessity, neither the plot, nor the main actor.
So my effort to be spent on the environment has to be as less as possible.

If a user spents too much time on the environment, being prevented of being really productive, then something is wrong.
I call this "linux" - tinker with a system just to tinker with it for itself.
qemu is very linux.

qemu offers a lot of advantages:

• alternative to Oracle, or others
• CLI-interface, no GUI - as I explained above to me this is an advantage. Among others you may finetune the VM to the point (may. See disadvantages.)
• qemu is very flexible; e.g. you can import virtual drives from others
• qemu comes with a lot of additional tools, such as for resizing, or transforming virtual disks (those could be the only reason to install qemu)
• ...

qemu has two knock-out-criteria:

• under FreeBSD no support for using CPU's virtualization features; there is no kqemu kernelmodule to load (anymore?). So if you're not running very small, "vintage" software, qemu is slow. Too slow for practical use.
• the documentation sucks

You may say: "Wait a minute... qemu's official documentation looks pretty good!"?
Well, yeah, it looks good, but it ain't.?

If you tinker a bit with qemu you'll soon run into situations like:
'...this function/option is obsolete - don't use it anymore!'
I got this from your documenation!
But...okay... - what shall I use then?
No answer.
So you trial-and-error for hours,...days to get it working somehow halfway usable...
So finally it works. Not nice, but it works.
Because of the lack of having anything else, you ignore the warning and use it.

Then an update occurs.
You'll receive no warnings anymore, but termination and error messages like:
'...this obsolete function has been removed...' (if even)
What should I use now?
No answer.
Thank you so very much!
Working points removed without naming replacements, which ment: removed, only.
You slaved days on this sh#t to get some (bad) sound. Now it's gone.
If this is progress in development, stop developing!
I mean it.

Such does not produce enthusiasm for me.
?️ As a user you feel like standing alone in the desert, *tumbleweed tumbles by*...

You're sitting in front of the doc
and trying to understand things like:
"
-audiodev sdl,id=id[,prop[=value][,...]]
Creates a backend using SDL.
"
....right...ehm.... ? ... - WHAT?! ?
...could you used it in an example?
useless.
The examples look quite the same. ?‍?
?

You may write a doc this way, if there would be any general explanation
how those weird combinations of commas, parenthesis,... to be read, to make any sense.
'cause for example [ ] does not necassarily mean 'optional' (as you may think) - in some cases those are real to be typed parts of parameters, such as a leading comma, in other cases they are optional options as you know them from the command-syntax of man-pages....
But when, which, how,... - what?!
Don't try to find explanations within the docs.
I did.
There aren't any.


So you're ending up desperately fumbling hours - days - of endless trial-and-error-attempts,
producing error messages only...
- the only results are wasted time, frustration, and feeling stupid.

Documenation is something else.
Or as a former teacher always said:
'So goes it not.'

You'll also quickly find lots of websites some nerds euphoric about qemu started to additionally document.
Forget those.
If they are not telling something you already knew, they are all obsolete.
Most haven't been updated for years, others are ancient.
Giving me the clue,
that I'm not the only one turned his back on qemu,
it's not worth the effort to dig in,
it changes quicker as you may catch up with desperate trial-and-error attempts.
That's not the way things should be.

In my eyes qemu is typical linux:
A bunch of nerds lost in hacking on a softwareproject, focused on the source-code and quick upgrade releases, only,
missing the crucial core point completely:
the user and the usage

If the documenation is useless, so is the software.

And because there is always someone to disagree:
How thef#ck shall a software be used, if no-one knows how?!
Digging the source-code ain't the answer.
If you have to understand the source you could write it yourself.
That's why there are documentations:
To explain a not included no-developer how to use the software,
to make software usable for users - to be used!
?

Peace out!