I.T. Proctology: XenConvert

Showing posts with label XenConvert. Show all posts

Friday, October 9, 2009

Importing Kensho OVF to ESX

My main focus has been in taking OVF content from other vendors and consuming that with Citrix Kensho (the OVF Tool or XenConvert 2.x) – however lets turn the tables.
OVF is a format that describes virtual appliances; these could be single or multiple machine. In doing so, OVF describes the virtual hardware and physical requirements of each machine.
In the spirit of supporting the development of interoperability between vendors I also consider how other vendors consume OVF appliances.
I have my personal opinion of how things should work, but the DMTF VMAN is a committee, therefore there are many opinions.
At the same time, the promise of interoperability is as much in the hand of the consume of an appliance as it is in the creator, as it is in the operating system of the machine in the appliance.
Lets look at using VMware Products (as released today 10/9/2009) to consume a Citrix Kensho created OVF appliance.
Well, I am going to be honest – at this time VMware does not translate other vendors hardware descriptions into VMware equivalents – therefore VMware cannot import OVF content that does not adhere to the VMware way of describing the hardware of a virtual machine.
So, knowing that, is there a workaround? Yes, there is.
In my example I am going to use XenConvert to create an OVF Appliance from a XenServer XVA (that is an export of a XenServer VM), modify that using a VMware created OVF, and then import to ESX.
Mind you, this is not for the easily sickened, nor is it something you want to do every day.
First of all, I begin by downloading the Citrix Merchandising Server virtual appliance. I also use XML Notepad, ESX, and VMware Converter. (Please note that following this process will NOT magically make the Merchandising Server work on ESX - you need to use the appliance built for VMware)
[1] Expand the Merchandizing bz2 zip archive. (WinRAR can do this, and others as well)
[2] Use Citrix XenConvert 2.x to convert from “Xen Virtual Appliance” to “Open Virtualization Format (OVF) Package”

Do not create an OVA, just an OVF.

[3] Using the VMware Client:

a. Create a shell VM using Linux / RedHat Enterprise Linux 5 (32-bit)
b. Select the VM that was created and export it to an OVF appliance
· VI3 = Select VM, File, Virtual Appliance, Export
· vSphere4 = Select VM, Export

[4] Open both folders containing the OVF appliance from XenConvert and the OVF appliance from VMware.
Note that both folders contain common items: a virtual disk file, and a .ovf metafile that describes the settings of the appliance.

[5] Copy the VHD from the XenConvert created appliance to the folder of the VMware created appliance

[6] Open the .ovf XML metafile from both appliances using XML Notepad
[7] Open the two references to the virtual disk
There are two important sections that need to be modified in the VMware OVF so that it will properly ‘see’ the VHD. The ‘name’ of the virtual disk and the ‘format’.

[8] Copy the disk reference sections from the XenConvert created appliance to the VMware created appliance.

[9] Save the changes
[10]If the VMware appliance folder contains a file ending in .mf – delete it
[11]Using VMware Converter import the modified VMware OVF appliance.
Only VMware Converter can both consume the OVF and convert the VHD to VMDK.

a. Open VMware Converter
b. Select Convert Machine
c. Choose virtual appliance, browse to the modified OVF
d. Select Next
e. Complete the import wizard

The preceding steps converted the Merchandising Server XVA based appliance to OVF and then used a VMware derived OVF to import the appliance to VMware. The operating system within the appliance still needs to be repaired to allow the machine to boot and run.
Hopefully, I will have a solution for that in the near future. As there are currently many challenges inherent within the operating system of the machines themselves that prevent true interoperability.

Wednesday, July 1, 2009

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:

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.

Monday, June 29, 2009

PV enabling an HVM from VMware on XenServer (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. Simply installing the XenServer tools within the vm does not enable paravirtualization of the vm.

In this example; the virtual machine was exported as an OVF package from VMware and imported into XenServer using XenConvert 2.0.1.

Installing the XenServer Supported Kernel:

1. After import, 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. yast install kernel-xenpae

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

ii. x64 can use kernel-xen, x86 requires kernel-xenpae

iii. This is not the same as installing “xen” which installs a dom0 kernel for running vms, not a domU kernel for running as a vm.

iv. yast is the package installer for SLES, Debian uses apt (apt-get).

4. 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. (optional) Modify the title of this entry

e. 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”

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

g. Save your changes

1. Edit fstab because of the disk device changes

a. open /etc/fstab in the editor of your choice.

b. Replace the “hd*” entries with “xvd*”

c. Save changes

2. Shut down the guest but do not reboot.

a. Shutdown now -h

Edit the VM record of the SLES VM to convert it to PV boot mode

In this example the VM is named “sles”

5. From the console of the XenServer host execute the following xe commands:

a. xe vm-list name-label=sles 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”

6. xe vm-disk-list uuid=<vm uuid> (this is to discover the UUID of the interface of the virtual disk)

7. 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 sles) 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”

Distribution Notes

Many Linux distributions have differences that affect the process above. In general the process is similar between the distributions.

Removal of VMware Tools was tested following import to XenServer and I do not recommend removal of VMware Tools after the VM has been migrated to XenServer. If it is desired to remove VMware Tools, the vm must be running on a VMware platform when the uninstall command is executed within the VM ( rpm -e VMwareTools ).

Some distributions have a kernel-xenpae in addition to the kernel-xen. If PAE support is desired (or required) in the virtual machine, please substitute kernel-xenpae in place of kernel-xen in the instructions. Please see the distribution notes for full details.

Wednesday, June 17, 2009

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!

Thursday, April 16, 2009

Migrating Debian from VMWare ESX to XenServer

Fixing Debian virtual machines after migration
After import: Debian boots, detects new hardware, and installs new device drivers.
The boot sequence fails at the following error: ALERT! /dev/sda1 does not exist. Dropping to a shell!

This is because the source host (ESX server) presents boot devices as SCSI bus devices by default and the paths have been set within the installation of Debian.
To fix the Debian boot loader:
The Grub boot loader has dropped you into the BusyBox recovery shell. At a command prompt under initramfs.
Begin by looking at the Storage tab in XenCenter and note the presentation (device path) of the virtual disk. This describes the bus that is used to present the virtual disk to the virtual machine. This information does not appear for all virtual machines, but in this case it is available so I will use it to save time attempting to discover the interface and volumes.

This shows that the virtual disk is on /dev/hda – this represents the first IDE interface.
I will begin by returning to the virtual machine console and listing the IDE devices.

Five IDE devices have been identified.
· /hda represents the disk in position 0 IDE controller 0
· /hda1 represents the first partition of the disk /hda
I am going to make an assumption that my Debian installation is on the first partition of the IDE interface. Please note that some Linux installations place the swap on first volume, so some repetition of the follow steps might be necessary to discover the proper volume.
At the command prompt I am going to mount the partition as /root.
This is safe in this case because /root was not loaded as noted by the Alert! message identifying the missing boot device.

Now that the file system is mounted under /root I will verify that it appears to be my Linux installation

Listing the contents I see \boot, \root, \etc, \bin, and so forth. All of these are directories that I expect to find at the root of a Linux installation.
I will first fix the device descriptor file /etc/fstab.
· Change to the /root/etc directory
· Open fstab in an editor

Note the entries that point to /dev/sda; these are the entries that we will be changing to /dev/hda since a SCSI disk controller is no longer available.
Modify the /sda entries and save the file.

Similar steps need to be repeated for the Grub boot loader and the device map.
Change to the /grub folder.

Open the menu.lst file in an editor.
*Note: This file name is menu.Lst not menu.1st
Near the end of the file are the entries that we are concerned with.
Find the boot menu options that point to the /sda device.

Change the entries to /hda. Then save the file.

The virtual machine is now ready for reboot.
Simply enter ‘reboot’ at the command prompt.
During reboot, you may notice that the boot hangs after detecting the USB Tablet device. Select <Enter> to accept the default identified mouse device.
Previously under VMware, my Debian virtual machine was running X server for a graphical desktop.
As with RedHat an error that X server failed to start. After selecting No to bypass the detailed troubleshooting screens a dialog is presented that the X server has been disabled.

After selecting OK you are presented with a logon prompt.
To repair the X server:
To reconfigure the X server two methods can be used:
1) Edit the file /etc/X11/xorg.conf directly
2) Allow automated reconfiguration and accept the identified devices.
To run the automated reconfiguration:
Login as root and then execute reconfiguration for the xserver package.

Step through the wizard and accept the automatically detected defaults.
When the wizard completes start xserver by entering startx or reboot the virtual machine.

Migrating SLES from VMWare ESX to XenServer

For SuSE Linux Enterprise Server I require a “Helper” virtual machine to mount and repair the file system. This is because SLES recovery console does not include an editor.

After migrating SuSE and booting the boot loader fails at: “waiting for device /dev/sda2.” This is as expected because /sda refers to a SCSI bus and on XenServer SuSE actually sees an /hda (IDE) boot device.

The Helper VM can be created using the XenServer provided Debian Etch template virtual machine (this template includes the media, making it practically ready to go). The included Debian distribution also works with the SUSE reiserFS that is installed by default.

It is also of note that SuSE has a full Xen aware kernel and can be further optimized by presentation of the boot devices as Xen Virtual Disks and by loading a paravirtualized kernel. These optimizations are outside of this article; this is specifically focused on having a running virtual machine.

Import the VM to XenServer:

In my examples I am using XenConvert 2.0 to consume the VMware OVF virtual appliances, however Citrix Project Kensho can also be used.

Creating the Helper virtual machine:

In XenCenter select VM -> New

Choose ‘Debian Etch 4.0’ as the template (this template provides the installation template plus the operating system, nothing to download).

Name the virtual machine “HelperVM” and complete the New VM wizard accepting the defaults, allow the VM to boot, and open the console of this VM.

At the console of HelperVM enter a new root password, VNC password, and a host name (‘HelperVM’ is my suggestion).

Mount the SLES virtual disk to HelperVM:

In XenCenter select the SuSE virtual machine, and then select the Storage tab.

Select the virtual disk (make a note of the disk name) and then click Detach.

*Note: the VM must be powered off to detach a virtual disk.

Select HelperVM, then the Storage tab, and then click Attach.

Select the SuSE virtual disk from the Storage Repository and click Attach.

Return to the HelperVM console.

Note that HelperVM should have auto-mounted the volume (in this example HelperVM was running when I attached the virtual disk). My example added the controller device xvdc with the partitions of xvdc1 and xvdc2.

This can also be seen in the Storage tab of XenCenter.

Return to the console of HelperVM and create a path to mount the volume and mount the first volume.

Mkdir /mnt/suse

mount /xvdc/xvdc1 /mnt/suse

Note the error that this looks like swap. I will try to mount the other volume.

Switch to the mounted file system and list to verify that this appears to be the root volume.

Repairing the boot loader:

From this point forward the process is fundamentally no different than repairing Debian or modifying the Grub menu and fstab of any Linux distribution.

I will begin by repairing fstab.

From the root of the mounted SuSE virtual hard disk (/mnt/suse) change to the /etc directory and open the fstab file in an editor.

It should look similar to my nano editor screen below:

I am going to modify the two entries that point specifically to a SCSI presented boot device to IDE.

Previously, in the XenCenter Storage tab for the SuSE virtual machine I observed that the virtual disk was presented on an IDE controller.

The new fstab should resemble this:

Now, to proceed to the Grub boot loader menu.

One way to approach this is to copy an existing entry to a new entry and make the necessary modifications to the new entry. In this example I am modifying the existing entries for the new hypervisor.

Change to the /boot/grub directory ( cd /mnt/suse/boot/grub )

And open menu.lst in an editor.

Find the entries that refer to /dev/sdaX and change them to /dev/hdaX. In the screen shot above this is /dev/sda2

Then save the modifications.

To safely continue I need to un-mount the SuSE virtual disk from the HelperVM.

Return to the root of the file system ( cd / ) and use the umount command to un-mount the xvdc2 device.

To continue to repair the SuSE virtual machine, the virtual disk needs to be detached from the HelperVM and attached back to the SuSE virtual machine.

Mount the SLES virtual disk to the SuSE VM:

Begin by shutting down HelperVM.

Select the Storage tab of HelperVM. Select the SuSE virtual disk and select Detach.

Select the SuSE virtual machine, select the Storage tab, click Attach

Select the correct virtual disk and Attach.

Open the console of the SuSE virtual machine and power it on.

Additional repairs:

As with other Linux distributions, if X server was used to present a graphical console it will require repair due to the capabilities of new video devices.

X server is then disabled.

To repair X server, logon as root and repair the X server by running SaX2

At the command prompt execute the command sax2 -f

At the completion of the wizard X server can be started by executing startx or rebooting.

The one thing that you will notice is that there is no mouse support. Setting up VNC Server within the virtual machine and connecting to a graphical console using this VNC connection can resolve this situation.

Migrating CentOS from VMWare ESX to XenServer

Repairing CentOS virtual machines after migration

After import: the experience of CentOS is identical to RedHat. In fact, if you watch the boot screen closely, you will notice the words “Red Hat” during the boot sequence.

I have outlined the process below.

CentOS boots, detects new hardware, and installs new device drivers. Nothing else needs to be done.

If VMware Tools was installed within the virtual machine then the following X server error will be seen.

The X Windows server will fail to start due to new video devices being detected. This is because of custom video devices and drivers that depended on the underlying VMware host. The system will prompt the user to repair the X server. If the user accepts the automated repair, X Windows will be functioning properly.