Hello,
I'm hoping this is the right forum for posting my question. If not, please let me know of a more appropriate forum.
I have several VM's created using VMware Workstation 12.5. The host machines these VM's running under
is Windows 7 x64 Professional. Recently I copied these VM's to a Dell Precision Workstation. When I tried to open
the .vmx file, it wasn't loading and wasn't even able to present the VM information on the screen just right before
you power up the VM. I am no expert but just with enough knowledge to build VM's for testing purposes. I suspect
because the Dell machine has different hardware (CPU, chipset and etc) than my Windows 7 x64 and it is the reason
why I am nt able to run these VM's. Am I correct and if so, what options do I have to make these VM's runnable again
after I copied them to a new host?
Thank you in advance.
One of the benefits of virtual machines is that they are (for the most part) portable.
Note that the guest OS should be *shut down*, not *suspended* before copying to another host computer, however.
You can check the vmware.log in the VM's folder on the new host to see if there are any error messages which point you towards the problem.
I couldn't even get to the point where I could power on the VM.
When I do a File -> Open -> .vmx, I get a blank screen. VMware Workstation is not even loading the details of this VM
As a result, most of the menu options including the menu VM -> Power are all grayed out.
I am almost positive I had all VM's shutdown before making the copies. I want to clarify when I say "Copy". This is actually what
I did
1. Powered off the VM
2. I used ISOCreator to create an ISO file starting at the root directory of my VM.
For example, I may have these VM's on my host machines
c:\virutal_machines\windows7
c:\virutal_machines\windows2016
So I used ISOCreator to create a "windows7.iso"
4. I then copied this "windows7.iso" to the new Dell machine
5. Unpacked the "windows7.iso" giving me the exact directory structure as where it came from.
So that's what I did. This is the same as doing a COPY command except it takes much longer. Creating an ISO is much more
compact and much faster. This is typically how I would clone a VM. But I have never cloned it to another host with different hardware.
I have done this many times to the same but a different location and never had an issue.
In addition, when I tried to load the .vmx file, it's almost acting as if nothing happened. I just see a blank screen
on the right pane side of my VMware Workstation. The left pane would still have what I had opened previously
but it just won't open the VM I want after the copy/move/clone however you want to call it.
I guess my question is: can I actually run my VM after I "copied" it to the new Dell machine knowing this Dell
machine has different hardware configurations than the machine the VM came from?
Of course you can copy a VM to another machine with different hardware. The issue you have run into if that you cannot "open" the VM, which has nothing to do with the new hardware (because you have never powered on the VM). I have never try to burn the VM to an iso image in order to copy it. When we want to copy the VM to another machine, we just copy the whole VM folder. But it should not be the cause of the issue since you can do it successfully within the same machine. Please paste the UI log (You can find the location of ui log from Workstation menu Help > About VMware Workstation > UI log file).
If you have added the files to an ISO image to copy, and copied them from the CD (or ISO image) onto the new PC, make sure the copied files are not marked read-only - many will be when you put them onto a CD.
Just to clarify, I did not "burn" the image to any media. I simply created the ISO (ie Windows7.iso) and copied this ISO to the target machine
via a USB flash drive.
Here's a couple of new discoveries from last night. I did a File -> Scan for Virtual Machines. I pointed it to the supposedly "bad" .vmx file.
I then imported it so it showed up on the left pane of my VMware Workstation. Now when I tried to open it, I got an error saying "vmx corrupt".
Went to Google and searched.... I followed one of articles to re-create the .vmx file. I first renamed the bad .vmx. Went through steps
and it created the new one. Tried to open the new .vmx but got a new error. Now it says "Bad dictionary" or "No Dictionary" or something to this
affect. It was late in the night and I just stopped there.
Does this give you more clues as to what might have caused this?
Also, someone said make sure the vm was powered off before I do the copy or create the ISO.
So I fired up this VM on the source machine last night just to be absolutely sure it was working. I
did a shutdown within Windows Server 2016 which powered off the VM. I re-did the ISO.
It did not fix my problem.
Please attach your vmx-file to your next reply
The original bad .vmx or the one I re-created last night?
both
That vmx-file is corrupted beyond repair.
Please attach all the vmware.logs you still have instead.
Can the vmx file be re-created using existing supporting files for this virtual machine? I know when I followed one of the articles I found last
night, it did re-create file but did not fix my issue. If this is possible, would you kindly share your experience on how to do this? I will look into
this more this weekend.
I will get a copy of the vmx file from the source and put it on the target and see what happens.
I will get a copy of the vmx file from the source and put it on the target and see what happens.
That's what I was about to recommend.
Other than this you may be able to recreate the vmx, see HowTo: Recreating a .vmx from the vmware.log file
André
André
I found an older link of yours and was looking at it earlier
Looks like it's the same DOS script and I was going to give this a try when I get home. But what did you mean by
drag & drop the .log file? These are Windows shell commands (black box command line).
You can either run the script from the command line by specifying the vmware.log as the command's argument, or simply use the GUI and drag the vmware.log over the script's icon.
If the script finds valid information within the .log file, it will then create a new .vmx file.
However, from what I read so far, I'm not sure whether the .vmx file is the only issue in this case. Why don't you use e.g. 7zip, if you don't want to copy the files directly?
What you should do to find out if the files on the target match those on the source after copying them, is to calculate the files' checksums (using e.g. MD5: Command Line Message Digest Utility) and compare them.
André
Thanks for everyone's help so far.
I will post some updates next week after I spend more time looking into this.
This "Windows Server 2016" is ~35Gb VM including a couple of snapshots. That's why I didn't want to use Windows' copy.
I apologize for wasting your time regarding the issue I posted here.
My problem seems to be related to ISOCreator. I suspect this tool had problems compressing
huge .vmdk files. I don't think these files were completely packaged initially. I tried a different
ISO tool as well as Peazip. Everything is working beautifully now.
Thanks again