Red Hat Bugzilla – Bug 848649
RFE: expose disk space settings on TUI installation
Last modified: 2016-04-26 11:19:22 EDT
Created attachment 604797 [details]
Disk space message captured via drac
Description of problem:
When installing ovirt-node on a Dell R720 server using the internal dual SD module (mirrored 2gb SD cards designed to run hypervisors), I am told I have not enough space and 67211MB is required.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot Install CD
2. Attempt to Install
I am told 65+ GB is required to install rather then 65+ MB and the install fails
Dell R720 server - hypervisor configuration (no disk arrays, boot from redundant SD cards).
This is really notabug.
It's the automatic calculation of the swap space that causes the problem. You can change this using a combination of kernel commandline paramaters.
Swap size is determined by the following formula
SWAP = BASE_SWAP + OVERCOMMIT * RAM
BASE_SWAP is determined with:
if RAM < 4GB;
BASE_SWAP = 2048MB
elif RAM < 16GB;
elif RAM < 64GB;
OVERCOMMIT is defined as .5 by default
You can override the amount of swap by setting mem_overcommit or storage_vol on the kernel command line.
storage_vol will allow you to set the size of SWAP to a static amount (but >= 5MB)
Additional Disk space required:
256MB for boot parition (either EFI or basic BIOS)
512MB for ROOT and ROOTBACKUP (2x256 MB partitions)
8MB for Config partition (can be reduced, but not recommended)
2GB for Logging (can be reduced using storage_vol)
There is also a data partition that should exist and be at least 200MB to support in place upgrades. It will, by default, take up the remainder of you storage.
These settings are currently not exposed on the TUI during installation, so I will make this an RFE for a future version.
Sorry about jumping the gun, The size seemed too large (and around an order of magnitude from what I expected, I actually expected something to be reporting in KB when it was expecting bytes).
While I can definitely see value in being able to tweak those values from the node installer tui, I wonder if it would be better for the general use case to make the installer default to work back from the storage size. I can see why allocating a massive amount of SWAP is worthwhile if your running in a server with disks, however I think that if the workload isn't going to be overcommitted then I think it makes sense to be able to install on a device of that size.
For example w/ 2GB of storage :
256 MB boot
256 MB ROOT
256 MB ROOTBACKUP
8 MB CONFIG
256 MB LOG
512 MB SWAP
(In reply to comment #2)
> Sorry about jumping the gun, The size seemed too large (and around an order
> of magnitude from what I expected, I actually expected something to be
> reporting in KB when it was expecting bytes).
> While I can definitely see value in being able to tweak those values from
> the node installer tui, I wonder if it would be better for the general use
> case to make the installer default to work back from the storage size. I can
> see why allocating a massive amount of SWAP is worthwhile if your running in
> a server with disks, however I think that if the workload isn't going to be
> overcommitted then I think it makes sense to be able to install on a device
> of that size.
> For example w/ 2GB of storage :
> 256 MB boot
> 256 MB ROOT
> 256 MB ROOTBACKUP
> 8 MB CONFIG
> 256 MB LOG
> 512 MB SWAP
> REST DATA
Yes, and you can do that if that's you're scenario with the storage_vol parameter:
This will override the SWAP and LOG partition sizes. By default, in ovirt engine, overcommit is enabled, which brings a requirement for swap on the server side. If you're disabling overcommit in the engine, then feel free to reduce the swap partition size on ovirt-node.
oVirt Node Hypervisor 2.5.999-999.201210101948.fc17
│ Please enter the sizes for the following partitions in MB │
│ UEFI/Bios: 256_______ │
│ Root & RootBackup: 256_______ (2 partitions at 256MB each) │
│ Swap: 39________ │
│ Config: 500_______ │
│ Logging: 2048______ │
│ Data: 100_______ │
│ <Quit> <Back> <Continue> │
This bug has been fixed in the 2.6.0 release of ovirt-node, which is now available on both ovirt.org and in Fedora 18