Since customer need to execute scheduled backup tasks and vdisk update tasks, administrator may copy vdisk, which is in-using for data streaming from PVS server.
Sometimes, data flow to NAS storage will increase even vDisk copy operation is finished. 

As the result, end user will experience pool performance issue and VDA unregistered issue.



Before copying vdisk,


After finished copying,

Due to SMB protocol limitation, It is not recommended to copy vDisk in use on PVS server directly. 

• For backup vdisk task: Do not back up a vDisk while its being used or while it is locked. Citrix recommends backing up these disks using your normal provisioning server backup routine.
• For update vdisk task: Please use vDisk versioning to update disk.

What is vDisk versioning:

Versioning simplifies vDisk update and management tasks, providing a more flexible and robust approach to managing vDisks.

A vDisk consists of a VHDX base image file, any associated side-car files, and if applicable, a chain of referenced VHDX differencing disks. Differencing disks are created to capture the changes made to the base disk image, leaving the original base disk unchanged. Each differencing disk that is associated with a base disk represents a different version.

The following sections discuss the file naming convention used and the relationship between a base disk and all versions referencing it.

---

Problem Cause

PVS uses the SMB(the variant used will be dependent on the OS and the file share is on) protocol to open a file from a CIFS share, SMB 2.1 introduced a feature called leasing which allows multiple handles from the same client to the same file.
When we attempt to stream a vDisk we send an Oplock create request which creates a handle to the disk and allows the client to cache reads locally on the PVS Server.
When 2 targets access the same Vdisk from different PVS Servers each creates a level 2 oplock which essentially allows multiple targets to simultaneously perform read operations on the same file.

During Streaming without Copy operation we see the following behavior, 

1. PVS target sends a read request to the PVS Server.
2. The Stream process then performs a read file operation the vDisk on the NAS .
   • The PVS Server (SMB client) sends a SMB read request to the NAS.
   • The NAS responds with a SMB read response.
3. The PVS Server then send the read response to the target.

Now looking at what happens when we start copying the active vDisk:

1. The PVS Server already has a lease open to the vDisk.
2. We attempt to copy the same file from NAS.
3. This creates a new SMB session.
4. This new SMB session attempts to create a lease on the vDisk.
5. At this point we appear to break the lease held by the stream process.

In summary PVS uses SMB2 to access a remote file share, this is done through standard windows file system operations. How these are handled depends on the SMB client and Server configuration and the OS of the machines involved, this is not dependent on the PVS implementation.

Consequently as this is the expected behavior when accessing a remote file share utilizing SMB2 and windows file system operations this is the expected behavior of PVS (any implementation). Doing any large copy operations to\from PVS server (or between PVS servers) in production is never a good idea. 
 

https://blogs.msdn.microsoft.com/openspecification/2009/05/22/client-caching-features-oplock-vs-lease/
https://msdn.microsoft.com/en-us/library/cc246482.aspx
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html
https://msdn.microsoft.com/en-us/library/cc246482.aspx