On Mon, Mar 14, 2011 at 5:24 PM, Nataraj incoming-centos@rjl.com wrote:
I have a kvm virtual host running on what will become CentOS 6 with 12GB of memory and a Quad Xeon X5560 2.8Ghz . The store for virtual machines will be a software raid 6 array of 6 disks with an LVM layered on top. I'm not initially planning any major overcommitment of resources, though there could be a need for some overcommitment with a light workload on the guests.
In recent years people seem to configure a wide range of different swap allocations. I was thinking initially to spread swap across seperate non-raid partitions on 4 of these disks, but the downside of that is if I put 2gb on each disk, then I can only swap processes that will fit in 2gb swap space. Also, if one of the disks fails, I have to reboot if anything was swapped to that drive.
My questions are as follows:
What experience are others having with putting swap space on raid partitions? I was thinking about maybe swapping on a raid10 device, otherwise an LVM spanning multiple drives. In practice, what kinds of swap allocation are people finding useful for a kvm virtual host of this size?
I definitely don't want a system that is so overcommited that performance is impacted, but if some overcommitment is reasonable for VM's that have light workload, then I consider that. I can increase system resources when that becomes necessary.
Nataraj
I recommend against using any type of parity-based RAID (5 or 6) for any workload, period. RAID10 is the only way to go for everything these days. VMs often run into IO issues, and RAID[56] is going to make that problem worse. Also, RAID10 in software shouldn't have much performance impact at all, as opposed to RAID[56] which will have a big load in software.
I wouldn't worry as much about swap, as others have said. Money spent adding another device for swap would be better spent on more RAM. However, I usually put swap on the same device as everything else. It might not strictly be best practice, but again, if you're hitting swap, you have bigger problems.