similar to: [PATCH] Remove virt-v2v from libguestfs.git repo

We've split off virt-v2v components into a separate repository: http://gitorious.org/virt-v2v/ (Previously they were part of the libguestfs repository). So virt-v2v stuff will disappear from the libguestfs repository shortly. You can get it from the link above instead. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual

Allows virt-v2v to be compiled against the libguestfs build directory. --- v2v/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/v2v/Makefile.am b/v2v/Makefile.am index 2a196d45d..104420d13 100644 --- a/v2v/Makefile.am +++ b/v2v/Makefile.am @@ -197,6 +197,7 @@ virt_v2v_CPPFLAGS = \ -I$(top_srcdir)/lib virt_v2v_CFLAGS = \ $(WARN_CFLAGS) $(WERROR_CFLAGS) \ +

We have phony tools for v2v tests, introduced with commit c1af1ba32f126b7be275bcc8cd4ea4e5af27a88e; make use of it also in tests related to v2v outside the v2v directory. --- p2v/test-virt-p2v.sh | 6 +----- tests/regressions/rhbz1232192.sh | 6 +----- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/p2v/test-virt-p2v.sh b/p2v/test-virt-p2v.sh index 8c3731c..540d2fd

On Sun, Nov 17, 2019 at 7:03 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Sun, Nov 17, 2019 at 06:07:48PM +0200, Nir Soffer wrote: > > Looks like virt-v2v cannot be built now, since it requires non-existing version > > of libguestfs-devel. > > > > Based on (no README or any instructions in virt-v2v) > >

Traditionally if you did live migration (KVM to KVM), you had to ensure that cache=none was set on all disks of the guest up front. This was because of quirks in how NFS works (I think the close-to-open consistency and the fact that during live migration both qemus have the file open), and we had to assume the worst case that a guest might be backed by NFS. Because of this when virt-v2v converts

There were two related bugs in the virt-v2v error messages when source inspection failed. Firstly it would print the message about running 'virt-v2v -v -x' twice: virt-v2v: error: inspection could not detect the source guest (or physical machine). Assuming that you are running virt-v2v/virt-p2v on a source which is supported (and not, for example, a blank disk), then this should

Test: - Bad SHA1 sum - Bad SHA256 sum - Invalid lines in manifest (x2) - Good checksum and manifest These tests were originally written by Tomáš Golembiovský. All I have done is to integrate them into the virt-v2v test suite. --- .gitignore | 1 + v2v/Makefile.am | 22 +++++++- v2v/test-v2v-i-ova-bad-sha1.sh | 66

v1 was here: https://www.redhat.com/archives/libguestfs/2018-June/msg00047.html v1 -> v2: - Add a regular expression in the virt-v2v modules code too. - - - I was planning a much more ambitious second version of this patch (half written too) which had: virt-v2v --describe-modules that listed a big chunk of XML which virt-p2v would parse. These would include the names of the

On Saturday, 12 November 2016 16:37:53 CET Tomáš Golembiovský wrote: > The virt-v2v behaviour for OVA input now depends on QEMU version > available. The tests affected by this now have two *.expect files and > the expected result now also depends on the QEMU used. > > Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> > --- This IMHO should be part of patch #4 as

Some ova files have their ovf and other files inside a folder rather than at the root of the tarball. Consider the paths relative to the ovf file to cover this case too. --- v2v/Makefile.am | 1 + v2v/input_ova.ml | 3 +- v2v/test-v2v-i-ova-subfolders.sh | 88 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 91 insertions(+), 1 deletion(-) create mode

On Tue, Apr 07, 2020 at 01:25:02PM +0200, Pino Toscano wrote: > The important thing is still that that you need to have space for the > temporary files somewhere: be it /var/tmp, /mnt/scratch, whatever. > Because of this, and the fact that usually containers are created > fresh, the cache of the supermin appliance starts to make little sense, > and then a very simple solution is to

I have a Fedora 24 system I can already get this working for most OVA files, just the BSD and atomic ones weren't recognized. Assuming my version of virt-v2v is just old, I installed rawhide on a different system and tried with virt-v2v-1.37.8-1.fc27.x86_64 and now its having another problem. Is there a known version of virt-v2v I should be using? Here is the output from the rawhide attempt

On Tue, Jun 12, 2018 at 12:13:32PM +0200, Pino Toscano wrote: > On Tuesday, 12 June 2018 11:27:56 CEST Richard W.M. Jones wrote: > > The new ‘-o rhv-upload’ output mode contains a '-' character in the > > name, but the regular expression which matched the output of the > > virt-v2v command did not recognize '-' as a valid character. It ended > > up

In commit 08f82f2e3d6975b72340dd59f438862e152a15ef we increased the memory size to 800MB (on x86) so that the semodule command would work. However it has been discovered that another SELinux command takes large amounts of RAM (setfiles during the SELinux relabel step). Therefore increase the memory size again, this time to 2000MB. --- v2v/v2v.ml | 2 +- v2v/virt-v2v.pod | 2 +- 2 files

The test checks that the newly introduced --block-driver option doesn't break conversion. Basically its logic somewhat repeats test-v2v-i-disk.sh and test-v2v-in-place.sh, but with the new option being set. The checks it performs are: 1. Run disk-sourced conversion (-i disk) based on the phony windows.img and check that it completes (i.e. produces converted disk and corresponding

Trivial fix. We really need a regression test for all v2v inpus related to nbdkit. There is actually nothing at all at the moment. Of course if it was easy to test inputs over the network from a ‘make check’ rule then we'd be doing it already. I thought about adding something like a ‘-it file’ option which would use nbdkit-file-plugin for test only. However I'm rather cautious about

Followup of commit f190e08d85556dac293ef15bfeee38e54471570f. --- v2v/Makefile.am | 2 ++ v2v/test-v2v-o-json.sh | 58 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+) create mode 100755 v2v/test-v2v-o-json.sh diff --git a/v2v/Makefile.am b/v2v/Makefile.am index 39511022e..1c37d20b4 100644 --- a/v2v/Makefile.am +++ b/v2v/Makefile.am @@ -468,6 +468,7 @@ TESTS

On Thu, Apr 02, 2020 at 05:51:32PM +0200, Pino Toscano wrote: > On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote: > > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > > > Previously we placed large files in g#get_cachedir () (usually > > > > /var/tmp).

On Tue, Apr 07, 2020 at 02:33:20PM +0200, Pino Toscano wrote: > On Tuesday, 7 April 2020 14:18:47 CEST Richard W.M. Jones wrote: > > On Tue, Apr 07, 2020 at 01:25:02PM +0200, Pino Toscano wrote: > > > The important thing is still that that you need to have space for the > > > temporary files somewhere: be it /var/tmp, /mnt/scratch, whatever. > > > Because of

On Wednesday, 7 December 2016 10:02:49 CET Richard W.M. Jones wrote: > Support for RHEV with RHEL 6 nodes required us to output the old style > qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been > supported as a RHEV node type. Since RHV 4.1, compat=1.1 is > supported. (Support for compat=1.1 is uncertain in RHV 4.0 even on > RHEL 7 nodes.) > > There are