VMware Cloud Community
RushAndNeverWas
Contributor
Contributor
Jump to solution

How would I recreate the swap file for a Windows 2008 VM running on an ESX 3i host?

As the subject states, I'm looking for a way to do this.  I inherited the environment from another group, and it is very tiny, but it is running ESX 3i on the two hosts, and Vcenter version 2.5 (Infrastructure) so it is a bit old.  5 of the 6 VM's are operational, however, the 6th when powered on will only get to 40% complete, but then it will fail stating that there isn't a swap file.  Now, normally there isn't a swap file, as they are created/deleted dynamically each time a VM is powered on either of the hosts.  It's quite odd. 

In newer versions / environments, there seems to be ways to recreate swap capability easily, but that does not seem to be the case here.  I do not think it's a process lock as both hosts were rebooted to clear HA agent / resource issues.  My guess is what happened was one of the hosts couldn't spawn any more processes for some reason, and when the problem VM was powered down to attempt to clear some, the issue occurred.  Either that, or there are unreadable sectors within the datastore, and the swap file black holed in there....

I was wondering if anyone had any ideas on how to fix the problem.  Any input would be welcome.

Thanks! 

Reply
0 Kudos
1 Solution

Accepted Solutions
RushAndNeverWas
Contributor
Contributor
Jump to solution

All,

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.

View solution in original post

Reply
0 Kudos
7 Replies
weinstein5
Immortal
Immortal
Jump to solution

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

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
RushAndNeverWas
Contributor
Contributor
Jump to solution

Weinstein5,

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.

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

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".

André

Reply
0 Kudos
RushAndNeverWas
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Not sure, but it could be related to a stale process which holds a lock. Please see whether http://virtualisedreality.com/2009/01/ helps resoling this issue.

André

RushAndNeverWas
Contributor
Contributor
Jump to solution

a.p.

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. 

Reply
0 Kudos
RushAndNeverWas
Contributor
Contributor
Jump to solution

All,

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.

Reply
0 Kudos