From ArchWiki
Jump to navigation Jump to search

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)

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

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 or is sufficient. What do you think? -- Lahwaacz (talk) 20:42, 22 July 2013 (UTC)

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)
I would not remove something that works still heh.--Webdawg (talk) 07:31, 17 July 2016 (UTC)

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)

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

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)

Replace -net with -netdev

The -net option is deprecated and replaced by -netdev. I think this article should be modified to reflect that. axper (talk) 18:12, 1 July 2014 (UTC)

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)

I'm rewriting the network section axper (talk) 20:07, 2 July 2014 (UTC)

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)

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

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


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)

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)

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)

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)

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)

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)

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

Options for fstab with 9p

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)

The options (and more) are written on the page which is linked from the section: -- Lahwaacz (talk) 17:23, 15 June 2019 (UTC)
+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)
msize is also mentioned on the linked page. -- Lahwaacz (talk) 18:13, 15 June 2019 (UTC)
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)


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:

   slirpvde -n -L 2222:
   Starting slirpvde: virtual_host=
       DNS         =
       vde switch  =*DEFAULT*
       redir TCP   =2222:
   qemu -m 512 -nic vde,mac=52:54:00:12:34:56 -hda samba.disk  #
   qemu -m 512 -nic vde,mac=52:54:00:12:34:57 -hda linux.disk  #
   qemu -m 1024 -nic vde,mac=52:54:00:12:34:58 -hda windows.disk  #

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)

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)

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)

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
    -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"
    -bios /usr/share/qemu/bios.bin"
Tinywrkb (talk) 12:08, 2 April 2021 (UTC)
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)

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)