You are not logged in.
XSIBACKUP-PRO 11.2.19
This time ESXIBackup saved my bacon An upgrade that should have been trivial failed so I had to revert to the backup VM on the backup server. Copied it to the primary server into another directory. The old VM was called Filr4_ny and the copy that I now run and it runs without issues is called Filr4_2021. problem is that ESXIBackup fails with:
cat: can't open '/vmfs/volumes/datastore1/Filr4/Filr4.vmsd
/vmfs/volumes/datastore1/Filr4/Filr4_2021.vmsd': No such file or directory
Ie, it is looking for the wrong file. I do not know from where it picks up that name so how do I correct it? I tried renaming the VM to match, but it did not help.
[root@ESXI34:~] ls /vmfs/volumes/datastore1/Filr4/
Filr4-Snapshot49.vmsn Filr4_1-flat.vmdk Filr4_2021.vmsd vmware-1.log
Filr4-aux.xml Filr4_1.vmdk Filr4_2021.vmx vmware-2.log
Filr4-flat.vmdk Filr4_2-flat.vmdk Filr4_2021.vmx.lck vmware.log
Filr4.nvram Filr4_2.vmdk Filr4_2021.vmx~ vmx-Filr4_2021-3005619324-1.vswp
Filr4.vmdk Filr4_2021-aux.xml vastorage-flat.vmdk
Filr4.vmsd Filr4_2021-b3261c7c.vswp vastorage.vmdk
Last edited by AndersG (2021-10-29 06:39:52)
Offline
Unless you have some previous snapshot, which does not seem to be the case, you don't need the .vmsd file, just delete it, or even better: rename it to avoid irreparable mistakes.
In any case renaming a VM is not only renaming the files. You will need to rename all references in the .vmx file and the file descriptors .vmdk files (the tiny ones not the -flat.vmdk) as well as any other reference to snapshot files in the eventual snapshot file descriptors and .vmsd files.
To avoid innecessary hassle, unless you are used to do this kind of thing, just keep the name.
Offline
Thanks! No I would never dream of renaming any other way than through the Web UI and that takes care of renaming all other files as well, but anyway. There were two files that retained the old name, that one and an XML-file that just had <config /> in it. Shut down the VM. Renamed those two and restarted. Backup is now running......
Offline
We would never dare on the other side to rename through the web UI ;-) for the exact reason that you are describing.
Offline
OK. I also noted that there was a disk image that has not been touched in months there and also does not seem to be defined in the VM properties. I guess I will make a backup of that file and remove it. This particular VM is an "appliance". You upgrade by moving the data disk to a new VM. There is always a chance that you forget to delete some old files.
Offline
It's never a bad idea to do some clean up and remove spurious files from the production VM.
From our experience after some time of a VM in production you can accumulate orphan snapshots, old log files etc...
Keep in mind that once you remove all snapshots, all that you need for a VM to work seamlessly from an stopped state is:
1/ The file descriptors and corresponding -flat.vmdk files
2/ the .vmx file pointing to the right file descriptors.
You can delete the .vmsd file, it will be regenerated. In fact in some cases you do need to do so to fix some inconsistencies in it.
(*) Of course in case you have some more advanced requirements, like keeping snapshots or the memory state, you will need to keep some more files, still to sanitize a VM from an stopped state all you need are the disks and the .vmx file.
Offline
Yes. You are right. That is what I did eventually. Noted what disks were defined and their files and copied just those and the VMX file to another diectory. That fixed it.
Offline