Restore virtual machine from secondary filer

[peter1965]

Hello,

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.

thoughts? input?

thanks for reading

[keitha]

Peter,

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

Keith

[peter1965]

During the copy..

I would browse the mounted datastore that is read only from the secondary san (snapvault destination) click the snapshot folder then select

Right click machine click copy

Then I would go to the datastore I wish to copy to and right click and past. And get the following error:

[sharmas]

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.

[peter1965]

This error is happening during the COPY. So there is nothing for me to power on to see an error on yet.

[sharmas]

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.

Thanks

[peter1965]

I wasnt able to get it via shell

[sharmas]

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.

[peter1965]

Which controller? Primary or secondary that I am trying to copy from?

[sharmas]

Secondary Controller as it is giving you a file access error. I assume that the Primary will have root/RW access with UNIX as it is currently serving VMs.

[peter1965]

Yep and already set... Sigh

[thomas_glodde]

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.

[peter1965]

No not off topic.. and I was actually just thinking about that…..

thanks

[sharmas]

It is recommended not to mix OnCommand Core Host Package and VSC. Also the backups taken by VSC will not be visible in the OCHP and you will have to recreate all the jobs.

[peter1965]

So another words you are saying either use vsc or oncommand 5 to do this?

[sharmas]

Yes, that is what I would recommend. VSC B&R is targeted towards VMware admins managing Backups and OCHP towards Storage admins managing it.

[peter1965]

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

[thomas_glodde]

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

[keitha]

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?

Keith

[peter1965]

Yes

[hadrian]

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

HTH,

Hadrian