The Best of Both Worlds

To make the emulated system run faster, I installed kqemu. I downloaded kqemu-1.3.0pre11.tar.gz from the QEMU download page and extracted it inside D:\QEMU\. Then, I clicked kqemu.inf with the right-mouse button and selected Install. Next, I added, in start-linux.bat, the command net start kqemu and added the parameter -kernel-kqemu to qemu.exe. Now, the last two lines of start-linux.bat look like this:

net start kqemu
qemu.exe -L . -m 256 -kernel-kqemu -hda \\.\PhysicalDrive0 
 ↪-soundhw all -localtime

Note: Scientific Linux 4.4 does not work at all with the parameter -kernel-kqemu, and the problem seems to be an incompatibility of the kernel with the BIOS file (which is named bios.bin, and I think that represents the BIOS configuration of the emulated system). When I replaced it with the BIOS of Puppy Linux, it worked. It is strange that the original BIOS is 128KB and Puppy's BIOS is 64KB, which is older as well.

The default QEMU parameters for the network are -net nic -net user. This means that it will emulate a virtual interface on the Windows side and create a network interface eth0 for the emulated Linux system. Both of these interfaces have a virtual connection between them, allowing them to communicate with each other. The IP of the Windows virtual interface is 10.0.2.2/24, and QEMU also creates a virtual DHCP server connected to it. To get an IP for Linux from the QEMU DHCPD, I log in as root and give the command dhclient. Then, the Linux interface gets IP 10.0.2.15/24, gateway 10.0.2.2 and DNS 10.0.2.3. Afterward, Windows and the Internet can be accessed from Linux without a problem.

Figure 2. Network Diagram

To check the network configuration, try the commands ip address ls, ip route ls and cat /etc/resolv.conf in Linux. Here's example output from those commands:

[root@fedora6 ~]# ip address ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

[root@fedora6 ~]# ip route ls
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
default via 10.0.2.2 dev eth0

[root@fedora6 ~]# cat /etc/resolv.conf
; generated by /sbin/dhclient-script
nameserver 10.0.2.3

To test the network connection, try the commands ping 10.0.2.2 and wget http://www.google.com/.

If you try to ping www.google.com (or any other IP), it won't work. However, the network connection is okay and working, and you can verify it with other tools, such as wget or lftp. It simply means that ping is not working for some reason. This has been very misleading to me, because the usual way to check for network connectivity is to ping something out there.

Because I can ping Windows from Linux as 10.0.2.2, I also can access any service (dæmon) that runs on Windows. In particular, I can access any file-sharing services. Usually, I run Apache as a Web server on Windows. It can be installed easily with EasyPHP. Then, I use wget to retrieve any files that are accessible through the Web server.

Another service I use is FTP. I install and configure it using the FileZilla FTP server. From Linux, I can access the folders (directories) that are shared by the FTP service, using lftp (you can use any other ftp client as well). This is better than using a Web server, because I can transfer files both ways—from Windows to Linux and from Linux to Windows.

I've even used svnserve to run a Subversion service in Windows. From Linux, I could access the Subversion repositories in Windows. Think of it as a way to transfer files between Windows and Linux, as you can access the svn repositories from both Windows and Linux, although it is not a very straightforward way to transfer files.

I tried transferring files between Linux and Windows using a fat32 partition, which can be accessed from both systems. Theoretically, there is no reason why it should not work, and actually it does work; however, it does not work so well. The problem is that the modifications that are done to fat32 from Linux are not “seen” from Windows until it is restarted, and the modifications that are done from Windows are not “seen” from Linux until QEMU is restarted, which makes this solution impractical and unusable.