similar to: [PATCH] v2v-snapshot: Improve documentation

We now always copy a guest during conversion, meaning this tool is no longer required. --- Build.PL | 2 +- MANIFEST | 2 - lib/Sys/VirtV2V.pm | 9 +- lib/Sys/VirtV2V/Connection.pm | 1 - po/POTFILES.in | 1 - snapshot/run-snapshot-locally | 43 -- snapshot/v2v-snapshot.pl | 931

virt-v2v.conf is no longer required on the command line in most circumstances. This change removes it from the command line in all examples. This change also references an optional --network parameter in all examples, as this typically will be required. --- v2v/virt-v2v.pl | 56 +++++++++++++++++++++++++++++++++--------------------- 1 files changed, 34 insertions(+), 22 deletions(-) diff

--- v2v/virt-v2v.pl | 140 ++++++++++++++++++++++++++++++++++++++++--------------- 1 files changed, 102 insertions(+), 38 deletions(-) diff --git a/v2v/virt-v2v.pl b/v2v/virt-v2v.pl index c1a4728..3559738 100755 --- a/v2v/virt-v2v.pl +++ b/v2v/virt-v2v.pl @@ -21,7 +21,6 @@ use strict; use Pod::Usage; use Getopt::Long; -#use Data::Dumper; use File::Spec; use File::stat; @@ -50,16 +49,19

Also changes command line parsing to require a pool to be specified when using libvirt output, meaning storage will always be copied. --- MANIFEST | 1 + lib/Sys/VirtV2V/Connection.pm | 74 +++++++++--------- lib/Sys/VirtV2V/Connection/LibVirt.pm | 18 +++-- lib/Sys/VirtV2V/Connection/LibVirtXML.pm | 11 ++- lib/Sys/VirtV2V/Target/LibVirt.pm

This implements the structure and most of the functionality of the initial virt-v2v tool. --- perl/lib/Sys/Guestfs/GuestOS.pm | 97 ++++ perl/lib/Sys/Guestfs/GuestOS/RedHat.pm | 506 +++++++++++++++++++++ perl/lib/Sys/Guestfs/HVSource.pm | 132 ++++++ perl/lib/Sys/Guestfs/HVSource/Xen/Linux.pm | 141 ++++++ perl/lib/Sys/Guestfs/HVTarget.pm

This patch refactors the data transfer code with several goals: * Have a common read(source)/write(target) loop so that common processing can happen in the middle of it, e.g. format change/progress bar * Provide volume metadata to transfers to allow smarter reading/writing, e.g. of sparse files * Simplify the data transfer code The patch *isn't* NFC because there are some minor behaviour

virt-v2v is capable of accessing ESXi hypervisors now. There is only one remaining use of this tool - when converting from Xen hypervisors over ssh which are using host block devices for storage. --- v2v/virt-v2v-copy-to-local.pod | 27 ++------------------------- 1 file changed, 2 insertions(+), 25 deletions(-) diff --git a/v2v/virt-v2v-copy-to-local.pod b/v2v/virt-v2v-copy-to-local.pod index

Previously, only the LibVirtXML connection translated network and bridge names in imported metadata. This change moves this functionality in Converter, making it available to LibVirt connections as well. At the same time, the format of the config file is switched to XML. The primary driver for this is that the allowable syntax of a foreign network/bridge name is not known. Rather than create a

This change replaces all direct usage of a Sys::Guestfs object in virt-v2v with a Sys::VirtV2V::GuestfsHandle proxy object. The proxy does 3 things: * Holds handle initialisation code * Adds the ability to explicitly close the handle * Adds the ability to register a callback to be executed before close The cleanup code in Sys::VirtV2V::Config is updated to use the new callback mechanism.

Previously, only the LibVirtXML connection translated network and bridge names in imported metadata. This change moves this functionality in Converter, making it available to LibVirt connections as well. At the same time, the format of the config file is switched to XML. The primary driver for this is that the allowable syntax of a foreign network/bridge name is not known. Rather than create a

It has frequently tripped us up that on RHEL / Fedora, installing the right set of libvirt RPMs (such as the one pulled in by "libvirt-daemon-kvm") does not result in an immediately running libvirt system instance. Document the need, and the simplest method, for starting libvirt up manually. Thanks: Daniel Berrang? Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024

You can now use -o rhv (-o rhev is supported for compatibility). --- v2v/Makefile.am | 8 +- v2v/OVF.ml | 30 +++---- v2v/OVF.mli | 2 +- v2v/changeuid.mli | 4 +- v2v/cmdline.ml | 12 +-- v2v/convert_windows.ml

It has frequently tripped us up that on RHEL / Fedora, installing the right set of libvirt RPMs (such as the one pulled in by "libvirt-daemon-kvm") does not result in an immediately running libvirt system instance. Document the need, and the simplest method, for starting libvirt up manually. Thanks: Daniel Berrang? Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024

You can now use -o rhv (-o rhev is supported for compatibility). --- p2v/gui.c | 5 +- p2v/virt-p2v.pod | 13 ++- v2v/Makefile.am | 8 +- v2v/OVF.ml | 30 +++---- v2v/OVF.mli | 2 +- v2v/changeuid.mli

See the new man page virt-v2v-test-harness(1) added in this commit for details of this library/harness, and also how to get the external tests. --- .gitignore | 6 + Makefile.am | 3 + README | 2 + configure.ac | 8 +- po-docs/ja/Makefile.am

On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: > It has frequently tripped us up that on RHEL / Fedora, installing the > right set of libvirt RPMs (such as the one pulled in by > "libvirt-daemon-kvm") does not result in an immediately running libvirt > system instance. Document the need, and the simplest method, for starting > libvirt up manually. >

On 6/28/23 12:05, Richard W.M. Jones wrote: > On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: >> It has frequently tripped us up that on RHEL / Fedora, installing the >> right set of libvirt RPMs (such as the one pulled in by >> "libvirt-daemon-kvm") does not result in an immediately running libvirt >> system instance. Document the need, and the

On Wed, Jun 28, 2023 at 01:31:53PM +0200, Laszlo Ersek wrote: > On 6/28/23 12:05, Richard W.M. Jones wrote: > > On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: > >> It has frequently tripped us up that on RHEL / Fedora, installing the > >> right set of libvirt RPMs (such as the one pulled in by > >> "libvirt-daemon-kvm") does not result

Hi Richard, That didn't resolve the issue. Now I'm getting the following error. Please advice. *[root@kvm16 ~]#* virt-v2v -ic esx://10.16.32.13/?no_verify=1 yardqakvm -o rhev -os 10.16.32.16:/vm-images/export_domain --network rhevm libvirt error code: 42, message: Domain not found: No domain with name 'yardqakvm'

On Tue, Sep 1, 2020 at 4:56 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > We previously implicitly supported writing to block devices instead of > local files, but there were several problems: > > * Block devices could be deleted, especially if virt-v2v failed during > a conversion. > > * Block devices could be overwritten by a file with the same name, >