I'll preface this with the obvious: I am dumb.

I am currently working from home on some scheduled maintenance on a production server running on a vm -- a bitnami redmine/svn stack to be specific.

I was taking a backup of the SVN repository when the size of my virtual disk maxed out (our repository is too big, that's the maintenance). I checked in VSphere and my VM was powered off with a message similar to `There is no space for vmname-00001.vmdk. Try clearing some files on the data store and try again.

Now, I don't know enough about VMs but I assumed that this meant my VM was using vmname-000001.vmdk. I browsed into the datastore and was about to delete the related -0000n.vmdk files when I decided "I don't know enough about VMs, I probably shouldn't do that."... And that's when TeamViewer hiccuped and the files got deleted anyway. Yay me.

So now my VM wont start because it is missing those other -00000n.vmdk files. The error I get is The System cannot find the file specified.

Can I somehow get the VM running using only that last remaining -000001.vmdk file? The timestamp on the -000001.vmdk file was from yesterday and the other -00000n.vmdk files were timestamped last year if it's relevant.

  • Let me guess, you don't have a backup? – joeqwerty Apr 9 '16 at 3:46
  • 1
    I'm referring to a backup of the VM as a whole, not the individual files, unless you have a backup of the base/parent VMDK? You think I'm not being constructive? Maybe so. It's exhausting seeing question after question from people managing production environments who don't have backups of their production systems. If you have backups then good for you, restore them and get on with your life. If you don't have them then shame on you and you should be relieved of all responsibility for these systems. Harsh? Yes. Backups are fundamental. – joeqwerty Apr 9 '16 at 3:58
  • 1
    Teamviewer glitching on you is an "Oops" moment. It's completely unforeseeable and out of your control. Mucking about with something you don't have experience with is poor judgment, but you corrected and caught yourself. That's a good thing. Not having backups? That's negligent and inexcusable. – joeqwerty Apr 9 '16 at 4:03
  • 2
    It's an easy comment to make regardless of the circumstances. Backups are a necessity. They're fundamental. If you're not making sure you have backups then you're not doing your job and have no business in the position you're in. If you're tasked with managing these systems then part of your job is getting what you need, fighting for it if necessary. If you've done that and not gotten what you need then the responsibility falls to your higher ups and I'd extricate myself from that situation as quickly as is feasible. – joeqwerty Apr 9 '16 at 4:08
  • 2
    At any rate, if you still have the base/parent VMDK then edit the VMX to refer to the base/parent VMDK rather than the snapshot. That will get the VM running again, but of course it will be in the state it was in before you created the snapshots, so any changes that were made to the VM are lost. – joeqwerty Apr 9 '16 at 4:31

As was said in the comment ; you can edit the VMX file of your VM and point it to the base disk.

BUT from what you said regarding your snapshots, they were old. So the data in the VM, once this is done, will probably be far too old to be of any use. You can however restore whatever you backed up on top of it. At least you will avoid rebuilding your production server from scratch.

To get your VM up and running again :

  1. Download the VMX file (name should be vmname.vmx) with the Datastore Browser
  2. Make a copy of it, just in case, before modifying it.
  3. Find the line containing vmname-00001.vmdk.

    For instance scsi0:0.fileName = "vmname-00001.vmdk"

  4. Change it to scsi0:0.fileName = "vmname.vmdk" (vmname.vmdk being the name of the base disk)
  5. If your VM has several disks, you should have other lines starting with scsiX:Y.filename= . Note that X and Y will be unique for each line, as well as the base disk name. Repeat step 4 for each of them, replacing the value accordingly.
  6. Save the VMX file and upload it to the ESX server again.
  7. Now your VM should boot.

Note : make sure that you really have no vmname-00XX.vmdk file before proceeding. Following this procedure will make these files useless.

|improve this answer|||||
  • Did this but for some reason I still can't boot and it's still forcing me to find vmname-00001.vmdk. – Enigma Sep 19 '16 at 1:53
  • 1
    You probably have several disks on your VM. You need to perform the steps above for each line starting with scsiX:Y.filename (X and Y may vary). – Orion1024 Feb 14 '17 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.