Tuesday, April 7, 2009

Windows 7, Qemu & the Internet

I decided to participate in Microsoft's testing program for Windows 7 earlier this year. I downloaded the 32- and the 64-bit installation package iso-images from Microsoft's website. I envisioned to test the next generation Windows operating system as guest in a qemu emulator (version 0.9.1) using Ubuntu's Hardy Heron 8.04 as the host operating system. Hardy Heron is installed on a MSI K8T Master 2FAR motherboard with two AMD Opteron 242 CPUs and 4Gb of RAM. Binary versions of qemu compiled as applications for for Apple's OS X are available from Q. The installation of Windows 7 should not be different. Below I describe what needed to be done to render a successful installation.

To install kqemu on the host, I essentially followed instructions provided on the ubuntu community documentation site here and on alien.slackbook.org here. Microsoft recommends to provide at least 16 Gb for Windows 7. I decided to create a raw image of 20 Gb and reserve 1024 Mb for RAM, that is the maximum qemu allows, in the /home directory for the guest, running the following command in the terminal:
  • qemu-img create -f raw windows7.img 20G

I used the following command to install Windows 7 on the raw image:
  • qemu-system-x86_64 -localtime -net nic,model=ne2k_pci,vlan=0  -net user -m1024 -cdrom './windows7.iso' -boot d windows7.img
I repeatedly attempted to use the 64-bit version of Windows 7 without success. Each time, the installation process halted with a blue screen below.

By contrast, I was successful with the 32-bit version. The install went smoothly. I could login and test the applications. However, I could not connect to the internet. The internet icon in the bottom panel was crossed out. The problem solver suggested that the proper driver was not found. I was asked to provide one. The reader is advised to review the experience I recount below to the end.

I examined numerous threads on drivers for windows and qemu over several weeks. By default, Qemu provides an ethernet interface that uses the Realtek RTL8029 driver. This is a legacy driver that Realtek no longer supports. I found an installable driver v5.08 here.

Installing, the RTL8029 driver resulted in limited connectivity with no internet access. Advice on a windows help forum suggested that this problem may be solved with disabling the firewall. It did not work.

On my continued quest for solutions, I found the following suggestions:
  • Under Properties for the Driver found in the Network and Sharing Center, click Local Area Connection, uncheck the Internet Protocol Version 6 (TCP/IPv6) option.
  • Click Start in the bottom panel,
  • type regedit in the Search programs and files box, and click on regedit in the list.
  • If you are prompted for an administrator password or for confirmation, type your password, or click Continue.
  • Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip4\Parameters\Interfaces\{GUID}. In this registry path, click the {GUID} subkey that corresponds to the enabled ethernet interface. 
  • On the Edit menu, point to New, and then click DWORD (32-bit) Value.
  • In the New Value #1 box, type DhcpConnEnableBcastFlagToggle, and then press ENTER.
  • Right-click DhcpConnEnableBcastFlagToggle, and then click Modify.
  • In the Value data box, type 1, and then click OK.
I added one more step:
  • Locate and click the following registry subkey:
  • On the Edit menu, click on New, and then on DWORD (32-bit) Value
  • In the New Value #1 box, type DhcpConnForceBroadcastFlag, and then press ENTER.
  • The Value data box remains set to: 0.
  • Close Registry Editor.
Note a DhcpConnForceBroadcastFlag value of 0 disables this registry entry. You can use this registry entry to prevent Windows from using the DHCP BROADCAST flag. After you set this registry entry, Windows never uses the DHCP BROADCAST flag.

Taking these steps did not render the ethernet connection with the RTL8029 driver functional either. Eventually, I disabled DHCP and entered the static IP addresses proposed on ubuntu's community documentation site manually:
  • qemu-emulated Windows 7 I.P. address:
  • Gateway address:
  • SubMask address:
  • DNS Server address:
Disabling the DHCP server did not help either. At that point, I concluded that connecting to the internet was not going to work with the legacy driver. Instead, I found here that recent versions of qemu may support the rtl8139 driver, though warning was given that this option would not provide any connectivity. Despite, restarting qemu with 
  • qemu-system-x86_64 -localtime -net nic,model=rtl8139 -net user -m1024 -cdrom './windows7.iso' -boot d windows7.img
produced a working connection to the internet, miraculously automatically. The system loaded the RTL8139C+ Fast Ethernet NIC driver from its own driver directory. The interface uses DHCP and found the correct IP addresses. I did not have to edit anything manually. The pre-installed driver can be replaced with the most recent driver from Realtek for Vista 64 and Vista bundled in the newest auto installation program (Submission ID: 1310628).

Further experimentation showed that the RTL8029 driver can be used as well. Once specified on the Qemu command line with the "-net nic,model=ne2k_pci" option, Windows 7 will load the RTL8029 driver, if it has been previously installed in the system's driver directory and configure an ethernet connection. The same will happen, when you start qemu with the default option "-net nic".

A crucial prerequisite for Windows 7 autoconfiguration to work successfully is that the RTL8029 driver must have been installed beforehand, because the driver is not included in Windows 7. By contrast, if RTL8139 is specified with the qemu command, the system loads the RTL8139C+ Fast Ethernet NIC driver pre-installed in Windows 7.

IE 8
Finally, I was ready to install the latest updates from Microsoft and test applications. I remain unimpressed with the Internet Explorer (IE) 8. This browser denies access to sites like this blog which are perfectly accessible with older versions of IE, Google Chrome, Firefox, Opera, Safari, and Seamonkey. IE 8 help does not suggest any precise actions to remedy the problem. Hence,
I opted for Google Chrome instead.

To access a shared folder on the host system, kqemu must be started with the following command in the terminal:
  • qemu-system-x86_64 -localtime -net nic -net user -m1024 -boot c windows7.img -smb /home/user/qemu_share
In order to access the qemu_share folder from Windows 7, the folder's permissions must be set for sharing on the host. In Windows 7, the folder can then be mounted following the sequence below:
  • Click Start in the bottom panel, choose Computer,
  • right-click Network and choose Map Network Drive...,
  • enter \\\qemu_share on the folder choice line,
  • choose Reconnect at logon,
  • and click Finish.
Qemu provides several options for sound hardware, the only option Windows 7 recognized on my setup was:
  • -soundhw es1370
Ensoniq's ES 1370 technology dates back at least ten years. I found an acceptable driver on the Ensoniq support site. The driver installer location can be accessed, using the following path:
E-MU Legacy Hardware support
Audio PCI
Windows 3.1 Driver Version 3.30.06.

Alternatively, you may wish to download the driver installer directly here.

The driver's setup wizard refused to fully install the software. Intriguingly, the following Windows 7 update detected and upgraded the ES 1370 driver, I needed to set the variable QEMU_AUDIO_DRV in my environment. Which drivers are supported depends on your host operating system. The options can be reviewed with qemu -audio-help. I chose alsa. Therefore, the launch of the emulator must be preceded with the comands :
  • export QEMU_AUDIO_DRV=alsa
  • export QEMU_ALSA_DAC=dmix
  • export QEMU_ALSA_ADC=null
Though I turned up full volume in all controls, the speaker sound remained exceedingly attenuated. The problem does not reside with the host. My Windows 2000 XP system emulated with the same qemu version produces great sound. This shortcoming still remains unresolved.

At this point, the complete command line to boot Windows 7 on kqemu includes the following options:
  • qemu-system-x86_64 -localtime -net nic -net user -m1024 -boot c windows7.img -smb /home/user/qemu_share -soundhw es1370
I recommend to save this command line in an executable shell script. The blue screen still erratically pops up during boot. The system will boot up after a couple of tries.

  • I applied the same procedure to successfully install the release candidate that became available for download on May 5, 2009. Reboot does not always work during installation. You may have to go through a number of lengthy repair routines that Windows suggests and be patient. Eventually, it will work (05/10/09).
  • I recently upgraded Ubuntu to Karmic Koala (9.10). This upgrade comprises a new version of qemu (0.11.0), changing the available options. With the new version, I can run the emulator with two central processing units, that is -smp 2. More types of emulated ethernet cards are available. As a consequence of the update, windows 7 uninstalled the rtl8139 ethernet driver after the next boot. I had to re-install the system-provided drivers with the Device Manager (Control Panel & System and Security & System). For sound, the es1370 option is still listed following the command qemu -soundhw ?. However starting qemu with this option now fails. I am investigating (11/28/09).
  • The sound problem is unrelated to qemu. After I removed the environmental variables for alsa from the start-up script, windows 7 recognized the virtual ensoniq sound card and installed the es 1370 driver. The loudspeaker icon on the bottom menu bar of windows 7 turned unstruck, indicating active sound. However, no sound is to be heard yet. The environmental sound variables many need to be set differently in Karmic, possibly because Karmic appears to use pulse audio instead of alsa by default. I am investigating further (12/22/09).
  • If pulse audio is used for sound, the above environmental sound variables must be replaced with: QEMU_AUDIO_DRV=pa (04/15/10).
  • The download link on www.softwarepatch.com for the RTL8029 driver provided above does not seem to work at times. I found an alternative at www.techspot.com here (08/03/10).
  • Because of recently exploited vulnerabilities, the use of the RTL8029 driver is highly discouraged. You may wish to read more here: The Stuxnet Worm, Windows & The Internet (09/29/10).
  • For those who are not obligated to use qemu as emulator, I am pleased to share that I have had great success with installing and running Microsoft Corporation's Windows 8 Consumer Preview (64 bit) on VirtualBox 4.1.10. VirtualBox is emulation freeware maintained by Oracle (formerly Sun Microsystems). The installation proceeded without impediments. I followed the suggestions for the best suited settings, and made sure that no warnings remained, before I started the installation. Red triangles alert to sub-optimally selected parameters in the settings pulldown menu. The most important choice may be to dedicate no more than half of the RAM installed in your computer to emulated base memory, even if the Windows operating system can be used with more. Since I installed the system on an old Apple MacBook (2.26 GHz Intel Core 2 Duo; OS X Snow Leopard, version 10.6.8) with only 2 GB DDR3, I limited the base memory to 1 GB. In addition, I limited the emulator video memory to 128 MB. I dedicated 20 GB to static disk storage, choosing the vmdk-format. With these settings the emulated operating system performs astonishingly well. Internet access is flawless. The virtual machine is accessible on our home network. For installation, I used the downloaded iso-image of Windows 8. Therefore, I had to make sure that the CD/DVD drive option pointed to the image for the initial boot. The image can be selected under the disk icon on the bottom bar of the virtual box or from the pulldown settings menu. Good luck (03/28/2012)!
Screenshot of VirtualBox running Windows 8 on virtual machine (Read more here).

Related Posts

1 comment:

Anonymous said...

You really should add "-usb -usbdevice tablet" which gives you mouse pointer integration without extra drivers.
Also the 64 bit version seems to work with the "kvm" fork/variant/whatever of qemu (unfortunately not with normal qemu with --enable-kvm).