No, I Will Not Fix Your #@$!! Computer → ESXi5.1 - magically renamed files...

Greetings; I'd had good luck copying files between data-stores, but the luck just ran out. I have one VMDK file that just won't copy, and another that renamed itself. I was copying files off of one datastore because I was replacing its disk with another larger disk, then I was going to copy the files back. Here's what I did...

*Took down all virtuals*

1-Browsed the Datastore, and did a shift-click on all files, and did a copy.

2-Browsed the new Datastore, and created a directory for the files. Went into that directory, and did a paste. All files copy OK except the VMDK. After 5min or so, I get, "Could not copy /vmfs/volumes/abc123abc123abc123/WindowsXP.vmdk because it could not be found. I assure you I could browse right to it & look it in the eye.. it was there....

3-I found some of it copied into the new Datastore, but it was named "WindowsXP-ff01.vmdk. -a temp file?

4-I strong-armed it by sshing into ESXi, and doing a 'cp' of the file to the proper data-store. Copy complete, no rename this time.

5-Same operation, different VMDK in a different direcetory this time. All files copied OK, including the VMDK, but it was renamed from "Windows7.VMDK" to "Windows7-flat.VMDK". I renamed it back to the original.

6-All files now on the new Datastore, and named just like the originals, despite any magic re-naming that ESXi did.

7-Added both virtuals' VMX files to the inventory. When they both start, I get, "Could not start xxxxxxxxxx because WindowsXP.VMDK (or Windows7.VMDK) could not be found, or a snapshot related to the image could not be found..."

---I still have the HD with the original datastore on it, where the virtuals were running OK. Otherwise, how can I fix this?

OK, I see that I screwed things up. "file.VMDK" and "file-flat.VMDK" sometimes should both be present. Renaming VMDKs using the 'mv' command is not a good thing. There's a special ESXi CLI command to do this. I found an artical on the subject. I'll try running thru it later.

All I can say, is that I built & configured this system to learn. And learn I shall.....

OK -- not good. All the pristine working versions of my vm's are GONE... When I deleted the data-store, it looks like it deleted the VMFS partition & everything. Disk empty. Game over. I thought deleting the datastore would leave the filesystem intact, and I could just disconnect the hard drive. Apparently VMFS goes away too.

Now I"m left with broken copies of my vm's. Are there any tricks that can be offered, or should I just go look for articles that deal with, "my vm's don't work after I copied them..." and "can't find xxxxx.vmdk, or a snapshot associated with it..."

Why are you browsing datastores or worse, using command line tools?

While you can do this, you generally have to have a firm grip on the underlying fundamentals of vmware.

You should be right clicking the machine and clicking "migrate" and then select "change datastore"

When you "delete a datastore". Define delete. Where did you do a "delete"?

Here's my first piece of advice: Disable SSH and do NOT do anything command line. For most vmware administrators, in most day-to-day situations, you will never need this. General rule of thumb: If you using cli (and NOT the PowerCLI), your either on your last hope and on the phone with tech support - or your doing it wrong and should either be in PowerCLI or the gui.

Thanks for responding... I don't have the 'migrate', or 'change datastore' options, because I don't run vCenter, I'm on the unlimited-free ESXi license. The only way to move files between datastores, is to browse to them. That's where the first trouble came in. I was copying files for my Windows7 virtual, and it included "Windows7.vmdk". 1/2 way thru the copy, I got the error that it couldn't be copied because it couldn't be found.. weird. I deleted everything from the target datastore & tried again. Same error. That's when I resorted to the CLI method for the copy.

When I deleted the datastore, I was looking at the datastores configured on the host, and right-clicked, then selected "Delete..." I was looking at the configuration tab of the host, then selected 'storage' on the LH-side list.

Why did you do a delete of the datastore when you didn't want to delete the data inside the datastore? Curious question.
Or let me phrase it in another way: What did you expect from this operation to happen?

The first and only thing that comes to my mind to solve the problem is to look into the VMX file and check what file names it expects. Change the filename in the VMX file or the file names of the files itself respectively. But I don't have high hopes since I don't understand what happened.

I guess I thought it would 'dismount' the drive from the system perminantly, leaving the file system intact.

I'll check the VMX files.. I do still have the XP and Win7 OS's in Clonezilla images, so if needed, I can always re-run the P-to-V converter after I put them on the PCs they used to be on. (more re-work, but this will re-create the virtuals from scratch essentially. Plus now I know how not to man-handle those files...

There's a difference between "remove" and "delete". The safest path is to physically take away the datastore (unplug the drive), make sure all the VMs function from the new datastore, then remove the unavailable datastore from the host. (you can always plug the drive back in)

Unless you are dealing with the datastore from the commandline, a number of details will be hidden from you. As you now know, a "vmdk" may, in fact, be MANY files.

General rule: unless you absolutely, 100% know what you are doing, never f*** with the underlying datastore.

I agree -- This is a home lab system, so I knew there would be a settling-in period where I was moving things around, with regards to the data-stores. Here's my final resting-position:

DataStore1..... 80GB drive that boots ESXi

DataStore2......500GB disk that will house Win7, WinXP, and CentOS5

DataStore3......1TB disk that will hold demo version of RSA Authentication Manager

DataStore4......1TB disk that will hold demo version of RSA Authentication Manager