Soussan DAS Computer Consultants

Our Team
Cool Stuff
KeyholeKeyboardLaptop ComputerComputer Chip

Solving Linux issues running in Virtual PC 2004 & 2007 environments

I love virtual machines! The first one I ever used was back in 1976 where a set of programs written in HP 2000F's BASIC interpreter simulated a Fortran IV programming environment. It is kind of neat seeing a completely different computer within another computer. The next one I saw was one that emulated an Apple II and ran on the PC.

When I was studying for all the MCSE exams back in the NT4 days (~1998 or so), I had at least 6 computers setup in the basement lab and was constantly tearing them down and building them back up for different configurations in order to learn first-hand what needed to be done. From memory, I had an NT4 workstation, 2 NT4 Servers, a Windows 95, a Windows 98, and a Mac IIsi running system 7. I stopped short of setting up a Novell box even though the exam heavily tested migrating from Novell to NT.

Click Here for Press Release

That was then, this is now

How different things can be today. With one system and LOTS of memory, I can have many different operating systems interact with each other all on the same computer, experiment with different configurations, completely break entire virtual systems and push the "UNDO" button to go back to how things were before I booted this last time.  


Except when things don't work right

Which is exactly what happened recently. And I looked all over and found nothing to give me any clue on how to fix it. So here it is, the problem defined, how it manifested itself, and how I fixed it - hopefully this will help someone else with their issues as well.

I had a virtual machine (VM) created years ago that ran in Microsoft Virtual PC 2004 that was a RedHat Linux 7 distribution. I used it for a few things, mainly to run an open source vulnerability scanner called Nessus back when you could scan your network without having to pay $1200/year for the vulnerability database. The VM sat unused on my old P4 notebook until another project to update some old network computers (NC) with additional features crossed my path, and that VM seemed like the perfect platform to run on that NC. It happened to be a Neoware EON N4000T with 48 MB DOM (DiskOnModule) running NeoLinux which was based on Red Hat Linux, but the details of that project are potentially the subject of another article.

I have other virtual machines - a Solaris 10 instance, a Ubuntu 6.10 installation, and even a DOS 6.22 / Windows for Workgroups 3.11 instance. What I'm describing here I also saw on the Ubuntu 6.10 virtual machine as well as a Ubuntu 9.1 instance I recently decided to dabble in. I can't speak yet for the Solaris instance as I haven't booted it in years.

Symptoms of the problem

The machine runs, but it is very slow. I mean pathetically almost unusable slow. And this was on my fancy new (at the time) Core2 Duo system with 4 GB RAM and 2.6 GHz of clock speed. If anything, this should run faster than anything I'd ever seen on my older 1.x GHz Pentium 4 notebook. Yet there it was, occasionally going out to lunch and freezing, only to wake up 10-30 seconds later and be responsive again.

When I paid attention to the boot, I noticed numerous lines that read:

hda: lost interrupt
hda: lost interrupt

If I ran dmesg, those errors showed up in the log as well.

This was running the new improved Microsoft Virtual PC 2007 sp1 on a Vista machine, versus my old system.

Here is a screen shot of the boot screen, showing the various error messages. Where / when they happened changed, but the effect was the same - the VM was barely functional:

Linux hda: lost interrupt messages

The big symptom I noticed was the virtual machine was running very slowly.

All the searching through the web on that hda: lost interrupt message pointed out hardware errors, like wrong cables, BIOS set wrong, BIOS updates, etc. - nothing told me exactly what the problem was or how to fix it.

I'm going to skip the diagnostic story and cut right to the chase.

If you are running on a multiple core system - Mine happens to be a Core2Duo, but it might very well happen on others as well - you have to force VirtualPC.EXE to run on only one of the cores.

To do this, go into task manager, find the process VirtualPC.exe, and right click it:

Task Manager Process Menu

Select the Set Affinity... menu option, and you'll see this screen:

Task Manager Set Process Affinity Screen

It looks slightly different in XP, but functions the same. Both CPU 0 and CPU 1 were checked on my system. When I unchecked CPU 0, that forces VirtualPC.exe to only run on core #1. This cured all my Linux virtual machine problems! If you have a quad core, or better system - leave only one of the CPUs checked. If you find a specific CPU that works and one that doesn't, please let me know so I can update this document and help others out.

This problem exists no matter what version of Virtual PC you are running, from 2004, 2007, and any service packs. I can't speak to this getting fixed in any future version.

I'll bet this problem also impacts Microsoft Virtual Server since both products are based on the same virtualization engine. But I haven't tried it with that, so if someone discovers this fix works for them with Virtual Server if you'd let me know I'll update the article with that information.

Curiously, I was able to install & run using Sun Microsystems VirtualBox product without any issues. It also gave me more options for the virtual machine, so playing with that is now on my list of things to do.

If you found this helpful or not, please send me a brief email -- one line will more than do. If I see people need, want, and / or use this kind of information that will encourage me to keep creating this kind of content. Whereas if I never hear from anyone, then why bother?

I can be reached at:

das (at-sign) dascomputerconsultants (dot) com


David Soussan
(C) 2009 DAS Computer Consultants, LTD. All Rights Reserved.

Everything below this line is to help search engines find, index, and thus help users find this content.