Hello,
I'm new to vmware and I'm trying to teach myself. I have ubuntu 11.10 running on a spare laptop with linux converter server 4.0.1. I have the Converter Standalone Client 4.0.1 installed on a windows 7 machine. I have an ESXi server cluster running 4.1.0 that I'm a superadmin on. I'm trying to use the windows machine to convert the ubuntu machine from physical to virtual. I go the through the wizard and everything looks fine. I click start, it starts, and then stops and disconnects with a very generic error "Error: Unable to create the virtual machine 'ubuntu-test-machine'." no other reason given.
Can someone point me in the right direction? Either documentation is limited or my googling needs work because I'm having a hard time finding info on this. It's either outdated or a little to vague for a beginner. Point me in the right direction and I'm sure I can figure it out.
I appreciate any help. Screenshots attached.
Clever workaround. Thanks.
any way of determining what the string would be for ubuntu 10.10 or is there by chance a fix/update in the works or anything?
If you paste this string - it will work (it is detected as GRUB2 - confirmed). Otherwise grub-install -v is showing the version, however it must be in the "supported" format or Converter falls back to GRUB1 as default.
This fix worked perfectly for me. I just had to put the listed code above into the correct location in the grub-install script file and things were just great past that. Thank you!
I didn't actually try this workaround until today, and it's not working for me. I'm still getting the following error
If I run
grub-install -v
on the machine I am trying to clone, I do indeed get
grub-install (GNU GRUB 1.99-12ubuntu5)
You are using Converter 5.0, aren't you?!
Converter 4.x does not support GRUB2 at all...
Wow. Embarassing. I did download and install 5.0 before I began, but unfortunately not on THIS computer. I'll also make sure the computer is powered on before I proceed. Thank you.
In an attempt to redeem myself, here's what I wish I had known before I started trying to convert an Ubuntu 11.10 system to a VM using VMware vCenter Converter Standalone on Windows.
Interesting reading :-). Thanks for summarizing all this information.
I think it is a good idea to add 1, 2, 4, 5 and 7 in the documentation in some form, but not just in the config file. As for 3 - we should really fix the code to be more flexible and recognize properly all version strings and remove step 3 completely :-). One clarification though - there is no need to edit converter-agent.xml file, converter-worker.xml should be enough (I guess we should update the default agent configuration file as well).
Sorry to add to this post but I'm having similar problems trying to P2V Ubuntu 12.04LTS. I got through all the other stumbling blocks but am now getting this error
FAILED: An error occurred during the conversion: 'GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 1, and message: FATAL: kernel too old Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root '
at 99%
Any help would be appreciated.
When you say "put the listed code above into the correct location in the grub-install script file"
where EXACTLY did you put it?
According to ivivanov, you just put it at the top...is there a better place because the error occurred for me on EVERY Ubuntu (10.10 1nd 11.04) server we have been virttualizing and cant get past them...only gotten a 10.04 successfully, but it was already on an esxi 4 server so that was a gimme.
We're about to just start building new machines in the cluster and try to migrate what we can cause we are beating our heads against this like crazy.
Thanks
The problem is that when Converter parses GRUB version it expects a string starting with "grub-install (GNU GRUB " and then the version number. This is what is received by "grub-install -v" prior to Ubuntu 10.10 (I think) and has been changed in newer versions to "grub-install (GRUB) " followed by the version number. So the fix is to have grub-install return a parseable string. Ivan suggests to put this piece of code at the top after the comments, I prefer to edit the part that returns the version, it's a matter of personal choice.
You may create a script that changes grub-install accordingly and just run it on all your machines.
HTH
Plamen
sed -i -e "/s/\$self (\${PACKAGE_NAME}) \${PACKAGE_VERSION}/\$self (GNU \${PACKAGE_NAME} \${PACKAGE_VERSION})/" /usr/sbin/grub-install
This should do, although I give no guarantee ![]()
It is August. This problem, and the solution, was clearly identified in January. Why has it not been fixed in Converter 5.0? I just downloaded my copy a few days ago. I mean, seriously, how much complexity are we talking about here - change the way the string is parsed, and we'll live with the need to set a password for root. That's all. Having it run as root, and parse every possible grub-install return string is a "would be nice".
Everyone who tries to run p2v on a relatively current Ubuntu or Debian machine is screwed... after spending an hour watching everything progress. How lame is that? All the resources VMware has, and they can't fix a relatively simple problem?
Why has it not been fixed in Converter 5.0?
Because it was reported for Converter 5.0 and because of that obviously it happened after Converter 5.0 was released.
And VMware can't release a patched or slightly updated version? A known bug like this takes over 6 months to be resolved? Seriously? I've done software development (and supported it from an IT perspective), this is a trivial delta from the frozen release code, and even if they'd done significant forward development on 6, they can't seriously argue that even if they have to integrate the changes into a revised version, that this amounts to a substantial level of work. Meanwhile, again, everyone trying to do a P2V from recent Ubuntu versions or Debian 6 is hosed. We can't be talking about more than an hour or two of coding, and even being generous, a week's worth of testing and Q/A. How many patches to vSphere, a much bigger, more critical beastie, have they released in the interim?
How many patches to vSphere, a much bigger, more critical beastie, have they released in the interim?
Here is the actual answer to your question - much bigger and more critical. Since you have been in software development you know it is all a matter of priorities and resources...
it is all a matter of priorities and resources...
Oh that is so helpful. I've been trying to get Ubuntu 12.04 LTS migrated from Workstation 8 to ESXi 5.0 and even after following the suggestions upthread here it always fails with "FAILED: An error occurred during the conversion: 'GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 1, and message: FATAL: kernel too old Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root '" no matter what I do with the grub-install version string. I even tried going back to grub 1 and that failed the same way. Fortunately I have access to the server so here's how I got it working.
1. On the Ubuntu system give root a password. It can removed later with "passwd -l root"
2. Use VMware vCenter Converter Standalone to do the migration. It will fail with the above error.
3. On the ESXi server put in the Ubuntu 12.04 install CD. I'm using the server version of Ubuntu.
4. In the vSphere Client, set the new VM to use the host CDROM, and set it to go into the BIOS on the next boot.
5. Power on the VM, and in the BIOS change the boot order so that the CDROM is above the hard drive. Reboot.
6. The VM will come up on the Ubuntu install CD. Go into rescue mode, then reinstall grub.
7. Before rebooting go into a shell on the Ubuntu system, it's a menu item in rescue mode. In the shell use blkid to see what the correct UUID is for the boot drive and then fix up /etc/fstab to show the correct UUID. blkid didn't show me anything for the swap partition so in /etc/fstab I removed the UUID for swap and just used the device name, /dev/sda5 in my case.
8. Reboot. The CD will boot again, just have it boot the hard disk. The Ubuntu VM should boot up OK at this point. Shut it down.
9. Set the VM to go into the BIOS again on the next boot, boot it, and change the boot order so that the CDROM is below the hard drive. Reboot.
10. The Ubuntu VM should come up OK now. All done.
I wish I could have found and edited vmware-updateGrub.sh in order to avoid all of this pain but I couldn't find it.
I am not saying whether it is good or bad, just this is the current situation. I know it is not helpful, but the best we can do given the current state is to offer a manual workaround of the issue.
BTW your error "kernel too old" is NOT the same issue and it would not be fixed with the proposed solution, no matter whether the manual workaround or implemented in the product.
I understand the unfortunate situation. But I only see workarounds offered by other users, not anyone from VMware.
The "kernel too old" message is bogus, and is an example of poor script writing. The kernel in my situation is Ubuntu's linux-image-3.2.0-29-virtual, which is 3.2.24 plus Ubuntu patches. The script is checking for "X" and finding "Y", but instead of logging "X" and "Y" someone decided that anything other than "X" MUST be "kernel too old". That's not the problem.
