Pagefiles, partitions and drives are an interesting combination of items to talk about regarding Provisioning Services and XenApp. Each one will have a direct impact on your environment. First, let's be clear, Provisioning Services does support many of these items, but when I design a Provisioning Services solution (or any solution for that matter), I'm always reminded of a message a professor told me once. The professor was a fan of the group KISS and he always wanted you to follow the KISS motto... "Keep It Simple Stupid", but I'll be a little more polite and say "Keep it Short and Simple". Keeping it simple is how we will design the following items.
Pagefile
The first area deals with the page file. Before we got into provisioning and virtualization, I would see many people put the page file on a different drive letter than their OS or applications. At first glance you would think, OK, they want the page file to respond fast. But the page file was only on a different drive letter at the logical layer. At the physical layer, the page file was still on the same physical disk as the other partitions. So, my question was "Why are you moving the page file? You are causing yourself more work for no benefit." The same holds true in Provisioning Services.
The pagefile is undergoing constant modification by the operating system. As physical memory is paged, it is stored in the pagefile. Upon reboot, the contents of the pagefile are not important, and it is overwritten on subsequent startups. In a Provisioning Services environment, the pagefile will be located on the vDisk, but any change made to the file will be recorded in the write cache, because the vDisk image is read-only. Assigning the pagefile to a different partition within the vDisk is not recommended, because there is no speed benefit. You are just causing yourself more work.
Multiple Partitions
On the heels of the page file decision is whether to use multiple partitions. Does this look familiar?
- One Partition Server
- Partition 1: Operating System, Pagefile, Applications
- Two Partition Server:
- Partition 1: Operating System, Pagefile
- Partition 2: Applications
- Three Partition Server
- Partition 1: Operating System
- Partition 2: Applications
- Partition 3: Pagefile
Provisioning Services can deliver an image with one or two partitions, but not three. Plus, based on the Pagefile section above, there is no gain from having a separate pagefile partition on a provisioned XenApp server as the pagefile changes will be stored in the write cache.
Although two partitions are supported, it does increase the complexity of the environment and does not offer any performance benefit to the environment. There is a Citrix article (CTX116698) that explains how to provision a server with multiple partitions, but why go through the hassle. Keep It Simple.
Drive Remapping
Finally we get to remapping XenApp server drives. Remember, this is when you change the C drive of the XenApp server to the M Drive. D becomes N and so on. Why would you do this you might ask? Well, the most common justification for this design consideration was for users to have their client drives mapped within their XenApp sessions as C and D. However, this approach should be re-examined. Remapping server drives is not considered a best practice for XenApp environments because:
- Drive remapping is no longer an option in XenApp 5 running on Windows 2008 Server.
- Giving users access to their local C and D drives within a XenApp session is considered a security risk. If the applications are hosted on the XenApp servers, the data should be in the data center for best application performance.
- It makes the environment more difficult to setup, maintain and troubleshoot
So remember, Keep it Short and Simple (KISS):
- Page file: don't create a special vDisk partition
- Partitions: Use a single partition
- Drive Remapping: Don't do it.
What do you think? Agree or disagree? BTW, we will be revisiting the page file topic again in an upcoming blog when we discuss Local Database Storage. How does the page file fit with local databases? Well, you will just have to stay tuned.
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
Comments (17)
Apr 15, 2009
Nico Van Meurs says:
Hi Daniell, I agree with keeping it simple. Especially in PVS environments...Hi Daniell,
I agree with keeping it simple. Especially in PVS environments keeping the XenApp servers simple spares you a lot of work and frustration.
One thing about the pagefile though.. isn't it so that the pagefile is automatically being redirected to a physical drive when one is present? Putting the pagefile on a physical drive (next to the writecache) does gain performance.
What do you think?
Nico van Meurs
www.virtualdesktopblog.com
Apr 15, 2009
Anonymous says:
I agree... Moving the pagefile for a vDisk is irrelevant. For both a...I agree... Moving the pagefile for a vDisk is irrelevant. For both a Private and Standard image.
To clarify your original point on moving the pagefile. Yes, the best practice was to move the pagefile to another volume/partition. Yes, moving it to another partition still mean that the your still going to same physical disk as if it was on the System Partition. The difference is, when you create that second partition, move the pagefile and reboot you ensure that the Pagefile is contiguous and not fragmented. It's not much of an issue today. With the introduction of SANs, Virtualization, etc everything pretty much fragmented at some point.
Nico, as far I know, the pagefile gets redirect as part of the writecache.
Joe Shonk
Apr 15, 2009
Daniel Feller says:
Joe One of Citrix Consulting's standard XenApp practice, whether we virtualize ...Joe
One of Citrix Consulting's standard XenApp practice, whether we virtualize XenApp on XenServer or delivery XenApp with Provisioning Services is to set the pagefile size minimum and maximum equal. This prevents the pagefile from growing and becoming fragmented.
Plus, it takes processing and disk time to expand a pagefile. When does a pagefile need to expand? When the server is under stress. So, when the server is under stress, the pagefile growth adds more stress. By setting min/max the same, we avoid this potential pitfall.
Daniel
Apr 15, 2009
Anonymous says:
Exactly, that's why you do it on a fresh partition. To pre-allocate ...Exactly, that's why you do it on a fresh partition. To pre-allocate the pagefile without fragmentation. Windows doesn't do a good job at this on the System Partition. I just finished a Windows 2003 x64 w/ Windows Update and the Disk Defrag shows 25% fragmentation already. The OS is only one hour old!
Yes, always set the min/max the same so the pagefile does not expand. I don't remember saying otherwise.
Joe
Jun 01
ubik ubik says:
Hi Daniel, I have been following your blogs with interest as I am trying to prov...Hi Daniel, I have been following your blogs with interest as I am trying to provision a xenapp server onto xenserver using PSV5+SP2 using best practise and performance
I am very confused about the pagefile now.
Do I set it to say 4096min, 4096 max before taking the image? As this is for a citrix server.
So windows wont be able to use any size of page file you set beause the vdisk will be read only?
So why bother using a page file at all?
I've noticed that when you boot the vdisk, Windows shows as not using any pagefile.
I intend to use the extra virtual drive for perm data and the vdisk cache, so will that be used for
the page file?
Also, when you use the extra drive for the chace etc, its not initialised when you boot up, so you have to use a script to do that?
Fred
Apr 15, 2009
Nico Van Meurs says:
Joe, This hotfix article describes what I mean, the pagefile being redirected t...Joe,
This hotfix article describes what I mean, the pagefile being redirected to the local disk when writecache on local disk is being configured.
http://support.citrix.com/article/ctx118014
Nico
Apr 15, 2009
Anonymous says:
About the pagefile and the place to put it, we want to keep the vdisk ...About the pagefile and the place to put it, we want to keep the vdisk as small as possible to consume less expensive SAN storage.
We alway put the pagefile on a physical drive (fixed size) next to the writecache, both seems to give a better performance
Apr 15, 2009
Niek Boevink says:
made a mistake and posted anonymous the info above Niekmade a mistake and posted anonymous the info above
Niek
Apr 15, 2009
Daniel Feller says:
what u mean about page file on physical drive that is next to the write cache? A...what u mean about page file on physical drive that is next to the write cache? Are you putting the write cache on the same physical drive as well?
May 27
Anonymous says:
We also put the pagefile beside the write cache on the local physical disk This ...We also put the pagefile beside the write cache on the local physical disk
This option saves 4 gb of size in the vdisk
I tested some settings and this seems to be the fastest methode
Apr 15, 2009
Niek Boevink says:
I define the local physical disk in standard mode With dynamic disk mode ...I define the local physical disk in standard mode
With dynamic disk mode i had a couple strange things
Niek
Apr 16, 2009
Anonymous says:
Remember that if you move the page file off the boot volume then you can't obtai...Remember that if you move the page file off the boot volume then you can't obtain memory dumps for debugging and support.
Apr 20, 2009
Alastair Cunningham says:
True - but if you're using provisioning server for XenApp, you'll most likely be...True - but if you're using provisioning server for XenApp, you'll most likely be using a common disk image, in which case all writes are discarded on reboot, so you'll never be able to recover the memory dump after a BSOD even if the pagefile is on the system drive
Apr 21, 2009
Anonymous says:
I have been redirecting the page file and event logs to a local physical disk or...I have been redirecting the page file and event logs to a local physical disk or in the case of virtual machines to a local virtual disk. I have found this configuration to provide the best performance.
Apr 23, 2009
Anonymous says:
Daniel, Thanks for the great blogs, but as someone getting into this technology...Daniel,
Thanks for the great blogs, but as someone getting into this technology (PVS and XenApp), how do you address the SPOF of the PVS? Will you be adding the HA deployment of PVS as a future topic?
Keep up the good work!
NB
Apr 23, 2009
Daniel Feller says:
I can definately add that as a future topic, but just so you aren't waiting arou...I can definately add that as a future topic, but just so you aren't waiting around for it, the short answer is that PVS has a HA option. If a PVS server fails, all target devices will re-establish to other PVS servers within the PVS farm.
Daniel
Nov 16
Anonymous says:
Although this is kind of an older topic, one reason we are considering placing t...Although this is kind of an older topic, one reason we are considering placing the PageFile on another disk is so that all the PageFile IO utilizes the HyperVisor's storage network. If the PageFile is on the vDisk, then all the PageFile IO will go through the provision server's network cards.
For example, if we deploy 500 XenDesktops via PVS, and they all have a D:\ on iSCSI volumes spread across 10 HyperVisor's with 2 iSCSI nic's per server, you are spreading the PageFile IO across 20 iSCSI nic's, instead of 2-4 PVS server network traffic nic's. It also isolates the PageFile IO on your iSCSI switching fabric instead of that traffic running across your production LAN.
Anonymous says: