Hide Forgot
1. What is the nature and description of the request? Following up a discussion the support for the Q35 chipset will not be available for RHEL6 guests (at least hot-(un)plug features won't work due to missing virtio 1.0 drivers. As such some support-matrix OS - Chipset is needed. Best case would be to implement this matrix into the engine as well to avoid "bad" combinations. 2. Why does the customer need this? (List the business requirements here) This is for customer experience of the product. Not being able to select non working combinations and get warnings about limitations will definitely increase the product experience. Having this matrix at least in the documentation will be a first needed step at least. 3. How would the customer like to achieve this? (List the functional requirements here) - Document the OS - Chipset - Requirements/Restrictions matrix in RHV documentation. - Implement this matrix in the Engine, so that warnings pop up for bad combinations and disable not working combinations. 4. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. - During creation of virtual machines, a warning should be displayed when creating "Bad" combinations (could be some exclamation mark that reveals additional information on Mouseover, e.g) - Deny combinations that we don't support or are not working anyways. 5. Is there already an existing RFE upstream or in Red Hat Bugzilla? No. 6. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? As Q35 is planned for RHV 4.1 this should be implemented for RHV 4.1 7. Is the sales team involved in this request and do they have any additional input? No 8. List any affected packages or components. - Documentation - engine / Web-UI
This bug had requires_doc_text flag, yet no documentation text was provided. Please add the documentation text and only then set this flag.
Is this a docs bug or a functional bug? Do we need to split it?
Hi Yaniv, (In reply to Yaniv Dary from comment #2) > Is this a docs bug or a functional bug? > Do we need to split it? first of all this is a documentation bug, as not all virtual hardware will be PCIe enabled from the beginning (which is a functional mismatch). To introduce a smooth experience, we should document the non-hotplug-able devices for Q35 chipset, especially if the devices are hotplug-able with the i440FX chipset. Please check with Marcel about the to be documented matrix. @Marcel: Do you also need a funtional bug for the missing PCIe devices?
(In reply to Martin Tessun from comment #3) > Hi Yaniv, > > (In reply to Yaniv Dary from comment #2) > > Is this a docs bug or a functional bug? > > Do we need to split it? > > first of all this is a documentation bug, as not all virtual hardware will > be PCIe enabled from the beginning (which is a functional mismatch). > > To introduce a smooth experience, we should document the non-hotplug-able > devices for Q35 chipset, especially if the devices are hotplug-able with the > i440FX chipset. > > Please check with Marcel about the to be documented matrix. > @Marcel: Do you also need a funtional bug for the missing PCIe devices? Hi Martin, Can you please be more specific, what are the missing PCIe devices? Thanks, Marcel
Wouldn't this make more sense in the RHEL docs?
(In reply to Marcel Apfelbaum from comment #4) > > Hi Martin, > Can you please be more specific, what are the missing PCIe devices? > > Thanks, > Marcel Afaik we discussed that not all devices available for i440fx chipset are already "migrated" for being PCIe devices. As such these devices would not be hot plugable, as they can only be attached to the PCIe root port (as we don't want to have a PCI-PCIe bridge). So more or less we need a matrix of what devices will be hot pluggable with Q35 and which ones are hot pluggable with i440fx chipset. (In reply to Yaniv Dary from comment #5) > Wouldn't this make more sense in the RHEL docs? Well, RHEL will not support Q35 chipset, so I believe it should be documented separately and should be linked to RHV and probably OSP documentation.
(In reply to Martin Tessun from comment #6) > (In reply to Marcel Apfelbaum from comment #4) > > > > Hi Martin, > > Can you please be more specific, what are the missing PCIe devices? > > > > Thanks, > > Marcel > Hi Martin, > Afaik we discussed that not all devices available for i440fx chipset are > already "migrated" for being PCIe devices. As such these devices would not > be hot plugable, as they can only be attached to the PCIe root port (as we > don't want to have a PCI-PCIe bridge). > Only a minor correction, the legacy PCI devices can be plugged only into the Root Complex as Integrated Endpoints, and this is why they are no hot-pluggable. The PCIe Root Ports are used to plug PCI Express Devices and here we have native hotplug. > So more or less we need a matrix of what devices will be hot pluggable with > Q35 and which ones are hot pluggable with i440fx chipset. > All *PCI Express* devices are hot-pluggable in Q35, all PCI devices are not hot-pluggable because they are Integrated Endpoints. Side note: We also have hybrid devices (e.g. virtio) which are PCI when connected to Root Complex (Integrated Endpoints) and therefore not hot-pluggable, PCIe otherwise (connected to PCIe Root Ports) so hot-pluggable. The distinction is quite clear, I think. Thanks, Marcel > (In reply to Yaniv Dary from comment #5) > > Wouldn't this make more sense in the RHEL docs? > > Well, RHEL will not support Q35 chipset, so I believe it should be > documented separately and should be linked to RHV and probably OSP > documentation.
Do you have a bug on RHEL docs to block this bug on?
Hi Yaniv, (In reply to Yaniv Dary from comment #8) > Do you have a bug on RHEL docs to block this bug on? did have a look at RHEL doc bugs. There is no such bug as of now. Please let me know, if you need one, so I would open one. Cheers, Martin
Restoring needinfo until the info is provided.
Hi Yaniv, as q35 is not supported in RHEL qemu afaik there is no BZ open for that. So we probably need to get that matrix from Marcel. Changing the needinfo to him, to provide the needed information (also he can correct me, if my above statement is wrong).
(In reply to Martin Tessun from comment #11) > Hi Yaniv, > > as q35 is not supported in RHEL qemu afaik there is no BZ open for that. So > we probably need to get that matrix from Marcel. > Hi, Indeed Q35 is not supported in RHEL, only in RHEV. > Changing the needinfo to him, to provide the needed information (also he can > correct me, if my above statement is wrong). Regarding the list of hot-pluggable devices for Q35. 1. All devices cannot be hot-plugged into Root Complex (pcie.0 bus). If we attach them at command line, they cannot be hot-unplugged. 2. We support PCI devices only as Integrated Endpoints (Root Complex), so we don't have hotplug here either. (DMI-PCI bridge/PCI bridge are not supported for now, and probably we will not support them in the future. We are thinking about a PCIe-PCI bridge, but we are not there yet) 3. All PCIe devices are hotpluggable if connected to PCIe Root Ports (or switches, but we don't encourage switches usage at this point) Device types: 1. PCI only - most of the existing devices 2. PCIe only - e1000e, maybe a few others 3. Hybrid devices - devices that will be PCI if connected to Root Complex (or PCI buses), PCIe if connected to PCIe Root Ports: - virtio modern devices - usb controller - (I hope I didn't forget anything) Thanks, Marcel
Verified and merged.
Updated article: https://access.redhat.com/articles/3201152 Updated documents: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/technical_reference/#System_Devices https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/planning_and_prerequisites_guide/#host-requirements