Welcome to the new location of Alien's Wiki, sharing a single dokuwiki install with the SlackDocs Wiki.

Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
slackware:qemu [2006/06/10 00:38] alienslackware:qemu [2007/11/16 09:19] – Talk about "modprobe kqemu" and udev. alien
Line 67: Line 67:
   - download, unpack kqemu archive   - download, unpack kqemu archive
   - configure and build kqemu, and install it on your computer using ''make install''.   - configure and build kqemu, and install it on your computer using ''make install''.
 +
 +
  
 ==== Running QEMU and kqemu ==== ==== Running QEMU and kqemu ====
Line 98: Line 100:
 </code> My kqemu package also installs a [[http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html | udev]] rule file as ''/etc/udev/rules.d/50-kqemu-rule'' in case you run QEMU on a 2.6 kernel, with these contents: <code> </code> My kqemu package also installs a [[http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html | udev]] rule file as ''/etc/udev/rules.d/50-kqemu-rule'' in case you run QEMU on a 2.6 kernel, with these contents: <code>
 # kqemu # kqemu
-KERNEL="kqemu", NAME="%k", MODE="0666"</code> If you decided to restrict access to ''/dev/kqemu'', then you should modify this file to for instance <code>+KERNEL=="kqemu", NAME="%k", MODE="0666"</code> If you decided to restrict access to ''/dev/kqemu'', then you should modify this file to for instance <code>
 # kqemu # kqemu
-KERNEL="kqemu", NAME="%k", MODE="0660" , GROUP="qemu"</code>.+KERNEL=="kqemu", NAME="%k", MODE="0660" , GROUP="qemu" 
 +</code>.
  
   * To make the kqemu module load on boot, you should add the following line to the file ''/etc/rc.d/rc.modules'': <code>   * To make the kqemu module load on boot, you should add the following line to the file ''/etc/rc.d/rc.modules'': <code>
 /sbin/modprobe kqemu /sbin/modprobe kqemu
-</code>+</code> Use the following line instead for kqemu if you have UDEV: <code> 
 +/sbin/modprobe kqemu major=0 
 +</code> This will automatically create the device node ''/dev/kqemu'' on demand.\\ Note that nowadays Slackware comes with ''/etc/rc.d/rc.modules'' as a symbolic link to the file ''/etc/rc.d/rc.modules-<kernelversion>''. You have to check carefully that you modify the //modules// file for the kernel you are currently running.
  
-This concludes the alterations needed for a performance boost of your Virtual Machines inside QEMU. As I said earlier, running qemu is really simple - it is a single binary with a lot of optional commandline parameters that customize the virtual machine it will setup for use. QEMU will use the kqemu accelerator if it finds the kernel module loaded in memory (and if it's built with support for kqemu). The newer versions of QEMU and kqemu (at the time of writing, it's only available in the CVS repository of QEMU, but it will be released as QEMU 0.8.1) provide an additional layer of acceleration called //kernel-kqemu//. In this acceleration mode, the Guest kernel processes will also be accelerated as opposed to the "regular" functionality of kqemu to only accelerate the Guest's user processes. You do need to supply an explicit parameter to the qemu commandline: <code>+This concludes the alterations needed for a performance boost of your Virtual Machines inside QEMU. As I said earlier, running qemu is really simple - it is a single binary with a lot of optional commandline parameters that customize the virtual machine it will setup for use. QEMU will use the kqemu accelerator if it finds the kernel module loaded in memory (and if it's built with support for kqemu). QEMU provides an additional layer of acceleration called //kernel-kqemu//. In this acceleration mode, the Guest kernel processes will also be accelerated as opposed to the "regular" functionality of kqemu to only accelerate the Guest's user processes. You do need to supply an explicit parameter to the qemu commandline: <code>
 qemu -kernel-kqemu <other parameters> qemu -kernel-kqemu <other parameters>
 </code> If you don't want kqemu functionality at all, for instance because some programs and Guest OS-es will not work reliably or not at all with acceleration enabled, you can explicitly tell qemu on the commandline to do without: <code> </code> If you don't want kqemu functionality at all, for instance because some programs and Guest OS-es will not work reliably or not at all with acceleration enabled, you can explicitly tell qemu on the commandline to do without: <code>
Line 300: Line 305:
 </note> </note>
  
-=== Copy/paste text between Host and Guest ===+=== PXE booting your QEMU virtual machine ===
  
-FIXME+In [[:slackware:pxe|another article]] on this Wiki, i talk about the advantages of network booting ([[wp>PXE boot]]) when you are installing Slackware. Booting the Slackware installer from the network can sometimes be the only way of installing Slackware - imagine a PC without floppy and CDROM drives. QEMU on the other hand, has no need for network boot since you can just create an ISO image and pass that as the "//-cdrom//" parameter and that's it.\\ 
 +Yet there are times when you'd want your QEMU virtual machine were able to use PXE to boot from the network, if only to test your network setup without sacrificing real hardware. There is only one problem, the emulated QEMU network card (Realtek 8029, a NE2000 clone) does not support booting from the network (it does not emulate a boot ROM).
  
 +There are two ways to overcome this problem.
  
-=== Sharing files between Host and Guest ===+  * The first is to use the [[http://rom-o-matic.net/|ROM-o-Matic]]. ROM-o-matic.net dynamically generates Etherboot ROM images. We will let it create a PXE-capable ISO image that has support for our emulated Realtec network card. We can then use this small (~130kB) ISO image with the "//-cdrom//" parameter to QEMU to let it serve as a "replacement" PXE-boot ROM for the emulated network card.\\ The ISO generation works as follows - on the ROM-o-Matic start page, 
 +    * Select //latest production release//  
 +    * Choose NIC/ROM type **ns8390:rtl8029 - [0x10ec,0x8029]** 
 +    * Choose ROM output format **ISO bootable image without legacy floppy emulation (.iso)** 
 +    * To generate and download a ROM image press: <key>Get ROM</key>\\ No further customizations are needed, the default options are exactly right for our purposes. 
 +    * Save the generated ISO file on your local hard disk (for instance as //qemu_pxeboot.iso//)\\ \\ To use this ISO to boot from your PXE server, run qemu as follows: <code> 
 +qemu -cdrom qemu_pxeboot.iso -boot d <other options> 
 +</code> Read the article on [[:slackware:pxe|installing Slackware using PXE]] if you want to know more about how to setup a full-blown PXE server. 
 + 
 +  * The other option you have is available since QEMU 0.9.0 and that is to use the //''-option-rom''// parameter. As of the 0.9.0 release, QEMU can do a PXE boot using one of the PXE-capable boot roms available in ''/usr/share/qemu'': 
 +    * /usr/share/qemu/pxe-ne2k_pci.bin 
 +    * /usr/share/qemu/pxe-pcnet.bin 
 +    * /usr/share/qemu/pxe-rtl8139.bin\\ In order to support booting from the network, the ''-boot'' parameter has been extended with the possible value //''n''// for "network". An example of the command to PXE-boot your QEMU Virtual Machine from the network follows: <code> 
 +qemu -localtime -m 256 -hda slackware.img -boot n -option-rom /usr/share/qemu/pxe-ne2k_pci.bin <other_parameters></code> 
 + 
 + 
 +<note tip> 
 +If you read the [[slackware:vde#dnsmasq|Wiki article on VDE]] in order to improve the networking support for QEMU, and are running dnsmasq using the example ''rc.vdenetwork'' script, you can easily add support for network booting to the script. Look in the script for <code>DNSMASQ_OPTIONS=""</code> and change it into <code> 
 +DNSMASQ_OPTIONS="--dhcp-boot=/slackware-11.0/pxelinux.0,\"10.111.111.254\",10.111.111.254"</code> The two assumptions here (which you are free to change of course) are: 
 +  * QEMU sees your //host// as having the IP Address ''10.111.111.254'' 
 +  * Your //host// has a TFTP server setup so that ''/slackware-11.0/pxelinux.0'' is the location under the tftproot directory where the PXE bootloader ''pxelinux.0'' can be downloaded. 
 +</note> 
 + 
 +<note tip> 
 +If your TFTP server is not installed on the //host// but somewhere on the "real" network, you're in a bit of a problem: the PXE client and the TFTP server are separated by a NAT firewall!\\ 
 +Actually, there is no problem if you are using VDE for the network support. The ''rc.vdenetwork'' script installs a few basic iptables rules that make your //host// act as the NAT (masquerading) router for the QEMU //guests//. The TFTP requests will not be able to pass the NAT (which causes Slackware's //tftp-hpa// server to log errors like '' in.tftpd[8146]: tftpd: read(ack): Connection refused'').\\ 
 +We need a some extra work on the iptables firewall here, to let the TFTP traffic pass along. Add the following commands to the ''rc.vdenetwork'' script, or another place if your firewall is not setup there: <code> 
 +modprobe ipt_state 
 +modprobe ipt_helper 
 +modprobe ip_conntrack_tftp 
 +modprobe ip_nat_tftp 
 +iptables -A INPUT -m helper --helper tftp -j ACCEPT 
 +iptables -A OUTPUT -m helper --helper tftp -j ACCEPT 
 +</code> after which the QEMU VM will find the TFTP server and start downloading the bootcode, and the Operating System. 
 +</note> 
 + 
 + 
 +=== Copy/paste text between Host and Guest ===
  
 FIXME FIXME
  
  
-=== The VNC patch and other user contributions ===+=== Sharing files between Host and Guest ===
  
 FIXME FIXME
  
 +
 +''Code Text''
  
 ==== A QEMU start script ==== ==== A QEMU start script ====
 Hardware virtualization with QEMU ()
SlackDocs