search for: i_mountpoints

...quot;unknown", then that indicates a > * failure in inspection, and we shouldn't continue. For an example > diff --git a/v2v/types.ml b/v2v/types.ml > index 08e1631..7f8a9b3 100644 > --- a/v2v/types.ml > +++ b/v2v/types.ml > @@ -315,7 +315,7 @@ type inspect = { > i_mountpoints : (string * string) list; > i_apps : Guestfs.application2 list; > i_apps_map : Guestfs.application2 list StringMap.t; > - i_uefi : bool; > + i_uefi : string list option; I think what you really want is for the type to be "string list" (not option), and for empty list...

This patch is just for discussion. There are still a couple of issues that I'm trying to fix. One is that all of the test guests I have, even ones with static IPs, have multiple interfaces, some using DHCP, so the conditions for adding the Powershell script don't kick in. This makes testing very awkward. However a bigger issue is that I think the premise is wrong. In some registries

v1 was here with much discussion: https://www.redhat.com/archives/libguestfs/2018-December/msg00048.html v2: - Fix the case where there are multiple interfaces. Note this does not preserve order correctly (see patch for comment on why that is a hard problem). - Preserve name servers. This patch is still for discussion only. I'd like to see what might be done to get this upstream

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

...quot;, json_unknown_string inspect.i_package_management; + "product-name", json_unknown_string inspect.i_product_name; + "product-variant", json_unknown_string inspect.i_product_variant; + "mountpoints", JSON.Dict (json_list_of_string_string_list inspect.i_mountpoints); + "applications", JSON.List apps; + "windows-systemroot", JSON.String inspect.i_windows_systemroot; + "windows-software-hive", JSON.String inspect.i_windows_software_hive; + "windows-system-hive", JSON.String inspect.i_windows_system_hiv...

...quot;, json_unknown_string inspect.i_package_management; + "product-name", json_unknown_string inspect.i_product_name; + "product-variant", json_unknown_string inspect.i_product_variant; + "mountpoints", JSON.Dict (json_list_of_string_string_list inspect.i_mountpoints); + "applications", JSON.List apps; + "windows-systemroot", JSON.String inspect.i_windows_systemroot; + "windows-software-hive", JSON.String inspect.i_windows_software_hive; + "windows-system-hive", JSON.String inspect.i_windows_system_hiv...

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

A very miscellaneous set of cleanups to how we handle the Windows registry in virt-v2v, firstboot, and inspection code. This should all be straightforward non-controversial refactoring. Some highlights: - Add a new mllib Registry module containing various utility functions that are currently scattered all around. - Only compute the software/system hive paths once during inspection, and

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.

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