I am trying to put together a process to restore virtual machines that were snap vaulted to our secondary 6210 san qtree from our 6280 primary san. The datastores are NFS. What I did is mount the secondary datastore/qtree onto the san by adding a datastore as read only then I would click on the snapshot folder and select a smvi folder to copy the machine over. I had the machine I wanted to restore on the production san off but this is where it doesnt work I woild simply get some error. I wanted it to be gui as possible. As I am using VSC 4 to snap this specific datastore as only dev test machines are residining there but I also snapvault them over.
The error from vmware is "Expected put message. Got:ERROR" Perhaps permissions..And I was trying to download the machine to my desktop (its a small machine) from the vmware datstore browser. And if I try the move option from the read only datastore to the datastore on the primary datastore I would get "cannot write on datastore (qtreename) on the target host"
I am just going to assume this isnt the best way to perform it and the snap vaulting is not part of ops manager/dfm. It appears I may have to do it the cli way of "snap restore" command. I wanted to make it gui as possible, As I thought I can copy the machine from the secondary datastore to the primary destination.. I suppose i was very wrong
Anyhow we use commvault for our production stuff and I didnt want to waste the commvault licensing on dev test stuff... and I was trying to see what i can do for these dev test machines for that "just in case" scenario.
thanks for reading
It looks like we are having the same issue here. When i want to copy a file from a mounted datastore (flexclone from a vsc backup) I get : Expected put message. Got: ERROR
From the cli on the ESX host I can access the files normal. (copy etc) but from vcenter (gui or web client) i cannot copy a file. (Or connect a disk to a vm)
The nfs export is normal : -sec=sys,rw,anon=0
Maybe slightly offtopic but if you have 62xx machines you have free licenses for oncommand core as well as oncommand host package which enables you to make gui driven backups and restores from primary and secondary storage as well as manage the snapvault replication.
Interesting. I think that makes sense as I will have to remove vsc 4.0 from the virtual center. Anyhow wow I should of looked at this first… Argh.. ☺ That also means the smvi script is no longer required to update that snapvault destination.
I have oncommand 5.1 installed but rarely use it as it had its own set of issues which I just fixed today. So if I install the host 1.1 package then I can be on my way with backups and restore the vm’s from the secondary filer to the primary… I will look more into it.. Anyhow it sounds like gui nirvana….
You need to keep VSC4 to apply the recommended settings to your ESX hosts as well as for cloning activities, you just need to remove the backup & restore component of VSC4.
And usualy, yes, OnCmd with Host package is supposed to be the way to go from now on. They might even add hyper-v again in the near future ... maybe ...
The grayed out options is not letting me remove the compnents. Actually when I installed it the top three selections were already made adn nothing i can do. I think those are dependincies and are required...
We will have some roadmap announcements regarding VM backup soon.
Regardless of how the backup was taken, OCHP or VSC the snapshot should be accessible from the SnapVault. Did you check the share permissions like Satinder suggested? Was the host in the root group?
Can we take a step back here and help us understand which restore scenario are you trying to test / implement?
Restore entire VM? Restore a single file? Restore your VMA? Restore an entire datastore?
I would suggest since the primary and secondary datasets are NFS datastores to attempt this copy via the CLI of a linux client (even a VM!) to isolate anything that vCenter client is trying to do on our behalf. If there is an issue with the linux copy then you know it will be a permission issue (could be qtree security in addition to your NFS export policy).
As mentioned in the initial post I am trying to restore VIRTUAL MACHINES that were snapvaulted to a secondary san (6210).
I am currently using VSC4 to snap them on the primary san (6280) and SMVI and the smvi script updates the destination qtree on the secondary san. Both san using NFS protocols on the datastores.
I have mounted the datastore from the secondary san to a ESX host as READ ONLY. So I was trying to copy the files within that machine folder “VMA” was an example machine back to the primary. Some files do copy over but not all of them. I have also created a new folder within the datastore to restore to and tried to paste all of the files there but not all of them will copy over that consist of the virtual machine.
I am not trying to restore specific files within the virtual machine at this time.
What you described should work. When you copy the VM back when do you get the error? during the copy or when you try to start the VM? You are trying a basic file->copy then File->paste? Don't try to do a move or a cut since the source is read only....
Once the VM has been copied over you will need to reregister the VM so it will show as a net new VM...
Can you show us the exact errors you are getting...
After copying, did you verify if the size of .vmdk-flat at the destination matches that at the source (SV destination)?
From what I remember, when you browse a datastore, the .vmdk-flat file is hidden and is pointed to by the .vmdk file. Once we copy the folder, all the files get copied including the .vmdk file but the .vmdk-flat file (which is the biggest of the lot) doesn't finish copying.
This can sometimes prevent the VM from powering on.
My bad... I should have read the thread more carefully. Is this error common across all the VMs? or have you tried it on just one? Can you share the file listing of the VM folder that you are trying to copy and getting an error on? A ls -la from the shell will be more helpful than just the GUI option of browse datastore.
Things look OK in the listing there. Las thing I would check is the the export permissions on the netapp controller. You should try using root and make sure that UNIX is selected as the security style (out of UNIX, NTFS and Mixed).
If this doesnt work, I would suggest logging a support case as this is not the expected behaviour.