RHEV-H 3.y - swap allocation
Hi
I have a question around the automatic allocation of swap partition during the RHEV-H installation.
According to the documentation, the amount of swap configured at build is determined by the following calc :- (physical mem x 0.5) + 2,4,8 or 16G - depending on amount of phys mem
For my new system with 256G of physical memory the result would be :-
(256 x 0.5) + 16 = 144G swap partition
Baring in mind that KSM is taking very good care of memory overcommit at the VM level, why does the installer insist on configuring such a huge swap partition ?
I understand it very bad news to have memory pages allocated to a VM in swap, especially when it comes to live migration, but its I would think it unlikely that a RHEV Hypervisor configured to allow 150% memory optimisation would start paging.
Thanks
Responses
Hi Richard,
You can change the swap size manually if you don't like the defaults. We use a very simple formula to calculate the partition sizes, and it can sometimes be a bit strange, especially on hosts with more RAM than the size of the internal SSD drive for example.
The formula is not set in stone, and you definitely can have less swap than what is suggested by the installer, The swap size is really up to you, if you never expect to overcommit RAM, you can easily set it to a smaller value.
Thing is, while you never want to get into swap, you still are better off swapping than running out of RAM completely. So this is all down to the sizing of the setup as you plan it
(and didn't we talk about this at the summit?)
Guru
2354 points
Dan
We did indeed speak about this in Boston, and yes I did take note ;) I just wanted to open the topic to the wider audience.
So, we can define our own swap partition size by using the "storage_vol" kernel parameter defined in a PXE/kickstart file or at RHEV-H interactive installer ? Correct ?
Thanks again
It's all in the guides: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Hypervisor_Deployment_Guide/sect-Deployment_Guide-RHEV_Hypervisor_Kernel_Parameters_and_Automated_Installation-Storage_parameters.html
The format is storage_vol=:SWAP::CONFIG:LOGGING:DATA
example 4.6 shows how simple it is
Guru
2354 points
On this subject of hypervisor swap, I've come across this in rhevm-config :-
BlockMigrationOnSwapUsagePercentage: 0 version: general
The comment for this seems to imply that the number is a percentage of swap that a hypervisor is allowed before live migrations to it are not permitted. The default value is 0.
Does this mean that ANY usage of swap on the hypervisor will prevent live-migrations to it ?
Thanks
This option defines the maximum percentage of swap on the host that a VM run or migration is allowed on this host. If the host is swapping beyond this percentage a VM will not migrate over and will not be started. So with 0 preset, incoming migrations and VM starts on the swapping host will be blocked. You really don't want VMs on a swapping host anyway, but you can tweak if you must
Guru
2354 points
Dan
Is there someway we could define a separate device to become the swap instead of all on one ?
Let me paint a picture..
We deploy the blackbox RHEV Hypervisor on blades with 256G mem. We take the option of two drives on each blade configured RAID1 for the hypervisor install including its swap device. The blades now come with the option of internal microSD ram to act as the boot device which is WAY cheaper and far more energy efficient than spinning disks but of course you can't buy SD ram large enough to include the required swap.
It would be nice if we could split out the swap device upon installation and drop it on a seperate device, a tier3 thin prov'd SAN lun for instance.
This is of course that deployment of RHEV-H onto mircoSD is supported !
Just a thought.
First of all, the deployment of RHEV-H on a USB/SD drive is supported and works just fine. The swap size can be tweaked (see hypervisor deployment guide). As for pointing the swap at a specific device, I'll need to check that, since I'm not sure it's currently possible (but it can be a nice RFE)
Hi Richard,
There are actually 2 ways to accomplish what you're looking for, though neither is exactly what you want.
Assumptions:
/dev/sda -> microsd card
/dev/sdb -> other storage (san, etc...)
Option 1: Install across multiple disks
In the TUI installer, choose the microsd card in the first screen, then all the disks on the second screen. This will spread the HostVG volume group across the SD card and the additional storage you have.
If you're using auto-install, just pass all the devices in a comma separate list in the storage_init parameter:
storage_init=/dev/sda,/dev/sdb
Option 2: Use AppVG
This does not work through the TUI. It only works through the auto-install process. You need to pass the following options on the command line:
storage_init=/dev/sda;/dev/sdb #note the semi-colon, not comma here
storage_vol=:5:::::SWAP_SIZE_MB
The storage_vol parameter will tell the installer to make the Swap lv on the microsd card 5MB (you can't disable it completely). The SWAP_SIZE_MB should be 148000 (.5*ram) + BASE = .5*256GB + 16GB = 144GB =~148000 MB
BASE is calculated as:
Guru
2354 points
Awesome Mike, thanks for that.
Doesn't look like an impossible prospect to have swap somewhere else.
I'll have a play around with your options and get an RFE into the system as Dan suggests.
Thanks again
Our TAM just pointed me to this discussion, as we had a similar question.
It's good to learn that the default behavior can be overridden by various methods. But that doesn't change my opinion that the RHEV defaults for swap space (and for logging space) are unreasonably high.
I have an RFE here: instead of having customers calculate the amount of required swap space based on physical RAM and envisaged overcommit policy, why not simply take the customer-configured swap size and use it to calculate the highest possible memory overcommit ratio?
There is no calculation needed on the Customer's side. This happens automatically. If you don't have enough space for the calculated swap, then simply specify what you want for swap.
The plan to fix this is 2-fold.
1. Add TUI screens to set the values for Swap and other partitions.
2. Add the ability to move swap to a separate disk.
As for the overcommit ratio, that would be a RHEV-M RFE. We default to .5, but that is changeable on the command line (and possibly on the TUI in the future).
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.