Richard W.M. Jones
2020-Dec-04  12:53 UTC
[Libguestfs] [PATCH] ovf: Try to set BiosType correctly according to the oVirt sources.
Tomas, what do you think about this? As far as I can tell we are not setting the BiosType correctly in any current scenario. Mostly we set it to "0" (cluster default), and I guess we can get away with that most of the time. For UEFI guests we set it to "2" which simply seems wrong. The patch tries to adjust the BiosType so it actually matches what the oVirt source code says. Am I missing something? Rich.
Richard W.M. Jones
2020-Dec-04  12:53 UTC
[Libguestfs] [PATCH] ovf: Try to set BiosType correctly according to the oVirt sources.
Previously we mapped TargetBIOS to 0 and TargetUEFI to 2, but I
believe that both of these are wrong, and they certainly don't match
the oVirt source code.
This changes the BiosType calculation to use all necessary inputs
(architecture, I440FX|Q35, and TargetBIOS|TargetUEFI) and try to map
these as closely as possible to the BiosType as described in the oVirt
sources.
An exact mapping is not possible, so in cases where we can't find one
we punt on this by returning 0 (use cluster default).
---
 tests/test-v2v-o-rhv.ovf.expected          |  2 +-
 tests/test-v2v-o-vdsm-options.ovf.expected |  2 +-
 v2v/create_ovf.ml                          | 23 +++++++++++++---------
 3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/tests/test-v2v-o-rhv.ovf.expected
b/tests/test-v2v-o-rhv.ovf.expected
index c6bd05c562..d7c1a0619f 100644
--- a/tests/test-v2v-o-rhv.ovf.expected
+++ b/tests/test-v2v-o-rhv.ovf.expected
@@ -25,7 +25,7 @@
     <IsStateless>False</IsStateless>
     <VmType>0</VmType>
     <DefaultDisplayType>1</DefaultDisplayType>
-    <BiosType>0</BiosType>
+    <BiosType>2</BiosType>
     <Section ovf:id='#VM_ID#' ovf:required='false'
xsi:type='ovf:OperatingSystemSection_Type'>
       <Info>Microsoft Windows 7 Phony Edition</Info>
       <Description>Windows7</Description>
diff --git a/tests/test-v2v-o-vdsm-options.ovf.expected
b/tests/test-v2v-o-vdsm-options.ovf.expected
index f0d418b46b..6a2029afc3 100644
--- a/tests/test-v2v-o-vdsm-options.ovf.expected
+++ b/tests/test-v2v-o-vdsm-options.ovf.expected
@@ -25,7 +25,7 @@
     <IsStateless>False</IsStateless>
     <VmType>0</VmType>
     <DefaultDisplayType>1</DefaultDisplayType>
-    <BiosType>0</BiosType>
+    <BiosType>2</BiosType>
     <OperatingSystemSection ovf:id='VM' ovf:required='false'
ovirt:id='11'>
       <Info>Microsoft Windows 7 Phony Edition</Info>
       <Description>Windows7</Description>
diff --git a/v2v/create_ovf.ml b/v2v/create_ovf.ml
index de938f6fc4..481867b43c 100644
--- a/v2v/create_ovf.ml
+++ b/v2v/create_ovf.ml
@@ -462,13 +462,18 @@ let origin_of_source_hypervisor = function
    *)
   | _ -> None
 
-(* Set the <BiosType> element. Other possible values:
- *   1  q35 + SeaBIOS
- *   3  q35 + UEFI + Secure Boot
+(* Set the <BiosType> element.
+ *
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/BiosType.java#L10
  *)
-let get_ovirt_biostype = function
-  | TargetBIOS -> 0  (* i440fx + SeaBIOS *)
-  | TargetUEFI -> 2  (* q35 + UEFI *)
+let get_ovirt_biostype arch machine firmware +  if arch <>
"x86_64" then
+    1
+  else
+    match machine, firmware with
+    | I440FX, TargetBIOS -> 1 (* i440fx + SeaBIOS *)
+    | Q35, TargetBIOS -> 2    (* q35 + SeaBIOS *)
+    | Q35, TargetUEFI -> 3    (* q35 + UEFI *)
+    | _ -> 0                  (* who knows! try cluster default *)
 
 (* Generate the .meta file associated with each volume. *)
 let create_meta_files output_alloc sd_uuid image_uuids overlays @@ -523,7
+528,9 @@ let rec create_ovf source targets guestcaps inspect target_firmware
   let vmtype = get_vmtype inspect in
   let vmtype = match vmtype with `Desktop -> "0" | `Server ->
"1" in
   let ostype = get_ostype inspect in
-  let biostype = get_ovirt_biostype target_firmware in
+  let biostype +    get_ovirt_biostype guestcaps.gcaps_arch
guestcaps.gcaps_machine
+                       target_firmware in
 
   let ovf : doc      doc "ovf:Envelope" [
@@ -612,8 +619,6 @@ let rec create_ovf source targets guestcaps inspect
target_firmware
                                      source.s_vcpu memsize_mb)]
       ] in
 
-      (* XXX How to set machine type for Q35? *)
-
       List.push_back virtual_hardware_section_items (
         e "Item" [] ([
           e "rasd:Caption" [] [PCData (sprintf "%d virtual
cpu" source.s_vcpu)];
-- 
2.28.0.rc2
Tomáš Golembiovský
2020-Dec-07  08:58 UTC
[Libguestfs] [PATCH] ovf: Try to set BiosType correctly according to the oVirt sources.
Hi, On Fri, Dec 04, 2020 at 12:53:06PM +0000, Richard W.M. Jones wrote:> Tomas, what do you think about this? > > As far as I can tell we are not setting the BiosType correctly in any > current scenario.Yes, we are.> Mostly we set it to "0" (cluster default), and I > guess we can get away with that most of the time. For UEFI guests we > set it to "2" which simply seems wrong. > > The patch tries to adjust the BiosType so it actually matches what the > oVirt source code says.It's not really intuitive (not to mention undocumented), but there is a difference from what oVirt reads from OVF and how the Bios types are represented internally. Basically all values are shifted by one. See the '+1' in [1]. The change corresponding to the hack is here [2]. When they introduced cluster default in 4.4 development they did not realize it is used also by others. When we spotted the mistake it was already quite late and changing the enum to the original state was already out of question. So this hack was born. If virt-v2v wanted to set it to cluster default it can be done by omitting <BiosType> element altogether or by setting custom="false" attribute. Specifying negative value for <BiosType> should also work but I'd rather not rely on that. [1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfReader.java#L699 [2] https://gerrit.ovirt.org/c/ovirt-engine/+/106692> > Am I missing something? > > Rich. > >-- Tom?? Golembiovsk? <tgolembi at redhat.com>