similar to: [v2v PATCH] -i ova: use Xml.parse_file for the OVF

Mixing the XML parsing with the other functions of this module made it very hard to understand. Splitting the XML parsing into another module simplifies the flow considerably. This is just code refactoring and should not affect the semantics. --- v2v/Makefile.am | 2 + v2v/input_ova.ml | 323 +++++++++++---------------------------------- v2v/parse_ovf_from_ova.ml | 226

Read the MAC address of the network interfaces from the <rasd:Address> tag of the OVF. This seems to be one of the possible ways used in OVFs. --- v2v/parse_ovf_from_ova.ml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/v2v/parse_ovf_from_ova.ml b/v2v/parse_ovf_from_ova.ml index fe8228dcc..4ee6bc901 100644 --- a/v2v/parse_ovf_from_ova.ml +++

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

When parsing OVA files we have to work backwards to whether the original VMware object was a network or a bridge. It seems as if the presence of <rasd:Connection> is sufficient. I dropped the use of <rasd:ElementName> since it is literally just an internal name for the network element, and is not significant in how the network is used. Also update documentation because you must use

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

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

A couple of patches cleaning up the -i ova code. These are both just refactoring (or should be at any rate). The second patch is best viewed with 'git show -w' to exclude whitespace changes. Rich.

Instead of using ‘xpath_(string|int|int64)_default’ we can write the equivalent code using ‘Option.default’. This is not quite so concise, but may be easier to understand. eg: xpath_int_default xctx "xpath_expr" 10 -> Option.default 10 (xpath_int xctx "xpath_expr") --- common/mltools/xpath_helpers.ml | 12 ------------ common/mltools/xpath_helpers.mli | 6 ------

https://bugzilla.redhat.com/show_bug.cgi?id=1570407 This turned into quite an in-depth refactoring of how we handle OVAs. It also fixes a potential security issue. 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

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

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

https://bugzilla.redhat.com/show_bug.cgi?id=1508874 Also avoids a warning. Rich.

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 ...

Provide a helper function rather than having callers read the file and then parse the string. --- mllib/xml.ml | 4 ++++ mllib/xml.mli | 3 +++ 2 files changed, 7 insertions(+) diff --git a/mllib/xml.ml b/mllib/xml.ml index e67245188..78e75b8f2 100644 --- a/mllib/xml.ml +++ b/mllib/xml.ml @@ -67,6 +67,10 @@ let parse_memory xml = Gc.finalise free_docptr docptr; docptr +let parse_file

This is just a bit of preparatory refactoring ... Rich.

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

v1 was here: https://www.redhat.com/archives/libguestfs/2017-September/msg00135.html This is a more complete evolution of the earlier patch. It replaces most important uses of Str with PCRE throughout the code. It also extends the bindings with some useful features like case-insensitive regexps. The main places I *didn't* touch are the generator (GObject uses Str extensively); and

v1: https://www.redhat.com/archives/libguestfs/2017-September/msg00135.html v2: https://www.redhat.com/archives/libguestfs/2017-September/msg00158.html v3 is almost identical to v2, but I have added 4 extra commits to almost finish the job of replacing Str everywhere possible (note it's not possible to replace Str in common/mlstdutils or the generator because those are pure OCaml). As