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

QEMU v4.0.0 released

qemu.org

Post reply on HN
Print view View original

71–80 of 168 posts

Re: QEMU v4.0.0 released

#71

Post by planteen »

rbanffy wrote: post #67

I always wanted (but never succeeded) in emulating SPARC guests using QEMU. Is there a comprehensive list of systems and hardware emulated? I suspect a lot of people in the HN crowd would be curious about emulating Alphas, even if for only running Genera. Having a collection of emulated Unix workstations is an upgrade in terms of space saved.

I got Debian for SPARC64 running under QEMU a few months ago. I wanted a big endian system for testing. I'll post the link on steps if I can find it. It was on GitHub IIRC.

Re: QEMU v4.0.0 released

#72

Post by therealmarv »

ktpsns wrote: post #61

I'm impressed nobody mentioned libvirt ( https://libvirt.org/ ) here, an open source framework for managing all kind of virtualization platforms. It is especially well suited to take off all heavy work of managing QEMU. From the features, Virt-Manager ( https://virt-manager.org/ ) can compete with VirtualBox -- and is probably well beyond, thanks to network transparency, the Spice protocol, real guest console access,…

Fun fact: Virt manager (plus the good stuff like e.g. splice) runs also natively on macOS and makes it easy to control remote Linux VMs:

https://github.com/jeffreywildman/homebrew-virt-manager

Re: QEMU v4.0.0 released

#73

Post by selvakn »

rcarmo wrote: post #10
founderling wrote: post #2

Anybody here using QEMU? What is your use case?

I'm using it extensively, but as a build tool: https://github.com/multiarch/qemu-user-static (See https://taoofmac.com/space/blog/2019/04/21/2300 and https://github.com/insightfulsystems/alpine-python )

Same here. Use it to build tools targeting arm architecture (rpi, etc) on a x86_64 machine, that too in docker.

Re: QEMU v4.0.0 released

#74

Post by kashyapc »

ktpsns wrote: post #61

I'm impressed nobody mentioned libvirt ( https://libvirt.org/ ) here, an open source framework for managing all kind of virtualization platforms. It is especially well suited to take off all heavy work of managing QEMU. From the features, Virt-Manager ( https://virt-manager.org/ ) can compete with VirtualBox -- and is probably well beyond, thanks to network transparency, the Spice protocol, real guest console access,…

Precisely so. Couple of us have mentioned libvirt as a recommendation in the comment threads above:

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

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

Re: QEMU v4.0.0 released

#75

Post by drmpeg »

rbanffy wrote: post #67

I always wanted (but never succeeded) in emulating SPARC guests using QEMU. Is there a comprehensive list of systems and hardware emulated? I suspect a lot of people in the HN crowd would be curious about emulating Alphas, even if for only running Genera. Having a collection of emulated Unix workstations is an upgrade in terms of space saved.

Here's a pretty good tutorial.

https://astr0baby.wordpress.com/2018/09/22/running-solaris-2...

I used a Solaris 7 .iso from archive.org.

https://archive.org/details/solaris_7_1199_sparc

Re: QEMU v4.0.0 released

#76

Post by [deleted] »

qalmakka wrote: post #31
Aardwolf wrote: post #22

It's pretty great and has been useful for many use cases for me, except too bad it lacks good 3D graphics support for modern gaming

It all depends on how and if someone will implement a Windows driver for VirGL. Given how complex video drivers are nowadays, it looks like a pretty daunting task.

[deleted]

Re: QEMU v4.0.0 released

#77

Post by tym0 »

I use Virtualbox on home PC to dev. I ssh into it and use tmux/vim as my IDE. Is there a better setup for performance on windows? Should I bite the bullet and get myself a Windows Pro upgrade for Hyper-V? If my memory serves well you Hyper-V can't have Hyper-V and Virtualbox at the same time.

Re: QEMU v4.0.0 released

#78

Post by antocv »

kashyapc wrote: post #36
idoubtit wrote: post #5

Last week, I intended to replace VirtualBox with QEMU for my personal use. The spartiate documentation made it really hard. I lack the competence to seriously contribute. The official documentation just explains the numerous parameters. It also points to tutorials (wikibook, etc), which unfortunately are very basic and out of sync. Even Arch Linux does not provide a good documentation (lack of clarity, some obsolete…

Launching QEMU directly is not merely "tricky", but incredibly inefficient and ineffective once you need something that's beyond bare minimal. E.g. here is a minimal QEMU command-line that gives you access to a serial console in the guest: `qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,forma…

> like running the QEMU process as an unprivileged user,

Anyone can run your example "qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,format=qcow2,if=virtio" from the command line/bash, as non-root user, yet libvirt which requires root to install, and is expecting root to configure it, is better? How?

Libvirt is one of those softwares which ads a layer of complexity for the sake of complexity, yet offers nothing of value in return.

Re: QEMU v4.0.0 released

#79

Post by fulafel »

kashyapc wrote: post #36
idoubtit wrote: post #5

Last week, I intended to replace VirtualBox with QEMU for my personal use. The spartiate documentation made it really hard. I lack the competence to seriously contribute. The official documentation just explains the numerous parameters. It also points to tutorials (wikibook, etc), which unfortunately are very basic and out of sync. Even Arch Linux does not provide a good documentation (lack of clarity, some obsolete…

Launching QEMU directly is not merely "tricky", but incredibly inefficient and ineffective once you need something that's beyond bare minimal. E.g. here is a minimal QEMU command-line that gives you access to a serial console in the guest: `qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,forma…

There's a lot to be said for running qemu from the command line, vs the complexity and opaqueness of libvirt. For example you can put the invocation in a script and check it into version control, and it will work on anyone's Linux box. You can easily debug the config and be suire about what options qemu was given.

Yes, there may be many switches in the invocation, but at least they are in one place, the invocation syntax rarely changes and works accross distributions, and they are applied from scratch in each invocation rather than having lots of implicit state hidden in daemons and their configurations / databases.

Your example is nicer on the eyes written in a config file style and leaving out the unnecessary options:

  qemu-system-x86_64 \
     -display none \
     -m 2048 \
     -serial stdio \
     -drive file=/export/cirros.qcow2,\
            format=qcow2,\
            if=virtio

Re: QEMU v4.0.0 released

#80

Post by ori_b »

antocv wrote: post #78
kashyapc wrote: post #36

Earlier quoted context omitted.

Launching QEMU directly is not merely "tricky", but incredibly inefficient and ineffective once you need something that's beyond bare minimal. E.g. here is a minimal QEMU command-line that gives you access to a serial console in the guest: `qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,forma…

> like running the QEMU process as an unprivileged user, Anyone can run your example "qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,format=qcow2,if=virtio" from the command line/bash, as non-root user, yet libvirt which requires root to install, and is expecting root to configure it, is bett…

Indeed. Instead of contributing a patch to qemu with better defaults, or even support for config files, someone wrote tens of thousands of lines of complex code.

People forget that software is malleable. Bend it to your needs, instead of adding fragile wrapper layers.

Post reply on HN