Talk:QEMU

From ArchWiki
Latest comment: 28 September 2023 by Lahwaacz in topic section on Removal deleted

Linear RAID

When I was updating the article yesterday, I had tried to fit the section about linear raid (boot a VM from a partition by prepending a MBR to it) into the article better. But I'm not sure the technique described is the right one at all. It looks like it works, but wouldn't it be easier to install a bootloader directly to the partition (e.g. syslinux)? Then the VM could be booted directly from the partition simply by using it as its virtual disk. --Synchronicity (talk) 19:23, 9 May 2012 (UTC)Reply[reply]

What about Windows installations then? Nesk (talk) 09:18, 4 October 2016 (UTC)Reply[reply]

Creating bridge manually

I really don't know what to do with this section. I'd say it has been superseded by QEMU#Creating bridge using qemu-bridge-helper (available since qemu-1.1, we now have qemu-1.5) - or is someone still using this method? Perhaps link to https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces or http://wiki.qemu.org/Documentation/Networking/NAT is sufficient. What do you think? -- Lahwaacz (talk) 20:42, 22 July 2013 (UTC)Reply[reply]

Actually, I've become a happy user of this method. I've written some scripts to easily create bridge interface, TAP interface, and combined with Xyne's excellent scripts to set up NAT and launch DHCP server, I have complete solution to easily manage multiple VMs on one (or even more) bridge.
My scripts are available on github: [1], [2], [3] but I won't probably integrate them into the wiki, I'l just leave a note when I do some more testing.
The thing is, what to do with the current content? Personally I think that links to [4], [5] and my scripts are sufficient (of course others are welcome). I'd also leave the note at the end to disable the firewall on the bridge, I find it extremely useful.
-- Lahwaacz (talk) 18:24, 5 September 2013 (UTC)Reply[reply]
I would not remove something that works still heh.--Webdawg (talk) 07:31, 17 July 2016 (UTC)Reply[reply]

People may be coming to this article for a very simple example, not using opinionated dependencies or assumptions about setup like firewalls. The method used in Lahwaacz script is perfect (although the link in this discussion is out of date). It can be boiled down to about 6 ip commands: Create the bridge bridge0 and bring it UP

# ip link add name bridge0 type bridge
# ip link set bridge0 up

Create the tap tap0 and bring it UP

# ip tuntap add dev tap0 mode tap
# ip link set tap0 up promisc on

Add your network interface (it must be UP), and tap to the bridge

# ip link set enp2s0f0 master bridge0
# ip link set tap0 master bridge0

-- Razzintown (talk) 23:54, 15 November 2020 (UTC)Reply[reply]

qemu-bridge-helper adds and removes tap, but does not construct a bridge, with an IP for the host, and containing the physical nic. I modified run-qemu to construct a bridge, such that network is available on host and guest. The previous run-qemu probably assumed that the main host network access had been moved to bridge before. Roland Puntaier (talk) 16:05, 24 June 2022 (UTC)Reply[reply]

Kexec Hackery When Using a Real Partition

After banging my head against a wall long enough and figuring out what -kernel and -initrd were really calling, I put a note above the appropriate section and mentioned two ways to use the guest's images. (Otherwise, you'll have to worry if the host and guest images match.) The first -- mount the partition(s) -- is more appropriate for "low-volume-handling" of VMs. The second -- using kexec -- becomes more useful when you're juggling more than a few VMs.

I'm only mentioning this hack because (as of now) Kexec only mentions use for rebooting into another kernel, not switching out the kernel before the system is even up. This hack comes from from https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader- which has two suggestions. The most recent, using systemd units by jkuan, doesn't work because jkuan tried to copy a .target file into a .service file and systemd wants ExecStart in a .service file. The second one, replacing /usr/bin/init by andrew_sparks, works for me on my Arch instance at DigitalOcean.

Adaptation from said post:

# pacman -S kexec-tools
# pacman -R systemd-sysvcompat
/tmp/init
#!/bin/sh

kexec --load /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --append="root=/dev/sda init=/usr/lib/systemd/systemd" &&
mount -o ro,remount / && kexec -e
exec /usr/lib/systemd/systemd
# cd [/path/to/vm]/usr/bin
# mv init init.dist
# cp /tmp/init ./
# chmod 755 init

I'm leaving this on the Talk page as I haven't even tried it out in QEMU myself. Also, my eyes are about ready to pop out of my head, so I'm barring myself from figuring out the appropriate way to edit this in for the time being. BrainwreckedTech (talk) 21:23, 14 January 2014 (UTC)Reply[reply]

Replace -net with -netdev

The -net option is deprecated and replaced by -netdev. I think this article should be modified to reflect that. http://en.wikibooks.org/wiki/QEMU/Networking#cite_ref-1 axper (talk) 18:12, 1 July 2014 (UTC)Reply[reply]

Yes -net is the old syntax as stated in Gentoo's Wiki where we should use -netdev user,id=vmnic -device virtio-net,netdev=vmnic Pickfire (talk) 04:11, 31 March 2017 (UTC)Reply[reply]

I'm rewriting the network section

https://wiki.archlinux.org/index.php/User:Axper/sandbox/qemu_network axper (talk) 20:07, 2 July 2014 (UTC)Reply[reply]

I think a lot of networking topics could be moved outside of the QEMU page. Many virtualization applications share the same basic principles with regards to networking, such as tun/tap creating, bridges, VDE, etc. There are a few networking schemes that are QEMU-specific, for example multicast sockets and -net socket,..., and these could be mentioned on the QEMU page, although these are less reliable and rarely used in comparison to tap devices. We should also of course note the QEMU-specific command line options in the QEMU page, but for general concepts and commands independent of the virtualization applications, they could go on pages dedicated to the task. The best example is VDE, which is in no way limited to QEMU, yet it still doesn't have its own page on the Arch wiki.
Incidentally, I'm planning on rewriting User Mode Linux (yes, I promise I will get around to it), which happens to share the "tap with bridge" and VDE concepts with QEMU. It would be nice if I could link to pages dedicated to those topics and only write UML-specific commands in the page, instead of duplicating a bunch of general information. I'm not familiar very familiar with Xen or LXC or Docker or the like, but I would suspect that they also share some networking infrastructure. We could possibly even create a category just for these types of pages, for example "Virtual Networking" or "Advanced Networking". EscapedNull (talk) 13:32, 19 February 2015 (UTC)Reply[reply]

-enable-kvm vs -machine type=pc,accel=kvm

The section QEMU#Enabling_KVM recommends -enable-kvm, while QEMU#Virtual_machine_runs_too_slowly recommends -machine type=pc,accel=kvm. Is there any difference between the two? Is one preferred over the other? Should we just link to the former section from the latter (and possibly move both command line switches to the same section)? EscapedNull (talk) 17:23, 18 January 2015 (UTC)Reply[reply]

2.5 years later... Has anyone found an answer to the question of `-enable-kvm` VS `-machine type=pc,accel=kvm`? -Physicist1616 (talk) 19:32, 3 August 2017 (UTC)Reply[reply]
Yes. They're equivalent. Discussion on the QEMU mailing list about marking -enable-kvm deprecated didn't result in that; -enable-hax did get deprecated. Confusing, especially when checking whether e.g. libvirt has actually started the machine with KVM enabled. MacGyver (talk) 16:24, 4 December 2018 (UTC)Reply[reply]

virtio-gpu

Any tutorial on using the new virtio-gpu which is introduced in qemu-2.4 and kernel 4.2? Adam900710 (talk) 02:44, 19 August 2015 (UTC)Reply[reply]

Should be "plug and play" with recent kernel and other packages: article. The article is about libvirt, but I've run Arch guest on Arch host successfully with qemu script. Nesk (talk) 09:24, 4 October 2016 (UTC)Reply[reply]

host only networking

I added a quick and easy method but it was deleted. I found errors in what is here. Is it worth my time to correct them or will they be deleted? —This unsigned comment is by Netskink (talk) 16:39, 4 January 2016‎. Please sign your posts with ~~~~!

You are welcome to make any corrections. Nobody can tell you if they will be kept or reverted beforehand, but if you're afraid to waste your time feel free to just point them out using an Article status templates|article status template (should be less time consuming). -- Lahwaacz (talk) 22:28, 21 February 2016 (UTC)Reply[reply]

Windows 7 specific issues

I have noticed that for me, any attempts at installing Windows 7 using qemu with virt-manager as a frontend stalls on "Starting Windows." This is immediately after booting the computer for the first time. In Virt-manager, I am able to change the Display from QXL to Cirrus to fix the issue. I'm not sure if this applies to this page in particular, but if so, might be worth adding to the "Troubleshooting" section -- Ephreal (talk) 14:25, 10 August 2016 (UTC)Reply[reply]

Using existing partition on GPT disk (with linear RAID or otherwise)

Section on using existing partition is pretty awesome, but it is MBR-specific. Can someone with enough knowledge create a similar section about GPT disk please?

Could not access KVM kernel module: Permission denied

Simply changing group = "78" to group = "kvm" in /etc/libvirt/qemu.conf was not enough for me to fix this issue. Indeed, some files were still installed with gid 78, which you can confirm with:

 find / -gid 78

So in the end, I still had to change the group id of kvm to workaround this issue:

  groupmod -g 78 kvm

—This unsigned comment is by Nivata (talk) 17:15, 1 September 2017‎. Please sign your posts with ~~~~!

Starting QEMU virtual machines with systemd in 2018

The custom service script uses KillMethod=none to avoid the virtual machine being killed before shutdown. Here is an example to avoid this logic using socat:

ExecStart=/usr/bin/env qemu-system-x86_64 -name %i … -monitor unix:/var/run/qemu-%i.monitor,server,nowait
ExecStop=/bin/sh -c 'echo system_powerdown | socat stdio,ignoreeof /var/run/qemu-%i.monitor'

In this way, the stop command will exit when the QEMU monitor closes the socket. Other options, e.g. PIDFile or KillMode are not necessary.

While a unix socket is used for this example, it works as well with telnet/tcp-connect. Ypnos (talk) 18:29, 30 January 2018 (UTC)Reply[reply]

I've tested using openbsd-netcat, and that variant seems to keep the connection open after issuing the command as well. So there are a couple options to avoid using the KillMethod, which I agree is not a good idea. Djmoch (talk) 13:21, 2 March 2019 (UTC)Reply[reply]

e1000e: waiting for carrier... timed out

my physical host is an ArchLinux with 4.14.40-1-lts kernel and Qemu 2.12.0.

in my first virtualisation case, my guest is an ArchLinux with 4.9.36-1-lts kernel (e1000e ver. 3.2.6-k) : everything works normally when I request the assignment of a network address with dhcpcd (after a few seconds, my guest gets the 10.0.2.15 intended address).

in my second virtualisation case, my guest is an ArchLinux with 4.14.40-1-lts kernel (e1000e ver. 3.2.6-k) : no carrier is detected and therefore no address is assigned to the enp0s2 network card.

I think the problem would rather come from the virtualized 4.14.40-1-lts kernel side because I do not meet it on my physical host which also uses the e1000e module...

does anyone have an idea or a lead ?

(this problem does not appear if I add in both cases the parameter "-machine pc" which forces the use of the module e1000/ens3 instead of the module e1000e/enp0s2).

Lacsap (talk) 16:09, 28 May 2018 (UTC)Reply[reply]

Options for fstab with 9p

https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=573709

Maybe the options are not very hard to deduce, but they are not obvious, and having them written down is very useful as a "cheat sheet".

Marmistrz (talk) 15:19, 15 June 2019 (UTC)Reply[reply]

The options (and more) are written on the page which is linked from the section: https://wiki.qemu.org/Documentation/9psetup -- Lahwaacz (talk) 17:23, 15 June 2019 (UTC)Reply[reply]
+1 to keep the options. I suggest also to mention msize=512000 option necessary to achieve satisfactory performance, this is something qemu docs fail to mention Ivank (talk) 17:39, 15 June 2019 (UTC)Reply[reply]
msize is also mentioned on the linked page. -- Lahwaacz (talk) 18:13, 15 June 2019 (UTC)Reply[reply]
Yes, in a totally useless way, just that msize exists and 8192 is the default. msize=512000 (max) vs msize=8192 (default) is 10x throughput difference in my testing, that's not mentioned and I'd argue is a much more important and helpful fact to know for a user. Ivank (talk) 18:40, 15 June 2019 (UTC)Reply[reply]

VDE

can you tell me if you are also having trouble running VDE with QEMU ? for my part, I encounter a very random functioning with the set below:

   vde_switch
   slirpvde -n 192.168.0.0.0 -L 2222:192.168.0.102:22
   Starting slirpvde: virtual_host=192.168.0.2/24
       DNS         =192.168.0.3
       vde switch  =*DEFAULT*
       redir TCP   =2222:192.168.0.102:22
   qemu -m 512 -nic vde,mac=52:54:00:12:34:56 -hda samba.disk  # 192.168.0.101
   qemu -m 512 -nic vde,mac=52:54:00:12:34:57 -hda linux.disk  # 192.168.0.102
   qemu -m 1024 -nic vde,mac=52:54:00:12:34:58 -hda windows.disk  # 192.168.0.103

dysfunctions are for example no answer when I execute the ssh -p 2222 root@localhost command from another console or the loss of connection (freeze) with my Linux VM when it finally established. I checked several times the network configuration of my three virtual machines. the logs do not report any particular errors.

I use the trio vde_switch, slirpvde and nic vde because it does not require any privileges.

Lacsap (talk) 12:49, 23 September 2019 (UTC)Reply[reply]

Systemd service starting qemu as root

The systemd unit suggested at QEMU#With_systemd_service runs qemu as root, unless it is started as a user service. Running qemu as root is explicitly discouraged from at QEMU#Running_virtualized_system. I suggest adding -runas some_user to ExecStart=, or User=some_user and Group=some_group. I prefer the former, because it allows to access block devices owned by root, in particular LVM logical volumes.

Respiranto (talk) 19:45, 28 November 2020 (UTC)Reply[reply]

UEFI with vanilla QEMU?

I'm not exactly sure if this is possible, however /usr/share/qemu seems to have support for many different UEFI implementations and the -bios option seems to be the one that specifies which one to use, however I have seen little to no documentation on the subject (probably because it is usually abstracted away by libvirt).

BTDMaster (talk) 10:54, 2 April 2021‎ (UTC)Reply[reply]

You haven't used your google powers, there are enough examples online. I'm just dropping here some code from my now-archived vm startup script (libvirt is much nicer).
#  cp /usr/share/edk2-ovmf/x64/OVMF_VARS.fd /tmp/my_vars.bin
if [ "$OVMF" = "yes" ]; then
  QEMU_ARG="$QEMU_ARG \
    -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \
    -drive if=pflash,format=raw,file=$DRV_BASE/${DRV_IMG}.fd"
else
  QEMU_ARG="$QEMU_ARG \
    -bios /usr/share/qemu/bios.bin"
fi
Tinywrkb (talk) 12:08, 2 April 2021 (UTC)Reply[reply]
Thank you! I've seen OVMF mentioned, but I thought the binaries provided by QEMU would be enough. (Saving less than 15 MB, I know.)
BTDMaster (talk) 20:52, 2 April 2021 (UTC)Reply[reply]

Fix short-form boolean options

QEMU has deprecated short-form boolean options. I have fixed the one instance of this that I was warned about in my own script ("-spice"), but I am sure there are more instances of this in this page that have to be fixed.

CodingKoopa (talk) 03:08, 19 July 2021 (UTC)Reply[reply]

UEFI instructions

I found two different places with almost identical instructions how to boot QEMU with UEFI:

But the QEMU article does not mention UEFI at all! I find this situation a bit absurd.

I think it would be better to create a new section named, for example, "Booting a virtual machine in UEFI mode" (probably as a "Tips and tricks" subsection) and redirect to that section from other articles to prevent duplication of instructions.

(I can do it myself if there are no objections.)

andreymal (talk) 16:54, 6 February 2022 (UTC)Reply[reply]

Sounds good to me. Though, I don't think Tips and tricks would be the ideal place. Maybe in QEMU#Running virtualized system or as a separate top-level section. This page is overdue for a large overhaul anyway... -- nl6720 (talk) 11:15, 7 February 2022 (UTC)Reply[reply]
Created: QEMU#Booting in UEFI mode. I was testing UEFI support by running Windows 11 as a guest OS, so I accidentally created another section: QEMU#Trusted Platform Module emulation.
I am not sure they are good enough, so feel free to edit or even shorten them if they are too long.
I did not mention Secure Boot because I did not find an easy way to install all the necessary keys (I just copied /usr/share/OVMF/OVMF_VARS.ms.fd from ubuntu/ovmf which is stupid). I think it would be nice if someone would add an additional subsection about Secure Boot.
andreymal (talk) 17:36, 6 August 2022 (UTC)Reply[reply]
Copying from ubuntu/debian does not sound like a bad idea. Although the preferred way should be either hard-coding Microsoft's keys during compilation (is that achievable?), or injecting them manually in UEFI settings the same way you load custom keys to a physical machine.
In the aforementioned guide, replace -hda fat:hda-contents with VVFAT arg -drive file=fat:rw:hda-contents,format=raw.
These cost me tons of googling. Consider giving some hints on this wiki page.
PXf (talk) 09:59, 8 September 2022 (UTC)Reply[reply]

Potential fix for sudo/doas issues in a chroot

Although the guide in this page for setting up an armv7/aarch64 container do work, I found myself unable to neither sudo nor doas with errors related to setuid (from googling it appears this is usually an issue with filesystem permissions, but definitely not in the case of a freshly created container).

This effectively makes it a showstopper for trying to cross build packages for an Arch Linux ARM system as makepkg does not allow running as root and pacman won't work without root (which means you can't just switch users with su).

I ended up finding a comment in a GitHub issue that mentions something related to binfmt flags and as it turns out I was able to get sudo/doas working in the chroot by copying /usr/lib/binfmt.d/qemu-aarch64-static.conf to /etc/binfmt.d/qemu-aarch64-static.conf, changing the flags from FP to OCF and restarting systemd-binfmt.service.

I wanted to add this to the page to help others, but I don't know if this is the best/correct way to fix this, I don't know a whole lot about binfmt or why it is setup like this (my guess is because the C flag will run the interpreter with root permissions as per the kernel documentation).

Any thoughts?

Luluco250 (talk) 23:43, 7 August 2023 (UTC)Reply[reply]

Turn off copy-on-write on BTRFS is deafult for libvirt

See libvirt official website, libvirt will attempt to disable COW on any btrfs filesystems since 6.6.0. --Heddxh (talk) 03:04, 6 September 2023 (UTC)Reply[reply]

This page is not about libvirt. — Lahwaacz (talk) 05:46, 6 September 2023 (UTC)Reply[reply]
But the libvirt is mentioned in many places. At least maybe add a tip? --Heddxh (talk) 04:53, 13 September 2023 (UTC)Reply[reply]

please keep Custom build section

Hello, I specifically created the QEMU#Custom_build section as I want to reference it from the GVT-g article in the future. I've discovered a way to have a shared clipboard without the spice display, on qemu and through libvirt, but it requires compiling qemu from source, with a specific config option.

I've written this section as I've had difficulty compiling qemu and though I don't want to insult the arch wiki readers intelligence, some specifics are not documented.

The internet is riddled with arch users giving up on GVT-g due difficult instructions and not getting it working, which I'd also attribute to difficult instructions. I don't think this necessarily has to be the case, please help me make it a bit easier.

EDIT 1: I've now added the section on qemu-vdagent here instead of in the GVT-g article since it is not GVT-g-specific.

—This unsigned comment is by IOfwq (talk) 16:41, 16 September 2023. Please sign your posts with ~~~~!

Why do you not submit a feature request for the official package? — Lahwaacz (talk) 16:48, 16 September 2023 (UTC)Reply[reply]
I've now done so though I didn't think it would be possible since the feature is experimental. Also, it took me a good while to figure out how to do this, so I thought providing guidance would be good. QEMU is a complex package and building it for arch isn't documented elsewhere. Only package maintainers knowing how to do these builds and everyone else having to spend a day to figure it out on their own helps no one. IOfwq (talk) 09:12, 17 September 2023 (UTC)Reply[reply]
Rebuilding Arch packages manually is described on the Arch build system page. The amount of time it takes to understand and master is tangential here.
There are two ways to make this more straightforward for users (readers of this page): 1) enable the functionality in the official package, or if the feature is too experimental for an official package, 2) make an unofficial package in the Arch User Repository that provides the official pkgname(s). Either way, when done correctly, it will take only a simple instruction to install the correct package and there will be no point in describing how to configure and build QEMU from source.
Lahwaacz (talk) 10:46, 17 September 2023 (UTC)Reply[reply]

section on Removal deleted

Hello, yesterday I created a section on removing qemu manually, specifying a list of packages that are installed when installing qemu-desktop on a new system.

I get that this was hard to look at, ideally I'd have hidden it somehow (don't know how). But this only illustrates the split nature of qemu, it is a complex package.

I had a specific need for this list: Installing a custom build with a different version after switching to the qemu-git AUR package required me to -Rdd these packages before installing them and such a list would have been very useful to me as I was uncertain which of -Qs qemu or -Rcnsu qemu-desktop were safe to remove. -Qii also couldn't have given me a correct list, and neither does the info on the arch packages page.

The only solution was to spin up a VM and install qemu-desktop as I know -Rdd is a dangerous operation and can easily break things, yet I feared even -Rcnsu might be dangerous in this case.

A normal arch user will never need to uninstall qemu but if you need to, such a list is a godsend. Can we please add the list back, in some form?

—This unsigned comment is by IOfwq (talk) 13:22, 16 September 2023. Please sign your posts with ~~~~!

It is not the scope of this page to cover Arch packaging details. Various details related to searching and removing packages from the system are covered on the pacman and pacman/Tips and tricks pages. — Lahwaacz (talk) 16:51, 16 September 2023 (UTC)Reply[reply]
removing / replacing something like vim is easy, but QEMU is a complex package and you might risk bricking virtualization on your install, you've seen how long that list is and no amount of pacman could have given me that list. as I said, I had to spin up a VM to get it, and that's unnecessary difficulty. I'd perfer to have it in a normally-hidden spoiler; when you need it, there should be some place to look it up. IOfwq (talk) 09:22, 17 September 2023 (UTC)Reply[reply]
Why do you need a full list exactly? When you install qemu-desktop, you can remove it along with its (unneeded) dependencies by running pacman -Rs qemu-desktop. Add --print to just get the list of targets. — Lahwaacz (talk) 10:54, 17 September 2023 (UTC)Reply[reply]

no amount of pacman can save us here. due to the complexity of the qemu package, pacman -Rs, -Rsu, and -Rsc deliver an incomplete list (33 items, instead of the 61 of the list you so swiftly deleted). the only way I know to obtain it is a reinstall, and that can't be the "good" solution here. Yes, I know I'm annoying. please reconsider. IOfwq (talk) 12:06, 25 September 2023 (UTC)Reply[reply]

Again: why do you need a full list exactly? When you install qemu-desktop, you can remove it along with its unneeded dependencies by running pacman -Rs qemu-desktop. — Lahwaacz (talk) 10:49, 28 September 2023 (UTC)Reply[reply]