lmemsm

I just got used to VirtualBox and ended up having to switch to QEMU. VirtualBox seems to run better than QEMU. I tried to load several operating systems in QEMU that ran fine under VirtualBox and they failed. Decided to try a Debian netinst because that works well with most machines. Then I had to figure out all over again how to get files between the host and guest systems. It's harder to find documentation on what you're looking for with QEMU as compared to VirtualBox.

The first step is to download and install qemu someplace. I'm assuming it's in the path. Otherwise, you need to specify where to run it from.

Next step, create a virtual disk to install the operating system to. The following creates a 2 GB image file in raw format. You can choose other formats.

qemu-img create linuximage.img 2G

I'm using an ISO for 64 bit Linux, so I use qemu-system-x86_64. For 32 bit systems, I can use qemu-system-i386. There are options like qemu-system-i386w.exe which I was wondering about. Turns out these are for use on Windows systems. They prevent bringing up a console when as well as a window when running. However, I typically run everything from the command line, so there's no advantage to this. Windows programs running in console don't create a new console. I recommend sticking with the standard versions without the w especially if you're running from the command line or on a non-Windows system.

I downloaded a Debian netinst ISO and put it in the iso directory. This is the command I used to start QEMU so I could install Debian to the linuximage.img file.

qemu-system-x86_64 -hda linuximage.img -cdrom iso\debian-10.10.0-i386-netinst.iso -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G -boot order=dc -usbdevice tablet

The -m option specifies RAM and I gave it 1 Gigabyte. Once you run the command, hopefully the operating system should boot from the ISO as if it was a CD. You can then proceed to install it to linuximage.img which should appear as the first hard drive on your system. Once the system is installed, you probably want to Power Down and/or Quit QEMU.

Use the following command to boot from the image rather than running from the ISO file.

qemu-system-x86_64 -hda linuximage.img -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G  -boot order=c -usbdevice tablet

The -usbdevice tablet setting seems to help smooth out mouse support which didn't work well without it.

Now comes the hard part, I wanted to move files back and forth from the new system. If the files are fat32 (such as a ReactOS image, you can mount the image and read the files. That doesn't help much with operating systems that use other disk formats. You can load images as floppies or cdroms (typically read only) or add another hard drive. So, the idea was to add a second drive that was formatted using a format the host system could read. I created another image and attempted to format it in using the Guest operating system in a way that the host could read. That failed. I recommend mounting the image and letting the host operating system format it. Then, the guest operating system can be set to access it as a second drive.

To do this on Window, I used a program called ImDisk.
https://sourceforge.net/projects/imdisk-toolkit/
Latest versions of Windows are supposed to allow you to mount an image as well.

I created a new image using:
qemu-img create drive.img 2G

Once I mounted the image using ImDisk, the operating system asked if I wanted to format the image and I let it do the formatting. Then, I could access the image using QEMU. Make sure the drive is not mounted on the host system before using it with the guest system and vice versa.

qemu-system-x86_64 -hda linuximage.img -hdb drive.img -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G  -boot order=c -usbdevice tablet

When I tried formatting the drive using Linux in QEMU, it wanted to access the new drive as /dev/sdb1. When I just use the image created from Windows, it used /dev/sdb.

Once you've created and formatted the extra image, you can access it in your virtual operating system. If you're running Linux virtually, you'll need steps like these.

mkdir -p /mnt/data
mount -o defaults /dev/sdb /mnt/data

They needed to be performed as root or you need to get sudo working properly first. Directory creation only has to be performed once. The mount needs to be done each time you activate the operating system and want to access the image unless you add the information to auto mount it in /etc/fstab. You can also unmount the drive using umount.

Once the drive is mounted, you can move files to and from it. You can see if there's anything on the image using:
ls -l /mnt/data
Copy or move files from /mnt/data or whatever location you mount the drive at as well.

While I couldn't access an image I formatted in the guest system, I did want to go through the steps. It worked fine from within the host and was readable from there.

Install fdisk. Since I'm using fat32, I also needed to install dosfstools. I found the tools in /usr/sbin and had to run from that directory since it wasn't in my path. The commands below assume programs are in the path. They probably need to be run as root or using sudo.

fdisk -l

This shows your images so you can find their names. I set drive.img as -hdb so it shows up as /dev/sdb on a Linux system.

fdisk /dev/sdb

The fdisk program will prompt for further information.

At the fdisk command prompt, I gave it the o option. This creates a new DOS partition. The next command was n to set a partition type. I chose p for primary. I chose the default partition number 1. It brought up first and last sector options and I chose the defaults for both. At the command prompt, I chose t for partition type and gave it a hex code of b which selected W95 FAT32. At the command prompt, I selected w which wrote the changes and exited the program. From the normal command prompt, I ran the following:
mkfs.vfat -F 32 -n WINSTORAGE /dev/sdb1

This should format the image and name the image WINSTORAGE. Windows prefers upper case for disk labels.

Once done I was able to use mkdir to create a directory under /mnt to mount it. In this case it needs to be mounted as /sdb1 not not sdb. The result made an image that worked fine in the guest system but wasn't recognized on the host.

If your host system is a Linux system, it might be helpful to use a more familiar format like ext2 or ext3 instead of fat32. On the other hand, many flash drives use fat32 and most systems can read them, so it might be a useful solution as well. If you create the second image before installing the new operating system, depending on the installation process, it might recognize the extra image and incorporate it automatically. Just make sure not to reformat it when installing the operating system.

The mtools programs can be used on various operating systems and can be used with emulators and images formatted for DOS. Wondering if it could be used to format a mounted image file as fat32 on systems that don't support it natively.

I was also able to successfully create an ISO image on the host system using mkisofs and load that as a virtual CDROM on the guest.

mkisofs is available on Windows with various software. I typically installed DVDStyler and used the program it supplies. Debian and some systems typically don't supply cdrtools which contains mkisofs. Many systems use another package which emulates or gives equivalents to commands cdrtools supplies. GRML is a Debian based distribution that does offer the original cdrtools package. There are some arguments over copyright which kept cdrtools from being added to some distributions. I also found a utility that worked only on Windows that could create ISO files. It was used by some ReactOS developers. Nice thing was that it built easily from source using MinGW.

Assuming my files are in the tmp directory below the directory I'm in, I can run mkisofs with the following command to make an ISO file.
mkisofs -r -R -J -l  -o test.iso tmp

I can add the image using a command like this one.
qemu-system-x86_64 -hda linuximage.img -drive id=cdrom0,file=file,index=1,media=cdrom,file=test.iso -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G  -boot order=c -usbdevice tablet

Once in Linux, the cdrom can be accessed after mounting it with:
mount /media/cdrom

I've used that technique to get Debian to install successfully with QEMU. Haven't had much luck with other systems yet including other versions of Linux. I'd also like to get Androic-x86 or Bliss OS working at some point. XFDOS would be another interesting option to try.

I did finally get ReactOS running in QEMU. Reactos is tricky to load. The Reactos version used must be 0.4.14-RC or higher.

I created an image using the native QEMU format as recommended on the ReactOS site.

qemu-img create -f qcow2 reactOS.qcow2 2G

I installed ReactOS on the image by following the prompts after using this command:

qemu-system-i386 -drive if=ide,index=0,media=disk,file=reactos.qcow2 -drive if=ide,index=2,media=cdrom,file=iso\reactos-bootcd-0.4.15-dev-2847-g0ffbbab-x86-gcc-lin-dbg.iso -m 1G -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -usbdevice tablet -boot order=dc -serial file:reactos.log

Most of the options I picked were defaults.

After the image is formatted and the operating system is installed, power down and/or quit QEMU.

I ran the following command to complete setup after the ISO was no longer accessible from the CDROM drive. It let me set up the system.

qemu-system-i386 -drive if=ide,index=0,media=disk,file=reactos.qcow2 -drive if=ide,index=1,media=disk,file=drive.img -m 1G -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -usbdevice tablet -boot order=dc -serial file:reactos.log

After it's set up as desired, power down and/or quit qemu.

Now, I can run the following command to move files to and from ReactOS within QEMU using the drive.img.

qemu-system-i386 -drive if=ide,index=0,media=disk,file=reactos.qcow2 -drive if=ide,index=1,media=disk,file=drive.img -m 1G -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -usbdevice tablet -serial file:reactos.log

It's accessible as e:. The d: drive is still reserved for the CDROM device.

At one point when I restarted the image, it asked me to press Ctrl-Alt-Delete to get into the system. I found out you can send special keys to QEMU by pressing alt-ctrl-2 to get to a screen where you can enter commands. You can emulate keys using sendkey. I entered sendkey alt-ctrl-delete. Return to the original screen using alt-ctrl-1. This actually accomplished nothing in this case, because the screen was coming due to an error with the system, possibly the registry. I ended up having to reinstall ReactOS to fix it. Sending alt-tab this way once the system was reinstalled worked well.

ReactOS is interesting and can run some great Windows programs. However, it does crash more often than I would like. Can't help thinking a Linux system with Wine would be more stable. There are several themes, but I miss the Windows XP Silver Metallic theme. Supposedly, you can copy the .msstyle file over from a Windows XP machine to ReactOS and it should emulate the style.

Still investigating what other operating systems will run under QEMU and what commands they require.

So, that's my cheat sheet of useful QEMU commands to date. It does seem to have some advantages to VirtualBox, but so far, I haven't been able to run as many operating systems on it. You also have to decipher what to use in the command line or it may fail to run. Once you have the techniques down and the images created, it seems to work well. It seems less complicated to get files in and out than using VirtualBox Guest Additions. Unfortunately, documentation for how to accomplish it is difficult to find.
I'll be interested to see if QEMU will allow access to an extra image when running an Android operating system. VirtualBox Guest Additions typically wasn't an option for most virtual Android based operating systems. Hopefully, that's all that's needed to get a virtual operating system up in QEMU and develop/build applications natively within the guest system.