Showing posts with label qemu. Show all posts
Showing posts with label qemu. Show all posts

Wednesday, November 25, 2009

A First Peek at Google's Chrome OS

Last Thursday, Google Inc. introduced Chrome OS aka Chromium OS, to the public with quite considerable fanfare. The news enjoyed universal coverage in the media. Chromium OS is an operating system that the company is developing on its own as an open source effort. Sources and build directions are now easily accessible.

I gave it try. In short, Chromium OS consists of a Debian-derived operating system using a Linux 2.6 kernel and Google's Chrome browser. It is meant to run on personal computers with the i386 architecture with either 32- or 64-bit processors. With the packages Google includes, the compressed install image is roughly 800 megabytes in size and takes up 2.8 gigabytes of disk space expanded.

The distribution is open to customization. Adding applications is possible. Only, the packages have to comply with the Debian distribution format.

Obviously, Chrome OS is meant to run bare-bones on very thin clients. Non-essential applications and data are intended to be stored elsewhere in the cloud. The small footprint and, hopefully, the ensuing speed may harbor this operating system's greatest strengths, potentially turning Chrome OS into a powerful, cost-efficient tool for corporate users.

In view of the current governmental push for patient record digitization, the health care sector appears particularly suited. I regularly visit a large academic outpatient clinic. Every examination room is equipped with a conventional stand-alone personal computer connected to an intranet. Across the entire hospital campus, these computers must number in the thousands. In such environment, thin clients appear superbly suited to drastically diminish cost for hardware, software and IT maintenance. Here, Chrome OS may provide a rich resource.

The build instructions for Chrome OS on the Chromium project site are straight forward. I compiled the system with Ubuntu's Karmic Koala (9.10) hosted on a work station with two 64-bit AMD Opteron 246 processors. The hardware is described in detail in my post dated May 22, 2008. I opted not to compile the Chrome browser myself. Instead, I downloaded the pre-built package available from Google and copied it to the build directory as directed in the Chromium project documentation. Do not omit to provide a user name and a shared user password. They may be essential for log in and system administration later.

The build process unfolded uneventful. However, complications arose, when I had to decide how to actually run the Chrome OS.

Google provides two options to ready the successful build for installation. One method uses a bootable USB 1-gigabyte flash memory drive, from which the system can be installed on a dedicated computer. For this procedure to work, USB devices have to be enabled in the boot list of the bios first.

The other installation option bundles the build in a VMware image named ide.vmdk.

Since I did not wish to dedicate a computer to testing Chrome OS quite yet, I chose this option. Eventually, I managed to install the image on a virtual personal computer emulated with qemu-kvm (version 0.11.0). Unfortunately, the emulation slows operations down considerably. Regardless, the procedure worked sufficiently fast for preliminary exploration.

I used qemu with the following options on the command line to start the emulator:
  • qemu-system-x86_64 -localtime -m 256 -vga std ide.vmdk

The screenshots below illustrate the sequence of steps I encountered starting up Chrome OS.

After a successful boot, the system introduces itself with a login screen.
I used my preset shared user password to log in. After we are signed in successfully, the Chrome browser launches. automatically.
We may browse the web or start our web applications.
Not too bad at this point!

Alas, I was not able to bring Chrome OS up to speed with qemu. I found a satisfactory solution in virtualbox. This emulator, however, does not accept the format of ide.vmdk. It has to be converted to vdi. The conversion takes two steps: We have to convert the Chrome OS vmdk image to a raw image with the suffix .bin with two commands in the directory where the image resides:
  1. We have toconvert the Chrome OS vmdk image to a raw image with the suffix .bin using qemu-img convert  ide.vmdk chrome_os.bin
  2. Then, we convert the raw image into a vdi image using a virtualbox tool with the command VBoxManage convertdd chrome_os.bin chrome_os.vdi

If we have not installed virtualbox yet, we shall be instructed to do so using sudo apt-get while trying to execute the second command.

After opening the virtualbox graphic user interface with the command virtualbox, we attach the vdi image as a hard drive from the menu by clicking Add in the Hard Disks tab under File > Virtual Media Manager. We locate and select the chrome_os.vdi image and click Open. Once the image has been added to the list, we click OK, and continue to create the remaining virtual machine profile. I reserved 256 megabytes as Base Memory. The operating system is Linux. The version is 2.6. The rest is set by default or optional. Now, Chrome OS is ready for boot.

Virtualbox is also available for Apple Macintosh computers with the intel architecture. Following the same steps as above, I successfully installed Chrome OS using the vdi image in virtualbox on a Mac Mini running OS X 10.5 (Leopard).

The emulator runs Chrome OS on both computers surprisingly fast.

Addendum
  • According to Stephen Shankland' s post with the title "Google shows off Chrome OS tablet ideas" on CNET.com dated Dec. 29, 2009, that I found on CNN.com today, the ideal thin client running Chromium could be a tablet (02/07/10).
Related Posts

Related Links

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.

KQEMU INSTALL
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

WINDOWS 7 INSTALL
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.

INTERNET
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:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\Interfaces\{GUID}
  • 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: 10.0.2.15
  • Gateway address: 10.0.2.2
  • SubMask address: 255.255.255.0
  • DNS Server address: 10.0.2.3
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.

SHARED FOLDER
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 \\10.0.2.2\qemu_share on the folder choice line,
  • choose Reconnect at logon,
  • and click Finish.
SOUND
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
PC
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.

RUNNING WINDOWS 7
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.

Addenda
  • 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