Home > Hardware and Software, Microsoft, Standards > Fighting Our Virtualization Standards

Fighting Our Virtualization Standards

July 20, 2007

With the soon-to-be-released SAN we’re having installed (woo.. shiny, clustered SQL, web, and other boxes that I get to sit and play with—I’m still a hardware junkie at heart), our platform of choice was VMWare for their enterprise solutions.  That has, however, led to an argument on standardization here in our enterprise.

Right now, the developers (read: me) are using Virtual Server 2007 R2 and/or Virtual PC 2007.  After failed attempts at really pushing the Altiris SVS solutions, we’re using differencing disks and have a beautiful (and working) process for instanciating environments in a few mouse clicks. 

Why did we I choose Microsoft’s product?  Because the images I get from Microsoft are in VPC format and I didn’t want to nor do I have the time to constantly convert or recreate them.  It seemed logical.  Also, VPC was free.  That helps; I’m cheap.

However, with this rollout, I found out that VMWare now has VMWare Server (v1.0.3) that is a free virtualization product.  So, this article was born—comparing what I’m comfortable with in VPC2007 to my experience creating and provisioning a new box using VMWare Server.  I didn’t do any comparisons to the Server management tools, so this doesn’t have a comparison to Virtual Server 2007 and VMWare ESX.

VPC 2007 – Current Issues or Concerns

So far, Microsoft products have been flawless and worked beautifully in our environment.  They support x86 and x64 platforms, are freely available, and, for the most part, foolproof.

  • Lack of high resolution graphic support – I don’t mean gaming, I mean 1920×1440 graphics, full screen on my large monitors.
  • Lack of USB support – I cannot connect a jump drive to the host and easily access it in the VM (I have to share the folders).
  • Video “flicker” in DirectX games – For some reason, various DirectX games, like FFXI, have a 1–2 second flicker after isntalling VPC 2007, rendering these games unplayable.  For this, I can’t install VPC on my desktop at home… and can’t play those games on my laptop that I use for development.  Not a huge issue, just annoying.

That’s about it; VPC has been very kind to me over the years.  I have many virtual machines that I use as base disks and, so far, the process works—so why change it for a bit of frivilious functionality?

VMWare Server – The Good!

Multiple CPU support

The first feature that caught my attention is that I can assign a number of CPUs to each virtual machine.  It isn’t as detailed as Virtual Server that I can assign a percentage of EACH CPU, but I at least can control whether or not it uses 1 or 2 CPUs (these are physical CPUs, not dual core).  That’s pretty neat.

Security – assign LDAP account to virtual machine

Each virtual machine can run as a specified LDAP (or local account) providing special access as needed.  That’s a neat security feature, though I’m not sure when I’d use it… since I’m just me and I tend to not try to lock myself out of my own stuff.  😀

USB Controller

VMWare natively supports USB.  Add the controller to the image and activate it—your USB devices connect.  VERY cool.  I did learn though—don’t add the USB device that the virtual machine is located on… it disconnects the device from the host (briefly) before loading it.  Whoops.

High resolution graphic support

VMWare supports up to 2360×1770 (odd resolution??) in the control panel… and does widescreen very nicely.

VMWare Server – The Bad!

Cannot full screen high resolution

The high resolution support is nice, but does not support full-screen at 1920×1200 (Dell 24” widescreen at work); it can only go to 1920×1440.  Now, I can maximize the window to somewhat avoid this, but I’m not real smart and the two Start buttons gets confusing.

VPC 2007 Imports Fail

VMWare supports importing Virtual PC/Server files (.vmc); however, fails that the files cannot be read.  Quite unfortunate.  This is a HUGE failing point for me since I don’t really want to rebuild the images I get from Microsoft (or that we have pre-built).

VMWare configuration changes modify the host

VMWare uses intercepting drivers (USB, hard drive, network, etc) to attach to the host.  I’m sure VPC does this too, but not as intrusively.  Every time you change your configuration to the virtual environment, it changes a driver on the host.  Network resets actually bounce your host’s network connection.  Not a huge issue, but really annoying.

No differencing disks!

*cry*  VMWare has “snapshots” that are basically a point in time that allows persistent or non-persistent changes; however, VMWare Server doesn’t support snapshot trees… so… yeah, I don’t see value in that and see the migration requiring a total redesign of our process (processes that are efficient and effective). Ugh.


For now, with the need to work with Microsoft and my crave for differencing disks, I see myself remaining with VPC 2007, but the VMWare solution seems viable and stable and the ESX side looks sweet—I’m sure it’ll do a great job running our SAN.  Now I just have to duck and cover when the networking guys come around.

  1. July 20, 2007 at 12:09 pm

    What were you trying to use SVS for? Reconfiguring development environments? What problems did you encounter?

  2. July 20, 2007 at 12:36 pm


    Ultimately, yes, SVS would remove the need for some levels of virtualization and our constant need for differencing disks.

    However, at this time, platform is a huge issue. We have mixed x86 and x64 computers; and as of SVS 2.1 (~11 july 07), x64 was still unsupported. I’m sure that’ll eventually change though.

    So, we approached it by placing SVS inside of a virtualized environment; however, large development tools, such as VS 2005/2008 and SQL Server were taking 10-15 minutes to activate the layers depending on the files involved. The VMs ran extremely slow and just made life a bit less enjoyable. Some of our layers, for products such as VS2008, actually would crash SVS’s Admin Panel if we tried to investigate the count of files/registry entries (assuming we hit a upper boundary on how high it’d count). Performance, even on ultra fast 7200 RPM external USB drives, was just atrocious. I can’t point to that as an SVS issue though–some of it could be how the VM software handled such massive changes in file pointers.

    My vision is something like:

    Developer sits down and has a new project. They instanciate a virtualized environment (whatever vendor) and populate a clean VM that is loaded with all the SVS packages for our common tools (SQL, VS, Oracle, etc). If additional tools are needed, they’re imported across a shared network location and activated. From there, they’re ready to go. When they’re done, the VM is removed. Over time, we’d update the base VM if new tools are added or we find that developers are contineously adding the same “optional” SVS packages.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: