Microsoft Hyper-V vs. Citrix Xen Server

For a few years now, here at Custom Systems we’ve had an ongoing debate between two different Virtualization camps: Microsoft Hyper-V Server and Citrix Xen Server.  Today I am going to take a look at the advantages and disadvantages of each.

Hyper-VIf you’ve read my blog posts before, you can probably guess which camp I’m in.  I’ve been a big fan of using Microsoft Hyper-V as a Virtualization host for a few years, and here’s why:  For starters, the host server is a true Windows Server environment, (excluding Core version).  I’m used to using Windows Servers, and I am very familiar with them.  I know how to install hardware drivers, software updates, etc.  I can install my Backup Software on the host, and make changes to my Virtual Servers from the Hyper-V host console.  When setup properly, I can have a new Virtual Server up and running in a few minutes.

Citrix Xen ServerCitrix Xen Server, by that comparison, is not as easy to manage.  Granted the install process is MUCH faster, but to properly manage your Xen’s Virtual Servers, you need to install the Xen Center Console on a Windows PC or server.  In some environments, that isn’t practical.

Now for the advantages of Xen Server:  There is almost no overhead.  The Xen Server Host can fit on a small RAID 1 partition, needs very little RAM, and doesn’t need to be managed as often as a Windows Host Server.  This allows you to dedicate all of those fast hard drives and RAM to your Virtual Servers, instead getting taken up by a Windows Host Server.  Plus if you use Xen Server as your host server, that’s one less Microsoft Server license you will need.  You can save that license for one of your VM’s.  Also, exporting or migrating a VM with Xen Server is easy and painless.  I wish I could say the same about Microsoft Hyper-V.  (Maybe in the next release?)

Just a few “Gotcha’s”

I have run into a few situations where a third party vendor would not support using their software or hardware on a Xen Server.  At the beginning of the sales process, we will meet with you to discuss your needs and to determine which Virtualization solution is right for you!

AZS-4Chase Reitter
Network Consultant




© Copyright 2014 Custom Systems Corporation

The 10 Commandments of Hyper-V

1. Thou shalt NOT use a dynamic disk with ANY database.  This includes, but is not limited to:  Active Directory, SQL Server and Microsoft Exchange.

2. Thou shalt always provide at least 4G of RAM minimum for the host operating system, and always provide the host operating system with its own NIC and disk partition.  Hyper-V is a jealous host, and will not share with any VM.

3. Thou shalt NOT join the host OS to the domain. Join it to a Workgroup by the same name.

4. Thou shalt always disable time synchronization and disable Automatic Updates on your host server.

5. Thou shalt always set the Hyper-V host to properly shutdown/restart the guest VM’s.

6. Thou shalt NOT use pass-through disks nor use SCSI virtual disks for your VM’s.  IDE is plenty good enough.

7. Thou shalt always use RAID controllers with at least 512MB of RAM on the board.

8. Thou shalt NOT use snapshots. Seriously. Stop doing that.

9. Thou shalt use Hyper-V as the ONLY role on your host OS.  Install no other roles nor features on your host server OS.  Except backup software.

10. Thou shalt never walk away from your host machine logged on. Once you are done with the console, log off.


ChaseChase Reitter
Network Consultant




© Copyright 2014 Custom Systems Corporation 

Microsoft Hyper-V Migrations

We’ve recently had to migrate a few Microsoft Hyper-V Virtual Servers from one host server to another.  This is useful if you have purchased new server hardware, but want to keep your current virtual servers as they are.  Another purpose is in the event of a partial hardware failure – for example you have lost more than one hard drive.  The ability to move virtual machines (VM) from one host server to another is a built-in feature of Microsoft Hyper-V, but requires several steps.

Here are a few tips:

  1. Take a full backup of each VM before you do anything else.
  2. I use the term ‘migrate’ loosely.  What we are actually doing is exporting a VM from one host to another.  You cannot simply copy and paste virtual servers.
  3. Make sure you do not have any snapshots.  Otherwise you won’t be able to export your VMs.  I STRONGLY urge my customers not to use snapshots – but if you have them, they must be merged before a migration can begin.
  4. Your virtual network settings need to match on both your old and new host servers.
  5. We have had issues losing the Server Identification Number (SID) when moving virtual database servers.  It can be sort of hit-or-miss. This is why backups are so important.
  6. If possible, export your virtual servers from your old server directly to the new storage location.  There is no need to move them twice and by doing so, you are eliminating possible failure points.
  7. After you have imported your virtual servers onto your new hardware, test each server before deleting the old copies.  Use caution not to have both the old VMs and new VMs running at the same time.
  8. Although I suggest migrating Hyper-V 2008 servers to another 2008 server, it is possible to migrate from a Hyper-V 2008 server to a Hyper-V 2012 server.  We will cover that in another article.  (Read as: after I have a chance to try it!)

ChaseChase Reitter
Network Consultant
Custom Systems Corporation
© Copyright 2013-20114 Custom Systems Corporation