Created attachment 1858993 [details] image showing as rhel7 Document URL: https://docs.openshift.com/container-platform/4.7/installing/installing_vsphere/installing-vsphere.html#machine-requirements_installing-vsphere Section Number and Name: Describe the issue: In the document, it state that ""Note that RHCOS is based on Red Hat Enterprise Linux (RHEL) 8 and inherits all of its hardware certifications and requirements. However, when the latest image "rhcos-vmware.x86_64.ova" was downloaded from [1]. the image is showing as RHEL 7. Please see attached image. [1]: https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.7/latest/ Suggestions for improvement: Is this correct? Additional information: Attaching image for reference.
I'm not sure which team is responsible for building the ova template, maybe RHCOS team. Installer team doesn't own this, thanks.
I suspect that this is showing up as RHEL 7 as we have the following in the metadata: ``` <OperatingSystemSection ovf:id="80" ovf:version="6" vmw:osType="rhel7_64Guest"> ```
I downloaded the image from the URL mentioned above, converted it to a QCOW2 image and booted it and confirmed that we have RHCOS 4.7 in it: ``` $ cat /etc/os os-release ostree/ [core@cosa-devsh ~]$ cat /etc/os-release NAME="Red Hat Enterprise Linux CoreOS" VERSION="47.84.202109241831-0" ``` Thus this is likely only a metadata issue.
Thanks for the update team. Yes, it looks like a metadata issue only. I hope this would be resolved in upcoming release.
That value is set in <https://github.com/coreos/coreos-assembler/blob/a2cb5353c4503a14877ef6c9bb986598c58e8ea8/src/cosalib/ova.py#L68>. I'm not sure whether VMware treats the value as purely cosmetic, or whether it affects the enablement of certain virtual hardware features. The attached case does not report any technical impact from the unexpected value.
The complication about changing the value of the osType in the OVF is that the RHEL 8 guest OS type is only supported in vSphere 6.5u3 and newer. Additionally, it requires virtual hardware version 14 on the vSphere side. See these VMWare KBs: https://kb.vmware.com/s/article/67443 https://kb.vmware.com/s/article/67621 Older versions of OCP (i.e. OCP 4.7) support using vSphere 6.5 and virtual hardware version 13 when doing installs: https://docs.openshift.com/container-platform/4.7/installing/installing_vsphere/installing-vsphere-installer-provisioned.html#installation-vsphere-infrastructure_installing-vsphere-installer-provisioned If we were to retroactively change the the osType of the RHCOS OVA to reflect that it is a RHEL 8 guest, we could cause customers using older supported versions of vSphere to be unable to install OCP. In future versions of OCP, we will stop supporting versions of vSphere below 6.7u2 and virtual hardware version 13: https://docs.openshift.com/container-platform/4.9/installing/installing_vsphere/installing-vsphere-installer-provisioned.html#installation-vsphere-infrastructure_installing-vsphere-installer-provisioned So we may be able to change the osType of newer RHCOS OVAs, but will not be able to backport these changes to older versions of OCP/RHCOS.
Updating the summary of the BZ to reflect the actual problem/ask. @jcallen @rvanderp have either of you had a chance to experiment with changing the osType/hw version as we discussed in Slack? https://coreos.slack.com/archives/C011MLLLY4W/p1644589351858629
Hi Micah, Check out: https://github.com/coreos/coreos-assembler/pull/2740
This bug has been reported fixed in a new RHCOS build and is ready for QE verification. To mark the bug verified, set the Verified field to Tested. This bug will automatically move to MODIFIED once the fix has landed in a new bootimage.
$ ls rhcos-411.85.202205100541-0-vmware.x86_64.ova $ tar xvf rhco* coreos.ovf disk.vmdk $ cat coreos.ovf | grep rhel <OperatingSystemSection ovf:id="100" vmw:osType="rhel8_64Guest"> $ cat coreos.ovf <?xml version="1.0"?> <Envelope xmlns="http://schemas.dmtf.org/ovf/envelope/1" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" vmw:buildId="build-880146"> <References> <File ovf:href="disk.vmdk" ovf:id="file1" ovf:size="1106632192"/> </References> <DiskSection> <Info>Virtual disk information</Info> <Disk ovf:capacity="17179869184" ovf:capacityAllocationUnits="byte" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="1106632192"/> </DiskSection> <NetworkSection> <Info>The list of logical networks</Info> <Network ovf:name="VM Network"> <Description>The VM Network network</Description> </Network> </NetworkSection> <VirtualSystem ovf:id="image"> <Info>A virtual machine</Info> <Name>OpenShift 4</Name> <OperatingSystemSection ovf:id="100" vmw:osType="rhel8_64Guest"> <Info>The kind of installed guest operating system</Info> </OperatingSystemSection> <VirtualHardwareSection ovf:transport="com.vmware.guestInfo"> <Info>Virtual hardware requirements</Info> <System> <vssd:ElementName>Virtual Hardware Family</vssd:ElementName> <vssd:InstanceID>0</vssd:InstanceID> <vssd:VirtualSystemIdentifier>image</vssd:VirtualSystemIdentifier> <vssd:VirtualSystemType>vmx-15</vssd:VirtualSystemType> </System> <Item> <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> <rasd:Description>Number of Virtual CPUs</rasd:Description> <rasd:ElementName>2 virtual CPU(s)</rasd:ElementName> <rasd:InstanceID>1</rasd:InstanceID> <rasd:ResourceType>3</rasd:ResourceType> <rasd:VirtualQuantity>2</rasd:VirtualQuantity> </Item> <Item> <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> <rasd:Description>Memory Size</rasd:Description> <rasd:ElementName>4096 MB of memory</rasd:ElementName> <rasd:InstanceID>2</rasd:InstanceID> <rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>4096</rasd:VirtualQuantity> </Item> <Item ovf:required="false"> <rasd:AutomaticAllocation>false</rasd:AutomaticAllocation> <rasd:ElementName>VirtualVMCIDevice</rasd:ElementName> <rasd:InstanceID>7</rasd:InstanceID> <rasd:ResourceSubType>vmware.vmci</rasd:ResourceSubType> <rasd:ResourceType>1</rasd:ResourceType> <vmw:Config ovf:required="false" vmw:key="allowUnrestrictedCommunication" vmw:value="false"/> </Item> <Item> <rasd:Address>0</rasd:Address> <rasd:Description>SCSI Controller</rasd:Description> <rasd:ElementName>SCSI Controller 0</rasd:ElementName> <rasd:InstanceID>3</rasd:InstanceID> <rasd:ResourceSubType>VirtualSCSI</rasd:ResourceSubType> <rasd:ResourceType>6</rasd:ResourceType> </Item> <Item> <rasd:AddressOnParent>0</rasd:AddressOnParent> <rasd:ElementName>Hard disk 0</rasd:ElementName> <rasd:HostResource>ovf:/disk/vmdisk1</rasd:HostResource> <rasd:InstanceID>4</rasd:InstanceID> <rasd:Parent>3</rasd:Parent> <rasd:ResourceType>17</rasd:ResourceType> <vmw:Config ovf:required="false" vmw:key="backing.writeThrough" vmw:value="false"/> </Item> <Item> <rasd:AddressOnParent>7</rasd:AddressOnParent> <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation> <rasd:Connection>VM Network</rasd:Connection> <rasd:Description>VmxNet3 ethernet adapter on "VM Network"</rasd:Description> <rasd:ElementName>Network adapter 1</rasd:ElementName> <rasd:InstanceID>5</rasd:InstanceID> <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType> <rasd:ResourceType>10</rasd:ResourceType> <vmw:Config ovf:required="false" vmw:key="connectable.allowGuestControl" vmw:value="true"/> <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="false"/> </Item> <vmw:Config ovf:required="false" vmw:key="bootOptions.efiSecureBootEnabled" vmw:value="true"/> <vmw:Config ovf:required="false" vmw:key="firmware" vmw:value="efi"/> </VirtualHardwareSection> <ProductSection> <Info>Information about the installed software</Info> <Product>rhcos OpenShift 4</Product> <Vendor>rhcos</Vendor> <Version>411.85.202205100541-0</Version> <Property ovf:userConfigurable="true" ovf:type="string" ovf:key="guestinfo.ignition.config.data" ovf:value=""> <Label>Ignition config data</Label> <Description>Inline Ignition config data</Description> </Property> <Property ovf:userConfigurable="true" ovf:type="string" ovf:key="guestinfo.ignition.config.data.encoding" ovf:value=""> <Label>Ignition config data encoding</Label> <Description>Encoding for Ignition config data</Description> </Property> </ProductSection> </VirtualSystem> </Envelope>
The fix for this bug has landed in a bootimage bump, as tracked in bug 2065893 (now in status MODIFIED). Moving this bug to MODIFIED.
Do not have vmware platform, just check conf like #c13 $ tar xvf rhcos-411.85.202205101201-0-vmware.x86_64.ova coreos.ovf disk.vmdk $ cat coreos.ovf | grep "osType\|efi" <OperatingSystemSection ovf:id="100" vmw:osType="rhel8_64Guest"> <vmw:Config ovf:required="false" vmw:key="bootOptions.efiSecureBootEnabled" vmw:value="true"/> <vmw:Config ovf:required="false" vmw:key="firmware" vmw:value="efi"/>
Change to verified based on Comment #16
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:5069