October 2009 - Posts

Windows Virtual PC (no not Microsoft Virtual PC) and I met up about the same time I installed Windows7 and also realized that the company laptop had support hardware assisted virtualization. Then I spent some time developing an image for BizTalk developers. After a while we all started noticing a “degradation in performance” or to put it bluntly; the performance was sh*t.

The problem was finding the solution since a Google search on “virtual pc bad performance” or “virtual pc slow mouse” turns up a lot of posts from people who simply needs a better computer. So I thought I would write a post that would turn up on Google when you search for the things I searched for. If you are a human reading this, you can skip to the solution at the end of the post.

When I started any image with the same settings and giving it as much resources as my laptop could spare (2,5 gb of memory), at first performance was good, but after about 10 minutes things started to slide downwards. Programs reacted slowly, graphics update was slow and things was generally miserable. At the worst point there was a clear delay for about 5 seconds from when I clicked the mouse button to when the interface responded. Of course I checked all the usual things like program priority and limiting SQL-server memory use.

These were the visible symptoms: slow interface and slow mouse.

The “invisible” was: High level CPU usage. Reaching 100% at the slightest provocation.

The solution finally turned up in this blog post. There are other posts pointing out the same thing but this post was the only one I could find that gave an explanation. Not even Virtual PC Guy’s blog said why. The solution is really simple:

  1. Turn of your virtual machine.
  2. Use Run and type “appdata”.
  3. Navigate to the Virtual PC settings file: “Local\Microsoft\Windows Virtual PC” (on Win7 using Microsoft VPC) or "Roaming\Microsoft\Virtual PC" (on Vista using Windows VPC) and open Option.xml
  4. Add this to the file after the last <virtual_network>-tag.
    <virtual_machines>
       <enable_idle_thread type="boolean">true</enable_idle_thread> 
    </virtual_machines>
  5. Save and reopen your virtual machine.

Personally I found an options-file in %appdata%\Roaming\Microsoft\Virtual PC as well and added the tag there to just to be safe. I don’t think you have to but better safe than sorry.

I used this in on Windows Virtual PC but I think it will work on Microsoft Virtual PC.

The explanation for the behaviour is the power management on the laptop. When you start your virtual machine, and start using it, the host OS thinks that it’s not very busy and turns off power to the processor to save energy (stupid I know). The host processor powers down and the guest processor gets even less time and so the guest processor is easily overloaded. The tag makes Windows Virtual PC use the host machine’s system idle thread therefore picking up the slack on the host machine processor.

Let’s hope “they” solve this in the next release.

Sometimes I think there is a grand conspiracy on my part. Somewhere deep within the windows core code there is a line like

if ( Instance.RegisteredUser = "Mikael Sand" )
    GenerallyFThingsUp();

And then I just remember that it probably is my own fault.

There is a strange BUG when you install BizTalk in a single server environment on a virtual machine. Strange being the operative word here. You get this error

Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSO0FAB.bak (SSO) Additional Information (0x80070005) Access is Denied.

So what happens is that the SSO Administrators group is never created during install (note that all other groups are created). No SSO Admin group = Unsuccessful authentication = Access is Denied.

The solution is simple though:

  1. Unconfigure BizTalk and delete the SSODB and BusinessRulesDB. The wizard does not delete them.
  2. Now create the SSO Administrators group manually and add the install account and the BizTalk Service Account to it.
  3. Log out and log back in. Restart the installation.

As commenter Jonathan Schellack points out this seems to be a problem in the 2010 version as well, so if you are trying to install the 2010 version, you might get this problem as well.
I have personally never experienced this problem either with the 2010 nor the 2009 version, except for that time that triggered me to write this post, so it is really hard to replicate.

If you look in the log following the failed installation you will only get an error stating that the group could not be created and then the installation quits. This does not seem to be a BizTalk installation issue but rather something to do with Windows it self.