Bug 1474519
Summary: | [RFE] Allow PXE boot for SHE VM appliance deployment | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Marina Kalinin <mkalinin> |
Component: | ovirt-hosted-engine-setup | Assignee: | Yaniv Lavi <ylavi> |
Status: | CLOSED WONTFIX | QA Contact: | meital avital <mavital> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.1.4 | CC: | dfediuck, lsurette, smaudet, ykaul, ylavi |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | Flags: | lsvaty:
testing_plan_complete-
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-10-26 12:28:39 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marina Kalinin
2017-07-24 20:34:36 UTC
Removal of PXE boot has been requested with bug #1366183 in 4.1. I don't think we're going to re-add it in 4.2. Yaniv? I do not see direct reason to remove PXE boot for the appliance from that bug. It can be still the appliance, provided by PXE. (In reply to Marina from comment #2) > I do not see direct reason to remove PXE boot for the appliance from that > bug. > It can be still the appliance, provided by PXE. Marina, boot options where: cdrom, pxe, disk. where disk meant disk from appliance. the RFE was filled for removing cdrom and pxe from the list. YAniv, Sandro, I can understand why we don't want to maintain this boot option, as it can just require unnecessary efforts of preparing the image for PXE and deploying a PXE server, then verifying that the image is actually the valid supported image by RH and SHE. But I would like to hear someone's else explanation why this flow is undesirable by design. Another use case for PXE that comes to my mind is when you need to troubleshoot the VM and boot it from liveCD. Or this is a flow that we do not need and each time there is a data corruption we assume we can just recreate the VM from backup and done? (In reply to Marina from comment #4) > YAniv, Sandro, I can understand why we don't want to maintain this boot > option, as it can just require unnecessary efforts of preparing the image > for PXE and deploying a PXE server, then verifying that the image is > actually the valid supported image by RH and SHE. But I would like to hear > someone's else explanation why this flow is undesirable by design. > Unlike mass deployment for hypervisors, there's only a single instance of the HE VM. So the whole point of mass deployment which PXE helps with is irrelevant in this case. More over additional setup flows are more likely to generate additional problems, than solving issues. For this reason bug #1366183 was requested and I see no reason to change the current status which provides a unified installation flow. > Another use case for PXE that comes to my mind is when you need to > troubleshoot the VM and boot it from liveCD. Or this is a flow that we do > not need and each time there is a data corruption we assume we can just > recreate the VM from backup and done? You have the appliance, so the only thing you need is- qemu-system-x86_64 -enable-kvm -hda /usr/local/vms/appliance.qcow2 -m 2048 -boot c -net nic -net tap,ifname=vm0,script=/bin/true If needed you add the cloud init sid which you'll need anyway. More examples available here: https://www.linux-kvm.org/page/RunningKVM Hi, I'm writing to ask if there is any update on this BZ. This PXE discussion is closed? or we need to proceed with the analysis? Thanks, Kind Regards, Santiago Maudet From my PoV: The image based installation is in no ways different to a PXE one (only difference: The packages are preselected). So all the things you need to apply for customization can be done the same way as they are done for PXE based installations. Just register the engine to your Satellite/Management system of choice and run the post setup steps for getting the system to the same state as all others. So I don't see any advantage providing more setup methods for the basic HE image, as it can be adjusted as needed after deploying the image. So I would suggest to close this RFE. Ack on the above, closing. |