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

81–90 of 97 posts

Re: QEMU 7.0

#81

Post by cpach »

rubyist5eva wrote: post #78
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

Any idea if this is enabled by default (or how to check/enable it manually) on UTM.app? I have the "Use Hypervisor" option enabled on the VM but it's dreadfully slow even with just a headless linux server.

Strange. I would guess that it’s enabled by default. You might want to submit a new discussion on their GitHub project: https://github.com/utmapp/UTM/discussions The devs are very active there.

Re: QEMU 7.0

#82

Post by MegaDeKay »

anderspitman wrote: post #65
asguy wrote: post #56

Earlier quoted context omitted.

> 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 codeb…

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

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.

Re: QEMU 7.0

#83

Post by aidenn0 »

belthesar wrote: post #29
_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 Linux side of the house, virt-manager is pretty great, though it leans much harder into KVM, so you don't necessarily get all the exotic architecture support of QEMU built in. QtEmu for Windows gets you there, but it's very much so an API frontend, so if you're looking for simple from a choices perspective, this ain't it (though you might figure out your sane defaults and go from there). Since you mentioned Fu…

> On the Linux side of the house, virt-manager is pretty great, though it leans much harder into KVM, so you don't necessarily get all the exotic architecture support of QEMU built in.

That's kind of funny because I end up accidentally creating non-KVM machines with virt-manager all the time...

Re: QEMU 7.0

#84

Post by asguy »

anderspitman wrote: post #65
asguy wrote: post #56

Earlier quoted context omitted.

> 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 codeb…

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

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

Re: QEMU 7.0

#85

Post by hoistbypetard »

anderspitman wrote: post #76
hoistbypetard wrote: post #36

Earlier quoted context omitted.

These weren't un-executed ideas, though. I think it lines up very well with my general sense that the best way to get to a really good implementation of something is to publish one that's lacking in some way that annoys people. Then you have an idea plus something people can contribute work to improve.

> These weren't un-executed ideas, though I think you're straw-manning what I said a bit.

Not intentionally… I am arguing that “Almost seems to challenge the common assertion that execution is more important than a great idea” is not the case. Because these ideas were executed.

Re: QEMU 7.0

#86

Post by binwiederhier »

Twirrim wrote: post #73
binwiederhier wrote: post #14

Since QEMU devs/maintainers are lurking, i just want to say thank you for a fantastic project. I work for a company (Datto) that backs up Windows/Linux machines, which can then later be run as VMs for disaster recovery. Our product heavily relies on QEMU, and would be significantly harder to implement and maintain without it (believe me, it was built around VBox in the past). Thank you!

How do you handle the missing drivers when it comes to running under the VM? Do you modify the backups, or do you opt for emulation with good old standard hardware instead? Windows is.. Windows. Always pain with drivers there. Linux should be the easiest story, but since RHEL7 (and the derivatives from there), dracut has defaulted to "host-only" mode which leaves the initramfs so skinny and devoid of drivers not rela…

We have a process called Hardware Independent Restore (HIR), which injects drivers into Windows before booting it in the virtual environment. If you Google "datto HIR" you'll find some resources (e.g. https://help.datto.com/s/article/KB217259206), but it's obviously a lot of secret sauce, so I can't talk about the details.

Re: QEMU 7.0

#87

Post by anderspitman »

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…

Thanks for the explanation. I'll give the dev list a shot.

Re: QEMU 7.0

#88

Post by anderspitman »

cpach wrote: post #81
rubyist5eva wrote: post #78

Earlier quoted context omitted.

Any idea if this is enabled by default (or how to check/enable it manually) on UTM.app? I have the "Use Hypervisor" option enabled on the VM but it's dreadfully slow even with just a headless linux server.

Strange. I would guess that it’s enabled by default. You might want to submit a new discussion on their GitHub project: https://github.com/utmapp/UTM/discussions The devs are very active there.

If you end up opening an issue please link it here. I'm interested in following this.

Re: QEMU 7.0

#89

Post by quic_bcain »

egberts1 wrote: post #59

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 i…

// shameless ad, mods please delete if it's not permitted //

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

If you have experience w/QEMU and you are interested in working on it more, my team is doing work with QEMU. For the most part we have tended to focus on architecture-specific stuff but trying to grow our expertise.

https://news.ycombinator.com/item?id=30879312

Re: QEMU 7.0

#90

Post by phendrenad2 »

QEMU is great for debugging the Linux kernel. But does anyone know if there are any paid alternatives? (QEMU is a bit clunky and the configuration is arbitrary and frequently broken)
Post reply on HN