similar to: [PATCH] v2v: rework handling of CPU topology

Where supported, pass the source CPU vendor, model and topology to the target hypervisor. For -i ova, we can get just cores per socket via a proprietary VMware extension to OVF. For -i libvirt and from virt-p2v, we can get all of these fields from the libvirt XML. For -o libvirt/local, we can preserve all of the information in the target XML. For -o glance, as far as I can tell from the

Many of the properties for disks are the same for all of them, so collect them only once, instead of doing that for every disk. Should be just code motion, with no behaviour change. --- v2v/output_glance.ml | 143 ++++++++++++++++++++++++++------------------------- 1 file changed, 73 insertions(+), 70 deletions(-) diff --git a/v2v/output_glance.ml b/v2v/output_glance.ml index cfb19b4..3feb2e4

Inspired by ocaml-extlib, introduce a module for handling option types. We already had the ‘may’ function (which becomes ‘Option.may’). This adds also ‘Option.map’ (unused), and ‘Option.default’ functions. Note this does *not* introduce the unsafe ‘Option.get’ function from extlib. --- builder/builder.ml | 6 ++--- builder/index.ml | 27 +++++++++------------

Add a new output mode to virt-v2v: similar to -o local, the written metadata is a JSON file with the majority of the data that virt-v2v knowns about (or collects) during the conversion. This is meant to be used only when no existing output mode is usable, and a guest needs to be converted to run on KVM anyway. The user of this mode is supposed to use all the data in the JSON, as they contain

Add a new output mode to virt-v2v: similar to -o local, the written metadata is a JSON file with the majority of the data that virt-v2v knowns about (or collects) during the conversion. This is meant to be used only when no existing output mode is usable, and a guest needs to be converted to run on KVM anyway. The user of this mode is supposed to use all the data in the JSON, as they contain

Does genid exist in oVirt ? If yes, is it already preserved or should it be a new patch ? On Thu, Jul 5, 2018 at 3:44 PM Richard W.M. Jones <rjones@redhat.com> wrote: > virt-v2v moves guests, it doesn't clone them. Therefore we should try > to preserve the VM Generation ID (genid) as much as possible. > > This has the ability to read the genid from VMware VMX files and

virt-v2v moves guests, it doesn't clone them. Therefore we should try to preserve the VM Generation ID (genid) as much as possible. This has the ability to read the genid from VMware VMX files and libvirt XML (but note RHBZ#1598348). It can also write the genid to libvirt (‘-o libvirt’, ‘-o local’) and QEMU (‘-o qemu’). We are missing support currently for all OVF-based formats (hence ‘-i

Version 1 was here: https://listman.redhat.com/archives/libguestfs/2023-February/thread.html#30694 I made a few changes in v2 but overall decided to keep the now unused gcaps_arch_min_version capability. This doesn't preclude removing it in future if we think it's never going to be useful. I changed patch 1 so that to remove the long comment about how the field is used, anticipating the

v1 -> v2: - Support for passing topology through -o glance. - Support for passing topology through -o rhv. - Use bool for acpi/apic/pae struct fields in virt-p2v. - Write the xpath expression in error messages instead of file/line. - Fix more memory leaks in virt-p2v cpuid.c. - Passes make check & check-valgrind. There may be some other minor changes. I believe that everything

Avoids the libvirt error: error: XML error: CPU vendor specified without CPU model --- v2v/create_libvirt_xml.ml | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index 582419f00..fbe90eeaa 100644 --- a/v2v/create_libvirt_xml.ml +++ b/v2v/create_libvirt_xml.ml @@ -51,15 +51,17 @@ let create_libvirt_xml

On 2/17/23 12:44, Richard W.M. Jones wrote: > As with the prior commit, prefer -cpu host for all guests (except when > we have more information from the source hypervisor). Although there > is the disadvantage that -cpu host is non-migratable, in practice it > would be very difficult to live migrate a host launched using direct > qemu commands. > > Note that after this

This is tangentially related to: https://bugzilla.redhat.com/show_bug.cgi?id=1372668 The problem in that bug is that we didn't pass the source CPU model (Sandybridge in that case) through to the target RHV hypervisor. So when the Windows guest booted on the target it gives an error about CPU hardware being disconnected (although it otherwise boots and works fine). This patch series

When converting a guest with UEFI firmware, set the also hw_firmware_type=uefi property for all the disks of the guest, so Nova can properly boot the guest. --- v2v/output_glance.ml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/v2v/output_glance.ml b/v2v/output_glance.ml index b712d68..cfb19b4 100644 --- a/v2v/output_glance.ml +++ b/v2v/output_glance.ml @@ -41,7

On Fri, Mar 23, 2018 at 12:35:36PM +0100, Pino Toscano wrote: > So far v2v did not read the model of network interfaces, resulting in > "virtio" as the model for such interfaces. > > Start reading the model, if available, mapping only E1000 for now. Looks sensible, ACK. > There are also other models, e.g. PCNet32 or VmxNet3, but they are > ignored for now: reading

Starting with 5.2.0, libvirt has a way to select automatically the firmware for a guest using an attribute of the <os> tag. Hence, use this information (when available, of course) to flag the firmware used by the guest. --- v2v/parse_libvirt_xml.ml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/v2v/parse_libvirt_xml.ml b/v2v/parse_libvirt_xml.ml index

So far v2v did not read the model of network interfaces, resulting in "virtio" as the model for such interfaces. Start reading the model, if available, mapping only E1000 for now. There are also other models, e.g. PCNet32 or VmxNet3, but they are ignored for now: reading them as Source_other_nic would result in v2v rejecting OVAs previously converted. --- v2v/parse_ovf_from_ova.ml

https://bugzilla.redhat.com/show_bug.cgi?id=1342398#c6 --- v2v/OVF.ml | 138 ++++++++++++++++++++++++++++++++++--------------------------- 1 file changed, 76 insertions(+), 62 deletions(-) diff --git a/v2v/OVF.ml b/v2v/OVF.ml index 8a6f13e..0599306 100644 --- a/v2v/OVF.ml +++ b/v2v/OVF.ml @@ -184,6 +184,15 @@ and get_ostype = function typ distro major minor arch product;

In Std_utils we already extend Char and String. These commits take it a little further by extending List and adding a new Option submodule. All basically simple refactoring. Rich.

v2 -> v3: - Renamed List.assoc_ -> List.assoc_lbl. - Rebased on top of current master branch. Rich.

This time including the first commit ...