On Windows XP/2K you can try to boot from the flash drive like so: qemu -hda //./PhysicalDriveN ... where N is the drive number found in the disk manager.

Why isn't full-screen mode "full screen"? The only thing I get is an original sized output with a full-screen border.

Short answer: No. QEMU does not support creating a partition table/MBR on the fly. You need to use "/dev/hda" (e.g. the entire hard disk). Note: An experimental patch has been released that adds this functionality. You need to pass "-hda part:/dev/hda1" instead of "-hda /dev/hda". QEMU will then create an MBR and partition table on the fly for /dev/hda1. Changes to the MBR or partition table are lost when restarting QEMU.

This is an SDL bug. Specifically, SDL is using a 32-bit visual provided by Xgl, which causes pixels to be specified in RGBA format. SDL has a bug that makes it (wrongly) specify alpha blending for its windows. You can work around this by doing 'XLIB_SKIP_ARGB_VISUALS=1; export XLIB_SKIP_ARGB_VISUALS' before running QEMU.

The QEMU monitor can be redirected else where using the -monitor specifier. For example, you can have the monitor listen on a host port for remote connections via telnet/netcat/etc (example will be added later).

You probably have not set up the ramdisk in /dev/shm. Add the following line to /etc/fstab: tmpfs /dev/shm tmpfs defaults 0 0

A workaround for those who must have 2 CD-ROMs visible at the same time is to use vvfat. Mount one of the CD-ROMs, and pass it as a hard disk via -hdd fat:/mnt-point. These will look like hard disks to the guest OS, and thus are not removable.

In the monitor, the "eject" command will remove the disk. The "change" command will insert a new one. If you are changing real disks (e.g. QEMU is using the host CD-ROM drive and you are changing physical CD-ROM disks) then it is recommended that you eject the CD-ROM from QEMU, and then change physical CD-ROM disks, and then use the "change" command in the monitor to reinsert the host CD-ROM disk.

Long answer: Once installed, Windows has only the minimal drivers required to boot the hardware on your computer - which happens to be completely different from what QEMU emulates. Windows 9x has enough problems with this, but Windows NT is especially fickle. You may be able to boot Windows 95 or 98 work from QEMU this way (there have been a few reports of success), but if you want to try we can not help you. You are better off installing Windows into a disk image.

It depends. Initial support for USB device proxy and emulation is now available in QEMU 0.8.0. From Fabrice Bellard's email to the QEMU developers list: I just committed an initial USB support for QEMU. This USB layer will ultimately enable QEMU to use some host USB devices and to simulate USB devices. WARNING: the current USB support is for USB hackers only - it is not meant to be fully usable yet. Flash drives have been reported to work.

Sort-of. Doing so will likely violate The Mac OS X End User License. QEMU does not emulate X86 Mac hardware, however some people have reported success hacking OS X to run on regular PC hardware (ie. qemu).

the time of this writing, it doesn't completely work yet. Darwin/PPC does work. Note that this has the same legal issues as X86 OS X.

Many "hardened" systems (eg. SSP/ProPolice) interfere with the way QEMU does dynamic code generation. The general solution is to disable these systems for QEMU. The QEMU design involves generating and running code on the fly, so it's unlikely these would provide any meaningful protection anyway. gcc-config -l (shows you a list of available cc) gcc-config i686-pc-linux-gnu-3.3.6-hardenednopiessp (use the correct version) source /etc/profile emerge qemu-cvs gcc-config i686-pc-linux-gnu-3.3.

Long answer: This generally requires cooperation from the guest OS/drivers (Like with Xen). Developers might be interested in the patch posted to the qemu-devel mailing list a while back which allowed for limited PCI proxy support on Linux hosts. You can find this here: more discussion here: http://lists.gnu.org/archive/html/qemu-devel/2005-03/msg00301.html and here: http://lists.gnu.org/archive/html/qemu-devel/2006-01/msg00082.html

Check out the Q project: http://www.kju-app.org/kju/. I have tested it briefly, and it works well so far. It is in Alpha officially but feels more advanced than alpha to me. Alternatively Parallels is the mainstream proprietary software. Also works well, although is a RAM hog, especially with two guests. You can try the PDtweaker module for Unsanity's Application Enhancer to make it work smoother. I couldn't make APE work on 10.4.7 though.

Since QEMU 0.9.0, the IDE emulation uses async transactions for DMA transfers. This employs the Linux AIO functionality that uses kernel threads. Making QEMU itself thread safe is an important goal for things such as allowing multiple cores (SMP). QEMU is not a cycle accurate emulator so some of this information is not going to be possible. Please use 'qemu -d ?' for a listing of items that can be logged. The QEMU build allows for it to be profiled via gprof.

KQEMU/KVM are kernel modules so require root privileges to install. Once loaded they can be used by normal users as long as device node premissions are set correctly.

Run 'file' on the .hdd image. Is it in raw format? If it is then you can use qemu-img to do the conversion. Please edit this and move it elsewhere if it indeed answers the question.

present, no. A separate project named Kernel Virtual Machine currently uses a modified QEMU to provide this ability for Intel's VT and AMD's SVM technologies. On VT capable Intel processors the 'vmx' cpuflag will show up in /proc/cpuinfo. 'svm' is shown for AMD-V enabled processors. VT is usually disabled by the BIOS - some vendors allow you to enable it from the BIOS menu. AMD-V can not be disabled by the BIOS. It is expected that once KVM matures it will be submitted for inclusion in QEMU.

QEMU doesn't support this by default. Note that you can use Ctrl-Esc for the Start Menu instead, and you can use "sendkey menu" in the monitor to get the Right-Click Menu button. If you can not live without these keys, you can try this patch. A patch that will allow you to send the Start Menu key via the sendkey command in the monitor is here. The key is called "windows", so you invoke it as "sendkey windows".

Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU not "emulate" any hardware you run a kernel on. You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.

Because QEMU only writes information in the guest OS, the chances to destroy the host OS are very low.

The guest OS provided by FreeOSZoo is executing into QEMU emulated environment, including a virtual hard drive and a virtual memory space. Whenever a serious problem happens on the host OS (like a power failure, a virus, a hard-disc failure, etc...), the guest OS provided by FreeOSZoo may be destroyed. We can only recommend to make daily backups.

This is answered below in the question "How do I know that Gridfinity is safe and won't harm my computer?".