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.
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).
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?
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.
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).
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.