Talk:QEMU

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 10:52, 5 November 2024 (UTC)
:: Your reply ~~~~

egrep -E

Talk status

This discussion is done.

Isn't it redundant to say "egrep -E"? "egrep" is supposed to just be a shorter/alternative way of saying "grep -E". -- Luiji 03:43, 31 December 2014 (UTC)

According to grep(1), "egrep is the same as grep -E" and direct egrep invocation is deprecated. So changed "egrep" to "grep" in the article. -- 0x6177 17:30, 31 December 2014 (UTC)

Feel free to make the article better, Luiji . :) --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

file capabilities

Talk status

This discussion is done.

Is there some documentation on USE="filecaps" actually needing DebugFS in kernel? I see DebugFS used for perf stats, but filecaps seems unrelated. Petteyg (talk) 19:16, 13 March 2015 (UTC)

Try: https://packages.gentoo.org/useflags/filecaps and: https://devmanual.gentoo.org/eclass-reference/fcaps.eclass/index.html --MiroR (talk) 19:52, 7 August 2016 (UTC)

I did more research, as: /usr/portage/profiles/use.desc:

caps - Use Linux capabilities library to control privilege

filecaps - Use Linux file capabilities to control privilege rather than set*id (this is orthogonal to USE=caps which uses capabilities at runtime e.g. libcap)

didn't tell me enough.

On Gentoo Wiki: Hardened/Overview_of_POSIX_capabilities (and that link should be included in the article IMO) It's the same capabilities in both the flags, caps and filecaps, just in caps, they are applied on the fly (strace ( emerge strace if you don't have it installed ) the /bin/ping command and you'll see capget and capset called for the command, and /bin/ping is not suid and it does not have filecaps set, not in my machine) and the: /usr/libexec/qemu-bridge-helper from your qemu installation has those capabilities set in file attributes (if you set the filecaps on, still uncertain if that is the good way to go for a grsecurity-hardened, because it cost me the CONFIG_GRKERNSEC_KMEM (see: Use Tor browser on grsecurity-hardened system?))

The base address for understanding of file capabilities is the inventor's page: http://www.friedhoff.org/posixfilecaps.html#POSIX%20Capabilities%20-%20Capability%20Rules ( or http://www.friedhoff.org/posixfilecaps.html from top of page for those who have the time ) Also worth reading is the:
Archlinux Wiki Page on Capabilities ( but if you do the example at the top, replace /bin/ping with /usr/libexec/qemu-bridge-helper, remember /bin/ping is runtime caps, qemu-bridge-helper is filecaps in Gentoo, IIUC ) It is very good and important to know that capabilites can be very much abused: False Boundaries and Arbitrary Code Execution And also there's something wrongly named that has nothing to do with Linux Capabilites too: A concept wrongly named (capabilities were invented previous) --MiroR (talk) 12:55, 14 August 2016 (UTC)

The formatting for this discussion was not good so I cleaned it up a bit. :P Thanks for the info, though. --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

very frustrating

Talk status

This discussion is done.

I had a very frustrating time trying to get this working. I don't want to be all crappy criticism, so I'll come back after I have things working well. There are a lot of kernel options that are missing from this page. I found http://www.linux-kvm.org/page/Tuning_Kernel this little guide] that gave a lot more, but some of this seems to be outdated already. Also, this section needs to distinguish between the kernel config on the host & guest. I finally had to boot the livecd and carefully examine lspci, /proc/config.gz, etc. to figure out what it was doing 'right' and that my guest kernel was doing 'wrong'.

Further, I suspect that grub2 with --target=i386-qemu may be preferable (I haven't actually gotten it working yet), but I was baffled by the lack of documentation. One of the reasons that I suspect that it may be preferable is that it will install on a device (or image file) that is not fdisk-ed, because you may just want to put a single file system on an image file. Grub2 does not like installing there, but it doesn't seem to mind if --target=i386-qemu. The flip side of this mystery I think I've figured out today -- when you start qemu, you can pass -bios xxx. But xxx isn't just "qemu", it wants a bios file! I had no fucking clue where that was, now I think it's /usr/share/qemu/bios.bin (ran qlist qemu|grep -i bios). I'll try this one out later. Daniel Santos (talk) 23:57, 27 January 2016 (UTC)

Daniel Santos (talk) 23:57, 27 January 2016 (UTC)

Thanks for the input. Feel free to improve the article if things are lacking/missing. Myself and others in the Gentoo community would appreciate it! I'll mark this dicussion as closed for now, since there's really no action myself or others can take on it. --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

/dev/kvm line to change more to the point

Talk status

This discussion is done.

This line:

If KVM support is available there should be a "kvm" device listed at /dev/kvm

should read:

If KVM support is available there should be a "kvm" device listed as /dev/kvm after you boot into the kvm enabled kernel.

It does not show before, as one might interpret the line as it currently is.--MiroR (talk) 20:06, 7 August 2016 (UTC)

Thanks for the input! I'll make the edit this time, but next time feel free to make the edit yourself. This is a publicly modifiable wiki. :) --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

iptables NAT rules

Talk status

This discussion is done as of May 21, 2018.

Just wanted to confirm whether or not the masquerade rule in the article is correct. Under the Configuration section, one of the iptables rules says:

root #iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

Shouldn't that -o option be eth1, instead of br0, so that packets are rewritten with the ip address of eth1 (that way, external routers know where to deliver response packets)? --niteLite (talk) 01:30, 25 January 2017 (UTC)

I agree, eth1 should be masquaraded instead of br0. --Mlyszczek (talk) 18:24, 20 gru 2017 (UTC)

Since no action on this item has been take for many months, I'll apply the fix to this article and close the discussion. --Maffblaster (talk) 16:14, 21 May 2018 (UTC)

module loading

Talk status

This discussion is done.

Reading on another page of wiki, kernel module loading is different on OpenRC from systemd. Why describe only systemd configuration? I have added the OpenRC version but was deleted. --xdarma (talk) 09:24, 26 Feb 2019 (UTC)

xdarma , I removed the conf.d/modules file as OpenRC can now read the same file(s) as systemd does for modules and has been able to for quite a while. This makes explanations easier with just one method for everyone. --Grknight (talk) 14:07, 26 February 2019 (UTC)

Good for OpenRC, but if the default configuration of OpenRC is to read the old file, I think is correct to keep the original configuration. I think systemd users don't care about OpenRC, so why OpenRC users should take care of systemd? --xdarma (talk) 16:04, 01 Mar 2019 (UTC)

OpenRC reads both locations by default with no intervention of the user. If we describe a common location for everyone, then there is less chance of error and frustration. This is about ease of use for users not init1 vs init2. --Grknight (talk) 18:06, 1 March 2019 (UTC)

Only if you write information correctly: there's less chance of error and frustration. Just add that OpenRC can use systemd configuration, why hide something? I think the original configuration of OpenRC has to be write down. As for every piece of software. --xdarma (talk) 15:06, 05 Mar 2019 (UTC)

Kernel Config for vhost-net

Talk status

This discussion is done as of 2022-02-07.

Recently, I made an edit to the Kernel section on this page (specifically the kernel options for the vhost-net useflag) that updates it to be in line with the most recent stable kernel version (5.10.76-gentoo-r1). Does anyone know the specifics of exactly which versions the "Kernel 5.4.92" kernel options apply to? Is it specifically that version, or anything less than that? Asking because I have exactly 0 experience with the version in question. --Slips (talk) 17:46, 15 November 2021 (UTC)

It is just text on the wiki page. Depends on the user's editing/ kernel configuration practice. With some effort you could go through all the kernel versions of interest and check whether this option exists/ find the kernel version this was added.--Onkobu (talk) 14:21, 18 November 2021 (UTC)

Generally for kernel symbols / config options we try to define configuration options for sys-kernel/gentoo-sources kernel versions available within gentoo::. If only one kernel target is to be supported, choose the latest upstream stable version that aligns with versions available within gentoo::. As of today, this is presently v5.16.7 according to https://kernel.org/ Although v5.16.7 is considered unstable within Gentoo (due to at least a 30 testing window), it is considered stable by upstream. Hope this helps! --Maffblaster (talk) 19:10, 7 February 2022 (UTC)

QEMU Project Infobox

Talk status

This discussion is done as of 2023-09-05.

I plan to remove the Project link to QEMU because it points to an empty project:QEMU page.

Is this ok, Jacob (Jacob) ?

Egberts (talk) 19:09, 5 September 2023 (UTC)

Sounds sensible, please do it.

Immolo (talk) 19:19, 5 September 2023 (UTC)

Usage: Commandline: Draft

Talk status

This discussion is still ongoing.

I emerged QEMU and I missed a few usage examples for common use cases. So I think I add a few here:

Command line

QEMU binaries are used to run the virtualized guest. QEMU supports System Emulation and User Mode Emulation. These are the commands that emulate the x86_64 architecture.

user $qemu-system-x86_64 [options] [disk_image]

user $qemu-x86_64 [options] program [arguments...]

The compilation of user targets need to be enabled by adding the targets to QEMU_USER_TARGETS. This can be done in /etc/portage/make.conf

Creation of a disk image

This is how you would create a raw disk image with with 40G size:

user $qemu-img create -f raw my-systems-disk-image.img 40G

This is how you would create a raw image with copy-on-write disabled (nocow). "nocow" is a file attribute. (check with lsattr)

user $qemu-img create -f raw my-systems-disk-image.img -o nocow=on 40G

This would create a qcow2 image (useful if your filesystem doesn't support sparse files):

user $qemu-img create -f qcow2 my-systems-disk-image.qcow2 40G

Preparation of a bootable disk image from scratch

If you don't use a cdrom installation medium you can prepare a disk image and copy a system onto it. By default qemu uses a "bios-firmware" to boot the system. The disk can be prepared with a msdos disklabel and a gap between the end of the 512 byte MBR (Master Boot Record) and the start of the first partition. The gap is needed for boot loaders like grub that place boot-code in the gap. A raw disk image can be prepared by attaching it as a loop device:

user $losetup -fP /path/to/my-systems-disk-image.img

• -f find the first unused loop device
• -P scans for the partitions

List the loop devices with this command:

user $losetup -l

Then the loop device can be formatted like a normal disk.
Print the partition table:

user $parted /dev/loop000 print

You can create a msdos disklabel with:

user $parted /dev/loop000-number-of-the-device-whose-data-will-be-lost mklabel msdos

Create an ext4 partition:

user $parted /dev/loop000 mkpart primary ext4 1Mib 40GiB

Set the boot flag:

user $parted /dev/loop000 set 1 boot on

Create a filesystem:

user $mkfs.ext4 /dev/loop000

Mount it somewhere

user $mount /dev/loop000 /mnt/my-new-fs

Create a boot/grub folder for grub.

user $mkdir -p /mnt/my-new-fs/boot/grub

Install grub on the loop device and advice grub to install its files in boot/grub

user $grub-install --boot-directory=/mnt/my-new-fs/boot/grub /dev/loop000

Unmount the filesystem and detach the loop device

user $umount /mnt/my-new-fs

user $losetup -d /dev/loop000

If the loop device is busy it will not return an error. You can verify it with

user $losetup -l

This is enough to boot into a grub2 boot prompt. This is can be used as the basis for a bootable system.

CPU selection

QEMU has "accelerators" like kvm(Kernel Virtual Machine) or tcg (Tiny Code Generator) or Xen (wikip[1]). The accelerator can usually only "accelerate" the features that are available on the host cpu. So the selection of the cpu affects the performance. Get a list of cpus:

user $qemu-system-x86_64 -cpu help

Show the available accelerators:

user $qemu-system-x86_64 -accel help

Starting QEMU

This is how you start a virtual machine with the same feature set as the host cpu, a raw disk image and 2G of ram. By default a vnc server is started that runs with no password protection and listens on the loop interface. You can advise QEMU to listen on a local UNIX socket with the following command. Set the file permissions appropriately to protect the VNC server from unauthorized access. You can add a cdrom image as a installation and boot medium with "-cdrom filename.img"

user $qemu-system-x86_64 -vnc unix:/home/user/.qemu-vnc-socket -cpu host -drive file=/var/virt/rootfs-build-tc,format=raw -m 2G

CAUTION: If you start the server with -vnc :0 it listens on port 5900 (first display) on all interfaces with no password protection. Alexander-n8hgeg5e (talk) 01:45, 2 March 2024 (UTC)

Folded into User:Egberts/Drafts/QEMU_Configuration_Usage_section and working on a fuller draft Egberts (talk) 19:38, 6 June 2024 (UTC)

Splitting Usage into Configuration/Usage sections

Talk status

This discussion is still ongoing as of 2024-06-06.

I'm splitting the Usage section into both Configuration section and Usage section of QEMU page in accordance with this Gentoo-Wiki guideline.

My rough draft is located in User:Egberts/Drafts/QEMU_Configuration_Usage_section.

Also, I will roll-up previous talk of Alexander-n8hgeg5e 's input as well. Egberts (talk) 18:54, 6 June 2024 (UTC)

ignore_msrs Not Working via Modprobe.d File

The steps to make ignore_msrs take effect on boot don't appear to work in Kernel 6.6.30. When I create /etc/modprobe.d/kvm.conf with the specified value and reboot, /sys/module/kvm/parameters/ignore_msrs is still N.

I can confirm that on Windows 11, setting this value manually after boot to 1 helps avoid a crash on boot. --GuyEP (talk) 00:54, 21 June 2024 (UTC)

The command to do this is: `echo 1 | sudo tee /sys/module/kvm/parameters/ignore_msrs`

More details at https://bugzilla.kernel.org/show_bug.cgi?id=205801

Egberts (talk)

More details https://lore.kernel.org/all/20200625162540.GC3437@linux.intel.com/T/

Egberts (talk)

find how to solve this spam messges from dmesg

echo 1 > /sys/module/kvm/parameters/ignore_msrs

echo 0 > /sys/module/kvm/parameters/report_ignored_msrs

or as permanent

/etc/modprobe.d/kvm.conf

options kvm ignore_msrs=Y

options kvm report_ignored_msrs=N

this work with latest kernel - did not test with other

boot cmdline option would be: KVM.ignore_msrs=1

I knew the command for it to apply temporarily; the issue is that the documentation on this page doesn't mention it, and the instructions on the page only appear to work if KVM is installed as a module. I was able to make the command-line option work by editing the GRUB_CMDLINE_LINUX_DEFAULT option in /etc/defaults/grub. --GuyEP (talk) 14:07, 22 June 2024 (UTC)