vPower NFS FAQ

[sphilp]

Quick question on the information shown during v5 installation...

When configuring the vPower NFS folder, the instructions request a volume with at least 100GB of free disk space.

The v5 Release Notes call out the requirement as 10GB.

Which one is correct?

[tsightler]

Well, the reality is that you need to size your vPower NFS space to be large enough to hold any changes that will be written any time you have Instant Restored VM's or Virtual Labs running, so the space requirements will change significantly based on how much you plan to use the feature. Veeam does not make changes to the actual backup files, so all changes have to be written somewhere. That "somewhere" is the vPower NFS folder.

It can be difficult to know exactly how large this space should be, but 10GB seems quite small for anything other than just playing with the feature. If you want to be able to actually boot and run more than a handful of VM's, and leave them running for a few hours, I'd suggest nothing less that 50GB, and for more extensive use of the feature, like using instant recovery in the event of a catastrophic SAN failure, I'd suggest even more space. If you know your change rate (perhaps estimated from the size of your nightly Veeam backups) you might be able to use this knowledge estimate the space required to keep system running for a given amount of time.

[Gostev]

Tom is right. Just one small correction, anything that runs in the Virtual Lab does not use this cache, instead it uses datastore selected during Virtual Lab setup to store redo logs for each VM running in Virtual Lab (essentially, all sandboxed VMs are configured with non-persistent disks with redo logs pointed to select datastore).

The local vPower NFS cache is used for Instant VM Recovery only. We cannot use non-persistent disks, or redirected snapshot during Instant VM Recovery, because both disable Storage VMotion. So instead we need to do our own, internal VM disk changes redirection to keep backup files read-only. This is where local vPower NFS cache comes in. So for ESX, it now looks like it deals with regular VMDK (without any snapshots - browse vPower NFS with VM published and see for yourself). This makes Storage VMotion possible.

Release Notes shows minimum storage space requirements, and instructions show recommended.

[tsightler]

Sorry about the misinformation there. I forgot that Virtual Lab does not use this cache.

[RumataRus]

[merged]

Hi, guys!
Sorry for my english, I do my best.

During installation Veeam Backup&Replication I was asked to specify vPower NFS root folder.
The comment says that "make sure, the selected volume has at least 100Gb of free disk space available to prevent recovered VMs from stopping due to the lack of free disk space recovery".

How big must be vPower NFS root folder if I have VMs with 500Gb disks?
Does it depend on the number of simultaneous recovery processes?

[RumataRus]

Thank You!
If the local vPower NFS cache is used during Instant VM Recovery for disk changes only, then recommended 100 Gb seems to be suitable.

[Vitaliy S.]

Yes, you should be fine with this value.

[real_tarantoga]

Hello board,
since vb&r 3.3 we use a dedicated veeam backup server. Since version 5.0 the server's disk is running out of space and I mounted a netapp lun using iscsi. How can I switch to the newly created lun to be used by vPower?
Do I really have to reinstall the software or is there another possibility that I didn't found yet?

thank you, stefan

[Alexey D.]

Hello Stefan,

Please take a look here: Changing vPower NFS Datastore

[real_tarantoga]

Thank You, Alexey. That's what I missed.

[nehalem]

[merged]

Hello team,

I need three things to figure out about the vPowerNfs folder,

Q1 : In a fully working installation of Veeam5, is there any way to reconfigure Veeam pointing the vPowerNFS folder somewhere else to another drive and folder?
I thing while having a bunch of replicas and hosts added the scratch re-installation to reconfigure the vPowerNFS folder is not a good idea!

Q2 : the vPowerNFS Datastore remains mounted on host took place an FLR of Instant restore, until someone manually unmounts it? Automatically it doesn't umnounts!

Q3 : The recommendation for free space is correct? If i want to instantly restore a VM with a based disk 200GB and more, do i need to have same free space on this vPowerNFS folder /drive?

Best regards,
NK

[Gostev]

Hi,

Q2. Correct, there is simply no sense to dismount it after every single operation.

Other questions have already been discussed before, see above.

Thanks!

[tsightler]

Q2. Correct, there is simply no sense to dismount it after every single operation.

I'm going to politely disagree with this, the behavior of leaving PowerNFS store mounted is quite annoying. I end up removing it every time manually when really Veeam should just remove it for me.

[Gostev]

Can you please elaborate what is annoying about it? If there are valid reasons, I can request registry hack implemented to make this behavior customizable.

There are multiple reasons to keep it mounted that significantly outweighed during this design decision, which include:
1. Performance (no need to spend time on mounting process each time). Chatting with ESX always takes very noticeable time.
2. Reliability (mount will not fail in the most important moment, if you used once the NFS will be there and ready).
3. Security (provide ability to mount it manually once, this way you do not have to give service account ability to manage datastores).
4. Technical issues around some versions of VMware ESX and NFS storage (some problems with multiple mounts/dismounts).
5. And more, don't remember everything already.

Sure, it would be good to have an option for everything... but if we had an option for everything, v5 would still not be released plus, today is the first time someone brings this up, in half-year since v5 was released, which is a good sign we did the right thing!

[tsightler]

I figured there were good reasons for the decision, I could even think of some of them myself, I just don't personally like the idea of having volumes that get used maybe .1% of the time mounted 100% of the time. We've had issues where, when the Veeam server was offline or unreachable that storage commands on the ESX host took a long time to complete because it was waiting for the PowerNFS host (I don't think we've seen this with 4.1), and we one time had an admin accidentally create a new VM on the PowerNFS volume. We've also had at least one case where the same PowerNFS server was mounted multiple times, although only one mount was actually usable, although I haven't seen that lately (of course, I now clean up behind Veeam whenever I see the volumes out there).

I basically just don't like the clutter. Certainly not a good technical reason, I get that, and I'm not asking for this feature, there's plenty of other things you should be working on that are much more important. I'm not even saying that the decision was wrong, only that I don't like the behavior. Sometimes you have to make the choice between the cleanest possible implementation, and the practical, and Veeam problem selected the practical, while I probably would have preferred the clean. Not a big deal.

[Gostev]

one time had an admin accidentally create a new VM on the PowerNFS volume.

This made me smile

I basically just don't like the clutter. Certainly not a good technical reason, I get that, and I'm not asking for this feature, there's plenty of other things you should be working on that are much more important.

OK, sounds good. Makes it easier for us. Becaise I am afraid this would have to be implemented separately in multiple places, so looks not so easy.

[tsightler]

The idea of manually mounting the PowerNFS volume is interesting. Can you name the volume whatever you want when you do this or does it have to be named using the same Veeam naming schema? If we could manually mount it we could name it so it better fits our own schema, and then also set security so hopefully an admin couldn't make the mistake of using it as an actual volume.

[Gostev]

Sure, here is the procedure. Good info for consolidated FAQ topic anyway!
Possible to specify IP used for mounting NFS datastore

Yes, it has to be named in a certain way to be recognized by Veeam Backup.

[pinkerton]

Hi,

with VBR 5, is it possible to:

- manually mount the vPower NFS store to ESX/ESXi servers? what would I need to specify as folder name in ESX?
- manually place files in the folder used for NFS?

I'm thinking of running a copy job for some VMs and place the copies directly in that NFS folder. This way we'd always have a standby copy, ready to be started when the original VM fails. Or is it not recommended to place VMs manually in the NFS folder so we rather should use Instant Recovery for that?

However, I feel more safe with having particular VMs backed up as 1:1 copy to unique folders, not tied to any dependencies from VBR.

Thanks

[Gostev]

Hi, please see above for manual mount process.

You can place files in the root folder manually (and some customers do use that to share ISO files easily), but for VMs it makes no sense to do. Instead, just use Instant VM Recovery - it will provide you same (if not better) performance without additional storage required to store those copies.

[HPersson]

Is there any kind of security / access rights for the vPower NFS-share so that just the esx-servers can access it? Or can anyone with a NFS-client access that share?

[veremin]

The NFS requests might be firewalled.

Based on internal discussion we had, the most secure way is to add an additional IP address to the Veeam Server (either on a separate physical network or a VLAN, at least) and make a secondary management interface on the ESX(i) host connect to it. Software firewall should be used to block all NFS requests on the primary interface of the Veeam server.

Thus, the vPower NFS service is reachable only by ESX(i) hosts that have access to the additional network. After that, mount the service manually to the specified ESX(i) hosts.

Hope this helps.
Thanks.