When live migrating from ESX 3.0.2 to ESX 3.5 VMware gives an error:”Migration will cause the virtual machine’s configuration to be modified, to preserve the CPU feature requirements for its guest OS.” This error indicates that the .vmx file is about to be changed.
I was trying to convert the great Nostalgia Virtual Appliance to a VMware Workstation compatible format but just copying didn’t work. I did the following to get this thing running directly under VMware Workstation 6.02:
- I exported the Nostalgia VM from VirtualCenter 2.5 into an OVF format.
- Copied the OVF files to my PC(d:\ovftools).
- Downloaded the OVF Tool and unzipped it into: d:\ovftools
- Ran the following command cause the damn ovf batch file didn’t work: C:\Program Files\Java\jre1.5.0_05\bin\java” -jar d:\ovftool\ovftool.jar d:\ovftool\nostalgia.ovf d:\nostalgia\ (The batchfile was complaining about the fact that the JAVA_Home environment variable wasn’t set, but it actually was…)
- Now it’s converted to a Workstation 6 compatible VM, just open it and start it.
Let’s see if I can fix that sound in the next couple of days…
Arne just posted a solution to the JAVA_Home environment error… And I just discovered that the fact that the ovftool.bat doesn’t work is because of the long file names within dos. You’ll have to set the environment variable with an 8.3 notation: JAVA_HOME = C:\Progra~1\Java\jre1.5.0_05\
No quotes or what so ever because VMware already used quotes in the batch file for the if exist statement.
When patching ESX Hosts with iSCSI attached SAN’s it’s possible you encounter the following event when starting a VM:
“A general system error occured: The system returned an error. Communication with the virtual machine may have been interrupted.”
This is caused by the fact that the “Software iSCSI Client” isn’t enabled on the ESX firewall. November the 15th VMware released a couple of patches which addressed a bug. This bug made it possible to connect via the iSCSI software initiator without enabling the service on the ESX firewall. To open up the port open a console session to the ESX host and type “esxcfg-firewall -e swISCSIClient” or enable it via VirtualCenter “Configuration -> Security Profile -> Properties -> Check Software iSCSI Client”.
After a p2v there are several “ghosted devices” left in the VM. This could for instance cause a message about having already assigned the same ip-address to another NIC when configuring your network.
This problem is caused by hidden devices which should be removed after a P2V:
- Within Windows open up the command prompt
- type “set devmgr_show_nonpresent_devices=1”
- start “devmgmt.msc”
- Click on “View” and select “Show Hidden Devices”
- Uninstall all grayed out devices