Converting physical RHEL5 to ESXi fails

[jgodau]

Hi All,

we are trying to convert a Physical RHEL5 machine to a VM running on an ESXi.

We are using the Standalone converter 4.0.0 Build 146302.

Source machine is approx 137GB (71GB used) - target drive is approx 260GB.

We stopped all unnecessary (business) services on the RHEL5 machine and started a "Hot conversion". Conversion fails at 99% with a message of "Error: Failed to reconfigure the target virtual machine."

The log (attached) shows:

generating suffix as old.0

generating backup file name as /mnt/p2v-src-root/boot/..old.0

file /mnt/p2v-src-root/boot/..old.0 does not exist, backup to it

error in backing up old file /mnt/p2v-src-root/boot/

InitrdNativePatcher failed with exception boost::filesystem::copy_file

Any help would be greatly appreciated

Jack...

[vmweathers]

hi jgodau. This is a Xen guest VM, which is not supported by Converter's Linux P2V feature. If it happens to be an HVM then it might work (though you may have to perform the reconfiguration steps manually after the clone). If it's a paravirtualized Xen guest, then it won't run on top of a VMware hypervisor anyways, so even if Converter claimed success, it would just yield an unworking VM. I'm fairly sure your guest is paravirtualized, so Converter will not work for you.

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[jgodau]

Hi vmwathers,

I don't quite understand? Which is a Xen guest VM? The source? The Target? Something else?

I am trying to convert as the source system a RHEL5 (Red Hat Enterprise Linux 5) system which is supposed to be supported by the standalone converter.

Source system result of 'uname -a' command:

Linux bacchus 2.6.18-53.1.14.el5xen #1 SMP Tue Feb 19 07:47:07 EST 2008 i686 i686 i386 GNU/Linux

The converter log also shows that it has found a linux system:

osVersion = (converter.info.ComputerOsInfo.OsVersion) {

dynamicType = <unset>,

guestOsId = "rhel5",

displayName = "rhel 5.1 (Tikanga)",

osType = "linuxOs",

osEdition = <unset>,

distribution = "redHatEnterpriseLinuxDistro",

majorVersion = 5,

minorVersion = 1,

kernelVersion = "2.6.18-53.1.14.el5xen",

os64Bit = false,

spLevel = <unset>,

},

doReconfig = true,

keepSparseFile = false,

useSudo = false,

}

Any clarification or further help appreciated!

Regards

Jack...

[vmweathers]

This RHEL5 source system is a Xen guest VM, see the grub configuration:

#boot=/dev/cciss/c0d0

default=0

timeout=5

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title Red Hat Enterprise Linux Server (2.6.18-53.1.14.el5xen)

root (hd0,0)

kernel /xen.gz-2.6.18-53.1.14.el5

module /vmlinuz-2.6.18-53.1.14.el5xen ro root=LABEL=/ rhgb quiet

module /initrd-2.6.18-53.1.14.el5xen.img

title Red Hat Enterprise Linux Server (2.6.18-53.el5xen)

root (hd0,0)

kernel /xen.gz-2.6.18-53.el5

module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/ rhgb quiet

module /initrd-2.6.18-53.el5xen.im

That is not supported by Converter's Linux P2V feature, and as I noted the system cannot run under VMware's hypervisor since it's probably using a paravirtualized xen kernel (which makes it dependent on running under the Xen hypervisor).

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[jgodau]

Hi vmweathers,

the source system is not a paravirtualised anything. It is a standard RHEL5 Installation on it's own hardware, it has never been any sort of VM and we have never used Xen in our company.

The question is why is the converter identifying it as such and how can we convince it to correctly identify the source system?

Regards

Jack...

[vmweathers]

You are running a Xen kernel, so you are "using" Xen in your company even if you don't realize it. Look above in your post of the uname output. Also, because of the non-standard grub configuration entries (kernel and initrd are "modules") that implies to me that it is a paravirtualized Xen guest, but I could be wrong.

But the standard RHEL5 distro does not run the xen kernel, you have to explicitly choose to use this.

There is no way of "making Converter not identify it as xen", since it is running a xen kernel.

In any case, this is not supported. If you had a non-xen kernel that you could run, then you could import it. But the system does not have a non-xen kernel listed in the grub configuration. So this really doesn't seem like a "standard RHEL5 distro" to me.

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[jgodau]

After some searching I found this bit of information: "The Xen hypervisor is now embedded in RHEL5 and was billed as a key feature by Red Hat." from here

So it seems that this is now a standard part of RHEL5 - perhaps the converter should be updated to take this into account? Failing with an understandable error message - or even better not starting the conversion at all once it sees a Xen kernel would be a good start.

Please at least mention this as a heads up in the release notes or supported systems list?

I also found this: Steps for taking a XEN paravirtualized RHEL 5.X to VMware ESXi 3.5.X vm. Can I use this guide to convert my physical standard RHEL5, unfortunately with Xen, machine?

Regards

Jack...

[vmweathers]

Hmm, it could be that when the RHEL5 installer detects VT-enabled hardware it purposefully installs the Xen hypervisor kernels. I've never installed RHEL5 on a physical VT-enabled machine myself.

That process to convert the RHEL5 xen paravirtualized guests seems pretty involved, but that is interesting, I'll note that down.

It seems to me that if you replace the xen kernel with a normal kernel (via an rpm update or something -- the rpm package would be present on your installation media), then you could use Converter to convert this machine. You should ensure that the grub configuration gets updated and has entries "kernel ..." and "initrd ..." instead of "module ..." and "module initrd ...". You should probably backup the grub configuration file (menu.lst) and then remove those xen kernel related entries in the active menu.lst before running converter.

We have updated the release notes for Converter Standalone 4.0.1 (due out soon) to openly declare the non-support of Xen guests by Linux P2V, but I'll see if we can also say something about Xen hypervisors, and hopefully mention somewhere that any distros (such as RHEL5) that install Xen kernels by default may not work. If this is indeed the default behavior of RHEL5 then I'll file a bug and maybe we'll be able to fix Converter to handle it in the future.

Honestly I'm surprised that a Xen hypervisor would have this odd "module ..." syntax for declaring the linux kernel and initrd. I assumed those were only for Xen guests.

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[grep65535]

A little late but.....

It's simply a matter of having "Virtualization" checked off during the RHEL install. Installing any of the virtualization packages via anaconda will end you up with a Xen kernel by default. It's not a "standard" kernel by way of just hitting next,next,next,finish.... Virtualization packages have to have been checked off during the installation for the system to end up w/ that kernel.

All that needs to be done is 'yum install kernel kernel-devel' & I believe it should add a grub entry automatically. Reboot into the regular kernel and there you go.

It's not a virtualized system at all. Converter probably just chokes on the fact that no regular kernel entries exist in grub.

The "odd" syntax isn't odd at all, it's the same syntax that's always been used to load a Xen kernel. KVM should be used from now on anyway on RHEL since they've moved away from Xen in favor of KVM.

[ds236]

Just found this thread. Sorry nobody came back and gave the easy answer. If it's a RHEL5 or CentOS5 that's running a Xen kernel but there are no VMs running, simply install a non-xen kernel with yum and/or RPM. When you boot the machine, select the non-Xen and see if it boots cleanly (it should). If it does, you can edit grub.conf to point at the non-Xen kernel. At that point use rpm to uninstall the kernel-xen packages (that'll save you grief when you port to VMWare).

Now you're running a kernel that VMWare converter will successfully convert.