similar to: [PATCH v3 0/3] v2v: improve OVF in OVirt flavour

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

When writing the OVF in OVirt flavour, add a ovirt:id attribute to the OperatingSystemSection tag: this attribute represents the numeric value of the ostype ID, which is ignored by oVirt when parsing OVFs in API mode. --- v2v/create_ovf.ml | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 201 insertions(+), 1 deletion(-) diff --git a/v2v/create_ovf.ml

On Thu, 5 Apr 2018 10:34:33 +0200 Pino Toscano <ptoscano@redhat.com> wrote: > When writing the OVF in OVirt flavour, add a ovirt:id attribute to the > OperatingSystemSection tag: this attribute represents the numeric value > of the ostype ID, which is ignored by oVirt when parsing OVFs in API > mode. > --- > v2v/create_ovf.ml | 202

On Thu, 05 Apr 2018 13:56:11 +0200 Pino Toscano <ptoscano@redhat.com> wrote: > On Thursday, 5 April 2018 13:45:53 CEST Tomáš Golembiovský wrote: > > On Thu, 5 Apr 2018 10:34:33 +0200 > > Pino Toscano <ptoscano@redhat.com> wrote: > > > > > When writing the OVF in OVirt flavour, add a ovirt:id attribute to the > > > OperatingSystemSection tag:

This is just a bit of preparatory refactoring ... Rich.

OUnit2 has an OUnit (v1) compatibility module. Unfortunately it is rather gravely broken: https://forge.ocamlcore.org/tracker/?func=detail&aid=1392&group_id=162&atid=730 Since there is no new release fixing this, it's easier to switch to using OUnit2 for unit tests. --- .gitignore | 2 +- README | 2 +- mllib/JSON_tests.ml | 56

The first two patches implement the change discussed here: https://www.redhat.com/archives/libguestfs/2016-April/msg00178.html The third patch fixes the mapping of inspection data to OVF VmType which was inherited directly from old virt-v2v and had never been changed. It had a number of problems. The fourth patch is only slightly related to the others. It adds an extra slow test to ensure that

When writing the OVF in OVirt flavour, add a ovirt:id attribute to the OperatingSystemSection tag: this attribute represents the numeric value of the ostype ID, which is ignored by oVirt when parsing OVFs in API mode. --- v2v/create_ovf.ml | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 201 insertions(+), 2 deletions(-) diff --git a/v2v/create_ovf.ml

When writing the OVF in OVirt flavour, add a ovirt:id attribute to the OperatingSystemSection tag: this attribute represents the numeric value of the ostype ID, which is ignored by oVirt when parsing OVFs in API mode. --- v2v/create_ovf.ml | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 201 insertions(+), 1 deletion(-) diff --git a/v2v/create_ovf.ml

On Wed, Apr 04, 2018 at 06:22:12PM +0200, Pino Toscano wrote: > When writing the OVF in OVirt flavour, add a ovirt:id attribute to the > OperatingSystemSection tag: this attribute represents the numeric value > of the ostype ID, which is ignored by oVirt when parsing OVFs in API > mode. > --- > v2v/create_ovf.ml | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++++- >

On Thursday, 5 April 2018 13:45:53 CEST Tomáš Golembiovský wrote: > On Thu, 5 Apr 2018 10:34:33 +0200 > Pino Toscano <ptoscano@redhat.com> wrote: > > > When writing the OVF in OVirt flavour, add a ovirt:id attribute to the > > OperatingSystemSection tag: this attribute represents the numeric value > > of the ostype ID, which is ignored by oVirt when parsing OVFs

I also checked the other ovirt IDs and they all seem to be correct, although this mapping to internal oVirt database IDs is by its nature very fragile and will require constant maintenance. Rich.

There's a standardized libosinfo namespace for libvirt domain metadata. For now it supports the id of the OS only. However that is still a very helpful feature that is already supported in gnome-boxes and virt-manager (at least). The discussion happened here: https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html So let's add the support to local and libvirt outputs.

This patch series adds stable bus and slot numbers for removable drives (CDs and floppies) when the guest is converted using virt-v2v or virt-p2v. Previously we were a bit random about this. After this patch series, the bus and slot numbers and preserved if at all possible. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1238053 Rich.

> On 1 May 2018, at 12:34, Richard W.M. Jones <rjones@redhat.com> wrote: > > This was the apparent cause of a conversion failure: ah, no, that’s not actually the reason. It is not a correct id, but it’s close enough (still a valid Windows id), there is a bug in the ovirt-engine import[1] It’s a simple enough fix, but delivering it is a bit challenging. We can only do the first

On Thu, 5 Apr 2018 14:53:51 +0200 Pino Toscano <ptoscano@redhat.com> wrote: > @@ -383,8 +581,9 @@ let rec create_ovf source targets guestcaps inspect > ] in > (match ovf_flavour with > | OVirt -> > - e "OperatingSystemSection" ["ovf:id", vm_uuid; > - "ovf:required",

On Fri, Nov 23, 2018 at 11:53:05AM +0000, Richard W.M. Jones wrote: >On Fri, Nov 23, 2018 at 12:39:44PM +0100, Martin Kletzander wrote: >> There's a standardized libosinfo namespace for libvirt domain metadata. For now >> it supports the id of the OS only. However that is still a very helpful feature >> that is already supported in gnome-boxes and virt-manager (at

CentOS 8 is represented with a simpler osinfo ID without a minor version. --- v2v/create_libvirt_xml.ml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index dbc24315..002ce2b8 100644 --- a/v2v/create_libvirt_xml.ml +++ b/v2v/create_libvirt_xml.ml @@ -43,9 +43,14 @@ let get_osinfo_id = function i_major_version

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

Hi there, Here is v3 of the remaining patches. Diff to v2: * Removed the patch related to QXL * Fixed the firstboot script with Roman's comments * Fixed ova with subfolders test * Handle MF-relative path in ova files * Fixed now unneeded match case as per Richard's comment Cédric Bosdonnat (3): customize: fix windows firstboot script v2v: add support for SUSE VMDP drivers v2v: