Created attachment 1700326 [details]
uefi-guest-bios-type-rhv4.3.png

Can reproduce the bug on rhv:4.4.1.8

Related versions:
rhv:4.4.1.8-0.7.el8ev
vdsm-4.40.22-1.el8ev.x86_64
virt-v2v-1.42.0-5.module+el8.3.0+7152+ab3787c3.x86_64
libguestfs-1.42.0-2.module+el8.3.0+6798+ad6e66be.x86_64


Steps to Reproduce:
1.Create a new cluster which has BIOS Type 'cluster default', then move the host to the new cluster on rhv4.4

2.Convert a uefi guest from VMware to rhv4.4 by virt-v2v
# virt-v2v -ic vpx://root.xx.xx/data/10.73.xx.xx/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -ip /home/passwd  -o rhv-upload -oo rhv-direct -oc https://dell-per740-xx.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -of raw -oo rhv-cluster=new-cluster -os nfs_data -b ovirtmgmt esx6.7-win10-x86_64-efi -on win10-x64-uefi

3.Check the guest after v2v conversion, can power on guest successfully but BIOS Type of uefi guest is 'Cluster default', then found guest can't boot into OS because of wrong BIOS type

Created attachment 1700427 [details]
uefi-guest-cannot-boot-into-os.png

ok, so the logic we've introduced in CompatibilityVersionUpdater should be adjusted -
if the given VM is set with Q35_OVMF, it should remain with Q35_OVMF regardless of the target cluster

*** This bug has been marked as a duplicate of bug 1726558 ***

Hi Arik,

   I don't think the bug is duplicated with bug1726558, bug1726558 is tracking the BIOS type problem of uefi guest with enabling secure boot, but this bug is tracking the problem of uefi guest no matter whether the secure boot is enabled or not, please see below results when converting guest from VMware in different ways


   Convert guest from VMware to rhv4.4 by v2v on standalone v2v server:

   Non-uefi guest---> cluster Default
   uefi guest without secure boot ---> cluster Default <---- bug1855001
   uefi guest with secure boot ---> cluster Default  <------bug1855001

   
   Import guest from VMware on rhv4.4 GUI web:

   Non-uefi guest---> legacy
   uefi guest without secure boot ---> Q35 Chipset with UEFI BIOS
   uefi guest with secure boot ---> Q35 Chipset with UEFI BIOS  <---- bug1726558
   

   For non-uefi guest, the BIOS type is different in above ways of v2v conversion, one is legacy and another one is cluster default. what's the difference between legacy and cluster default? Which one is the correct BIOS type for non-uefi guest? By the way, Cluster has BIOS type 'Q35 Chipset with Legacy BIOS' and non-uefi guest can boot into OS with both BIOS type 'legacy' and 'cluster default'

Created attachment 1702351 [details]
import-vmware-guest-on-rhv4.4.png

Yes, I'd agree this bug is more general but the problem seems to be the same - that we cannot/should not change the bios type in these particular cases.

Did you run the flows mentioned above with the same version of RHV? which version of RHV was it?

Regarding legacy vs. cluster-default, it may be the same and may differ - depending on the cluster.
If the cluster is set with bios=legacy, then it's the same.
If the cluster is set with bios=q35, then:
  if the VM is set with legacy, it will run with i440fx
  if the VM is set with cluster-default, it will run with q35

(In reply to Arik from comment #8)
> Yes, I'd agree this bug is more general but the problem seems to be the same
> - that we cannot/should not change the bios type in these particular cases.
> 
> Did you run the flows mentioned above with the same version of RHV? which
> version of RHV was it?
> 
> Regarding legacy vs. cluster-default, it may be the same and may differ -
> depending on the cluster.
> If the cluster is set with bios=legacy, then it's the same.
> If the cluster is set with bios=q35, then:
>   if the VM is set with legacy, it will run with i440fx
>   if the VM is set with cluster-default, it will run with q35

All scenarios of comment6 are using the same version of rhv4.4 and version is 4.4.1.8-0.7.el8ev, the BIOS type of cluster is 'Q35 Chipset with Legacy' which is set automatically if add a host to the cluster(https://bugzilla.redhat.com/show_bug.cgi?id=1846954#c43)

I'm confused about the BIOS types of rhv4.4 cluster, there are five BIOS types in cluster('cluster default', 'legacy','Q35 Chipset with Legacy', 'Q35 Chipset with UEFI', 'Q35 Chipset with secure boot'),  what's the difference between 'cluster default and 'legacy'?  which bios type of cluster is the best one to use for testing? We need to convert many different guests(non-uefi, uefi without secure, uefi with secure) to rhv4.4, besides, also need to test v2v integration with rhv, we need a cluster can support all types of guests.


I think non-uefi guest should have same bios type after v2v conversion whatever BIOS type of cluster or how the guest is converted by v2v. May I file a bug for this?

cluster-default - this value changes when the first host gets activated in the cluster. the bios type would be determined according to that host and cluster version.
legacy - machine type i440fx.

Clusters that are set with bios-type=cluster-default may latter change to bios-type=legacy. For instance, take an empty 4.3 cluster (with 4.4 engine), set its bios type to cluster-default, and activate a x86 host in the cluster and the bios-type would be set to 'legacy'. But they may change from cluster-default to q35 as well.

I don't think there's such a thing as 'best bios type to test with'.
On the one hand, q35 with sea bios is the new default so it needs to be tested.
On the other hand, legacy (i440fx) bios type is what users and customers would typically run with after upgrade - possibly, for a long time.
The others are tech preview at the moment, so the focus should be on the aforementioned ones.

I'd suggest to test the following:
non-UEFI to both Legacy and Q35 Chipset with Legacy BIOS clusters.
UEFI without secure boot to a Q35 Chipset with UEFI BIOS cluster.
UEFI with secure boot to a Q35 Chipset with SecureBoot cluster.

I believe that others flows are either not interesting or unlikely to work until 4.4.2.

> I think non-uefi guest should have same bios type after v2v conversion
> whatever BIOS type of cluster or how the guest is converted by v2v. May I
> file a bug for this?

Well, let me ask you this:

1st case:
You're the admin of a cluster with 200 VMs in RHV 4.3.
We tell you that you can upgrade your system to 4.4 and keep the cluster as is.
At some point, you can change the cluster's bios type to q35 and from that point on all new VMs will be set with q35, the next time you start existing VMs they would start with q35 and when you import VMs from lower versions they would change q35.
But in the meantime, before changing the cluster compatibility version to 4.4, you import 20 non-UEFI VMs from VMware to that cluster.
Would you expect those 20 VMs to be any different than the 200 VMs that you already had or would you expect them to automatically change to q35 as the others?
If you expect them to change as well then we must set those 20 imported VMs to cluster-default and not to legacy bios.

2nd case:
You're the admin of a cluster with 200 VMs in RHV 4.3.
You've upgraded the cluster compatibility version to 4.4 and so all existing VMs changed (or will change the next time they start) to q35, all new VMs are set with q35 and all VMs you import from lower compatibility version change to q35.
Now you decide to import 20 non-UEFI VMs from VMware.
Would you expect those VMs to be any different than the existing VMs or oVirt VMs that you've imported and changed to q35 or would you expect them to keep running with legacy bios just because they were converted by virt-v2v?
If you expect them to change as well then without the ability to specify to virt-v2v that we want the VM to be converted to q35, we have to make this conversion from the legacy bios to q35 on the ovirt/rhv side.

So I see your point in saying "virt-v2v prepared this VM that way and that's how it should be set" but unfortunately I don't see how we can do it without having conflicts with other flows.

But I think that what you've reported in comment 8 deserves a bug because it likely means that we missed a flow.

Hi Arik, thanks for your reply, according to what you said, my understanding is:

cluster-default - this default value of cluster when cluster is newly created, but bios type of cluster will be changed when the first host gets activated in the cluster. the bios type may be changed to legacy or 'Q35 Chipset with Legacy BIOS' which is determined according to the host and cluster version. By the way, all test result of comment6 is got by cluster bios='Q35 Chipset with Legacy BIOS'


> I'd suggest to test the following:
> non-UEFI to both Legacy and Q35 Chipset with Legacy BIOS clusters.
> UEFI without secure boot to a Q35 Chipset with UEFI BIOS cluster.
> UEFI with secure boot to a Q35 Chipset with SecureBoot cluster.


For non-uefi guest, BIOS type of cluster is legacy or 'Q35 Chipset with Legacy BIOS'，both types would be ok， rignt?
For UEFI without secure boot guest, do you mean need to change the bios type of cluster to  Q35 Chipset with UEFI BIOS?
For UEFI with secure boot,  do you mean need to change the bios type of cluster to Q35 Chipset with SecureBoot?

I think it's not reasonable that user need to change the bios type of cluster when test different bios type of guest. Such as, our team has only one rhv4.4 env and only one host is registered on rhv4.4, we can't change the bios type of cluster during auto testing

RHV4.3 Cluster has no BIOS type option, why rhv4.4 designed so many BIOS types for cluster？ It's really confusing to use


> So I see your point in saying "virt-v2v prepared this VM that way and that's
> how it should be set" but unfortunately I don't see how we can do it without
> having conflicts with other flows.

 I don't understand why you said rhv4.3 can be updated to rhv4.4，rhv4.3 is built on rhel7 system but rhv4.4 is built on rhel8 system. is it possible to update rhv4.3 to rhv4.4 directly?

 What I expect is as long as the bios type of rhv4.4 cluster is 'Q35 Chipset with Legacy BIOS' no matter Whether cluster is new created or upgraded from old version:

 (1)all non-uefi guest should have bios type 'cluster default' no matter the guest is converted by v2v on standalone server or imported on rhv GUI;  
 (2)uefi-no-secure guest should have bios type 'Q35 Chipset with UEFI BIOS',
 (3)uefi-have-secure guest should have bios type 'Q35 Chipset with secure boot'
 

> But I think that what you've reported in comment 8 deserves a bug because it likely means that we missed a flow.

 Maybe I didn't describe problem clearly in comment6. Import guest from VMware on rhv4.4 GUI web, the imported the guest is also converted by v2v (v2v is installed on rhv-node), besides, can find bios type is '0' in import log ( bios type is also'0' in v2v debug log if the guest is converted to rhv4.4 on standalone v2v server), so I said "non-uefi guest should have same bios type after v2v conversion whatever BIOS type of cluster or how the guest is converted by v2v' in comment9, anyway, I have filed bug1861963 to track the problem.Thanks

(In reply to mxie from comment #11)
> cluster-default - this default value of cluster when cluster is newly
> created, but bios type of cluster will be changed when the first host gets
> activated in the cluster. the bios type may be changed to legacy or 'Q35
> Chipset with Legacy BIOS' which is determined according to the host and
> cluster version. By the way, all test result of comment6 is got by cluster
> bios='Q35 Chipset with Legacy BIOS'

That's correct. 

> For non-uefi guest, BIOS type of cluster is legacy or 'Q35 Chipset with
> Legacy BIOS'，both types would be ok， rignt?

Yes

> For UEFI without secure boot guest, do you mean need to change the bios type
> of cluster to  Q35 Chipset with UEFI BIOS?
> For UEFI with secure boot,  do you mean need to change the bios type of
> cluster to Q35 Chipset with SecureBoot?

Yes, or creating new clusters with those bios types.

> I think it's not reasonable that user need to change the bios type of
> cluster when test different bios type of guest. Such as, our team has only
> one rhv4.4 env and only one host is registered on rhv4.4, we can't change
> the bios type of cluster during auto testing

I see, it's a bit more complicated in the current state, I agree, and we're working on improving this in 4.4.2.

> RHV4.3 Cluster has no BIOS type option, why rhv4.4 designed so many BIOS
> types for cluster？ It's really confusing to use

RHV 4.3 enabled to configure the bios type per-VM but when it comes to big clusters (in terms of VMs) it's not really practical.
This cluster-level setting is supposed to make it easier for the admins to shape their entire cluster -
there's surely a room for improvement but in general this approach, of having cluster-level settings and being able to override them per-VM, is already pretty common in RHV.

> > So I see your point in saying "virt-v2v prepared this VM that way and that's
> > how it should be set" but unfortunately I don't see how we can do it without
> > having conflicts with other flows.
> 
>  I don't understand why you said rhv4.3 can be updated to rhv4.4，rhv4.3 is
> built on rhel7 system but rhv4.4 is built on rhel8 system. is it possible to
> update rhv4.3 to rhv4.4 directly?

Note that I was referring to a cluster.
There's a procedure to upgrade RHV 4.3 to 4.4 - once you do that and run RHVM 4.4 and 4.4 hosts, you can upgrade the compatibility version of the cluster from 4.3 to 4.4.

>  What I expect is as long as the bios type of rhv4.4 cluster is 'Q35 Chipset
> with Legacy BIOS' no matter Whether cluster is new created or upgraded from
> old version:
> 
>  (1)all non-uefi guest should have bios type 'cluster default' no matter the
> guest is converted by v2v on standalone server or imported on rhv GUI;  
>  (2)uefi-no-secure guest should have bios type 'Q35 Chipset with UEFI BIOS',
>  (3)uefi-have-secure guest should have bios type 'Q35 Chipset with secure
> boot'

Yes, that's what we're aiming for in 4.4.2.

Not a duplicate of bz 1726558 - this one is about UEFI and bz 1726558 is about UEFI + secure-boot which requires different handling in the context of import from VMware

This bugzilla is included in oVirt 4.4.4 release, published on December 21st 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.4 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.