Jump to content
EduGeek EdSec 2026 is Go! 27th Oct in Derby! Join us for a day of EdTech security focused talks, networking, and an evening social ×

Recommended Posts

Posted

I have a script that takes a snapshot backup of VMs sitting on an ESXi host on a weekly basis to a backup PC.

 

Since last week I have now come across a spare server that's been donated on a temporary basis and decided I'd set it up as another host just for testing purposes. I copied the backed up VMs over to the new host to see if they boot up; imported it the .VMX's into the inventory and, lo and behold, they don't.

 

I get an error message popping up saying "File not found."

 

I have double checked everything to make sure all files were copied over. I even opened up some of the files in notepad to see if their names had got muddled up, or it was referencing something it shouldn't, and I couldn't see anything obvious.

 

I copied the VMs from a HP ML 350 G5 to a ML 370 G5.

 

Where have I gone wrong?

Posted

Just an update.

 

The problem I'm having at the moment is with a single VM. I haven't copied over the rest of the other VMs to test yet, but I am doing so right now. However, I have since realised that the VM I am having a problem with has had 2 snapshots taken in the past. One going far back as to the middle of December and the other one to the beginning of January. Am I right in thinking this could be the problem?

 

I'm hoping so 'cause the VMs I am currently copying over right now to test - if they exhibit the same problem, that is - don't have any snapshots saved and are totally free of them.

Posted

The snapshots could be the problem. If you use something like ghettoVCB (which may be similar to your script) then it won't snapshot and backup a VM that has any existing snapshots. You need to consolidate and delete any other snapshots before running it so that the image it creates when it runs is the only thing it needs to backup. I guess test your other VMs without snapshots and if they work then problem solved. ;)

 

Chris

Posted

Have a look at the vmx. It may store the paths with the volume ID, having a quick look at one of mine shows that the swap location contains the full path.

 

sched.swap.derivedName = "/vmfs/volumes/45d3758f-a756b511-ab5f-001143fe0c86/Prometheus (Website)/Prometheus (Website).vmss.vswp"

  • Thanks 1
Posted
Have a look at the vmx. It may store the paths with the volume ID, having a quick look at one of mine shows that the swap location contains the full path.

 

sched.swap.derivedName = "/vmfs/volumes/45d3758f-a756b511-ab5f-001143fe0c86/Prometheus (Website)/Prometheus (Website).vmss.vswp"

 

Yes, you're absolutely right.

 

Do you know how I can view the entire volume path name on the new host?

 

Under Configuration tab >> Storage... the furthest I can see is vmfs/volumes/4b66f1....

Posted (edited)

Mouseover it until the full names appears then hit alt+print screen and paste it into MS Paint. Or, if you've got SSH enabled, access the box and cd /vmfs/volumes then ls.

 

(Yes, I'm sure there's a better way than either of those but I couldn't find it when I needed to yesterday!)

 

Chris

Edited by Duke
  • Thanks 1
Posted
Mouseover it until the full names appears then hit alt+print screen and paste it into MS Paint. Or, if you've got SSH enabled, access the box and cd/vmfs/volumes then ls.

 

(Yes, I'm sure there's a better way than either of those but I couldn't find it when I needed to yesterday!)

 

Chris

 

Thanks for that. I altered the path name but still get the same error as mentioned earlier.

 

In the events console this is what it states. The first error I get is:

 

Message from localhost.localdomain: VMware ESX 
cannot find the virtual disk 
"/vmfs/volumes/4b66f14b-2039fd1e-5308-0021-
5a5c344a/MSS-SR-005 - AV/MSS-SR-005 - 
AV-000001.vmdk". Please verify the path is valid 
and try again. Cannot open the disk 
'/vmfs/volumes/4b66f14b-2039fd1e-5308-00215-
a5c344a/MSS-SR-005 - AV/MSS-SR-005 - 
AV-000001.vmdk' or one of the snapshot disks it 
depends on. Reason: The system cannot find the 
file specified.

 

 

Followed by:

 

Cannot power On MSS-SR-005 - AV on 
localhost.localdomain. A general system error 
occurred: 
error

 

Anyone know where I'm going wrong with it?

Posted

Hmm, the 'or one of the snapshot disks it depends on' sounds dodgy.

 

Stupid question, but presumably if you browse through the datastore then '/vmfs/volumes/4b66f14b-2039fd1e-5308-0021-5a5c344a/MSS-SR-005 - AV/MSS-SR-005 - AV-000001.vmdk' is a valid path and the file does exist on the new server?

 

Can you compare the datastores on new and the old servers and make sure all the files have been backed up and copied across correctly? Are you able to consolidate the snapshots on the VM and delete them then try the whole thing again to see if that's the problem?

 

Cheers,

Chris

Posted

I've solved it.

 

In the .VMX file, for some odd reason, it references to a file called xxxxxx-000001.vdmk (size 1KB) when it should just state xxxxxx.vdmk.

 

Don't get me wrong, both files exist but it should be the latter.

 

Anyways, it's working and I'm a happy bunny.

 

Thanks for all your help guys.

Posted

I think (may be wrong), that's the name for the snapshot files. Backing up snapshots is a little complicated, so it may be that your script won't cleanly backup snapshot files (like ghettoVCB) and what you ended up with was a vmx that pointed to a snapshot which wasn't really there.

 

Anyways, glad you got it sorted! Apparently snapshots were never meant for long-term use so that might be something to bear in mind.

 

Cheers,

Chris

Posted

Yeah, you're right.

 

When comparing both datastores, on the original datastore there isn't a file called xxxx-000001.vdmk. I suspect that when the backup occurs, the backup script must create it and alters the .VMX file to tell it to point at the xxxx-000001.vdmk.

 

Are you using the ghettoVCB script?

Posted

Yep, check out this thread: http://www.edugeek.net/forums/thin-client-virtual-machines/48329-esxi-backups.html

 

It's probably not perfect but so far it seems pretty good. I haven't tested the restore script yet and won't until next weekend, but from what I can see I have no reason to believe it's not working correctly.

 

Give me a shout if you want a hand setting it up as I literally did it this weekend and I've documented what I did. :)

 

Chris

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...