4 ms·

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. Tha

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. Honestly I'm struggling to get my foot in the door. My questions on the user mailing list go mostly unanswered. I'm not aware of any QEMU book. Documentation feels sparse and is fragmented across multiple locations and often requires hoping someone has written a blog post about the specific piece you're interested in. I wish there were more descriptions of architecture and design decisions. I hesitate to use the development mailing list since it appears dominated by patches (a ton of them; QEMU is very active), and my requests don't quite seem to be development-level (yet). 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.

ori_b 4y ago
> 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.
- mysterydip 4y ago
  > My questions on the user mailing list go mostly unanswered.
  - anderspitman 4y ago
    They might be referring to the dev mailing list. I've only tried the user mailing list so far.
_vdpp 4y ago
A QEMU book would be _very_ welcome.
pm215 4y ago
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.
- wyldfire 4y ago
  > 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.
- anderspitman 4y ago
  Thanks for the explanation. I'll give the dev list a shot.
asguy 4y ago
> 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.
- anderspitman 4y ago
  > find the libvirt functionality and work backwards from it This is a great suggestion, thanks. > 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. Yeah it's unfortunate that not many people seem to use QEMU directly. I can't use libvirt for my project because a) I'm targeting windows and b) libvirt seems to assume that it will run with root privileges, and I'm targeting userspace. Honestly other than a few things like CPU pinning, I haven't seen much to justify libvirt over plain QEMU. This would be especially true if the QEMU CLI was simplified slightly and better documented.
  - MegaDeKay 4y ago
    CPU pinning is something I'd really like to see in plain QEMU as well. Another is some equivalent to the pre- and post- hooks that libvirt supports, though I can get around this with a bash script.
  - asguy 4y ago
    > I can't use libvirt for my project because ... Yah I had some similar constraints, also I just didn't want to bring the entire mess of libvirt into my project's life. > This would be especially true if the QEMU CLI was simplified slightly and better documented. I think this is the biggest issue. I can't complain because I haven't helped fix it, but the command line flag explosion, coupled with the qemu -readconfig/-writeconfig sucking is a big reason people just check out mentally and write big XML descriptions of their VMs.

ori_b 4y ago

> 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.

mysterydip 4y ago
> My questions on the user mailing list go mostly unanswered.
- anderspitman 4y ago
  They might be referring to the dev mailing list. I've only tried the user mailing list so far.

_vdpp 4y ago

A QEMU book would be _very_ welcome.

pm215 4y ago

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.

wyldfire 4y ago
> 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.
anderspitman 4y ago
Thanks for the explanation. I'll give the dev list a shot.

asguy 4y ago

> 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.

anderspitman 4y ago
> find the libvirt functionality and work backwards from it This is a great suggestion, thanks. > 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. Yeah it's unfortunate that not many people seem to use QEMU directly. I can't use libvirt for my project because a) I'm targeting windows and b) libvirt seems to assume that it will run with root privileges, and I'm targeting userspace. Honestly other than a few things like CPU pinning, I haven't seen much to justify libvirt over plain QEMU. This would be especially true if the QEMU CLI was simplified slightly and better documented.
- MegaDeKay 4y ago
  CPU pinning is something I'd really like to see in plain QEMU as well. Another is some equivalent to the pre- and post- hooks that libvirt supports, though I can get around this with a bash script.
- asguy 4y ago
  > I can't use libvirt for my project because ... Yah I had some similar constraints, also I just didn't want to bring the entire mess of libvirt into my project's life. > This would be especially true if the QEMU CLI was simplified slightly and better documented. I think this is the biggest issue. I can't complain because I haven't helped fix it, but the command line flag explosion, coupled with the qemu -readconfig/-writeconfig sucking is a big reason people just check out mentally and write big XML descriptions of their VMs.