\[VI3 & ESX 3.0.1. Shared iSCSI storage for use with VMotion. 1 large VMFS volume for 7 VMs]
Is it possible to store VMs' .vwsp files in a different location (i.e. another store) to their .vmdk files? If it is, is there a recommendation for the maximum number of .vswp files per volume before performance starts to slide?
I've provisioned my VMFS LUN for 7 x 25GB VMs + the amount of RAM in my ESX cluster (for swap space - we don't overbook RAM) + a bit of extra space for config files.
If I grow the physical RAM in my cluster or start overbooking RAM then I'll need to extend the VMFS volume, but only by a small amount (e.g. by 4GB for each ESX host upgraded). This means creating a very small LUN and adding it as an extent.
Alternatively, copying the existing volume to a new LUN is possible now becuase I have plenty of free space on my filer, but may not be in the future.
If I could move the .vswp files out to a separate VMFS & LUN than (a) the main VMFS volume can be left alone to store only VMs and (b) the new "SWAP" volume would be much smaller & much easier to copy to a new, larger LUN & VMFS volume if the ESX RAM was upgraded again.
.... or am i doing this all wrong?
Thanks in advance.... ![]()
DrS
Hello,
Yes it is....
In the .vmx file is an option named sche.swap.derivedName... You can change its value.
However, I recommend you leave it where it is. If you need to add more VMFS, consider adding another LUN. Growing a LUN is not recommended. Thereby you can balance your VMs across multiple LUNs which depending on your SAN could get you better overall performance.
Best regards,
Edward
Yes it is....
In the .vmx file is an option named
sche.swap.derivedName... You can change its value.
Cheers - I'll give it a go!
However, I recommend you leave it where it is. If you
need to add more VMFS, consider adding another LUN.
Growing a LUN is not recommended. Thereby you can
balance your VMs across multiple LUNs which depending
on your SAN could get you better overall
performance.
yup, i found a way of growing a LUN & adding the new space to VMFS as a new extent, but VMWare hid it well (had to use Linux cmd line tools), but haven't done it in production just in case...
Splitting VMs across LUNs won't help at the filer level as the LUNs are all on the same disks, but splitting them across VMFS volumes will reduce VMFS contention & SCSI locks.
I had planned to keep servers for particular projects on "project" LUNs & VMFS vols, unless performance issues or differing filer snapshot requirements cropped up, that way i keep the number of VMs per volume down & don't end up provisioning lots of "per VM" volumes with slack space to cope with RAM expansion or fewer very large volumes with too many VMs on them.
Slack space is an issue - once it's allocated to the VMFS LUN I can't get it back again without creating a new smaller LUN, copying data & destroying the original, which may not be possible if disk space is low. I thought the separate .vswp volume would reduce the problem to a manageable level by changing it to "resize the small .vswp volume" instead of "resize the volume with 5+ VMs + .vswp files".
It's be so much easier if VMFS could grow to use new free space in the same way as NTFS in win2k3 - i could then expand the LUN by 8, 16, etc GB and have VMFS grow too, without messing about with extents.
Maybe VMFS4 will do this......
DrS
i did it using fdisk & vmkfstools, both of which have good "man" entries.
It's NOT supported by VMWare & I REALLY wouldn't do it in a production environment. I just did it to see if I could ![]()
DrS
Doh! you can't mark an answer as "correct" if you've already marked it as helpful.
Short answer: yes.
Sure you can, you're allowed 2 Helpful's and 1 Correct for every topic. These can be applied at any time and in any order.
I have the vswp location documented here...
