similar to: [PATCH] v2v: -o local: Check that UEFI firmware is installed before conversion.

Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 45 +++++++++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index 633c29f..afffde2 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -103,26 +103,7 @@ let rec main () = g#shutdown (); g#close (); - (* Does the guest require UEFI on the target?

Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 45 +++++++++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index c6a567a..c1bce1b 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -399,6 +399,30 @@ let do_convert g inspect source keep_serial_console = guestcaps +let get_target_firmware inspect

It will be used to do extra checks in the output before copying the disks. Partially revert commit 3bafec4e693a25ef1c84abc0fd1bc3251862c7de. --- v2v/output_glance.ml | 2 +- v2v/output_json.ml | 2 +- v2v/output_libvirt.ml | 2 +- v2v/output_local.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_openstack.ml | 2 +- v2v/output_qemu.ml | 2 +- v2v/output_rhv.ml

Add oVirt specific elemnt to OVF. It represents the combination of machine type (i440fx/q35) and firmware (BIOS/UEFI). Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/create_ovf.ml | 20 +++++++++++++++++++- v2v/create_ovf.mli | 2 +- v2v/output_rhv.ml | 6 ++---- v2v/output_rhv_upload.ml

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

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, Jun 10, 2016 at 05:07:02PM +0300, Pavel Butsykin wrote: > Store the list of EFI system partitions on the inspect object in order to be > able to tune their contents later in the process. > > Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com> > --- > v2v/convert_linux.ml | 2 +- > v2v/inspect_source.ml | 29 +++++++++++++++++++++-------- >

On Thursday, 19 July 2018 15:51:04 CEST Tomáš Golembiovský wrote: > Add oVirt specific elemnt to OVF. It represents the combination of > machine type (i440fx/q35) and firmware (BIOS/UEFI). Other than adding a new element in the OVF, this also enables the conversion of UEFI guests to oVirt. It is tested? Does it require other changes? I'd split the addition of <BiosType> to the

XXX No documentation. Only handles one disk. Network cards? Do we need to escape YAML format? What firmware types does kubevirt support. --- v2v/Makefile.am | 2 + v2v/cmdline.ml | 21 ++++++++++ v2v/output_kubevirt.ml | 103 ++++++++++++++++++++++++++++++++++++++++++++++++ v2v/output_kubevirt.mli | 24 +++++++++++ 4 files changed, 150 insertions(+) diff --git

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. The latest advice from the QEMU and libvirt communities is not to rely on

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 least). > > The discussion happened here: > >

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.

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

Don't pass these flags to dozens of functions. --- builder/builder.ml | 47 +++++++++-------- builder/cache.ml | 4 +- builder/cache.mli | 2 +- builder/cmdline.ml | 13 ++--- builder/downloader.ml | 14 +++-- builder/downloader.mli

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.

Since this output method was written the code has always been capable of adding the hw_firmware_type = uefi image property, and this property has been supported since at least OpenStack 12 which is years old. Interestingly now all of the output modes support both BIOS and UEFI. --- v2v/output_openstack.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/output_openstack.ml

Create two temporary directories for all the files created during the virt-v2v run: 1) tmpdir, created as $TMPDIR/virt-v2v.XXXXXX, for all the small files 2) cachedir, created as $LIBGUESTFS_CACHEDIR/virt-v2v.XXXXXX, for the big files (e.g. disks) This way there is no need to manually schedule all the temporary files and directories for removal when the application quits. --- v2v/input_ova.ml

Implement what old virt-v2v did (from lib/Sys/VirtConvert/Connection/LibVirtTarget.pm) Thanks: Tingting Zheng, Matthew Booth --- v2v/output_libvirt.ml | 118 ++++++++++++++++++++++++++++++++++++++++++++++--- v2v/output_libvirt.mli | 2 +- v2v/output_local.ml | 13 +++++- v2v/test-v2v-i-ova.xml | 5 ++- 4 files changed, 128 insertions(+), 10 deletions(-) diff --git

On 4/6/20 10:40 AM, Pino Toscano wrote: > Create two temporary directories for all the files created during the > virt-v2v run: > 1) tmpdir, created as $TMPDIR/virt-v2v.XXXXXX, for all the small files > 2) cachedir, created as $LIBGUESTFS_CACHEDIR/virt-v2v.XXXXXX, for the > big files (e.g. disks) > This way there is no need to manually schedule all the temporary files >