Dedicated vSwap LUN on Clariion storage?

[burjoes]

We have 8 ESXi 4.0 servers today, and are adding 8 4.1 servers right now - and will be upgrading the existing ones to 4.1. Our existing servers have a 200GB vSwap LUN each. I'm a new storage administrator with the company, and my background is working for Dell where I did mostly Windows design work. In the limited designs I did for VMware, I don't remember us recommending a dedicated LUN for vSwap. My memory is that dedicated vSwap LUNs are for Netapp boxes, who recommend that to avoid a penalty when doing replication. I've never heard that recommendation from EMC - but I haven't heard them NOT recommend it either.

So - when implementing ESXi 4.1 on Clariion, is it a best practice to use dedicated LUNs for each host's vSwap - or should we just put the vSwap on existing storage?

Thanks!

Jason Burroughs

[DCjay]

We use Clariion, though our infrstructure is very large. Host swap reside in the host.

[burjoes]

I should have mentioned - we are using UCS blades with no internal storage at all - we are booting to SAN. Not my choice, it was set up that way when I got here.

If I could start all over, I would start out with 2 x hard drives on each blade and do a small drive for OS. Are you suggesting in that config, you'd put the vSwap LUN on the internal drives? Maybe that's why I've never heard of people using dedicated LUNs - because we also didn't recommend boot to SAN...hmm

[depping]

it is not a best practice for Clariion to do this. However it could be useful for your environment when you have multiple tiers of storage or are doing for instance replication as you already noted. I prefer to keep it simple and just use the datastore the VM is stored on, especially for troubleshooting it will make your life a lot easier.

Duncan (VCDX)

Available now on Amazon: vSphere 4.1 HA and DRS technical deepdive

[Gleed]

In addition to the replication considerations, I've also seen people create dedicated vswap LUNs on lower tiered storage when they have many VMs with large amounts of memory and want to save space on their Tier 1 datastores.

Keep in mind there are VMotion implications when VM swap files are stored separate from the other VM files.  This is documented in the DC Admin Guide.

[mittim12]

We have a Clariion CX4-480 and we have always kept our swap files on the datastore with the VM.  I've never had a need to adjust the location and agree with Duncan about the simplicity of keeping it the default.

[Josh26]

Hi,

I'll second that the configuration you've got seems to mean far more administrative overhead for no gain from default.

I would suggest rather than having two local disks as your goal, consider Flash of CF cards. When you can get something for $20 it's often a budget you can sneak in without anyone else being involved :smileysilly:

[burjoes]

So it sounds like the consensus is that it's just not worth it to have dedicated vSwap LUNs. With 16 x servers, and 200GB dedicated LUNs, we are burning 3.2TB of storage - and we are using RAID 10, so that is 6.4TB of raw disk space for this. Also, using dedicated vSwap LUNs is one of two reasons (along with boot to SAN) that we use separate storage groups on the array, so removing the dedicated vSwap LUNs would ease the transition to a single storage group.

So, next question - what are the steps to transition from dedicated vSwap LUNs, should we decide to go that route?

Thanks,

Jason

[burjoes]

I was incorrect about it being RAID 10 - it is RAID 5. So at least it's not double the disk space being used. I'm still interested in a method to move the vSwaps off of dedicated LUNs and into the datastores though.

[Dave_Mishchenko]

There are two settings to look at.  First edit the settings for the cluster and select Swapfile Location.  You can choose between using a specific datastore and storing the swapfile with the virtual machine.  If you have the specific datastore setting chosen, then you also have to set the datastore to use.  Select a host and go to Configuration > Software > Virtual Machine Swapfile Location.