Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QEMU 7.0

qemu.org

Post reply on HN
Print view View original

51–60 of 97 posts

Re: QEMU 7.0

#51

Post by mysterydip »

ori_b wrote: post #45
anderspitman wrote: post #44

First off I want to make it clear that this isn't intended as criticism. I recognize the QEMU devs are busy, do incredible work, and don't owe me anything. That said, I started a project recently that I'm very excited about. It wouldn't be possible without QEMU. I've had to get deeper into somewhat lower-level features, and it's likely I'll have to implement some new devices and interfaces for QEMU itself eventually.…

> Any suggestions for how to get help learning QEMU as a "power user" hoping to eventually contribute as a dev? Use the IRC channel. Or the mailing list.

> My questions on the user mailing list go mostly unanswered.

Re: QEMU 7.0

#52

Post by anderspitman »

mysterydip wrote: post #51
ori_b wrote: post #45

Earlier quoted context omitted.

> Any suggestions for how to get help learning QEMU as a "power user" hoping to eventually contribute as a dev? Use the IRC channel. Or the mailing list.

> My questions on the user mailing list go mostly unanswered.

They might be referring to the dev mailing list. I've only tried the user mailing list so far.

Re: QEMU 7.0

#53

Post by quux »

_8j50 wrote: post #24

I like QEMU a lot but VirtualBox is my goto because the cli commands work fairly reliably and simply and I'm ashamed to say the simplicity of the UX is compatible with my laziness. For server workloads KVM/Qemu is great but imho, Vbox or Fusion are the best in my experience. Does anyone know if there are Qemu wrappers with a nice UI/UX? My current use cases aside, it's amazing the number of nice use cases Qemu is mad…

On the Mac UTM is a nice wrapper around QEMU. They have a convenient gallery of preconfigured guest machines you can use and it's easy to export the QEMU cli command for any of the hosts you config in UTM if you need to.

https://mac.getutm.app

Re: QEMU 7.0

#54

Post by lxgr »

_8j50 wrote: post #39
cpach wrote: post #28

Earlier quoted context omitted.

“Does anyone know if there are Qemu wrappers with a nice UI/UX?” What operating system are you on?

Linux and MacOS

UTM is very nice on macOS.

Re: QEMU 7.0

#55

Post by pm215 »

anderspitman wrote: post #44

First off I want to make it clear that this isn't intended as criticism. I recognize the QEMU devs are busy, do incredible work, and don't owe me anything. That said, I started a project recently that I'm very excited about. It wouldn't be possible without QEMU. I've had to get deeper into somewhat lower-level features, and it's likely I'll have to implement some new devices and interfaces for QEMU itself eventually.…

The -devel list is dominated by patches just because that's how our workflow works; but if you have a technically focused question or one that's about the internals or the source code then you should feel free to ask it there (though of course I can't promise anybody will answer it...) The user list is lower traffic and tends to be more "users helping other users with straightforward queries"; not all the developers read it.

The documentation is indeed not great, and documentation of the internals is worse. I think this is a mix of people often not having the time or priority to write documentation, being on the inside and not seeing the gaps in the docs that are obvious from outside, and sometimes the docs not having a structure that gives a simple place to add the needed new information. Plus as a low-level tool we assume to some extent that most users will be using a higher-level management app like libvirt which has hopefully better UX and docs. I don't have any bright ideas here, so if anybody does I'd be interested in them. Bug reports of the form "functionality X is undocumented" would be useful too I think.

Re: QEMU 7.0

#56

Post by asguy »

anderspitman wrote: post #44

First off I want to make it clear that this isn't intended as criticism. I recognize the QEMU devs are busy, do incredible work, and don't owe me anything. That said, I started a project recently that I'm very excited about. It wouldn't be possible without QEMU. I've had to get deeper into somewhat lower-level features, and it's likely I'll have to implement some new devices and interfaces for QEMU itself eventually.…

> Any suggestions for how to get help learning QEMU as a "power user" hoping to eventually contribute as a dev? I'd happily pay for consulting if I knew the right people to ask.

I'm not being cheeky: read the source.

I worked with qemu for years, and the only way I could get real answers was to find the libvirt functionality and work backwards from it. Once I got good enough with that, I could navigate the qemu codebase on my own and just read.

Almost all the docs are going into libvirt, and libvirt's (IMHO) terrible abstractions. The reality is that almost all the investment in qemu's user-facing capabilities are done via libvirt, so it makes sense.

Re: QEMU 7.0

#57

Post by cpach »

anderspitman wrote: post #48
cpach wrote: post #23

Earlier quoted context omitted.

From my toying around with it it seems quite good. But I haven’t done any stress-testing/benchmarking. NB: Important to use the HVF accelerator! Otherwise it will surely be slow. See https://wiki.qemu.org/Features/HVF

I'd be very interested to hear experiences from people working with QEMU+HVF. I only have Linux/Windows devices to test on.

Feel free to shoot me an email.

Re: QEMU 7.0

#58

Post by nicce »

_8j50 wrote: post #24

I like QEMU a lot but VirtualBox is my goto because the cli commands work fairly reliably and simply and I'm ashamed to say the simplicity of the UX is compatible with my laziness. For server workloads KVM/Qemu is great but imho, Vbox or Fusion are the best in my experience. Does anyone know if there are Qemu wrappers with a nice UI/UX? My current use cases aside, it's amazing the number of nice use cases Qemu is mad…

What are your use cases? I have used to use UI/UX (virt-manager) in the past but finally just went for direct CLI on Qemu, because UI/UX is often missing some features. In most of the cases, you only need to build one optimized single command and then you can reuse it everywhere. Over time, you also learn options pretty well. Just save the command for somewhere.

Re: QEMU 7.0

#59

Post by egberts1 »

My only lamentation of QEMU is their rapid development. (I did say “only”).

We had an open source CPU emulator (of many CPU arch) called “Unicorn” that was a heavy test instrumentation points inserted widely throughout and into QEMU 4.0. I spent 2 solid years on these dynamic API bindings of Unicorn into QEMU.

It was an awesome piece of SW that allowed us to recreate the behavior of malware.

Asking the QEMU team to insert some 50-odd test points into the QEMU code was proved to be a maintenance nightmare.

Even if it just an #ifdef of C language, it was too “cluttery”, it was still an awesome automated detection of code generation of just the affected malware portion.

I still believe this approach to be a significant tangential vector of prime investing for a startup.

https://github.com/unicorn-engine/unicorn

Re: QEMU 7.0

#60

Post by wyldfire »

pm215 wrote: post #55
anderspitman wrote: post #44

First off I want to make it clear that this isn't intended as criticism. I recognize the QEMU devs are busy, do incredible work, and don't owe me anything. That said, I started a project recently that I'm very excited about. It wouldn't be possible without QEMU. I've had to get deeper into somewhat lower-level features, and it's likely I'll have to implement some new devices and interfaces for QEMU itself eventually.…

The -devel list is dominated by patches just because that's how our workflow works; but if you have a technically focused question or one that's about the internals or the source code then you should feel free to ask it there (though of course I can't promise anybody will answer it...) The user list is lower traffic and tends to be more "users helping other users with straightforward queries"; not all the developers…

> The -devel list is dominated by patches just because that's how our workflow works

I guess the community likes it this way, but it's my least favorite part of working with upstream QEMU. I think partitioning patches and discussion into separate lists would be a (IMO) small impact but would significantly facilitate communication.

Post reply on HN