VMTN

So, what is the "manual workaround" at this point? I'm running Debian 6.0.2 on the server(s) that I'm attempting to migrate (this is a p2v of an existing virtual machine, with the intent of resizing the underlying partition and the filesystem as well, which are over-allocated on really expensive NAS space as a result of confusion and lack of familiarity with the true requirements at the time of installation). I have ten machines like this that I'd like to eventually migrate. Am I going to run into this problem? Sounds like it, even though I'm not running Ubuntu 12.04 LTS. Which makes me wonder whether the manually posted workarounds will fix it... very frustrating to be at 99%, have all the data transferred and on the new machine, and yet be unable to complete the conversion.

If the kernel version being run inside the converter software is 2.6.x, I understand why it isn't a quick patch (although I don't understand why VMware can't patch the fixable, trivial element) and would require a lot more Q/A, but it is still very frustrating. There should be a prominent notice in the software and on the web site about which versions of Linux are NOT supported for P2V, so we don't waste our time.

... and really, VMware should fix the problem, and keep key utilities like this up to date. Is there a venue for expressing our support for this up the value chain?!?

For the "kernel too old" error the only workaround I know is the multi-step one I listed upthread. You can tell if you are going to have the "kernel too old" problem by knowing that the kernel used during conversion by Converter 5.0.0 is 2.6.20. On the Linux system you are thinking about converting run file on a binary, for this example I am choosing grub-setup.

On Ubuntu 12.04 I get:

file /usr/lib/grub/i386-pc/grub-setup

...for GNU/Linux 2.6.24....

2.6.20 < 2.6.24, so when that or any other binary is run in a chroot on a 2.6.20 kernel it's going to bomb with FATAL: kernel too old.

On Debian 6.0.5:

file /usr/sbin/grub-setup

...for GNU/Linux 2.6.18....

So Debian Squeeze won't have the kernel too old problem since 2.6.20 > 2.6.18.

"kernel too old" = "binaries too new". If the binaries in the Linux you want to convert are too new you will have to use something like the workaround I listed. If your binaries are not too new and the conversion still fails you might be experiencing the too new grub version problem, and a workaround for that (make update-grub lie about its version) is further upthread.

If VMWare Converter isn't important enough to get maintenance resources, could it be open sourced? At least then the community can fix the problems. It's frustrating to deal with an increasing number of known issues that we understand how to fix.

I've saved off all the different problem resolution suggestions. This is an incredibly useful thread, containing information that should be prominently referenced on the page where VMware Converter 5.0 is listed for download, and in the release notes, and in a VMware knowledge base article... we shouldn't have to dig through Google to find the one thread on the Internet that has useful information (sigh).

My current plan is to first hack the update-grub script as specified earlier in the thread, and attempt the conversion; hopefully that's all that is necessary given that I'm running Debian 6.0.2 (as you mentioned).

If not, then I'm going to attempt to use an ISO of the "Boot Repair" disk to see if I can get the transferred VM working.

If that doesn't work, I'm going to go through the entire multi-step process as outlined earlier in the thread.

At least this is fixable. Just a major hassle that vastly reduces the utility of the tool provided by VMware... I suspect that, in fact, there are other tools that could do the same P2V function, and actually work properly, but I haven't had time to search for them, and given that only the final step is broken (for some client systems), it seems better to just "make it work" rather than start over from scratch.

Here here... open source is the way to go with these tools.

Well, on my Debian 6.0.2 "source" system, this is the error message I got...

Extraordinarily frustrating... ran a conversion from the latest version of VMware Workstation to another client's vSphere deployment, and it went smooth as ice. This, however, is wasting hundreds of dollars of my client's money to pay for the time necessary to identify what the heck is going on and work around it, as well as extending the downtime for the 24/7 system (Integrated Library System) that this (and the other VMs to be transferred) is a part of.

The "Boot Repair" disk option suggested earlier in this thread magically fixed things, and got my VM up and running... only hitch is that what was reported as "/dev/sda1" before is now reported as "/dev/rootfs", which has exposed a bug in one of my system monitoring tools (totally trivial). System works great after "conversion".

I'm in the process of converting / shrinking 8 other VMs at the moment (they're all under 5GB in size, sitting on 100GB of allocated NAS space). The "Boot Repair" tool (which, incidentally, is built using a much more modern kernel version than VMware's tool) restores VMware Converter to something useful. Hallelujah.

Thomas

I need to try your solution....a few questions thou..
Where do I put your code....in what file (where is it located on my debian)?
Also, Do I put it at a specifik location in the file or just at the top?

Thanks
//mp

I added the code sugested earlier......
Now I do not get the GRUB1 problem.....still, I get stuck on 99% with this:

FAILED: An error occurred during the conversion: 'GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 1, and message: Installing GRUB2 on (hd0)... /usr/sbin/grub-setup: error:
no such disk. Error installing GRUB Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root '

Any ideas?

//Thanks

We managed the Grubproblem with the hack of post 19 but now we run in the following problem:

--> (converter.fault.CloneFault) {
-->    dynamicType = <unset>,
-->    faultCause = (vmodl.MethodFault) null,
-->    description = "native initrd patcher only supports Rhel, SLE and Ubuntu",
-->    msg = "",
--> }

We try to convert a ubuntu 12.04 with kernel 3.0.0-19-generic x86_64. It seems that the converter cannot handle the initial ramdisk of ubuntu 12.04? Any ideas?

Thanx

Hermann

We try to convert a ubuntu 12.04 with kernel 3.0.0-19-generic x86_64. It seems that the converter cannot handle the initial ramdisk of ubuntu 12.04? Any ideas?

Boot the new VM off of an install CD, chroot to it, then rebuild the initrd. You should have to do about the same steps as message #37. You might need to first fix your /etc/fstab or /boot/grub/grub.cfg.

I tried several of the above methods with Ubuntu server 12.04 64 bit and had no luck. I finally was able to use boot-repair and then edit the fstab to get it to work. The earlier instructions for installing boot-repair don't work with the 64 bit versions of Ubuntu. If you run the 32bit version of boot-repair, you get a message to download and boot to this ISO:

http://sourceforge.net/projects/ubuntu-secured/

which includes the 64 bit version.

Hi all,

VM debian 6.0.4 -x64

Conversion from vmware-server 2.0.2 to ESXi 5.1

After the power-on conversion (VMware Converter 5.1) is completed with the fateful error "98% Grub Error"; this solution (boot cd) work for me: http://sourceforge.net/p/boot-repair/home/Home/

I hope you help...

Ivivanov, I am trying your workaround method beow:

What  do you mean?

Just remove these lines from grub-install.