similar to: [PATCH] v2v: Support <listen type='socket'> and <listen type='none'> (RHBZ#1378022).

Support also a "socket" listen type with no explicitly specified socket (which will be generated by libvirt). Updates commit a4adf48915c0e3e7f4e8b7bbdbb5ac622da1ac58. Related to: RHBZ#1378022 --- v2v/create_libvirt_xml.ml | 4 +++- v2v/parse_libvirt_xml.ml | 4 ++-- v2v/types.ml | 5 +++-- v2v/types.mli | 2 +- 4 files changed, 9 insertions(+), 6 deletions(-)

This is just a refactoring and doesn't change the meaning of the code. --- v2v/output_libvirt.ml | 60 +++++++++++++++++++++++++-------------------------- 1 file changed, 29 insertions(+), 31 deletions(-) diff --git a/v2v/output_libvirt.ml b/v2v/output_libvirt.ml index 68af3de..d1cbaa1 100644 --- a/v2v/output_libvirt.ml +++ b/v2v/output_libvirt.ml @@ -222,46 +222,44 @@ let create_libvirt_xml

Those will be useful when making decisions about what configuration to set on output. The data is also included in --print-source so the tests are adjusted accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- test-data/phony-guests/guests.xml.in | 8 ++++++++ v2v/input_disk.ml | 2 ++ v2v/input_libvirtxml.ml | 32

Those will be useful when making decisions about what configuration to set on output. The data is also included in --print-source so the tests are adjusted accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- test-data/phony-guests/guests.xml.in | 8 ++++++++ v2v/input_disk.ml | 2 ++ v2v/input_libvirtxml.ml | 27

Those will be useful when making decisions about what configuration to set on output. The data is also included in --print-source so the tests are adjusted accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- Notes: v2: - add catch-all string-valued variants for source network and video adapter models test-data/phony-guests/guests.xml.in | 8 ++++++++

When reading a libvirt XML which has: <graphics ...> <listen type='none'/> </graphics> then just ignore it, as it is (roughly) the same as no <listen> child elements at all. This avoids a warning about an unknown listen type. --- v2v/input_libvirtxml.ml | 1 + 1 file changed, 1 insertion(+) diff --git a/v2v/input_libvirtxml.ml b/v2v/input_libvirtxml.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 importing from VMware via the libvirt driver, the libvirt driver can add an empty source bridge name: <interface type='bridge'> <mac address='00:01:02:03:04:05:06'/> <source bridge=''/> </interface> Replicate what we do on the -i ova path, and map these to "eth0", "eth1" etc. This also includes a bunch

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

On Sat, Feb 20, 2016 at 11:26:10AM +0300, Roman Kagan wrote: > In in-place mode, the decisions on which interfaces to use are made and > the source configuration is created by the outside entity. So in that > case v2v needs to look it up in the source configuraion, and try to > follow. > > For that, the source configuration is used to populate requested caps > object which

On 32 bit platforms, reading the memory values can cause some numbers to be read as negative numbers. Fix this by treating memory values as 64 bit integers throughout the parsing and calculation. --- v2v/input_libvirtxml.ml | 7 ++++--- v2v/input_ova.ml | 7 ++++--- v2v/utils.ml | 15 +++++++++++++++ 3 files changed, 23 insertions(+), 6 deletions(-) diff --git

Setting spice display if we know the libvirt guest doesn't have QXL capabilities will only make the guest slower for the user. Fallback to VNC in such a case. A typical use case is when v2v-ing a windows guest without having the windows QXL driver at hand. --- v2v/output_libvirt.ml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/v2v/output_libvirt.ml

Setting spice display if we know the libvirt guest doesn't have QXL capabilities will only make the guest slower for the user. Fallback to VNC in such a case. A typical use case is when v2v-ing a windows guest without having the windows QXL driver at hand. --- v2v/output_libvirt.ml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/v2v/output_libvirt.ml

Just refactoring, no change. --- sparsify/cmdline.ml | 49 +++++++++++++++++++++++-------------------------- 1 file changed, 23 insertions(+), 26 deletions(-) diff --git a/sparsify/cmdline.ml b/sparsify/cmdline.ml index ce2b913..bd49e71 100644 --- a/sparsify/cmdline.ml +++ b/sparsify/cmdline.ml @@ -98,6 +98,7 @@ read the man page virt-sparsify(1). let check_tmpdir = !check_tmpdir in let