Linux vm from VMware to XenServer the videos

If you have been following, you will note quite a few posts related to importing / migrating Linux virtual machines from VMware to XenServer.

I realize that many folks don’t use XenServer – but the basic steps of repairing after migration apply to Hyper-V just as well as to XenServer – the steps are the same if you want your VM to boot. However, PV enablement on Hyper-V does not exist, you just need to install the vm tools.

Here are the links in case you missed them:

• PV enabling an HVM from VMware on XenServer (CentOS RedHat)
• PV enabling an HVM from VMware on XenServer (SLES and Debian)
• Migrating Debian from VMWare ESX to XenServer
• Migrating SLES from VMWare ESX to XenServer
• Migrating CentOS from VMWare ESX to XenServer
• Migrating RedHat from VMware to XenServer

I have turned three of these into short (less than 10 minutes) video presentations, just to add a bit more information than in the articles.

• Repairing SLES 10 boot loader after import to XenServer
• PV enabling SLES 10 vm after import to XenServer
• PV enabling CentOS VM after import to XenServer

PV enabling an HVM from VMware on XenServer (CentOS RedHat)

This example works for RedHat and CentOS, the instructions are slightly different for SLES and Debian.
As a condition for paravirtualization to work, a kernel that supports the Xen hypervisor needs to be installed and booted in the virtual machine.
Installing the XenServer Supported Kernel:
1. After importing the vm as HVM, boot the virtual machine and open the console.
2. (optional) update the modules within the vm to the latest revision
a. If the kernel-xen package is installed from an online repository – best practice is to fully update the distribution to avoid problems between package build revisions.
3. Install the Linux Xen kernel.

a. yum install kernel-xen

i. the xen aware kernel is installed and entries are created in grub

4. Build a new initrd without the SCSI drivers and with the xen PV drivers

a. cd /boot

b. mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk initrd-$(uname -r)xen-no-scsi.img $(uname -r)xen

i. This builds a new initrd for booting with pygrub that does not include SCSI drivers which are known to cause issues with pygrub and Xen virtual disk devices.

5. Modify the grub boot loader menu (the default entries are not pygrub compatible)
Open /boot/grub/menu.lst in the editor of your choice

a. Remove the kernel entry with ‘gz’ in the name

b. Rename the first “module” entry to “kernel”

c. Rename the second “module” entry to “initrd”

i. SuSE and Debian require that entries that point to root device locations described by a direct path such as: “/dev/hd*” or “/dev/sd*” be modified to point to /dev/xvd*

d. Correct the *.img pointer to the new initrd*.img created in step 4

e. (optional) Modify the title of this entry

f. Edit the line “default=” to point to the modified xen kernel entry

i. The entries begin counting at 0 – the first entry in the list is 0, the second entry is 1 and so on

ii. In our example the desired default entry “0”

g. (optional) Comment the “hiddenmenu” line if it is there (this will allow a kernel choice during boot if needed for recovery)

h. Save your changes

6. Shut down the guest but do not reboot.

a. Shutdown now -h

Edit the VM record of the CentOS VM to convert it to PV boot mode
In this example the VM is named “centos”
7. From the console of the XenServer host execute the following xe commands:

a. xe vm-list name-label=centos params=uuid (retrieve the UUID of the vm)

b. xe vm-param-set uuid=<vm uuid> HVM-boot-policy=”” (clear the HVM boot mode)

c. xe vm-param-set uuid=<vm uuid> PV-bootloader=pygrub (set pygrub as the boot loader)

d. xe vm-param-set uuid=<vm uuid> PV-args="console=tty0 xencons=tty" (set the display arguments)

i. Other possible options are: “console=hvc0 xencons=hvc” or “console=tty0” or “console=hvc0”

8. xe vm-disk-list uuid=<vm uuid> (this is to discover the UUID of the interface of the virtual disk)
9. xe vbd-param-set uuid=<vbd uuid> bootable=true (this sets the disk device as bootable)

The vm should now boot paravirtualized using a Xen aware kernel.
When booting the virtual machine, it should start up in text-mode with the high-speed PV kernel. If the virtual machine fails to boot, the most likely cause is an incorrect grub configuration; run the xe-edit-bootloader (i.e. xe-edit-bootloader –n centos) script at the XenServer host console to edit the grub.conf of the virtual machine until it boots.
Note: If the VM boots and mouse and keyboard control does not work properly, closing and re-opening XenCenter generally resolves this issue. If the issue is still not resolved, try other console settings for PV-args, being sure to reboot the vm and close and re-open XenCenter between each setting change.
Installing the XenServer Tools within the virtual machine:
Install the XenServer tools within the guest:
1. Boot the paravirtualized VM (if not already running) into the xen kernel.
2. Select the console tab of the VM
3. Select and right-click the name of the virtual machine and click "Install XenServer Tools"
4. Acknowledge the warning.
5. At the top of the console window you will notice that the "xs-tools.iso" is attached to the DVD drive. And the Linux device id within the vm.
6. Within the console of the virtual machine:

a. mkdir /media/cdrom (Create a mount point for the ISO)

b. mount /dev/xvdd /media/cdrom (mount the DVD device)

c. cd /media/cdrom/Linux (change to the dvd root / Linux folder)

d. bash install.sh (run the installation script)

e. answer “y” to accept the changes

f. cd ~ (to return to home)

g. umount /dev/xvdd (to cleanly dismount the ISO)

h. In the DVD Drive, set the selection to “<empty>”

i. reboot (to complete the tool installation)

7. Following reboot the general tab of the virtual machine should report the Virtualization state of the virtual machine as “Optimized”

XenConvert 2.0.1 is released with VMware OVF compatibility

We have been working on adding Citrix Project Kensho OVF capabilities to XenConvert.

XenConvert is the free Citrix machine conversion utility.  It is primarily focused on converting workloads to either Provisioning Server or to XenServer, however there are some more generic functions that are of interest to most any virtualization folk.

The download can be found here:

http://www.citrix.com/English/ss/downloads/details.asp?downloadId=1855017&productId=683148

If this moves in the future go here: http://www.citrix.com/English/ss/downloads/results.asp?productID=683148 and look for XenConvert in the XenServer download section.

OVF packages from any existing VMware product (known to this date) can be consumed (imported) direct to XenServer.

The physical to OVF path can be run within a Windows machine and convert it to an OVF (meta file + .vhd) or just a vhd.

The OVF can then be consumed to XenServer with XenConvert 2 or to XenServer and / or Hyper-V in the upcoming Kensho refresh.

The VHD can, of course, be copied to any engine that uses vhd.

It also does a binary conversion of vmdk to vhd and injects a critical boot device driver that is compatible with XenServer (and works with Hyper-V).

Also, the XenServer .xva (vm backup files) can be converted to OVF.

Download and enjoy!

Do you know where your VM has been?

For a tester, creating a situation that causes a piece of software to fail gives you a warm fuzzy feeling inside. Some situations are easy. Some are difficult. Others are accidental, but totally realistic as to how they happened.

I have recently been busy testing virtual disk conversion tools. You might say: "how relatively boring is that.." And I will admit that it isn't the most glamorous thing to test. However, it has lead me to the reality that virtualization of a machine workload is NOT new.

Almost 6 years ago I first began working seriously with virtualization, moving a number of physical machines and their applications into virtual machines on ESX server. Back then, this was really cool stuff. Very few companies were doing it. Microsoft did not officially support running their operating systems within virtual machines, and you could never tell an application support person that you had virtualized the server their application was running on as they would immediately declare "there is your problem."

Well, we have grown and MSFT has gotten into the hypervisor market and all of a sudden this stuff is becoming main stream.

The most important part that I want to bring up is: People are migrating between hypervisor platforms, virtual disk formats, throwing away an old platform for a different one. Why? Because they can.

This is totally relevant to testing, evaluating, understanding performance, and a number of other things with your VMs. What was the life of that virtual machine? How did it get to where it is today? Does anyone in the enterprise even know?

I recently had the pleasure of breaking a piece of software and was told by a developer that "that was a really good bug, you found a great case." Now, as a tester, there is nothing better than a developer giving you a compliment because you found a good bug.

Now, I need to get back to my point.

I had access to a VM that was built on VMware workstation, moved to ESX server, to Virtual Server, to Hyper-V, and then I converted it back to a VMDK from VHD using WinImage.
This is at least five disk format modifications, three tools modifications, and this VM was running an application.

And, during most of those conversions a 3rd party, offline, conversion tool was probably involved. Some examples you may be familiar with: WinImage, Acronis, VMDK2VHD, PlateSpin, etc.

Needless to say there was a problem introduced to the virtual disk at some point in its life. Did any of the tools report this? No. Did the VM boot and run? Most definitely. Did we have any idea that there might be a problem? Definitely not.

It just goes to show you that in this day and age we need to keep track of these things. As who knows where an error can be introduced into an environment.

It is no different than the case of converting that old NT domain controller in the back corner into a VM because there is one legacy application that runs on it that is critical and the application has never been updated... And then you realize that you have migrated between platforms, formats, and who knows what tools.

So, always be mindful of your virtual machines. Their life and lifetime. Not just from a security standpoint, but from a stability standpoint.

You want to convert a machine to a vhd

So, for some reason you want to convert a machine to a vhd. Let me not limit your thinking by saying that this has to be a physcial machine, it could be a VM.

I am going to cover two items: XenConvert (free, converts running machine), and a Hyper-V feature (part of Hyper-V, converts any mountable disk).


Using Hyper-V:

With Hyper-V you can take a physical disk, attache it to a Hyper-V host and convert the disk (fully intact) to a VHD. A neat feature that no-one talks about.

This is great for a number of scenarios where you have a physical drive, a host, and the machine on the physical drive can be is is offline (we will assume that this is a disaster recovery exercise).

But those are the limitations. Still, a neat feature.

Here's how:
Mount the disk to a Hyper-V host. (SCSI, in an external enclosure, ATA, however)
Be sure that the disk is attached and recognized in Disk manager
Open Hyper-V manager
Select Actions -> New -> Hard Disk..
Step through the wizard to select your type of virtual disk, the location, then stop.
On the Configure Disk page, select the option "Copy the contents of the specific physical disk"
Then complete the wizard.

This then copies the contents of the desired physical disk (not just the files, but the actual blocks, formatting and all) to a VHD.

That is it.

Another option is to

Use XenConvert:
Download the XenConvert tool (You can download it from MyCitrix (@ Citrix.com) where you download XenServer)
Install it within the Operating System that you want to convert (again, physical or VM).
Then begin the conversion process choosing VHD as your output.
You can just convert an existing installation to VHD (it can even route the VHD to a network share using a mapped drive).

the benefit of XenConvert: You machine is running the entire time.
I have converted SQL, Operations Manager, and SCVMM servers to VHDs (yes, they boot and everything) then moved them to either Hyper-V or XenServer.

I hope you get creative with your options.
You can convert physical to virtual, virtual to virtual, etc. No need for expensive conversion tools as long as you have the time and the knowledge.