I did a recovery point installation last year that was similiar to this. We did not use SRS but were replicating using recovery point across two Clarion SANS in different states. Dependant upon the type of server that you are replicating (SQL, Application, Citrix etc.) moving the swap volumes to a non replicated LUN can result in a huge difference in total replicated volume. In our case upwards of 60% on certain servers. I believe it was over 80% on one Citrix server. Given the cost savings and bandwith savings I believe the overhead for moving the guest OS swap volume is probably warranted for most people - even though that requires a much more detailed setup of the guest and significantly more admin overhead time when spinning up a new OS

Think about it, a single windows guest brought online with swap on the local c: drive may generate over 8 gigs of data to be replicated just during it's install or setup process before it's even online to users.

We were not using DRS so on the far side we were bringing the guest OSes back online manually. If I recall correctly if you bring windows up and it can't find it's associated swap volume it simply re-creates a default one on the C:\ volume. So you may not have to replicate the swap volumes at all - as long as you leave enough room on the c:\ volume for the swap to be brought back there in case you fail over. Although it MIGHT have taken two boot processes for the guest to come up this way. In my instance since the guests were brought back online manually in the DR facility booting it twice was not an issue. But I would suggest you experiment with bringing it back up without it's designated swap volume and see what the results are - I don't really remember.

That being said, and given the bandwith savings that equal significant dollars moving swap out of the OS volume generates I think customers should start pushing VMWARE for a truly automated solution for this issue. It should be very easy to automate relocation of the windows swap volume through VMWare Tools or even perhaps at the virtual hardware level.

There needs to be a truly automated and proper management function for this issue. Particularly when dealing with Windows as it can be very difficult to prevent Windows from swapping.

Looking at the big picture the following server types:
Database Servers do mostly reads - most database servers do far more reads than writes after all we look at information more often than we create new info. This means lots of swap
Application Servers (Citrix, MS TS etc.) - Swap is the single biggest bottleneck for many applications on Terminal Services or Citrix
Business Rules Servers - Swap again is often the biggest bottleneck

For all these types of servers swap is a huge bottleneck and usually represents the single largest quantity of disk IO in the guest overall. And is certainly the highest amount of IO on the c:\ volume.

I would think it would be easy enough to create a feature in VMWARE that allows delegation on the SAN of a given LUN as a SWAP file sandbox. Then either by altering the OS through VMKTools or intercepting data as it goes through the virtual hardware it would be possible to redirect this data out into that sandbox. That sandbox could then be simply ignored from a backup and or replication standpoint.

Then in virtual center it would be easy enough to build an interface to designate for which OSes to redirect the swap file. Of course this would affect VMOTIONS etc. so it would not be a simple change, but given the amount of bandwith saved during replication I think such a feature would be a significant cost benefit to most customers.

There are actually multiple levels of cost savings. First there is no reason to include swap in snapshots etc or daily backups. Moving swap files out to a sandbox would save on disk overhead for any of these types of functions. Then when using replication such as SRS you add in the significant bandwith savings of eliminating potentially huge amounts of replication. This could easily have an ROI to a truly large organization of multiple hundreds of thousands of dollars per year.

If I remember correctly, that if Windows "loses" it's swap volume it attempts to boot, displays an error that it will default swap back to c:\ and then comes up just fine. But it has been a year. In the case of the client I was working with they decided this was acceptable as they intended to semi-manually bring guests back online via scripting after a failover event. This was before the fully automated SRS solution was available.

In their case they did not have the bandwith to replicate the Guest OS if they attempted to replicate swap as well. They could only replicate the data volumes on a real time basis. By removing the swap files they did have enough bandwith to replicate the OS volumes as well.