Talk:QEMU
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.egrep -E
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
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
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
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
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)
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
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)
Kernel Config for vhost-net
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
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)
Usage: Commandline: Draft
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 40GThis 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 40GThis 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 40GPreparation 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 -lThen the loop device can be formatted like a normal disk.
Print the partition table:
user $parted /dev/loop000 printYou can create a msdos disklabel with:
user $parted /dev/loop000-number-of-the-device-whose-data-will-be-lost mklabel msdosCreate an ext4 partition:
user $parted /dev/loop000 mkpart primary ext4 1Mib 40GiBSet the boot flag:
user $parted /dev/loop000 set 1 boot onCreate a filesystem:
user $mkfs.ext4 /dev/loop000Mount it somewhere
user $mount /dev/loop000 /mnt/my-new-fsCreate a boot/grub folder for grub.
user $mkdir -p /mnt/my-new-fs/boot/grubInstall 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/loop000Unmount the filesystem and detach the loop device
user $umount /mnt/my-new-fsuser $losetup -d /dev/loop000If the loop device is busy it will not return an error. You can verify it with
user $losetup -lThis 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 helpShow the available accelerators:
user $qemu-system-x86_64 -accel helpStarting 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 2GCAUTION: 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)