1 person found this helpful
Welcome to the Community - Look at the datastore where tthe VM is stored and make sure there is sufficient room to create the swap file - the swap by default is equal to amount of memory assigned to the VM minus its reservation.
I am also moving this to a more approroiate forum
Thanks for your reply, and for moving it into the appropriate forum. I looked at the Datastore that the VM's files are stored on, and there is 450 GB free space, while the VM's swap file would be 1 GB maximum (the size of it's currently configured RAM) To elaborate a little on the environment, The Vcenter version is 2.5, The virtual machine itself is version 4, and the hosts are running ESX 3i. There is a DS 3200 running as the storage platform for the datastores.
The actual error returned when the VM attempts to power on is: Could not power on VM:No swap file. Failed to power on VM.
There is another oddity as well, it seems to be stuck on the host it is currently on. When I attempt to migrate it to the other host, (without moving the disks) it "appears" to succeed, and even temporarily displays as being hosted on the other host. However, when I refresh the GUI, or attempt to power it on, it's host as shown as it's original host, as if it had not been moved at all. When I look down at the tasks, there is not a second migration that occurred, only the one I initiated, so something is definitely up.
The reason the VM moves back to the first host might be due to DRS initial placement!? Anyway, do you see the error in the VM's vmware.log file? Maybe there's a little bit more info in this file which may help solving the issue. You can attach the vmware.log file to a reply post after clicking "Use advanced Editor".
As requested, I have attached the most recent logfile containing the errors as an attachment to this post. If there is some information in this file that would help, it would be fantastic.
vmware.log 13.7 K
I have tried that just now, and I don't get anything from the process list concerning the problem VM on either host. I can check the process list for the running VM's however, and they come up as they should.
I'm pretty certain it's not a stale process however, as both hosts were recently rebooted, and the problem VM hasn't been up since then.
Thanks for the suggestions, but I have solved the issue. What needed to be done was to remove the VM from the inventory, and then re-create it as a new virtual machine under the cluster with the same name, same settings, and to have it use it's 2 existing virtual disks. For some stupid reason, once this was done, it was able to power on normally, and is running without issues now.
I'm not necessarily happy that about this solution because it does not really help me understand what the underlying problem actually was, but I suppose I can live with it. The reason I didn't try this earlier is that I was afraid that the vmdk's would be overwritten, and I wanted to keep the existing information. However, someone I work with was certain they had done it before, and that it maintained the pre-existing data, even in this older version, so I finally tried it.
Anyways, thanks for the support, and if anyone can glean a root cause to the problem based on the solution I just gave, it would be helpful.