Bug 2141534
| Summary: | Can't launch uefi volume and image as instance on OSP17 | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | mxie <mxie> |
| Component: | openstack-nova | Assignee: | OSP DFG:Compute <osp-dfg-compute> |
| Status: | CLOSED DUPLICATE | QA Contact: | OSP DFG:Compute <osp-dfg-compute> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 17.0 (Wallaby) | CC: | alifshit, chhu, dasmith, eglynn, hongzliu, jhakimra, jparker, juzhou, kchamart, lersek, mzhan, rjones, sbauza, sgordon, tyan, tzheng, vromanso, vwu, xiaodwan |
| Target Milestone: | --- | Keywords: | Regression, TestBlocker |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | V2V_OSP_INT | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-02-07 00:40:21 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: | |||
|
Description
mxie@redhat.com
2022-11-10 06:42:37 UTC
Do we believe this is a regression in nova itself which has nothing to do with virt-v2v, but affects virt-v2v? Hi, Rich. We needed two fixes here; one in OSP, one in RHEL. Both are available. In short, these are the versions to be used: - openstack-tripleo-common-15.4.1-0.20221114190240.51f6577.el9osttrunk - edk2-20220126gitbb1bba3d77-3.el9_0.1 Context ------- The firmware descriptor files, "50-edk2-ovmf-amdsev.json" and "50-edk2-ovmf-cc.json" shipped as part of "edk2-ovmf" RHEL package hard-codes "pc-q35-rhel8.5.0"; and didn't have 9.0 machine type. That is now fixed as part this[1] and this 9.0.0.z clone[2] in RHEL. And this patch[3] one in the installer tool, TripleO. I'm not 100% sure if [3] is required. I'll ask OSP QE, James. He verified a similar bug[4] recently. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2090752 -- Add RHEL 8.5, 8,6 and 9.x machine types to firmware descriptor files 50-edk2-ovmf-{amdsev,cc}.json [2] [rhel-9.0.0.z] clone pf [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2109988 [3] https://code.engineering.redhat.com/gerrit/c/openstack-tripleo-common/+/426556/ -- Update ovmf-amdsev from ovmf-cc to boot UEFI VMs [4] https://bugzilla.redhat.com/show_bug.cgi?id=2109644#c7 -- [RHOS 17] UEFI guest deployment fails due to UEFINotSupported exception. (In reply to Kashyap Chamarthy from comment #3) > Hi, Rich. We needed two fixes here; one in OSP, one in RHEL. Both are > available. > > In short, these are the versions to be used: > > - openstack-tripleo-common-15.4.1-0.20221114190240.51f6577.el9osttrunk > - edk2-20220126gitbb1bba3d77-3.el9_0.1 > > Context > ------- > > The firmware descriptor files, "50-edk2-ovmf-amdsev.json" and > "50-edk2-ovmf-cc.json" shipped as part of "edk2-ovmf" RHEL package > hard-codes "pc-q35-rhel8.5.0"; and didn't have 9.0 machine type. That is > now fixed as part this[1] and this 9.0.0.z clone[2] in RHEL. And this > patch[3] one in the installer tool, TripleO. I'm not 100% sure if [3] is > required. I'll ask OSP QE, James. He verified a similar bug[4] recently. James: if you wanted add anything extra here, please go ahead. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2090752 -- Add RHEL 8.5, 8,6 > and 9.x machine types to firmware descriptor files > 50-edk2-ovmf-{amdsev,cc}.json > [2] [rhel-9.0.0.z] clone pf [1]: > https://bugzilla.redhat.com/show_bug.cgi?id=2109988 > [3] > https://code.engineering.redhat.com/gerrit/c/openstack-tripleo-common/+/ > 426556/ -- Update ovmf-amdsev from ovmf-cc to boot UEFI VMs > [4] https://bugzilla.redhat.com/show_bug.cgi?id=2109644#c7 -- [RHOS 17] UEFI > guest deployment fails due to UEFINotSupported exception. I believe that covers it Kashyap, looking at the failure logs for this BZ compared to [1], this looks to be a duplicate of [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2109644#c3 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2109644 (In reply to Kashyap Chamarthy from comment #3) > Hi, Rich. We needed two fixes here; one in OSP, one in RHEL. Both are > available. > > In short, these are the versions to be used: > > - openstack-tripleo-common-15.4.1-0.20221114190240.51f6577.el9osttrunk > - edk2-20220126gitbb1bba3d77-3.el9_0.1 > Sorry, I don't understand what I need to do, by the way, the versions of the above packages in my OSP17.0 are: openstack-tripleo-common-15.4.1-0.20220705010409.51f6577.el9ost.noarch edk2-ovmf-20220126gitbb1bba3d77-3.el9_0.1.noarch (In reply to mxie from comment #6) > (In reply to Kashyap Chamarthy from comment #3) > > Hi, Rich. We needed two fixes here; one in OSP, one in RHEL. Both are > > available. > > > > In short, these are the versions to be used: > > > > - openstack-tripleo-common-15.4.1-0.20221114190240.51f6577.el9osttrunk > > - edk2-20220126gitbb1bba3d77-3.el9_0.1 > > > > Sorry, I don't understand what I need to do, by the way, the versions of the > above packages in my OSP17.0 are: > > openstack-tripleo-common-15.4.1-0.20220705010409.51f6577.el9ost.noarch > edk2-ovmf-20220126gitbb1bba3d77-3.el9_0.1.noarch @jparker Can you please provide testing guidance to mxie, here? The BZ tracking is tracking two fixes landing as Kashyap mentioned earlier. The fix for edk2-ovmf should already be present in current puddles but the other change [1] for tripleo-common has yet to land. This BZ [2] is currently tracking the overall status of both and is in MODIFIED state, so both fixes should land in the next phase3 puddle. If testing is urgent you can unofficially verify this by applying [1] to the Undercloud and redeploying or you can wait until [2] is ON_QA and redeploy/retest with the associated puddle. [1] https://review.opendev.org/c/openstack/tripleo-common/+/855142/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2109644 Hi mxie, does James' answer in comment#8 provide enough info for you to test? (In reply to Kashyap Chamarthy from comment #9) > Hi mxie, does James' answer in comment#8 provide enough info for you to test? Yes, I will continue to do v2v testing on OSP17.1 recently, I think fixed packages will be included in OSP17.1 env, thanks! *** This bug has been marked as a duplicate of bug 2109644 *** |