Jump To: Support > KB > Citrix > PVS > vDisks

Maintaining vDisks within Provisioning Services 5.6

Prerequsites

You should be familiar with the Provisioning Services Console; specifically, assigning vDisks to target devices and viewing stores.

You need to know how many Provisioning (PVS) Servers you have and where your vDisks are stored. There are 3 likely options:

1. Single PVS server with large local discs and no connection to shared storage. All vDisks held in one location on its disc.
2. Multiple PVS servers with large local discs and no connection to shared storage. vDisks must be replicated between the servers
3. Multiple PVS servers with little or no local storage, but connected to a SAN. vDisks are held in multiple managed stores which can be switched between Active (i.e. in production) and Maintenance.

Terminology

• vDisk - a virtual hard disc which can be used by multiple target devices. The main vDisk file is called vDiskName.vhd. This is accompanied by a vDiskName.pvp file which contains settings for the vDisk. Both files must be copied or moved together. The file called vDiskName.lok can be ignored. The files will tend to be in a folder on a hard disc on the provisioning server(s)
• Store - a collection of vDisks which can be served by one or more servers. If served by multiple servers, the paths set for the store must be available on all servers.
• Target Device - a specific client machine. This is defined by its MAC address and name
• Private mode - a vDisk set up to be written back to
• Shared mode - a vDisk in read-only mode where all date written will be sent to a Write Cache that will be discarded at reboot
• Master Device - a specific Target Device which is only used to work on updating vDisks. Generally this will be a virtual machine

General procedures

A list of different vDisks is maintained, generally one per operating system type or workload. The number of vDisks should be kept as small as possible. So for instance, if you have XenApp servers running Server 2008 and PCs running Windows 7, you will tend to have 2 vDisks. The Windows 7 vDisks will be configured to run on multiple types of hardware. Each vDisks will have multiple generations, i.e. there will be later copies with updated software on as well as older version for backup purposes. The vDisks would tend to be called XenApp-XX and Win7-XX, where XX is a number denoting the generation.

Of each type of vDisk, 2 generations will be in use. A main one will be set in Shared Mode and will be in production (i.e. in use by multiple Target Devices). There will then be the next generation ready to have software or updates installed. This 'development' copy will be set to Private Mode and assigned to a certain Master device. For a XenApp server, there will be a Virtual Machine called XenAppMaster for this purpose.

When an update is required:

1. The development vDisk is checked to be set to Private Mode
2. The development vDisk is checked to be assigned to the master device
3. The master machine is booted
4. Administrator logs in, makes changes
5. If a XenApp 5 server, XenAppPrep is run. On XenApp 6, the machine must be rejoined to the farm (procedure to be written)
6. Master machine is shut down
7. vDisk is set to Shared Mode
8. vDisk (the .vhd and the .pvp file) is copied (simply using Ctrl-C and Ctrl-V within Windows Explorer)
9. Copy is renamed to have an incremented generation number
10. Original is assigned to all relevant target devices
11. Copy is added to Store by right-clicking on the Store in the PVS console and choosing Add Existing vDisk...
12. Copy is set to Private Mode
13. Copy is assigned to master device

So, for example, if all the XenApp servers are using XenApp-5, the master device will have XenApp-6 assigned to it. XenApp-6 will then be copied and renamed XenApp-7. XenApp-6 will be assigned to all XenApp servers and XenApp-7 will be assigned to the master device.

The exact procedure of copying and adding to a store depends on the how your stores are set up (See Prerequisites).

Single server

Simply follow the procedure above.

You should periodically remove older generations of vDisks to save space. To do this, use the PVS Console and delete the vDisks from the vDisks section or from the Stores section. You may select the Delete the associated VHD file(s) option. If you do not, once you have removed the vDisks from within the PVS Console, delete the .vhd, .pvp and .lok files manually from the hard disc.

Multiple servers - large local storage

You will have multiple Stores set up within your PVS farm. Generally you will have one called Production and another called PVS01 or Development (assumed to be PVS01 for the purposes of this discussion.

Right-click on a Store and choose Properties. Click on the Servers tab and you will see that the Production Store will be served by multiple servers, but the PVS01 Store will be served by only one. Next, click on the Paths tab and you will see that the Stores each use vDisk files from a different location. Production will usually be E:\liveDisks and PVS01 will be E:\vDisks.

To put a vDisk into production, the vDisk must be moved into the liveDisks folder, copied to the liveDisks folder on the other server(s) and then imported into the Production Store. Generally, the vDisk will be moved to the liveDisks folder rather than just copied as this will be quicker and it saves space.

So the procedure is:

1. The development vDisk is checked to be set to Private Mode
2. The development vDisk is checked to be assigned to the master device
3. The master machine is booted
4. Administrator logs in, makes changes
5. If a XenApp server, XenAppPrep is run
6. Master machine is shut down
7. vDisk is set to Shared Mode
8. vDisk (the .vhd and the .pvp file) is copied within E:\vDisks (simply using Ctrl-C and Ctrl-V within Windows Explorer)
9. Copy is renamed to have an incremented generation number
10. Copy is added to PVS01 Store by right-clicking on the Store in the PVS console and choosing Add Existing vDisk...
11. Copy is set to Private Mode
12. Copy is assigned to master device
13. Delete the original from the Store within the PVS console, but 'do not select the Delete the associated VHD file(s) option. If you cannot delete the original, then it must still be assigned to a device. Right-click and choose Unassign from Selected Device(s)... to remove the assignments.
14. Move the original .vhd and .pvp files from E:\vDisks to E:\liveDisks
15. Double click on syncLiveDisks.bat in the root of drive E: and wait for the copy to complete
16. Right-click on Production Store and choose Add Existing vDisk...'. Search and add
17. Assign the vDisks from the Production Store to the target devices

You should periodically remove older generations of vDisks to save space. To do this, use the PVS Console and delete the vDisks from the Production Store. Do not select the Delete the associated VHD file(s) option. Manually delete the .vhd, .pvp and .lok files manually from the hard discs on all servers.

syncLiveDisks.bat will contain something like:

robocopy E:\liveDisks \\pvs02\e$\liveDisks /S /PURGE /XO

Multiple servers - connected to SAN

In this scenario, a logical drive on the SAN is split into multiple LUNs. The LUNs are shown as separate drives within Windows Explorer (and paths are consistent across all servers). So, for example, you might have drives E:, F: and G: representing 3 LUNs on the SAN. Each provisioning servers can access all stores and the stores are configured to be served by all PVS servers.

It is not possible to access a LUN from more than one server at a time unless there is only read-only access (otherwise the filesystem would get corrupted). The clever bit is that PVS understands this and allows you to switch each store between two modes:

• Active - drive is mounted read-only on all servers and thus can be served by all servers
• Maintenance - drive is taken offline on all servers but one. On the server, it is mounted read-write

By using these Managed stores, you don't need to copy vDisks between servers and so it is much quicker to maintain. The downside is that if a store is set to Active, all vDisks within it will be read-only (even if set to Private mode). Therefore, you sometimes need to juggle vDisks between stores to ensure that you always have at least 1 store in Maintenance mode with your development vDisks in.

To work with Managed stores, you can follow the instructions for Single Server (above), but when copying vDisks to make a new generation you will need to copy to a different store and then put the Store with the original in into Active mode.