search for: osinfo_subnod

...ovf source targets guestcaps inspect ); List.push_back content_subnodes ( - e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; - "xsi:type", "ovf:OperatingSystemSection_Type"] [ + let osinfo_subnodes = [ e "Info" [] [PCData inspect.i_product_name]; e "Description" [] [PCData ostype]; - ] + ] in + if rhv_export_flavor then + e "Section" ["ovf:id", vm_uuid; "ovf:required", "false";...

...; ["ovf:id", vm_uuid; - "ovf:required", "false"] + "ovf:required", "false"; + "ovirt:id", string_of_int ovirt_osid] osinfo_subnodes | RHVExportStorageDomain -> e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; -- 2.14.3

Hi, v3 of these patches: https://www.redhat.com/archives/libguestfs/2018-April/msg00002.html https://www.redhat.com/archives/libguestfs/2018-April/msg00006.html Thanks, Pino Toscano (3): v2v: OVF: improve get_ostype mappings v2v: OVF: write ovirt:id attribute for the OS in OVirt flavour v2v: OVF: fix ovf:id for VirtualSystem in OVirt flavour v2v/create_ovf.ml | 253

...:required", "false"; > + "ovirt:id", string_of_int ovirt_osid] Sadly, OVF schema says ovf:id is reqiured. But since the generated OVF is not used by anything besides oVirt I think we can live without it. Tomas > osinfo_subnodes > | RHVExportStorageDomain -> > e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; > -- > 2.14.3 > -- Tomáš Golembiovský <tgolembi@redhat.com>

Hi, v2 of this patch: https://www.redhat.com/archives/libguestfs/2018-April/msg00003.html that includes an additional fix. Thanks, Pino Toscano (2): v2v: OVF: write ovirt:id attribute for the OS in OVirt flavour v2v: OVF: fix ovf:id for VirtualSystem in OVirt flavour v2v/create_ovf.ml | 204 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 202 insertions(+), 2

...; ["ovf:id", vm_uuid; - "ovf:required", "false"] + "ovf:required", "false"; + "ovirt:id", string_of_int ovirt_osid] osinfo_subnodes | RHVExportStorageDomain -> e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; -- 2.14.3

..."ovf:required", "false"] + let ovirt_osid = get_ovirt_osid inspect in + e "OperatingSystemSection" ["ovf:required", "false"; + "ovirt:id", string_of_int ovirt_osid] osinfo_subnodes | RHVExportStorageDomain -> e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; -- 2.14.3

...;, vm_uuid; > - "ovf:required", "false"] > + "ovf:required", "false"; > + "ovirt:id", string_of_int ovirt_osid] > osinfo_subnodes > | RHVExportStorageDomain -> > e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; Yes looks OK, ACK. Also Michal gave his ACK on IRC. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rj...

The main reason for creating different OVF is that it can be used to create VM by oVirt REST API. The RHV export domain flavor cannot be used that way. Tomáš Golembiovský (3): v2v: tests: check generated OVF v2v: ovf: Create OVF more aligned with the standard v2v: vdsm: add --vdsm-fixed-ovf option v2v/cmdline.ml | 5 ++ v2v/create_ovf.ml

The main reason for creating different OVF is that it can be used to create VM by oVirt REST API. The RHV export domain flavor cannot be used that way. v1 -> v2: - introduced flavour types instead of booleans - instead of referring to the new flavour as "standard OVF" or "fixed OVF" I refer to it as oVirt flavour. While it is more conforming than the one used in export

...Tomas > - "ovf:required", "false"] > + "ovf:required", "false"; > + "ovirt:id", string_of_int ovirt_osid] > osinfo_subnodes > | RHVExportStorageDomain -> > e "Section" ["ovf:id", vm_uuid; "ovf:required", "false"; > -- > 2.14.3 > -- Tomáš Golembiovský <tgolembi@redhat.com>