Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1095423

Summary: nova: do not allow launch of instances with less than 512MB on memory
Product: Red Hat OpenStack Reporter: Dafna Ron <dron>
Component: openstack-novaAssignee: Nikola Dipanov <ndipanov>
Status: CLOSED NOTABUG QA Contact: Ami Jeain <ajeain>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.0CC: aberezin, eglynn, ndipanov, rbryant, sgordon, yeylon
Target Milestone: ---Keywords: Reopened
Target Release: 5.0 (RHEL 7)   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-09 16:48:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1095432    
Attachments:
Description Flags
logs none

Description Dafna Ron 2014-05-07 16:39:23 UTC
Created attachment 893388 [details]
logs

Description of problem:

I can create a flavor with 1MB of memory and launch instances.

since as far as I know we do not have any computers that run on less than 512MB (even that is rare today) I am not sure allowing less than 512MB should be allowed.

Version-Release number of selected component (if applicable):

openstack-nova-compute-2013.2.3-7.el6ost.noarch

How reproducible:

100%

Steps to Reproduce:
1. Run: nova flavor-create <name>  92  1 6 1
2. launch an instance from the flavor
3.

Actual results:

we can boot an instance which is 1MB in memory

Expected results:

we should not be able to run an instance with less than 512MB

Additional info:


[root@puma32 ~(keystone_admin)]# nova flavor-create Dafna_cli1 92 1 6 1
+----+------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+------------+-----------+------+-----------+------+-------+-------------+-----------+
| 92 | Dafna_cli1 | 1 | 6 | 0 | | 1 | 1.0 | True |
+----+------------+-----------+------+-----------+------+-------+-------------+-----------+

[root@puma32 ~(keystone_admin)]# nova show 8ff3a219-4119-4d54-b62e-1af85c743f09
+--------------------------------------+----------------------------------------------------------+
| Property | Value |
+--------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2014-05-07T16:33:00Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | puma32.scl.lab.tlv.redhat.com |
| key_name | None |
| image | two (014f76a0-fd5a-48b0-8fdb-e3e684efe7a3) |
| hostId | 6bd25fb14bba890fa4a8c2cd793ff056a9ae39dbddcebd683fee1f6b |
| OS-EXT-STS:vm_state | active |
| OS-EXT-SRV-ATTR:instance_name | instance-0000001a |
| OS-SRV-USG:launched_at | 2014-05-07T16:33:00.000000 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | puma32.scl.lab.tlv.redhat.com |
| flavor | Dafna_cli1 (92) |
| id | 8ff3a219-4119-4d54-b62e-1af85c743f09 |
| security_groups | [{u'name': u'default'}] |
| OS-SRV-USG:terminated_at | None |
| user_id | 81c761b68ebb423cb29312b8bede978a |
| name | dafna |
| created | 2014-05-07T16:32:54Z |
| tenant_id | 5502ab8e099843cfa39df71b3037ccd6 |
| OS-DCF:diskConfig | MANUAL |
| metadata | {} |
| novanetwork network | 192.168.32.3 |
| os-extended-volumes:volumes_attached | [] |
| accessIPv4 | |
| accessIPv6 | |
| progress | 0 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-AZ:availability_zone | nova |
| config_drive | |
+--------------------------------------+----------------------------------------------------------+
[root@puma32 ~(keystone_admin)]#

Comment 1 Nikola Dipanov 2014-05-09 14:16:00 UTC
So what is the bug here exactly - that the instance does not error out (it probably fails to boot the OS tho), or that we are allowed to create a flavor with less than 512 Mb of RAM?

If it's the former, it is really up to the user to pick flavors that are sufficient for their OSes to run on (this is ultimately really limited by the hypervisor, and the guest OS minimal limit where the latter is the one that is likely higher), so not sure what use is there for us to limit it in any way.

If it's the latter - I don't see why picking an arbitrary number like 512 would make any more or less sense than 1, or what the real benefit to the user might be.

We can re-open the bug if the above feels like it does not answer your concerns around this.

Comment 2 Dafna Ron 2014-05-09 14:25:26 UTC
A virtual system should imitate a real computer behaviour. 
since a real computer needs at least 512MB to boot we should keep this behaviour.

Comment 4 Stephen Gordon 2014-05-09 16:45:35 UTC
I am -1 on this proposal for two reasons:

1) 512 MB is *way* too high. qemu-kvm is capable of booting VMs down to 64 MB and potentially even lower. I also know from RHEV that we have customers that run cut down VMs at 128 MB, possibly lower.

2) I think it's unlikely this would be acceptable upstream. The default flavors are (much) larger than this and if an admin wants to define smaller flavors then they should be able to.

Comment 5 Arthur Berezin 2014-05-09 17:11:59 UTC
In addition, there are use cases where users would like to run instances with much less memory(embedded, etc'..) we should not limit this behavior