Archive for April, 2014

Migrating a VM from XenServer to Hyper-V

April 29, 2014 4 comments

My last two posts have spoken about my former XenServer and the fact that I replaced XenServer with Hyper-V. What I didn’t explain was how to actually migrate the exiting virtual machines off XenServer and into Hyper-V.

If you are lucky enough to have both XenServer and Hyper-V servers running concurrently, the process goes a lot quicker than the way I had to do the task. In my case I had to migrate VM’s off the server, install and configure Server 2012 R2, install Hyper-V and then set up my VM’s. Not a difficult task, just time consuming. With two servers, you can move the exported VM hard drive directly to Hyper-V and get going a lot quicker. Moving 120+GB VHD files does take some time, even on gigabit Ethernet.

On XenServer, I had 5 VM’s. I determined that I would be migrating 3 of them, while I would rebuild the other 2 from scratch once Hyper-V was up and running. I searched the net for info on how to do a migration of the existing VM’s, but there wasn’t a lot of info out there. I certainly couldn’t find any tools to do the job automatically, which is a pity as there is plenty of tools that will convert from Hyper-V to VMware and vice versa, or do a Physical to Virtual (P2V) migration.

I did come across info that said that once I had exported the VM, the VM would be able to boot in Hyper-V without problems. I tried exporting a VM directly from XenCenter, but it wouldn’t export VHD files. Exporting an OVF file and then converting that was possible, but it would be even more time consuming while waiting for the conversion.

Eventually the solution I found was to use Microsoft’s Disk2vhd program. It’s a small program that will snapshot the VM inside XenServer and push it to a VHD or VHDX file, which is the hard drive format used by Hyper-V. The program will create one file per physical drive, not per partition. So a VM with a hard drive with 3 partitions on it will actually create only 1 file.


Store the VHD file anywhere except on the machine being captured. Depending on the size of the drives, the process could take a few minutes to a few hours. Having a gigabit network helps in this regard, as the program will max out your network connection if you save the file via the network.

If you are capturing a server running Exchange or SQL or acting as a TMG firewall, stop all those services before capturing so that you don’t have any inconsistencies after the machine is booted up again.

Once you have your VHD file, this can be copied onto your Hyper-V server’s local storage or cluster storage or whatever you are using. Set up your VM in Hyper-V using Generation 1 hardware (unless you captured Windows 8/Sever 2012) and boot up the VHD file. Hyper-V will boot the system up and once you reach the desktop, Windows will install some drivers. Before you reboot, go to Programs and Features and remove all the XenServer tools and drivers. Reboot the VM, then install the Hyper-V tools, reboot etc.

By the time you are done, the VM should be running stably inside Hyper-V. You will need to reactivate your copy of Windows due to the massive hardware changes, as well as set up any static IP addresses again, as the virtual network card from XenServer is obviously not carried over to Hyper-V. Watch out for your anti-virus product (if you had one installed previously.) After I migrated my Exchange Server over, the VM started locking up and rebooting. Turns out that the specific version of NOD32 that was on the server was conflicting with the Hyper-V tools.

Speaking of my Exchange server, that particular system has gone from being on Pentium 4 class server into XenServer, through 3-4 XenServer OS upgrades and now into Hyper-V. Pretty amazing when you think about how it’s managed to survive all these jumps. Even more surprising when you consider it’s running on Server 2008 (not R2) which is basically the Vista code base.

I hope this helps someone out there who is contemplating making the move themselves, or is simply doing research. Always helps to have someone experiment before you and take those nervous steps first.


Goodbye XenServer

April 28, 2014 1 comment

In my last post I mentioned that I did a server migration, and that the hub around which everything turned was the server running Citrix XenServer. As also mentioned, I replaced XenServer with Microsoft’s Hyper-V. Let me explain some of my thinking around why I made that choice.

Xen has been around since 2003, making it a pretty mature hypervisor. When Citrix got involved, the project only grew and became more powerful. In fact, it often seemed like XenServer was the only competition to VMware. When we decided to make use of virtualization at the school, we had the choice of VMware, XenServer and the original version of Hyper-V. VMware was fussy on the hardware, Hyper-V didn’t have decent management tools or Linux at the time, all while XenServer just worked out the box.

Fast forward a couple of years though and the scene has changed quite a bit. Hyper-V has made huge strides and is fighting it out with VMware for top dog in the virtualization world. Linux KVM has come along in leaps and bounds and is pretty popular for running Linux VM’s. XenServer unfortunately began to look like a deer in headlights, not knowing where its place is.

The free edition of XenServer was a good product, but it often felt like Citrix was keeping back that one or two juicy features that would just make it so much more excellent. A business generally wouldn’t be adverse to purchasing a more advanced version, but it’s not so easy in a school where resources are often a lot tighter.

I decided to move the server over to Hyper-V because a) it comes free with Server 2012 R2 and b) all of the servers I was virtualizing are Windows servers. It just seemed to make better sense to me to run Windows servers under the platform made by the same people who make Windows. There were other benefits as well, namely that I could run Windows applications for setting up or monitoring the RAID array, easier network management and better support of Windows guests. Upgrading the Xen integrations tools after an OS update was always a fingers crossed moment, hoping that it wouldn’t affect the OS. Sometimes the tool updates ran extremely slowly, something which was always frustrating.

With XenServer, it often took a long time for later versions of Windows to be officially supported. Server 2008 R2 for example would be considered experimental for a release and then upgraded to official support in the next release. However, the gap between major releases of XenServer could be a year or more. With Hyper-V, all Microsoft have to do is release an update of their integration tools to support a new version of Windows – the whole OS doesn’t need to be upgraded.

Since migrating, Hyper-V has behaved itself. My Exchange server initially didn’t like the migration, tending to lock up at random intervals, while all the other servers behaved themselves. Turns out that the Hyper-V tools conflicted with the Eset NOD32 version I had installed on the server, which is a very old version to be honest. Removing NOD32 solved that freezing problem, and now all servers are behaving themselves nicely. Best of all, the management tools are all nicely built into Windows, or are a simple download away. The overall server gets managed with Server Manager, while Hyper-V gets managed using its own console. XenCenter was a great management console, but it felt like precious little had changed between versions over the years.

To Citrix, I say thanks for giving away XenServer all the years. There were quirks and minor issues, but XenServer pretty much worked as promised. Good luck with the transition back to a more open source model, I hope it helps to keep Xen relevant in the cutting edge market of virtualization.

When a server gives you grey hair…

April 28, 2014 1 comment

About a month ago I did a fairly large server migration project at our school. In addition to installing a brand new server, I also did a lot of logical migrations of virtual servers or server roles. The main hub around which my plans revolved was our generic Intel server.


Originally purchased and installed in March/April 2011, the server has been humming away quietly for the last 3 years, doing what it was meant for – virtualization. It hasn’t been all smooth sailing however, as their have been some quirks. The original 16GB SSD died one day, and by died I mean a complete and utter death – not even visible in the BIOS. That took XenServer along with it, giving me a miserable 2 days getting the server back up to scratch. Funny enough, the mechanical 160GB I used to run XenServer after the crash was still running fine up to when I removed it and swapped it for Microsoft Hyper-V.

Another issue that came up early in the machine’s life was XenServer hanging at random intervals, usually at night when the network was quiet. No info in any logs, just a random hard lock up that only a power cycle could clear. My ex colleague and I eventually discovered that it was due to XenServer not liking the lower power C states on the then new Intel “Nehalem” Xeon chips. Disabling the lower C states in the BIOS solved that issue and XenServer then chugged away for the rest of its life.

This server has never had its firmware updated, so when I did the server migration I took the opportunity to flash the latest firmware available. This would also help in getting the server ready for Server 2012 R2 and Hyper-V. I prepared my flash drive with the update, no problem there. Updating modern Intel servers is pretty easy, so I didn’t expect any issues. Of course, that’s when the issues started…

During the update, the update was unable to determine the chassis type, which I found odd. Still, I manually entered the model when given a choice. A few seconds later, all the fans in the chassis ramped up to full speed and stayed there, as well as the system health LED blinking an ominous amber. Prior to this, the server was near whisper quiet, only ramping up fans during POST. I ran the firmware update again, thinking maybe something hadn’t stuck. No joy, system was still sounding like a jet engine. Although the server was perfectly usable, I couldn’t imagine the system running like that 24/7 in the server room. That noise level would drive anyone mad after a while! I left defeated for that night and decided to hit it head on the next morning. I did some research when I got home and based on what info I could discover using the server’s built in event log, I was able to narrow down where the potential problem was – fans not being installed on the correct headers for that specific chassis.

The next morning, my colleague and I took the server out the rack to look at the internals. Along with some guides from Intel’s web site, we found that the issue causing the jet like noise was what I suspected from my research. When our hardware IT provider built the server, he didn’t connect the AUX cable from the power supply to the motherboard, as well as the fact that 2 of the 3 on-board fans were plugged into the wrong fan headers. On a desktop PC this wouldn’t be an issue, but server systems are picky about what is present and what is missing. If the firmware expects a fan to be plugged into header X and if it’s not there it’s going to make a fuss.

After sorting out the cabling the server went back to being whisper quiet after the next boot. The system health LED went back to green, the way it’s meant to be. Just for safety, I ran the firmware update again, which worked perfectly this time. The chassis was detected correctly and the system behaved normally after the update. With the hardware issues resolved, we moved onto installing Windows and getting Hyper-V up and running.

Since the migration, the server is behaving well. The server is showing its age a little, as the Nehalem chips are quite old now. Surprisingly, the system is still doing ok with 48GB RAM, though we may bump that up to 64GB to enable the system to host more VM’s. In the end, it just goes to show that it’s sometimes the smallest of things that give us the most grief.