Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1062441 - [RFE] Provide ability to overcome ~300 instance effective limit on VM pools when using iSCSI or FC storage domain
Summary: [RFE] Provide ability to overcome ~300 instance effective limit on VM pools ...
Keywords:
Status: CLOSED DUPLICATE of bug 1081536
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.3.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Michal Skrivanek
QA Contact:
URL:
Whiteboard: virt
Depends On:
Blocks: 1066135
TreeView+ depends on / blocked
 
Reported: 2014-02-06 23:56 UTC by Simon Sekidde
Modified: 2015-03-31 09:57 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1066135 (view as bug list)
Environment:
Last Closed: 2015-03-31 09:57:01 UTC
oVirt Team: ---
scohen: needinfo+
amureini: needinfo-
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 441203 None None None Never

Description Simon Sekidde 2014-02-06 23:56:34 UTC
3. What is the nature and description of the request?
       As described in the RHEV 3.3 Technical Reference Guide, chapter 11.4, iSCSI and FCP Storage Domains have a performance limit of ~350 disks,
       due to overhead from large LVM metadata. Because a pool is connected to a single storage domain, this limit effectively constrains the size of
       the pool. When using non-persistent desktops, this number is even smaller (according to information provided by RHEV engineering), due to the
       use of snapshots. Some method should be provided to allow pools to overcome this limit, allowing for pools with iSCSI/FC storage domains to
       grow much larger.
      
    4. Why does the customer need this? (List the business requirements here)  
       Customer is deploying RHEV on IBM Pureflex, which has an integrated fiber channel SAN.
       They are looking to deploy roughly 1600 virtual desktops per Pureflex.  
       The variety of their desktops is fairly limited; a few pools would functionally suffice. 
       It is quite possible that all 1600 users will all be using the same exact desktop image, so a pool that can support 1600 instances would be
       sufficient. However, if desktop density is shown to be greater than expected due to power processors and memory overcommit, this number could
       be larger than 1600.

    5. How would the customer like to achieve this? (List the functional requirements here)  
       The method is loose -- I can imagine mulitple hypothetical ways to overcome this limit:
       * Create a single LUN and format it with GFS2, containing the desktop template used by the pool, and shared by the 14 hypervisors in a
          Pureflex.
       * Allow a pool to have multiple assinged storage domains that are used serially or round-robin, such that 5 SDs each with a limit of 300
          guests could used for a pool of size 1500
       * Fix the LVM metadata performance bottleneck, to allow higher limits
      
    6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully
       implemented.  
       Success will be validated by ability to create a pool of 1000 guests, or larger, and to not have the performance impact indicated in the
       documentation.
      
    7. Is there already an existing RFE upstream or in Red Hat Bugzilla?  
       Unknown

    8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?  
	The customer is in the early phases of a multi-year deployment that will eventually be several 10s of thousands of users. This is a highly
        strategic phase; the customer could still choose another product.
      
    9. Is the sales team involved in this request and do they have any additional input?  
	Yes -  this RFE is requested by the Solution Architect
      
    10. List any affected packages or components.  
	RHEV 3.2, 3.3.
      
    11. Would the customer be able to assist in testing this functionality if implemented?
	Yes, they would be very happy to test.

Comment 2 Ayal Baron 2014-02-16 10:59:25 UTC
You can create multiple storage domains in the same pool.
The limitation is 350 per storage domain, not per pool.
I'm not sure what is being requested here? (unless we're discussing lifting the lvm limitations in which case this bug should be against lvm).

Comment 4 Itamar Heim 2014-02-17 03:34:42 UTC
Simon - this RFE seems to be about enhancing the storage domain using LVM to perform better so it won't be limited to 300 disks per storage domain (which i think is worth keeping).

if relevant, can you please open a separate RFE to "support pools across multiple storage domains", so a pool could be created with more than 300 VMs, just using multiple storage domains?

Comment 5 Matt Smith 2014-02-17 18:54:40 UTC
Customer is looking for functional solution, does not care too much about method of implementation.

Goal: Use FC storage, be able to create a desktop VM pool with 1000+ plus guest instances.

If the recommended functional solution is to support VM pools across multiple SD, then that should be sufficient.

Comment 7 Ayal Baron 2014-02-17 22:24:15 UTC
The misunderstanding was around the word 'pool'.
The requirement here is to be able to provision a VM pool on multiple storage domains.
A VM pool is created from a template.  the template can have copies of its disks on multiple domains (this is supported right now).
What we need to verify is that when creating a VM pool the user can choose which domains to use for provisioning the disks of the VMs.
In this way the user could create multiple pools from the same template but on different storage domains and effectively bypass the limitations.

A possible enhancement (definitely not supported atm) would be to provision a single vm pool with pool VMs created on multiple domains (allow user to choose per disk how many would be created on each domain).

Comment 8 Matt Smith 2014-02-17 22:33:31 UTC
Correct - and one more functional point, just to clarify the word "user":

* It is acceptable for the RHEV Administrator to see the "rough edges" of having multiple storage domains,

* The consumer of the VDI service should only see a single VM pool in the User Portal, and the selection of which storage domain will contain this user's instance must be kept completely invisible from this consuming user.


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