Zoho Banner September 2011

Archive for the ‘Virtualization’ Category

When running through final preparations for a presentation to a few hundred people (well, tens of people…ok, at least 5 people…proabably) the last thing you need is for your Hyper-v environment to start misbehaving.   This is exactly what happened to me and I’ve just found the cause, so am feeling a lot more relaxed about things.

 I had prepared a number of Hyper-v VMs (child partitions, if using the Microsoft jargon) and found I was not able to log on to any of them following a log off.  The VMs were a mix of Windows Server 20008 64bit and 32bit.   When trying to re-log on, I received the error “Your system is running low on resources.  You cannot log on as a new user.  Please use an account that has already been logged on.”

The only workaround I found for this scenario was to shut down the machine and boot up again. 

After investigation the error about “running low on resources” appeared to be spurious.  The VMs were running fine and weren’t under any real resource load.  Assigning more memory and/or additional processors made no difference.  The problem was 100% reproducible.

 In the end I noticed that a newly created Windows Server 2008 VM did not exhibit the same problem.  From there it was a question of trial and error, running through each step of my build process to see what introduced the problem.  Bizarrely, it turned to be changing the default 96 DPI font size to large font (120 DPI).  I had been changing to the bigger font to save my failing eyesight! 

 As soon as I changed the font back to 96 DPI on my VMs the problem disappeared.

 I’m now trying to find out whether this is a bug, or just something weird in my environment.

 

Call me rash and impulsive, but the other day I blew away XP and installed Windows Server 2008 x64 Standard Edition on my Dell Latitude D830 laptop.  Other than idle curiosity, the main driver behind my foolishness was the need to create some demo machines using Hyper-V.  I don’t have any other hardware that meets the system specifications for Hyper-V, so it was the laptop or nothing.

The installation itself was a breeze and completed without mishap.  Windows Server 2008 didn’t have the correct video drivers, but I found these fairly quickly on the Dell support site.  They were Vista 64bit drivers, but work just as well for Windows Server 2008.

The first problem I encountered was that the built-in Intel PRO\Wireless 3945ABG wireless connection no longer works.  I found some 64bit Vista drivers from the Intel web site, which seemed to load ok, but I can’t see any wireless networks despite Device Manager showing the device as working properly. The Intel PROSet/Wireless diagnostic tool passes on the driver test, but fails on the hardware test.  The Dell web site also has 64bit Vista drivers but these are older than those from Intel.  I tried these older drivers too, but again without success.

I even tried installing my old Cisco Aironet 350 series wireless card, but couldn’t find any drivers that would work for that either.  The Cisco support site’s latest drivers for the card are for XP.

The second annoyance is that VMWare Workstation guests were working fine until I installed Hyper-V.  Then all hell broke loose.  The VMWare guests started causing the host to bluescreen.  There were also warning messages on the guests about changes to processor speed.  Oh, and I lost 64bit guest support.   Apparently, all this is due to incompatibilities between the hypervisors used by VMWare and Hyper-V.  Happily, I found a workaround on Geert Baeke’s web site that shows how to create a new entry in the boot loader that allows you to select a hypervisorless (is that a word?) boot option.  Good stuff.  Here’s a link to the information.

http://blog.baeke.info/blog/_archives/2007/12/18/3416738.html

Now I’m busy creating virtual machines in Hyper-V.  I haven’t used it before, but it all seems fairly intuitive, especially for anyone already familiar with VMWare.

Okay, okay, so I’m a little behind the times.  “Welcome to the nineties, dude!”, as a friend of mine would say.  I can’t help it – I’m the one who thinks this whole Interweb thing is just a fad. :-)

Anyway, I’m working with a new laptop (Dell Latitude D830) that, apart from being the size of a dining room table, has some reasonably good specs.  The key thing about the D830 is that it has a 64-bit chipset.  This means that, although the operating system is the 32-bit version of Windows XP, I have the ability to run 64-bit VMWare Virtual Machine guests.  Getting the system to the point where I could fire up a 64-bit guest took a while, so I thought I would share my experiences here.

The first step is to determine whether your host machine hardware is capable of running 64-bit guests.  There are two methods I came across for doing this.

Method 1.  VMWare Processor Check for 64-Bit Compatibility

Download the tool from http://www.vmware.com/download/server/drivers_tools.html

The tool itself is tiny and gives a minimalist output when successful, as shown in the screenshot below.

64-bit-1

Method 2.  CPU-Z

CPU-Z is a handy little freeware utility from http://www.cpuid.com/cpuz.php and provides information on some of the main devices of your system.  More importantly, it provides detailed information relating to your processor.

64-bit-2

In my case it tells me that my processor is an Intel Mobile Core Duo T7500 (codename “Merom”).  The EM64T (Extended Memory 64 Technology) tag is important in that it indicates that the CPU is based on Intel’s 64-bit technology.  EM64T was the original name and has now been superseded by the term “Intel 64″.

Armed with the processor information from Method 2, I then used Google to try to confirm whether the model supports Virtualization Technology (VT).  Some CPU models that are based on EM64T architecture (like the one in my home PC!) are not VT-capable, which means that they do not support virtual machines as guests.  The best information I found was, curiously enough, on Wikipedia.   The page covering the “List of Intel Core 2 Microprocessors”  quickly gave me the information I was looking for.  Regarding my “merom” CPU it had this to say:

Virtualization Technology: supported by all models except T5200, T5450 and some T5500″

Given that my model is T7500 it all looked very promising!

The next step was to check that the VT was enabled in my laptop’s BIOS.  For some bizarre reason known only to hardware manufacturers VT is typically disabled by default.  The BIOS settings obviously vary according to the manufacturer and model. For my Dell Latitude D830 the VT setting is located in the “POST Behavior” section under “Virtualization”.  POST stands for Power-on Self-Test – essentially the computer’s pre-boot sequence. As suspected, virtualization support was disabled in line with the factory default settings.

With VT was enabled in the BIOS it was all plain sailing and I am watching my Windows Server 2008 x64 guest machine run through the setup routine as I type.  The next step will be to install the 64-bit version of Exchange Server 2007 – something I have been unable to do in the lab until now.  :-)