similar to: [PATCH 1/2] v2v: -o glance: add property for UEFI firmware (RHBZ#1445659)

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

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

This patch implements output to OpenStack Cinder volumes using OpenStack APIs. It has only been lightly tested, but appears to work. There are some important things to understand about how this works: (1) You must run virt-v2v in a conversion appliance running on top of OpenStack. And you must supply the name or UUID of this appliance to virt-v2v using the ‘-oo server-id=NAME|UUID’ parameter.

v1 was here: https://www.redhat.com/archives/libguestfs/2018-August/thread.html#00287 v2: - The -oa option now gives an error; apparently Cinder cannot generally control sparse/preallocated behaviour, although certain Cinder backends can. - The -os option maps to Cinder volume type; suggested by Matt Booth. - Add a simple test.

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

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

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.

This time including the first commit ...

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

Instead of storing the number of sockets, cores, and threads separately with the possibility to have each of them optional, store them together, so either we have a CPU topology or none. This slightly simplifies the handling of CPU topology. Most of the output modes/producers already considered a missing information of a topology as "1" when any of the other was specified, so the

Thanks: Vladik Romanovsky, Ming Xie. --- v2v/output_glance.ml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/v2v/output_glance.ml b/v2v/output_glance.ml index e38b172..179448b 100644 --- a/v2v/output_glance.ml +++ b/v2v/output_glance.ml @@ -92,6 +92,10 @@ object | Virtio_net -> "virtio" | E1000 -> "e1000" | RTL8139 ->

The glance client v1.0.0 defaults to the Image v2 API: this means that an image can be referenced only by its UUID, and not anymore by the name as well (which does not need to be unique). This caused our glance invocation to set the properties for the newly created image to fail, since we are using the name as identifier. Instead of first creating the image and then setting all the properties

This patch series lifts the previous restriction that virt-v2v would refuse to convert a guest to Glance that had more than one disk. The first patch is just better documentation for the Glance output mode. The second patch contains the change (best viewed with 'git diff -w' since it is mostly a whitespace change). virt-v2v -o glance will now create multiple disks called: - guestname

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

Use the common open_guestfs to open Guestfs handles, so we get debugging, tracing, and other common options set. --- v2v/convert_windows.ml | 4 +--- v2v/input_disk.ml | 2 +- v2v/input_libvirt_other.ml | 2 +- v2v/input_ova.ml | 2 +- v2v/output_glance.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_rhev.ml | 2 +- v2v/output_vdsm.ml | 2 +-

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. Newer versions of libvirt and QEMU will probably switch over to defaulting

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

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

This changes the infrastructure to allow the target_file to be a QEMU URI. Rich.