ESXi Snapshot VMs

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 <unspecified filename> 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?

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.

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

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"

Quote:

---

Originally Posted by DMcCoy

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

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

Quote:

---

Originally Posted by Duke

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:

Code:

---

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:

Code:

---

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?

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

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.

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

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?

Yep, check out this thread: http://www.edugeek.net/forums/thin-c...i-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