similar to: [PATCH v2 0/2] v2v: improve OVF in OVirt flavour

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

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

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.

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.

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

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

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

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

When writing the libosinfo metadata in the libvirt XML, use the newly added (in osinfo-db) ID for Windows Server 2019; sadly, this version of Windows has the same version as Windows Server 2016, so distinguish it by looking at its product name. --- v2v/create_libvirt_xml.ml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index

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

Libguestfs supports passing an ISO image as a source of virtio windows drivers to v2v. That support, however, looks too heavy-weight: in order to access those drivers, a separate guestfs handle is created (and thus a new emulator process is started), which runs until v2v completes. This series attempts to make it simpler and lighter-weight, by making the relevant code more local, and by