Bug 848649 - RFE: expose disk space settings on TUI installation
Summary: RFE: expose disk space settings on TUI installation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-node
Version: 3.1 GA
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Mike Burns
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 825735
TreeView+ depends on / blocked
 
Reported: 2012-08-16 06:36 UTC by Jason Lawer
Modified: 2016-04-26 15:19 UTC (History)
7 users (show)

Fixed In Version: 2.6.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 13:38:13 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)
Disk space message captured via drac (22.97 KB, image/jpeg)
2012-08-16 06:36 UTC, Jason Lawer
no flags Details

Description Jason Lawer 2012-08-16 06:36:40 UTC
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):
ovirt-node 2.5.1-1.0-fc17

How reproducible:
Always

Steps to Reproduce:
1. Boot Install CD
2. Attempt to Install
3.
  
Actual results:
I am told 65+ GB is required to install rather then 65+ MB and the install fails

Expected results:
Install works

Additional info:

Dell R720 server - hypervisor configuration (no disk arrays, boot from redundant  SD cards).

Comment 1 Mike Burns 2012-08-16 10:28:52 UTC
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;
   BASE_SWAP=4096MB
elif RAM < 64GB;
   BASE_SWAP=8192MB
else
   BASE_SWAP=16384MB

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.

Comment 2 Jason Lawer 2012-08-16 21:09:40 UTC
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

Comment 3 Mike Burns 2012-08-16 23:13:48 UTC
(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:

storage_vol=:512:::256:-1

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.

Comment 4 Mike Burns 2012-10-12 20:49:50 UTC
http://gerrit.ovirt.org/#/c/8520/

                                                                                
    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>                               │

Comment 6 Mike Burns 2013-02-13 13:38:13 UTC
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


Note You need to log in before you can comment on or make changes to this bug.